From frnkblk at iname.com  Wed Jun  1 00:40:53 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Tue, 31 May 2011 23:40:53 -0500
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com>
References: <4DDFA7A6.105@arin.net>	<BANLkTik+-2YZVyikgdnojvw7-2yiMS4f1w@mail.gmail.com>	<C46FA11C-306B-494F-A287-81824CEB90F9@delong.com>	<20110529191506.GA28505@panix.com>	<B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>	<20110530021405.GA22407@panix.com>	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>	<013401cc1e82$dfddd260$9f997720$@iname.com>	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<4DE516B6.6080609@matthew.at>
	<82A34E79-64E9-4AAC-BDB2-0CEE598A88F7@delong.com>
	<4DE525B1.8030704@matthew.at>
	<29986C0D-0F99-4F95-AB2E-A4228F778FFC@delong.com>
Message-ID: <016301cc2016$171c9420$4555bc60$@iname.com>

It would be even more preferable that the /20 not be broken into /24's, but
kept whole.  I don't think we need to modify policy to do that -- I'm hoping
that the market will price that consideration into the transaction.  Someone
who needs a /20 will likely prefer a whole /20 than a collection of smaller
pieces, not only for their own documentation, but it's less deals for the
buyer to transact and less risk that the address pace would be filtered from
route announcements.   So while it may seem from a volume perspective that a
/20 would be cheaper per address, it may end up being more expensive.

Frank

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, May 31, 2011 4:11 PM
To: matthew at matthew.at
Cc: frnkblk at iname.com; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

On May 31, 2011, at 10:30 AM, Matthew Kaufman wrote:
<snip>

> Back to my original point, the right answer is somewhere between "all
blocks may be broken up into /24-sized pieces" and "all blocks must not be
broken up any further than the original ARIN allocation size"... and that's
the *only* way to prevent table growth, as *who* gets the blocks is
completely irrelevant for that point.
> 

Yes and no. The right answer is to allow transfers that disaggregate only to
the
extent absolutely necessary to meet a given recipient's need. If they need
a /20, then, transferring a /20 is vastly preferable to
transferring 16 disjoint /24s. On the other hand, 16 organizations, each of
whom need a /24 have no better solution than to transfer 16 /24s, whether
they come from the same source or not.

<snip>

Owen




From bensons at queuefull.net  Thu Jun  2 01:47:46 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 2 Jun 2011 00:47:46 -0500
Subject: [arin-ppml] RIR distribution of legacy addresses
References: <4DE70B8F.3070903@apnic.net>
Message-ID: <B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>

Hi, John.

The message forwarded below was sent to the APNIC sig-policy mailing list this evening (or morning, as it may be in AP region).  It seems to describe APNIC behavior regarding redistribution of "historical resources", and indicates that APNIC does not redistribute ERX Legacy address resources.  Apparently, from the text of this message, the APNIC view of these address resources is that they should be returned to IANA.

Can you please help educate me on ARIN's view of this topic?  In particular, I would appreciate if you can describe how ARIN process compares with APNIC process, with regard to the redistribution of Legacy address resources.  If there are differences, then further explanation of the rationale would be appreciated as well.

Thanks,
-Benson


Begin forwarded message:

> From: Sanjaya <sanjaya at apnic.net>
> Date: June 1, 2011 11:03:27 PM CDT
> To: "sig-policy at apnic.net" <sig-policy at apnic.net>
> Subject: Re: [sig-policy] Call for policy proposals for APNIC 32
> 
> Hi Randy,
> 
> There are 3 types of historical resources as defined in section 2.2 of 
> the document:
> 
>     http://www.apnic.net/policy/historical-resource-policies#2.2
> 
> APNIC redistributes the following types of reclaimed historical 
> resources, which are listed in IANA as being delegated to APNIC:
> 
>     * Registrations transferred to APNIC as part of the AUNIC to APNIC
>       migration, and
>     * Historical APNIC resources (delegated by APNIC before the
>       establishment of a membership structure)
> 
> We do not redistribute reclaimed historical resources of the following 
> type as they are listed in IANA as LEGACY:
> 
>     * Registrations transferred as part of the Early Registration
>       Transfer (ERX) project
> 
> APNIC is holding these resources pending its return to IANA subject to 
> an agreed mechanism for doing so.
> 
> Regards,
> Sanjaya

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

From bensons at queuefull.net  Thu Jun  2 02:59:23 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 2 Jun 2011 01:59:23 -0500
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
References: <4DDFA7A6.105@arin.net>
	<BANLkTik+-2YZVyikgdnojvw7-2yiMS4f1w@mail.gmail.com>
	<C46FA11C-306B-494F-A287-81824CEB90F9@delong.com>
	<20110529191506.GA28505@panix.com>
	<B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>
	<20110530021405.GA22407@panix.com>
	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>
	<013401cc1e82$dfddd260$9f997720$@iname.com>
	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>
	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
Message-ID: <E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>

Hi, Bill.

On May 31, 2011, at 12:18 PM, William Herrin wrote:

> If that's the consensus goal then put together some verbiage for 8.3
> that hits these five points:
> 
> a. Any registrant may offer an entire ARIN IPv4 address block
> registration for transfer without restriction.
> 
> b. Any registrant may offer part of an ARIN IPv4 address block
> registration with a prefix no longer than /24 for transfer. /8 through
> /24 allowed, /25 through /32 prohibited.
> 
> c. Transfers under 8.3 are only received as fulfillment of an ordinary
> section 4 request following all ordinary policies and procedures under
> section 4. To the extent that turns out to obstruct reasonable
> behavior, we'll fix it in section 4.
> 
> d. Any registrant may receive any number of address blocks from (a) as
> needed to fulfill their ARIN-approved section 4 request.
> 
> e. Any registrant may receive no more than $N discontiguous address
> blocks per $UNIT_TIME from (b) as needed to fulfill their approved
> section 4 request. So if you buy a partial fill, shop wisely.

It seems to me that disaggregation in the routing table will be dominated by the source of an address block rather than a recipient.  If somebody disaggregates a very large block, in order to parcel it out or because they can only spare a part of it, then multiple new routes will appear from the original source even if the new recipient only announces a single route.  For example, if I have a /16 announcement in BGP today and I want to sell a /19, then I have to start announcing a /17, /18, and /19 to cover the retained space - while my buyer starts announcing a /19 prefix that I transfer to him.  That results in 4 routes in BGP where there used to be 1.

Clearly, limiting what people can receive will have an effect on disaggregation - reducing the number of blocks allowed per-recipient-per-time-period will encourage buyers to acquire as much as they can afford as a single block, rather than many small blocks over time.  That's good.  But just as disaggregation occurs today at the "whim" of the announcing AS, it will continue to do so under the regime described above.

ARIN could attempt to limit this by only accepting disaggregation in Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course, that means holders of very large blocks will have a hard time selling their unused space - they may need to disaggregate by larger values of N in order to meet demand under a "justified need" regime - so some kind of sliding scale might be useful, based on original block size.  Otherwise, for a uniform value of N this policy would limit the supply of address blocks (and probably drive up prices).

I'm personally inclined to view this (+N idea) as market distorting, and probably ineffective since ARIN doesn't control BGP anyways. But I offer it for your consideration, regardless.

Cheers,
-Benson



From owen at delong.com  Thu Jun  2 03:14:29 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 00:14:29 -0700
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>
References: <4DDFA7A6.105@arin.net>
	<BANLkTik+-2YZVyikgdnojvw7-2yiMS4f1w@mail.gmail.com>
	<C46FA11C-306B-494F-A287-81824CEB90F9@delong.com>
	<20110529191506.GA28505@panix.com>
	<B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>
	<20110530021405.GA22407@panix.com>
	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>
	<013401cc1e82$dfddd260$9f997720$@iname.com>
	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>
	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
	<E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>
Message-ID: <386C8A2C-9148-4941-8142-F45D165AC363@delong.com>


On Jun 1, 2011, at 11:59 PM, Benson Schliesser wrote:

> Hi, Bill.
> 
> On May 31, 2011, at 12:18 PM, William Herrin wrote:
> 
>> If that's the consensus goal then put together some verbiage for 8.3
>> that hits these five points:
>> 
>> a. Any registrant may offer an entire ARIN IPv4 address block
>> registration for transfer without restriction.
>> 
>> b. Any registrant may offer part of an ARIN IPv4 address block
>> registration with a prefix no longer than /24 for transfer. /8 through
>> /24 allowed, /25 through /32 prohibited.
>> 
>> c. Transfers under 8.3 are only received as fulfillment of an ordinary
>> section 4 request following all ordinary policies and procedures under
>> section 4. To the extent that turns out to obstruct reasonable
>> behavior, we'll fix it in section 4.
>> 
>> d. Any registrant may receive any number of address blocks from (a) as
>> needed to fulfill their ARIN-approved section 4 request.
>> 
>> e. Any registrant may receive no more than $N discontiguous address
>> blocks per $UNIT_TIME from (b) as needed to fulfill their approved
>> section 4 request. So if you buy a partial fill, shop wisely.
> 
> It seems to me that disaggregation in the routing table will be dominated by the source of an address block rather than a recipient.  If somebody disaggregates a very large block, in order to parcel it out or because they can only spare a part of it, then multiple new routes will appear from the original source even if the new recipient only announces a single route.  For example, if I have a /16 announcement in BGP today and I want to sell a /19, then I have to start announcing a /17, /18, and /19 to cover the retained space - while my buyer starts announcing a /19 prefix that I transfer to him.  That results in 4 routes in BGP where there used to be 1.
> 
There are two possibilities...

1: The source wants to disaggregate it because they don't want to renumber to aggregate their available space.

I agree this should be avoided to the extent possible.

2: The recipient wants to purchase smaller disjoint blocks because:
	a)	They are cheaper
	b)	They can find sources for them sooner
	c)	They are otherwise easier to come by than a full aggregate

In the case of 1, this can be prevented by restricting transactions to a single aggregate and restricting any given
recipient to one sub-aggregate transfer per n-unit of time (currently proposed at 1 year).

Disaggregation outside of the aspects covered by that provision would be the result of dividing the address space
up to multiple organizations with smaller needs and would be akin to the deaggregation that ARIN does when issuing
new space. While I think it would be better to preserve aggregates, the consensus of the community as we were
developing the current 8.3 was that doing so would be overly restrictive, so, in this respect, I bow to the will of the
majority and am attempting to preserve this capability.

Quite frankly, if you sell a /19, you really don't have to announce the /17, /18, and /19. You could just continue to
announce the /16 knowing that the recipient's /19 would override your /16 announcement.

There is little or no benefit to you announcing the /17, /18, and /19 instead of the /16.

> Clearly, limiting what people can receive will have an effect on disaggregation - reducing the number of blocks allowed per-recipient-per-time-period will encourage buyers to acquire as much as they can afford as a single block, rather than many small blocks over time.  That's good.  But just as disaggregation occurs today at the "whim" of the announcing AS, it will continue to do so under the regime described above.
> 

I think this is somewhat inevitable and not really an address policy matter.

> ARIN could attempt to limit this by only accepting disaggregation in Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course, that means holders of very large blocks will have a hard time selling their unused space - they may need to disaggregate by larger values of N in order to meet demand under a "justified need" regime - so some kind of sliding scale might be useful, based on original block size.  Otherwise, for a uniform value of N this policy would limit the supply of address blocks (and probably drive up prices).
> 

We have long since examined the idea of fixed values of N per unit time deaggregation as you propose above and determined that it was beyond
dysfunctional. As such, I think that rehashing it here really isn't worth while. I realize this discussion occurred before you were active on PPML,
but, if you want to review it, I suggest reviewing the archives for 2008-2, 2008-15, and 2009-1.

> I'm personally inclined to view this (+N idea) as market distorting, and probably ineffective since ARIN doesn't control BGP anyways. But I offer it for your consideration, regardless.
> 

Understood, and, in this case, I actually agree with you.

Owen



From jcurran at arin.net  Thu Jun  2 08:13:03 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 2 Jun 2011 12:13:03 +0000
Subject: [arin-ppml] RIR distribution of legacy addresses
In-Reply-To: <B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
References: <4DE70B8F.3070903@apnic.net>
	<B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
Message-ID: <97DD40F6-3441-4015-9804-5126AAF04774@arin.net>

On Jun 2, 2011, at 1:47 AM, Benson Schliesser wrote:

> Hi, John.
> 
> The message forwarded below was sent to the APNIC sig-policy mailing list this evening (or morning, as it may be in AP region).  It seems to describe APNIC behavior regarding redistribution of "historical resources", and indicates that APNIC does not redistribute ERX Legacy address resources.  Apparently, from the text of this message, the APNIC view of these address resources is that they should be returned to IANA.

Benson - 

That is not a correct summary of the "APNIC view of these address resources", i.e.
if you read the full APNIC sig-policy thread on this topic, you will see that Sanjaya
from APNIC earlier stated:

" ? 4,686,848 addresses (approximately 0.28 x /8) are historical address 
     blocks returned to APNIC, which are being held until there is clear  
     guidance from global policy. "

ARIN would also welcome global policy guidance in handling of returned address
blocks (as I have stated on record at several recent RIR meetings).  We also have 
local policy development active as well in this area, i..e, ARIN-2011-6.

Traditionally, all address blocks returned to ARIN smaller than /8 have been made
available for use in the ARIN region, and all address blocks of /8 returned to ARIN 
have been returned to IANA.  Note - there is also an RIR-agreed procedure at the
IANA which is applicable to the return of legacy /8 allocations - 
<http://www.iana.org/procedures/updating-legacy-classa.html>

FYI,
/John

John Curran
President and CEO
ARIN



From rbf+arin-ppml at panix.com  Thu Jun  2 10:08:10 2011
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Thu, 2 Jun 2011 09:08:10 -0500
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <386C8A2C-9148-4941-8142-F45D165AC363@delong.com>
References: <B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>
	<20110530021405.GA22407@panix.com>
	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>
	<013401cc1e82$dfddd260$9f997720$@iname.com>
	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>
	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
	<E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>
	<386C8A2C-9148-4941-8142-F45D165AC363@delong.com>
Message-ID: <20110602140810.GA11520@panix.com>

On Thu, Jun 02, 2011 at 12:14:29AM -0700, Owen DeLong wrote:
> 
> Quite frankly, if you sell a /19, you really don't have to announce
> the /17, /18, and /19. You could just continue to announce the /16
> knowing that the recipient's /19 would override your /16
> announcement.

Would, say, your employer go along with that?  If I have a /16 and sell
a /19 from it, I'll end up with a /17, /18, and /19 in ARIN's records. 
If I then seek service from HE, and tell them I want to announce the
/16, will they allow it even though there's no record of that /16
being allocated to me?  

What would the standard be?  A customer can announce it if they provide
documentation that they once held the /16 and still hold part of it? 
Or would you allow anyone to announce a /16 if any part of it were
assigned to them in whois?  If two or more portions of it were assigned
to them in whois?  If more than half of it were assigned to them? 
(Obviosuly, each provider gets to make their own decision here.  I'm
just wondering what you'd suggest their policies should be.)

Certainly I agree that what you propose would work, but it would seem
cumbersome to implement in practice, especially for any orgnaization
seeking service from a new upstream after the sale had occurred.

And, of course, it all falls apart under RPKI.

> There is little or no benefit to you announcing the /17, /18, and /19
> instead of the /16.

As long as the other /19 is continuously announced.  One downside of
announcing the /16 is you get traffic for the /19 you sold whenever
that /19 isn't being announced by its new holder.

     -- Brett


From bensons at queuefull.net  Thu Jun  2 10:51:15 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 2 Jun 2011 09:51:15 -0500
Subject: [arin-ppml] RIR distribution of legacy addresses
In-Reply-To: <97DD40F6-3441-4015-9804-5126AAF04774@arin.net>
References: <4DE70B8F.3070903@apnic.net>
	<B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
	<97DD40F6-3441-4015-9804-5126AAF04774@arin.net>
Message-ID: <F7A45F92-71FB-44D2-9147-74C16EFBA1A8@queuefull.net>

Hi, John.

Thanks for your response.

On Jun 2, 2011, at 7:13 AM, John Curran wrote:

>> ...
>> indicates that APNIC does not redistribute ERX Legacy address resources.  Apparently, from the text of this message, the APNIC view of these address resources is that they should be returned to IANA.
> ...
> That is not a correct summary of the "APNIC view of these address resources", i.e.
> if you read the full APNIC sig-policy thread on this topic, you will see that Sanjaya
> from APNIC earlier stated:
> 
> " ? 4,686,848 addresses (approximately 0.28 x /8) are historical address 
>     blocks returned to APNIC, which are being held until there is clear  
>     guidance from global policy. "

I have also sent a note to Sanjaya asking for clarification, in case I misunderstand.  But my comment was in response to his statement that "We do not redistribute reclaimed historical resources ... transferred as part of the Early Registration Transfer (ERX) project[.]  APNIC is holding these resources pending its return to IANA subject to an agreed mechanism for doing so."  This statement seems to support my conclusion, but I await Sanjaya's response to be sure.

> Traditionally, all address blocks returned to ARIN smaller than /8 have been made
> available for use in the ARIN region, and all address blocks of /8 returned to ARIN 
> have been returned to IANA.  Note - there is also an RIR-agreed procedure at the
> IANA which is applicable to the return of legacy /8 allocations - 
> <http://www.iana.org/procedures/updating-legacy-classa.html>

Just to clarify: what I understand from your comment is that, while APNIC will not redistribute any ERX Legacy blocks, ARIN will redistribute </8 sized blocks and return /8 blocks to IANA.  Is this correct?  If so, can you comment on the source / root cause of the different procedures?

Thanks,
-Benson



From kkargel at polartel.com  Thu Jun  2 11:25:53 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 2 Jun 2011 10:25:53 -0500
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <386C8A2C-9148-4941-8142-F45D165AC363@delong.com>
References: <4DDFA7A6.105@arin.net>
	<BANLkTik+-2YZVyikgdnojvw7-2yiMS4f1w@mail.gmail.com>
	<C46FA11C-306B-494F-A287-81824CEB90F9@delong.com>
	<20110529191506.GA28505@panix.com>
	<B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>
	<20110530021405.GA22407@panix.com>
	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>
	<013401cc1e82$dfddd260$9f997720$@iname.com>
	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>
	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
	<E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>
	<386C8A2C-9148-4941-8142-F45D165AC363@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD289F0330A5@MAIL1.polartel.local>



 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, June 02, 2011 2:14 AM
> To: Benson Schliesser
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM
> 8.3
> 
[Much snippage to comment on a single point]
> 
> Quite frankly, if you sell a /19, you really don't have to announce the
> /17, /18, and /19. You could just continue to
> announce the /16 knowing that the recipient's /19 would override your /16
> announcement.

The only real reason not to advertise the /16 is that if their /19 networks (read BGP sessions) go completely down you *could* then receive and pay for traffic *to* their netblock, even if you blackhole it.  This could affect your peak use (billing statistic) or possibly create a DoS type situation at your edge if your pipe/router is not sized to accommodate the resultant aggregate traffic or if their network is under a DDoS attack.  

This will probably not be an issue for anyone actually utilizing a /17.  I am just nit-picking.

Kevin


> 
> There is little or no benefit to you announcing the /17, /18, and /19
> instead of the /16.
> 
> > Clearly, limiting what people can receive will have an effect on
> disaggregation - reducing the number of blocks allowed per-recipient-per-
> time-period will encourage buyers to acquire as much as they can afford as
> a single block, rather than many small blocks over time.  That's good.
> But just as disaggregation occurs today at the "whim" of the announcing
> AS, it will continue to do so under the regime described above.
> >
> 
> I think this is somewhat inevitable and not really an address policy
> matter.
> 
> > ARIN could attempt to limit this by only accepting disaggregation in
> Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course,
> that means holders of very large blocks will have a hard time selling
> their unused space - they may need to disaggregate by larger values of N
> in order to meet demand under a "justified need" regime - so some kind of
> sliding scale might be useful, based on original block size.  Otherwise,
> for a uniform value of N this policy would limit the supply of address
> blocks (and probably drive up prices).
> >
> 
> We have long since examined the idea of fixed values of N per unit time
> deaggregation as you propose above and determined that it was beyond
> dysfunctional. As such, I think that rehashing it here really isn't worth
> while. I realize this discussion occurred before you were active on PPML,
> but, if you want to review it, I suggest reviewing the archives for 2008-
> 2, 2008-15, and 2009-1.
> 
> > I'm personally inclined to view this (+N idea) as market distorting, and
> probably ineffective since ARIN doesn't control BGP anyways. But I offer
> it for your consideration, regardless.
> >
> 
> Understood, and, in this case, I actually agree with 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 jcurran at arin.net  Thu Jun  2 12:07:58 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 2 Jun 2011 16:07:58 +0000
Subject: [arin-ppml] RIR distribution of legacy addresses
In-Reply-To: <F7A45F92-71FB-44D2-9147-74C16EFBA1A8@queuefull.net>
References: <4DE70B8F.3070903@apnic.net>
	<B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
	<97DD40F6-3441-4015-9804-5126AAF04774@arin.net>
	<F7A45F92-71FB-44D2-9147-74C16EFBA1A8@queuefull.net>
Message-ID: <642918D2-2314-4998-8468-F211051FDFA9@arin.net>

On Jun 2, 2011, at 10:51 AM, Benson Schliesser wrote:
> 
> Just to clarify: what I understand from your comment is that, while APNIC will not redistribute any ERX Legacy blocks, ARIN will redistribute </8 sized blocks and return /8 blocks to IANA.  Is this correct?

I can't speak to APNIC's procedures.  With respect to ARIN, your summary 
refers to the future, and I have only stated that our historic practice 
has been to redistribute </8 sized blocks and to return /8 blocks to IANA.  
I do not know about future practice; that is subject to the policies which
are developed in the ARIN region and guidance from the ARIN Board. 

With respect to ARIN's historic practices in this area, I note that when 
InterNIC registry services were transferred from NSI to ARIN, we continued 
to use existing practices, and since space was being allocated to RIRs at 
the /8 boundary, return of address blocks smaller than /8 to IANA did not 
actually make space available for reuse for another RIR.  

FYI,
/John 

John Curran
President and CEO
ARIN



From jeffrey.lyon at blacklotus.net  Thu Jun  2 14:35:23 2011
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Thu, 2 Jun 2011 14:35:23 -0400
Subject: [arin-ppml] RIR distribution of legacy addresses
In-Reply-To: <642918D2-2314-4998-8468-F211051FDFA9@arin.net>
References: <4DE70B8F.3070903@apnic.net>
	<B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
	<97DD40F6-3441-4015-9804-5126AAF04774@arin.net>
	<F7A45F92-71FB-44D2-9147-74C16EFBA1A8@queuefull.net>
	<642918D2-2314-4998-8468-F211051FDFA9@arin.net>
Message-ID: <BANLkTimA2hyiW1_1OanOhY5Y8U5gw-2mLQ@mail.gmail.com>

On Thu, Jun 2, 2011 at 12:07 PM, John Curran <jcurran at arin.net> wrote:
> On Jun 2, 2011, at 10:51 AM, Benson Schliesser wrote:
>>
>> Just to clarify: what I understand from your comment is that, while APNIC will not redistribute any ERX Legacy blocks, ARIN will redistribute </8 sized blocks and return /8 blocks to IANA. ?Is this correct?
>
> I can't speak to APNIC's procedures. ?With respect to ARIN, your summary
> refers to the future, and I have only stated that our historic practice
> has been to redistribute </8 sized blocks and to return /8 blocks to IANA.
> I do not know about future practice; that is subject to the policies which
> are developed in the ARIN region and guidance from the ARIN Board.
>
> With respect to ARIN's historic practices in this area, I note that when
> InterNIC registry services were transferred from NSI to ARIN, we continued
> to use existing practices, and since space was being allocated to RIRs at
> the /8 boundary, return of address blocks smaller than /8 to IANA did not
> actually make space available for reuse for another RIR.
>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

John,

How would it ever have made sense to return a /8 at all? It has been
known for years that IPv4 will be depleted and that our need will far
outlast supply.

Is this some type of horse trading or are you just genuinely that nice
and equitable?

-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions


From owen at delong.com  Thu Jun  2 15:22:03 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 12:22:03 -0700
Subject: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
In-Reply-To: <20110602140810.GA11520@panix.com>
References: <B5D008A3-161D-43F2-B2E5-1603A11D807A@delong.com>
	<20110530021405.GA22407@panix.com>
	<AEF50AA3-A6E9-46C3-A4EB-67D24761D158@delong.com>
	<013401cc1e82$dfddd260$9f997720$@iname.com>
	<8F6F6B58-2A61-480A-B5FC-B3B97EA11809@delong.com>
	<014c01cc1f38$b5a28b60$20e7a220$@iname.com>
	<EF2C90B2-E8E4-440A-AD34-4BBC810EDE5E@delong.com>
	<BANLkTi=PFBWpE2=t7tA1AJOiV5k5KnKxqQ@mail.gmail.com>
	<E11BB7B9-39F5-4D7D-B982-C7E761486A62@queuefull.net>
	<386C8A2C-9148-4941-8142-F45D165AC363@delong.com>
	<20110602140810.GA11520@panix.com>
Message-ID: <BFB6DF69-9232-4674-8B24-5F5B4053358A@delong.com>


On Jun 2, 2011, at 7:08 AM, Brett Frankenberger wrote:

> On Thu, Jun 02, 2011 at 12:14:29AM -0700, Owen DeLong wrote:
>> 
>> Quite frankly, if you sell a /19, you really don't have to announce
>> the /17, /18, and /19. You could just continue to announce the /16
>> knowing that the recipient's /19 would override your /16
>> announcement.
> 
> Would, say, your employer go along with that?  If I have a /16 and sell
> a /19 from it, I'll end up with a /17, /18, and /19 in ARIN's records. 
> If I then seek service from HE, and tell them I want to announce the
> /16, will they allow it even though there's no record of that /16
> being allocated to me?  
> 

Well, there should be a record. If nothing else, you should be able
to produce some record of the sale.

Additionally, there is a policy proposal which would require ARIN to
maintain such a record in public view.

> What would the standard be?  A customer can announce it if they provide
> documentation that they once held the /16 and still hold part of it? 

I can't say what my employer would do, but, in general, I would think
that in a situation where you are the holder of record of most of the
components of a larger aggregate and it is known that the smaller
subcomponents would have overriding routes (thus your aggregate
cannot cause harm) that it is reasonable to simply advertise the
aggregate rather than the subcomponents.

> Or would you allow anyone to announce a /16 if any part of it were
> assigned to them in whois?  If two or more portions of it were assigned
> to them in whois?  If more than half of it were assigned to them? 
> (Obviosuly, each provider gets to make their own decision here.  I'm
> just wondering what you'd suggest their policies should be.)
> 

Personally, I would look at each case for what would be the smallest
total number of prefixes advertised without causing the probability
of harm.

> Certainly I agree that what you propose would work, but it would seem
> cumbersome to implement in practice, especially for any orgnaization
> seeking service from a new upstream after the sale had occurred.
> 

It doesn't seem so cumbersome to me, but, I guess it depends on how
the upstream providers respond.

> And, of course, it all falls apart under RPKI.
> 

I suspect that IPv4 will all fall apart long before RPKI becomes a
reality that affects the routing table.

>> There is little or no benefit to you announcing the /17, /18, and /19
>> instead of the /16.
> 
> As long as the other /19 is continuously announced.  One downside of
> announcing the /16 is you get traffic for the /19 you sold whenever
> that /19 isn't being announced by its new holder.
> 

If the other /19 is not announced, then, the only downside is that you
sink the traffic for it which you don't want when it isn't. It's still not
harming the party you transferred the /19 to, so, I kind of view that
as a risk you take when you transfer a small fraction of your
address space.

Owen



From owen at delong.com  Thu Jun  2 15:43:33 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 12:43:33 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
Message-ID: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>

There were comments from staff requesting certain clarifications
and pointing out that the first part of 8.3.a was unnecessary in policy
and should be eliminated or moved to the rationale.

My intent is for this version to address those concerns. I welcome
comments, feedback and discussion.

Owen


ARIN-prop-149 Improved Transparency for Directed Transfers

Proposal Originator: Owen DeLong

Proposal Version: 1.3

Date: 2 June 2011

Proposal type: new

Policy term: permanent

Policy statement:

Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
replaced with appropriate new subsection numbers when incorporated into
the NRPM)

8.3.a  ARIN shall maintain and publish a list of all prefixes
transfered under section 8.3. The list will identify the original prefix
(the block originally held by the transferor) and each subordinate prefix
(each partial block derived from that original block) transferred under
this policy and the date each prefix was transferred.

8.3.b  Upon activation of this policy, ARIN shall include in the list at
the earliest possible time all prefixes which have been transferred
under section 8.3 to date.

Rationale:

The community has a right to know which prefixes have been added or are
the result of transfer-related disaggregation. This will provide
accurate data in a central well-known location.

Timetable for implementation: immediate



From kkargel at polartel.com  Thu Jun  2 15:59:52 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 2 Jun 2011 14:59:52 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	Directed	Transfers
In-Reply-To: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD289F0330AE@MAIL1.polartel.local>

I would support this as written or with the move of verbiage to rationale.
Kevin Kargel


 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, June 02, 2011 2:44 PM
> To: policy; arin ppml
> Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
> Transfers
> 
> There were comments from staff requesting certain clarifications
> and pointing out that the first part of 8.3.a was unnecessary in policy
> and should be eliminated or moved to the rationale.
> 
> My intent is for this version to address those concerns. I welcome
> comments, feedback and discussion.
> 
> Owen
> 
> 
> ARIN-prop-149 Improved Transparency for Directed Transfers
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1.3
> 
> Date: 2 June 2011
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
> replaced with appropriate new subsection numbers when incorporated into
> the NRPM)
> 
> 8.3.a  ARIN shall maintain and publish a list of all prefixes
> transfered under section 8.3. The list will identify the original prefix
> (the block originally held by the transferor) and each subordinate prefix
> (each partial block derived from that original block) transferred under
> this policy and the date each prefix was transferred.
> 
> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
> the earliest possible time all prefixes which have been transferred
> under section 8.3 to date.
> 
> Rationale:
> 
> The community has a right to know which prefixes have been added or are
> the result of transfer-related disaggregation. This will provide
> accurate data in a central well-known location.
> 
> Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jcurran at arin.net  Thu Jun  2 16:06:24 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 2 Jun 2011 20:06:24 +0000
Subject: [arin-ppml] RIR distribution of legacy addresses
In-Reply-To: <BANLkTimA2hyiW1_1OanOhY5Y8U5gw-2mLQ@mail.gmail.com>
References: <4DE70B8F.3070903@apnic.net>
	<B7B0BA8D-B84B-4639-8AB2-967B6CBC822F@queuefull.net>
	<97DD40F6-3441-4015-9804-5126AAF04774@arin.net>
	<F7A45F92-71FB-44D2-9147-74C16EFBA1A8@queuefull.net>
	<642918D2-2314-4998-8468-F211051FDFA9@arin.net>
	<BANLkTimA2hyiW1_1OanOhY5Y8U5gw-2mLQ@mail.gmail.com>
Message-ID: <415072C6-31A8-4E3B-9160-319E7AC4DBB6@arin.net>

On Jun 2, 2011, at 2:35 PM, Jeffrey Lyon wrote:

> John,
> 
> How would it ever have made sense to return a /8 at all? It has been
> known for years that IPv4 will be depleted and that our need will far
> outlast supply.
> 
> Is this some type of horse trading or are you just genuinely that nice
> and equitable?

Jeffrey - 
 
  Each RIR has been drawing from central free pool on an equitable basis, 
  and hence the return of a very significant block of reallocatable IPv4 
  address space (e.g. a /8) has generally been viewed as a resource that
  belongs back in the global free pool.

  This has occurred numerous times over the last two decades.

FYI,
/John

John Curran
President and CEO
ARIN




From farmer at umn.edu  Thu Jun  2 16:07:25 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 02 Jun 2011 15:07:25 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
 Transfers
In-Reply-To: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
Message-ID: <4DE7ED7D.9080608@umn.edu>

Owen,

I would like to clarify something, the intent is to publish a list of 
resources (the numbers) that have been transferred and any resources 
disaggregated as part of transfers.  Similar to the list of micro 
allocations that have been made, see;

https://www.arin.net/knowledge/micro_allocations.html

Further, the intent is not to publish a list of the parties involved in 
the transfers as well.


On 6/2/11 14:43 CDT, Owen DeLong wrote:
> There were comments from staff requesting certain clarifications
> and pointing out that the first part of 8.3.a was unnecessary in policy
> and should be eliminated or moved to the rationale.
>
> My intent is for this version to address those concerns. I welcome
> comments, feedback and discussion.
>
> Owen
>
>
> ARIN-prop-149 Improved Transparency for Directed Transfers
>
> Proposal Originator: Owen DeLong
>
> Proposal Version: 1.3
>
> Date: 2 June 2011
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
> replaced with appropriate new subsection numbers when incorporated into
> the NRPM)
>
> 8.3.a  ARIN shall maintain and publish a list of all prefixes
> transfered under section 8.3. The list will identify the original prefix
> (the block originally held by the transferor) and each subordinate prefix
> (each partial block derived from that original block) transferred under
> this policy and the date each prefix was transferred.
>
> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
> the earliest possible time all prefixes which have been transferred
> under section 8.3 to date.
>
> Rationale:
>
> The community has a right to know which prefixes have been added or are
> the result of transfer-related disaggregation. This will provide
> accurate data in a central well-known location.
>
> Timetable for implementation: immediate
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


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


From owen at delong.com  Thu Jun  2 16:52:12 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 13:52:12 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
In-Reply-To: <4DE7ED7D.9080608@umn.edu>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
Message-ID: <0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>


On Jun 2, 2011, at 1:07 PM, David Farmer wrote:

> Owen,
> 
> I would like to clarify something, the intent is to publish a list of resources (the numbers) that have been transferred and any resources disaggregated as part of transfers.  Similar to the list of micro allocations that have been made, see;
> 
> https://www.arin.net/knowledge/micro_allocations.html
> 
Yes, but, in this case, I think that dates are also vital data.

> Further, the intent is not to publish a list of the parties involved in the transfers as well.
> 

I don't care one way or the other about this. Obviously, by publishing the list, one
can associate the numbers in the list with whois entries to determine the identities
if one wishes. I don't have a problem with identifying the parties, but, it is not a
specific goal of this policy. I think that it would be impossible to usefully anonymize
the parties and still preserve the integrity of what needs to be disclosed.

Owen

> 
> On 6/2/11 14:43 CDT, Owen DeLong wrote:
>> There were comments from staff requesting certain clarifications
>> and pointing out that the first part of 8.3.a was unnecessary in policy
>> and should be eliminated or moved to the rationale.
>> 
>> My intent is for this version to address those concerns. I welcome
>> comments, feedback and discussion.
>> 
>> Owen
>> 
>> 
>> ARIN-prop-149 Improved Transparency for Directed Transfers
>> 
>> Proposal Originator: Owen DeLong
>> 
>> Proposal Version: 1.3
>> 
>> Date: 2 June 2011
>> 
>> Proposal type: new
>> 
>> Policy term: permanent
>> 
>> Policy statement:
>> 
>> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
>> replaced with appropriate new subsection numbers when incorporated into
>> the NRPM)
>> 
>> 8.3.a  ARIN shall maintain and publish a list of all prefixes
>> transfered under section 8.3. The list will identify the original prefix
>> (the block originally held by the transferor) and each subordinate prefix
>> (each partial block derived from that original block) transferred under
>> this policy and the date each prefix was transferred.
>> 
>> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
>> the earliest possible time all prefixes which have been transferred
>> under section 8.3 to date.
>> 
>> Rationale:
>> 
>> The community has a right to know which prefixes have been added or are
>> the result of transfer-related disaggregation. This will provide
>> accurate data in a central well-known location.
>> 
>> Timetable for implementation: immediate
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota	
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================



From mike at nationwideinc.com  Thu Jun  2 17:16:26 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 2 Jun 2011 17:16:26 -0400
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	DirectedTransfers
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com><4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
Message-ID: <54FF01F9E2204851AA930FEE15C749BF@mike>

Hi,

Is it possible for ARIN to calculate a deaggregation factor for transfers 
and report just that, to protect identities?

Regards,
Mike


----- Original Message ----- 
From: "Owen DeLong" <owen at delong.com>
To: "David Farmer" <farmer at umn.edu>
Cc: "arin ppml" <ppml at arin.net>
Sent: Thursday, June 02, 2011 4:52 PM
Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for 
DirectedTransfers


>
> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>
>> Owen,
>>
>> I would like to clarify something, the intent is to publish a list of 
>> resources (the numbers) that have been transferred and any resources 
>> disaggregated as part of transfers.  Similar to the list of micro 
>> allocations that have been made, see;
>>
>> https://www.arin.net/knowledge/micro_allocations.html
>>
> Yes, but, in this case, I think that dates are also vital data.
>
>> Further, the intent is not to publish a list of the parties involved in 
>> the transfers as well.
>>
>
> I don't care one way or the other about this. Obviously, by publishing the 
> list, one
> can associate the numbers in the list with whois entries to determine the 
> identities
> if one wishes. I don't have a problem with identifying the parties, but, 
> it is not a
> specific goal of this policy. I think that it would be impossible to 
> usefully anonymize
> the parties and still preserve the integrity of what needs to be 
> disclosed.
>
> Owen
>
>>
>> On 6/2/11 14:43 CDT, Owen DeLong wrote:
>>> There were comments from staff requesting certain clarifications
>>> and pointing out that the first part of 8.3.a was unnecessary in policy
>>> and should be eliminated or moved to the rationale.
>>>
>>> My intent is for this version to address those concerns. I welcome
>>> comments, feedback and discussion.
>>>
>>> Owen
>>>
>>>
>>> ARIN-prop-149 Improved Transparency for Directed Transfers
>>>
>>> Proposal Originator: Owen DeLong
>>>
>>> Proposal Version: 1.3
>>>
>>> Date: 2 June 2011
>>>
>>> Proposal type: new
>>>
>>> Policy term: permanent
>>>
>>> Policy statement:
>>>
>>> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
>>> replaced with appropriate new subsection numbers when incorporated into
>>> the NRPM)
>>>
>>> 8.3.a  ARIN shall maintain and publish a list of all prefixes
>>> transfered under section 8.3. The list will identify the original prefix
>>> (the block originally held by the transferor) and each subordinate 
>>> prefix
>>> (each partial block derived from that original block) transferred under
>>> this policy and the date each prefix was transferred.
>>>
>>> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
>>> the earliest possible time all prefixes which have been transferred
>>> under section 8.3 to date.
>>>
>>> Rationale:
>>>
>>> The community has a right to know which prefixes have been added or are
>>> the result of transfer-related disaggregation. This will provide
>>> accurate data in a central well-known location.
>>>
>>> Timetable for implementation: immediate
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>>
>> -- 
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE     Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues. 



From owen at delong.com  Thu Jun  2 17:31:14 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 14:31:14 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	DirectedTransfers
In-Reply-To: <54FF01F9E2204851AA930FEE15C749BF@mike>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com><4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<54FF01F9E2204851AA930FEE15C749BF@mike>
Message-ID: <FFFA034F-1430-4E4F-8A15-E2FB82D63CF1@delong.com>

Why protect identities? All of this is required to be visible in whois today for
ARIN issued space, why should transfers be any different?

Anyone can subscribe to the ARIN daily report which would reveal the
same data for ARIN issued space. All this policy demands is a similar
level of transparency for transfers.

Owen

On Jun 2, 2011, at 2:16 PM, Mike Burns wrote:

> Hi,
> 
> Is it possible for ARIN to calculate a deaggregation factor for transfers and report just that, to protect identities?
> 
> Regards,
> Mike
> 
> 
> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
> To: "David Farmer" <farmer at umn.edu>
> Cc: "arin ppml" <ppml at arin.net>
> Sent: Thursday, June 02, 2011 4:52 PM
> Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for DirectedTransfers
> 
> 
>> 
>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>> 
>>> Owen,
>>> 
>>> I would like to clarify something, the intent is to publish a list of resources (the numbers) that have been transferred and any resources disaggregated as part of transfers.  Similar to the list of micro allocations that have been made, see;
>>> 
>>> https://www.arin.net/knowledge/micro_allocations.html
>>> 
>> Yes, but, in this case, I think that dates are also vital data.
>> 
>>> Further, the intent is not to publish a list of the parties involved in the transfers as well.
>>> 
>> 
>> I don't care one way or the other about this. Obviously, by publishing the list, one
>> can associate the numbers in the list with whois entries to determine the identities
>> if one wishes. I don't have a problem with identifying the parties, but, it is not a
>> specific goal of this policy. I think that it would be impossible to usefully anonymize
>> the parties and still preserve the integrity of what needs to be disclosed.
>> 
>> Owen
>> 
>>> 
>>> On 6/2/11 14:43 CDT, Owen DeLong wrote:
>>>> There were comments from staff requesting certain clarifications
>>>> and pointing out that the first part of 8.3.a was unnecessary in policy
>>>> and should be eliminated or moved to the rationale.
>>>> 
>>>> My intent is for this version to address those concerns. I welcome
>>>> comments, feedback and discussion.
>>>> 
>>>> Owen
>>>> 
>>>> 
>>>> ARIN-prop-149 Improved Transparency for Directed Transfers
>>>> 
>>>> Proposal Originator: Owen DeLong
>>>> 
>>>> Proposal Version: 1.3
>>>> 
>>>> Date: 2 June 2011
>>>> 
>>>> Proposal type: new
>>>> 
>>>> Policy term: permanent
>>>> 
>>>> Policy statement:
>>>> 
>>>> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
>>>> replaced with appropriate new subsection numbers when incorporated into
>>>> the NRPM)
>>>> 
>>>> 8.3.a  ARIN shall maintain and publish a list of all prefixes
>>>> transfered under section 8.3. The list will identify the original prefix
>>>> (the block originally held by the transferor) and each subordinate prefix
>>>> (each partial block derived from that original block) transferred under
>>>> this policy and the date each prefix was transferred.
>>>> 
>>>> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
>>>> the earliest possible time all prefixes which have been transferred
>>>> under section 8.3 to date.
>>>> 
>>>> Rationale:
>>>> 
>>>> The community has a right to know which prefixes have been added or are
>>>> the result of transfer-related disaggregation. This will provide
>>>> accurate data in a central well-known location.
>>>> 
>>>> Timetable for implementation: immediate
>>>> 
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> 
>>> 
>>> -- 
>>> ===============================================
>>> David Farmer               Email:farmer at umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE     Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues. 



From owen at delong.com  Thu Jun  2 17:41:27 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 14:41:27 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	DirectedTransfers
In-Reply-To: <54FF01F9E2204851AA930FEE15C749BF@mike>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com><4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<54FF01F9E2204851AA930FEE15C749BF@mike>
Message-ID: <2B89EC22-CAF7-4935-AF93-F8E4F3BFE46E@delong.com>

BTW, the point of this transparency is so that people can decide whether or not
to route blocks that were transferred as disaggregates. The ability to take when
the block was disaggregated into account in that decision is vital to preserving
a working internet for earlier users.

That cannot be accomplished with the kind of anonymization you are proposing.

Owen

On Jun 2, 2011, at 2:16 PM, Mike Burns wrote:

> Hi,
> 
> Is it possible for ARIN to calculate a deaggregation factor for transfers and report just that, to protect identities?
> 
> Regards,
> Mike
> 
> 
> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
> To: "David Farmer" <farmer at umn.edu>
> Cc: "arin ppml" <ppml at arin.net>
> Sent: Thursday, June 02, 2011 4:52 PM
> Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for DirectedTransfers
> 
> 
>> 
>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>> 
>>> Owen,
>>> 
>>> I would like to clarify something, the intent is to publish a list of resources (the numbers) that have been transferred and any resources disaggregated as part of transfers.  Similar to the list of micro allocations that have been made, see;
>>> 
>>> https://www.arin.net/knowledge/micro_allocations.html
>>> 
>> Yes, but, in this case, I think that dates are also vital data.
>> 
>>> Further, the intent is not to publish a list of the parties involved in the transfers as well.
>>> 
>> 
>> I don't care one way or the other about this. Obviously, by publishing the list, one
>> can associate the numbers in the list with whois entries to determine the identities
>> if one wishes. I don't have a problem with identifying the parties, but, it is not a
>> specific goal of this policy. I think that it would be impossible to usefully anonymize
>> the parties and still preserve the integrity of what needs to be disclosed.
>> 
>> Owen
>> 
>>> 
>>> On 6/2/11 14:43 CDT, Owen DeLong wrote:
>>>> There were comments from staff requesting certain clarifications
>>>> and pointing out that the first part of 8.3.a was unnecessary in policy
>>>> and should be eliminated or moved to the rationale.
>>>> 
>>>> My intent is for this version to address those concerns. I welcome
>>>> comments, feedback and discussion.
>>>> 
>>>> Owen
>>>> 
>>>> 
>>>> ARIN-prop-149 Improved Transparency for Directed Transfers
>>>> 
>>>> Proposal Originator: Owen DeLong
>>>> 
>>>> Proposal Version: 1.3
>>>> 
>>>> Date: 2 June 2011
>>>> 
>>>> Proposal type: new
>>>> 
>>>> Policy term: permanent
>>>> 
>>>> Policy statement:
>>>> 
>>>> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
>>>> replaced with appropriate new subsection numbers when incorporated into
>>>> the NRPM)
>>>> 
>>>> 8.3.a  ARIN shall maintain and publish a list of all prefixes
>>>> transfered under section 8.3. The list will identify the original prefix
>>>> (the block originally held by the transferor) and each subordinate prefix
>>>> (each partial block derived from that original block) transferred under
>>>> this policy and the date each prefix was transferred.
>>>> 
>>>> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
>>>> the earliest possible time all prefixes which have been transferred
>>>> under section 8.3 to date.
>>>> 
>>>> Rationale:
>>>> 
>>>> The community has a right to know which prefixes have been added or are
>>>> the result of transfer-related disaggregation. This will provide
>>>> accurate data in a central well-known location.
>>>> 
>>>> Timetable for implementation: immediate
>>>> 
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> 
>>> 
>>> -- 
>>> ===============================================
>>> David Farmer               Email:farmer at umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE     Phone: 612-626-0815
>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>> ===============================================
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues. 



From frnkblk at iname.com  Thu Jun  2 17:53:54 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 2 Jun 2011 16:53:54 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
In-Reply-To: <4DE7ED7D.9080608@umn.edu>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
Message-ID: <000701cc216f$91143990$b33cacb0$@iname.com>

While including the parties involved would allow for further analysis by the
community, listing just the resources would be a good start.  As Owen wrote,
we can identify the recipient easy enough, and those who have WHOIS history
can supply the seller.

Frank

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of David Farmer
Sent: Thursday, June 02, 2011 3:07 PM
To: Owen DeLong
Cc: arin ppml
Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for Directed
Transfers

Owen,

I would like to clarify something, the intent is to publish a list of 
resources (the numbers) that have been transferred and any resources 
disaggregated as part of transfers.  Similar to the list of micro 
allocations that have been made, see;

https://www.arin.net/knowledge/micro_allocations.html

Further, the intent is not to publish a list of the parties involved in 
the transfers as well.


On 6/2/11 14:43 CDT, Owen DeLong wrote:
> There were comments from staff requesting certain clarifications
> and pointing out that the first part of 8.3.a was unnecessary in policy
> and should be eliminated or moved to the rationale.
>
> My intent is for this version to address those concerns. I welcome
> comments, feedback and discussion.
>
> Owen
>
>
> ARIN-prop-149 Improved Transparency for Directed Transfers
>
> Proposal Originator: Owen DeLong
>
> Proposal Version: 1.3
>
> Date: 2 June 2011
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> Add the following to section 8.3 of the NRPM (where 8.3.[a..z] are
> replaced with appropriate new subsection numbers when incorporated into
> the NRPM)
>
> 8.3.a  ARIN shall maintain and publish a list of all prefixes
> transfered under section 8.3. The list will identify the original prefix
> (the block originally held by the transferor) and each subordinate prefix
> (each partial block derived from that original block) transferred under
> this policy and the date each prefix was transferred.
>
> 8.3.b  Upon activation of this policy, ARIN shall include in the list at
> the earliest possible time all prefixes which have been transferred
> under section 8.3 to date.
>
> Rationale:
>
> The community has a right to know which prefixes have been added or are
> the result of transfer-related disaggregation. This will provide
> accurate data in a central well-known location.
>
> Timetable for implementation: immediate
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From farmer at umn.edu  Thu Jun  2 17:54:58 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 02 Jun 2011 16:54:58 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
 Transfers
In-Reply-To: <0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
Message-ID: <4DE806B2.50604@umn.edu>

On 6/2/11 15:52 CDT, Owen DeLong wrote:
>
> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>
>> Owen,
>>
>> I would like to clarify something, the intent is to publish a list of resources (the numbers) that have been transferred and any resources disaggregated as part of transfers.  Similar to the list of micro allocations that have been made, see;
>>
>> https://www.arin.net/knowledge/micro_allocations.html
>>
> Yes, but, in this case, I think that dates are also vital data.

I'm not seeing why the date is vital, could you explain your reasoning?

>> Further, the intent is not to publish a list of the parties involved in the transfers as well.
>>
>
> I don't care one way or the other about this. Obviously, by publishing the list, one
> can associate the numbers in the list with whois entries to determine the identities
> if one wishes. I don't have a problem with identifying the parties, but, it is not a
> specific goal of this policy. I think that it would be impossible to usefully anonymize
> the parties and still preserve the integrity of what needs to be disclosed.

I'm not looking to anonymize anything, but I don't see a valid need to 
include the identities of the parties in this list either.  If someone 
wants to look each one up, more power to them.

> Owen

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


From owen at delong.com  Thu Jun  2 19:48:36 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 2 Jun 2011 16:48:36 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
In-Reply-To: <4DE806B2.50604@umn.edu>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>
Message-ID: <A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>



Sent from my iPhone

On Jun 2, 2011, at 2:54 PM, David Farmer <farmer at umn.edu> wrote:

> On 6/2/11 15:52 CDT, Owen DeLong wrote:
>> 
>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>> 
>>> Owen,
>>> 
>>> I would like to clarify something, the intent is to publish a list of resources (the numbers) that have been transferred and any resources disaggregated as part of transfers.  Similar to the list of micro allocations that have been made, see;
>>> 
>>> https://www.arin.net/knowledge/micro_allocations.html
>>> 
>> Yes, but, in this case, I think that dates are also vital data.
> 
> I'm not seeing why the date is vital, could you explain your reasoning?
> 

To prevent breaking smaller networks that have been online for years by limiting prefix sizes overall it will be necessary to be able to tell recent deaggregation apart from earlier segmentation. 
>>> Further, the intent is not to publish a list of the parties involved in the transfers as well.
>>> 
>> 
>> I don't care one way or the other about this. Obviously, by publishing the list, one
>> can associate the numbers in the list with whois entries to determine the identities
>> if one wishes. I don't have a problem with identifying the parties, but, it is not a
>> specific goal of this policy. I think that it would be impossible to usefully anonymize
>> the parties and still preserve the integrity of what needs to be disclosed.
> 
> I'm not looking to anonymize anything, but I don't see a valid need to include the identities of the parties in this list either.  If someone wants to look each one up, more power to them.
> 
>> Owen
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota    
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================


From narten at us.ibm.com  Fri Jun  3 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 03 Jun 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201106030453.p534r2C6004268@rotala.raleigh.ibm.com>

Total of 124 messages in the last 7 days.
 
script run at: Fri Jun  3 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 29.03% |   36 | 27.20% |   344067 | owen at delong.com
  9.68% |   12 | 14.81% |   187357 | frnkblk at iname.com
 14.52% |   18 |  8.93% |   113030 | matthew at matthew.at
  4.84% |    6 | 11.74% |   148556 | mike at nationwideinc.com
  8.87% |   11 |  6.94% |    87745 | jcurran at arin.net
  4.84% |    6 |  3.42% |    43276 | rbf+arin-ppml at panix.com
  4.84% |    6 |  3.26% |    41267 | bill at herrin.us
  2.42% |    3 |  4.00% |    50605 | billd at cait.wustl.edu
  3.23% |    4 |  2.01% |    25432 | farmer at umn.edu
  0.81% |    1 |  3.61% |    45707 | rudi.daniel at gmail.com
  2.42% |    3 |  1.91% |    24167 | bensons at queuefull.net
  1.61% |    2 |  2.06% |    26034 | stephen at sprunk.org
  1.61% |    2 |  1.51% |    19166 | ikiris at gmail.com
  1.61% |    2 |  1.34% |    16999 | jeffrey.lyon at blacklotus.net
  1.61% |    2 |  1.12% |    14144 | kkargel at polartel.com
  1.61% |    2 |  1.05% |    13342 | lucas at cs.ucla.edu
  1.61% |    2 |  0.98% |    12431 | info at arin.net
  0.81% |    1 |  1.28% |    16144 | scottleibrand at gmail.com
  0.81% |    1 |  0.88% |    11076 | adudek16 at gmail.com
  0.81% |    1 |  0.52% |     6626 | gary.buhrmaster at gmail.com
  0.81% |    1 |  0.52% |     6576 | hannigan at gmail.com
  0.81% |    1 |  0.52% |     6538 | narten at us.ibm.com
  0.81% |    1 |  0.38% |     4823 | tedm at ipinc.net
--------+------+--------+----------+------------------------
100.00% |  124 |100.00% |  1265108 | Total


From farmer at umn.edu  Fri Jun  3 02:34:53 2011
From: farmer at umn.edu (David Farmer)
Date: Fri, 03 Jun 2011 01:34:53 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
 Transfers
In-Reply-To: <A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>
	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
Message-ID: <4DE8808D.6030703@umn.edu>

On 6/2/11 18:48 CDT, Owen DeLong wrote:
>
>
> Sent from my iPhone
>
> On Jun 2, 2011, at 2:54 PM, David Farmer<farmer at umn.edu>  wrote:
>
>> On 6/2/11 15:52 CDT, Owen DeLong wrote:
>>>
>>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>>>
>>>> Owen,
>>>>
>>>> I would like to clarify something, the intent is to publish a
>>>> list of resources (the numbers) that have been transferred and
>>>> any resources disaggregated as part of transfers.  Similar to
>>>> the list of micro allocations that have been made, see;
>>>>
>>>> https://www.arin.net/knowledge/micro_allocations.html
>>>>
>>> Yes, but, in this case, I think that dates are also vital data.
>>
>> I'm not seeing why the date is vital, could you explain your
>> reasoning?
>>
>
> To prevent breaking smaller networks that have been online for years
> by limiting prefix sizes overall it will be necessary to be able to
> tell recent deaggregation apart from earlier segmentation.

I see how having the date for each transfer would let you differentiate 
between transfers on the list, earlier transfers verses later transfers. 
  But, how does the date of the transfer help you differentiate between 
disaggregation from transfers verses earlier segmentation?

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


From owen at delong.com  Fri Jun  3 03:42:00 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Jun 2011 00:42:00 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
In-Reply-To: <4DE8808D.6030703@umn.edu>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>
	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
	<4DE8808D.6030703@umn.edu>
Message-ID: <28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>


On Jun 2, 2011, at 11:34 PM, David Farmer wrote:

> On 6/2/11 18:48 CDT, Owen DeLong wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>> On Jun 2, 2011, at 2:54 PM, David Farmer<farmer at umn.edu>  wrote:
>> 
>>> On 6/2/11 15:52 CDT, Owen DeLong wrote:
>>>> 
>>>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>>>> 
>>>>> Owen,
>>>>> 
>>>>> I would like to clarify something, the intent is to publish a
>>>>> list of resources (the numbers) that have been transferred and
>>>>> any resources disaggregated as part of transfers.  Similar to
>>>>> the list of micro allocations that have been made, see;
>>>>> 
>>>>> https://www.arin.net/knowledge/micro_allocations.html
>>>>> 
>>>> Yes, but, in this case, I think that dates are also vital data.
>>> 
>>> I'm not seeing why the date is vital, could you explain your
>>> reasoning?
>>> 
>> 
>> To prevent breaking smaller networks that have been online for years
>> by limiting prefix sizes overall it will be necessary to be able to
>> tell recent deaggregation apart from earlier segmentation.
> 
> I see how having the date for each transfer would let you differentiate between transfers on the list, earlier transfers verses later transfers.  But, how does the date of the transfer help you differentiate between disaggregation from transfers verses earlier segmentation?
> 

It's unclear where in time the breaking point will occur, so, it may
be some network operators want to allow smaller prefixes from
some earlier transfers. If we have the date, the network operators
can make the decision. If we don't, then they can't.

Owen



From kkargel at polartel.com  Fri Jun  3 10:57:12 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 3 Jun 2011 09:57:12 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	Directed	Transfers
In-Reply-To: <28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
	<4DE8808D.6030703@umn.edu>
	<28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>

I actually wouldn't mind seeing the source ASN in the data.  The destination ASN is trivial to find so is a non issue.  I don't see why this would be an issue, if an ASN is afraid of anyone noticing they are transferring blocks there is probably a reason for that the community should be aware of anyway.

This is not a deal breaker in any way shape or form and would not affect my support.  Just to satisfy my curiosity.  

Kevin


 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Friday, June 03, 2011 2:42 AM
> To: David Farmer
> Cc: arin ppml
> Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for
> Directed Transfers
> 
> 
> On Jun 2, 2011, at 11:34 PM, David Farmer wrote:
> 
> > On 6/2/11 18:48 CDT, Owen DeLong wrote:
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On Jun 2, 2011, at 2:54 PM, David Farmer<farmer at umn.edu>  wrote:
> >>
> >>> On 6/2/11 15:52 CDT, Owen DeLong wrote:
> >>>>
> >>>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
> >>>>
> >>>>> Owen,
> >>>>>
> >>>>> I would like to clarify something, the intent is to publish a
> >>>>> list of resources (the numbers) that have been transferred and
> >>>>> any resources disaggregated as part of transfers.  Similar to
> >>>>> the list of micro allocations that have been made, see;
> >>>>>
> >>>>> https://www.arin.net/knowledge/micro_allocations.html
> >>>>>
> >>>> Yes, but, in this case, I think that dates are also vital data.
> >>>
> >>> I'm not seeing why the date is vital, could you explain your
> >>> reasoning?
> >>>
> >>
> >> To prevent breaking smaller networks that have been online for years
> >> by limiting prefix sizes overall it will be necessary to be able to
> >> tell recent deaggregation apart from earlier segmentation.
> >
> > I see how having the date for each transfer would let you differentiate
> between transfers on the list, earlier transfers verses later transfers.
> But, how does the date of the transfer help you differentiate between
> disaggregation from transfers verses earlier segmentation?
> >
> 
> It's unclear where in time the breaking point will occur, so, it may
> be some network operators want to allow smaller prefixes from
> some earlier transfers. If we have the date, the network operators
> can make the decision. If we don't, then they can't.
> 
> 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 rbf+arin-ppml at panix.com  Fri Jun  3 11:20:42 2011
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Fri, 3 Jun 2011 10:20:42 -0500
Subject: [arin-ppml] Update for pp149 Improved Transparency for
 Directed	Transfers
In-Reply-To: <8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>
	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
	<4DE8808D.6030703@umn.edu>
	<28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>
	<8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>
Message-ID: <20110603152042.GA27451@panix.com>

On Fri, Jun 03, 2011 at 09:57:12AM -0500, Kevin Kargel wrote:
>
> I actually wouldn't mind seeing the source ASN in the data.  The
> destination ASN is trivial to find so is a non issue.  I don't see
> why this would be an issue, if an ASN is afraid of anyone noticing
> they are transferring blocks there is probably a reason for that the
> community should be aware of anyway.
> 
> This is not a deal breaker in any way shape or form and would not
> affect my support.  Just to satisfy my curiosity.

ARIN doesn't really have that information.  ARIN allocates IP addresses
to organizations, not to ASs.  (There are possible hacks.  They could
assume that an org with one ASN is using that ASN for all its IP space,
but that's not necessarily always the case, and some orgs have multiple
ASNs, and so on.)

Historical BGP announcement information is probably the best place to
get this information.  But expecting ARIN to look that up and provide
historical announcement information is probably not realistic.

     -- Brett


From owen at delong.com  Fri Jun  3 12:21:23 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Jun 2011 09:21:23 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for Directed
	Transfers
In-Reply-To: <8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
	<4DE8808D.6030703@umn.edu>
	<28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>
	<8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>
Message-ID: <D9013E60-FDC7-428C-A3D8-3D994DC33772@delong.com>

There isn't necessarily an ASN that belongs to the resource holder involved.

Owen

On Jun 3, 2011, at 7:57 AM, Kevin Kargel wrote:

> I actually wouldn't mind seeing the source ASN in the data.  The destination ASN is trivial to find so is a non issue.  I don't see why this would be an issue, if an ASN is afraid of anyone noticing they are transferring blocks there is probably a reason for that the community should be aware of anyway.
> 
> This is not a deal breaker in any way shape or form and would not affect my support.  Just to satisfy my curiosity.  
> 
> Kevin
> 
> 
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Owen DeLong
>> Sent: Friday, June 03, 2011 2:42 AM
>> To: David Farmer
>> Cc: arin ppml
>> Subject: Re: [arin-ppml] Update for pp149 Improved Transparency for
>> Directed Transfers
>> 
>> 
>> On Jun 2, 2011, at 11:34 PM, David Farmer wrote:
>> 
>>> On 6/2/11 18:48 CDT, Owen DeLong wrote:
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On Jun 2, 2011, at 2:54 PM, David Farmer<farmer at umn.edu>  wrote:
>>>> 
>>>>> On 6/2/11 15:52 CDT, Owen DeLong wrote:
>>>>>> 
>>>>>> On Jun 2, 2011, at 1:07 PM, David Farmer wrote:
>>>>>> 
>>>>>>> Owen,
>>>>>>> 
>>>>>>> I would like to clarify something, the intent is to publish a
>>>>>>> list of resources (the numbers) that have been transferred and
>>>>>>> any resources disaggregated as part of transfers.  Similar to
>>>>>>> the list of micro allocations that have been made, see;
>>>>>>> 
>>>>>>> https://www.arin.net/knowledge/micro_allocations.html
>>>>>>> 
>>>>>> Yes, but, in this case, I think that dates are also vital data.
>>>>> 
>>>>> I'm not seeing why the date is vital, could you explain your
>>>>> reasoning?
>>>>> 
>>>> 
>>>> To prevent breaking smaller networks that have been online for years
>>>> by limiting prefix sizes overall it will be necessary to be able to
>>>> tell recent deaggregation apart from earlier segmentation.
>>> 
>>> I see how having the date for each transfer would let you differentiate
>> between transfers on the list, earlier transfers verses later transfers.
>> But, how does the date of the transfer help you differentiate between
>> disaggregation from transfers verses earlier segmentation?
>>> 
>> 
>> It's unclear where in time the breaking point will occur, so, it may
>> be some network operators want to allow smaller prefixes from
>> some earlier transfers. If we have the date, the network operators
>> can make the decision. If we don't, then they can't.
>> 
>> 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 joelja at bogus.com  Sat Jun  4 11:53:37 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Sat, 4 Jun 2011 08:53:37 -0700
Subject: [arin-ppml] Update for pp149 Improved Transparency for
	Directed	Transfers
In-Reply-To: <20110603152042.GA27451@panix.com>
References: <B614701E-E38C-4664-8A68-0F7825BD63A4@delong.com>
	<4DE7ED7D.9080608@umn.edu>
	<0F5E9904-3C0B-473D-9E5D-EF44DB5CC9AF@delong.com>
	<4DE806B2.50604@umn.edu>
	<A65540C7-7871-4124-B8C4-C237E5DFDF97@delong.com>
	<4DE8808D.6030703@umn.edu>
	<28E0E04B-4648-483F-AA50-20743004AFFE@delong.com>
	<8695009A81378E48879980039EEDAD28A3A7CEE0@MAIL1.polartel.local>
	<20110603152042.GA27451@panix.com>
Message-ID: <E7C92EF5-39AA-48ED-99C9-E6270A953B5D@bogus.com>


On Jun 3, 2011, at 8:20 AM, Brett Frankenberger wrote:

> On Fri, Jun 03, 2011 at 09:57:12AM -0500, Kevin Kargel wrote:
>> 
>> I actually wouldn't mind seeing the source ASN in the data.  The
>> destination ASN is trivial to find so is a non issue.  I don't see
>> why this would be an issue, if an ASN is afraid of anyone noticing
>> they are transferring blocks there is probably a reason for that the
>> community should be aware of anyway.
>> 
>> This is not a deal breaker in any way shape or form and would not
>> affect my support.  Just to satisfy my curiosity.
> 
> ARIN doesn't really have that information.  ARIN allocates IP addresses
> to organizations, not to ASs.  (There are possible hacks.  They could
> assume that an org with one ASN is using that ASN for all its IP space,
> but that's not necessarily always the case, and some orgs have multiple
> ASNs, and so on.)

the routing table is really as authoritative source  as you're likely to get for how a prefix has been used in the dfz internet. an rpsl entry or registry assignment is is only as accurate as the maintainer.

> Historical BGP announcement information is probably the best place to
> get this information.  But expecting ARIN to look that up and provide
> historical announcement information is probably not realistic.

There is some question in my mind as to whether what actually happened reflects the intentions of the organization to which the prefix was assigned or if that's even relevant.

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



From Marla.Azinger at FTR.com  Mon Jun  6 12:43:28 2011
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 6 Jun 2011 12:43:28 -0400
Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits
In-Reply-To: <4DDFA799.6060005@arin.net>
References: <4DDFA799.6060005@arin.net>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1049E2678C1C@ROCH-EXCH1.corp.pvt>

Im opposed to this proposal.

Strangulation by RSA doesn't need to occur and it would not improve the current address management situation.

Cheers
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Friday, May 27, 2011 6:31 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits

ARIN-prop-152 RSA Modification Limits

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

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

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

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

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

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

Regards,

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


## * ##


ARIN-prop-152 RSA Modification Limits

Proposal Originator: Owen DeLong

Proposal Version: 1

Date: 27 May 2011

Proposal type: new

Policy term: permanent

Policy statement:

Add the following to section 8.1 of the NRPM

All transfers conducted under section 8 of the NRPM shall require the recipient to sign an RSA which provides at least the same limitations and restrictions as the standard RSA that would be used with any new allocation or assignment of number resources in at least the following
areas:

  a. Justified Need Requirements
  b. Subject to and Effect of NRPM 12
  c. Requirement for an annual fee to be paid
  d. Subject to future policy revisions adopted by the community

The above requirements may be waived to the extent necessary to meet a court order or settlement, but, such court order must be public or such settlement must include terms allowing the settlement terms to be published by ARIN, including the list of affected addresses and the exact resulting RSA. ARIN shall publish the terms of any such settlement and the resulting RSA within 10 days of drafting the settlement or RSA whichever comes later.

Rationale:

There have been a tremendous number of questions of late as to whether ARIN policies were followed and to what extent the modified LRSA issued to some transfer recipients allows such policy to be enforced. Since it is not possible to make the modified LRSAs public and it is not possible for the community to exercise any form of independent verification or validation of staff actions, this policy serves to provide guidelines and set limits on the extent to which an RSA can be modified to meet the needs of a transfer.

Timetable for implementation: Immediate






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

This communication is confidential.  Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.


From bensons at queuefull.net  Mon Jun  6 13:22:02 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Mon, 6 Jun 2011 12:22:02 -0500
Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1049E2678C1C@ROCH-EXCH1.corp.pvt>
References: <4DDFA799.6060005@arin.net>
	<2E2FECEBAE57CC4BAACDE67638305F1049E2678C1C@ROCH-EXCH1.corp.pvt>
Message-ID: <AB209E8E-65E9-4577-A6C7-527164F62A95@queuefull.net>

+1, I'm also opposed to this proposal and agree with Marla's comment.

ARIN should become more open and cooperative.  This proposal moves in the wrong direction.

-Benson


On Jun 6, 2011, at 11:43 AM, Azinger, Marla wrote:

> Im opposed to this proposal.
> 
> Strangulation by RSA doesn't need to occur and it would not improve the current address management situation.
> 
> Cheers
> Marla
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Friday, May 27, 2011 6:31 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits
> 
> ARIN-prop-152 RSA Modification Limits
> 
> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> ARIN-prop-152 RSA Modification Limits
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1
> 
> Date: 27 May 2011
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Add the following to section 8.1 of the NRPM
> 
> All transfers conducted under section 8 of the NRPM shall require the recipient to sign an RSA which provides at least the same limitations and restrictions as the standard RSA that would be used with any new allocation or assignment of number resources in at least the following
> areas:
> 
>  a. Justified Need Requirements
>  b. Subject to and Effect of NRPM 12
>  c. Requirement for an annual fee to be paid
>  d. Subject to future policy revisions adopted by the community
> 
> The above requirements may be waived to the extent necessary to meet a court order or settlement, but, such court order must be public or such settlement must include terms allowing the settlement terms to be published by ARIN, including the list of affected addresses and the exact resulting RSA. ARIN shall publish the terms of any such settlement and the resulting RSA within 10 days of drafting the settlement or RSA whichever comes later.
> 
> Rationale:
> 
> There have been a tremendous number of questions of late as to whether ARIN policies were followed and to what extent the modified LRSA issued to some transfer recipients allows such policy to be enforced. Since it is not possible to make the modified LRSAs public and it is not possible for the community to exercise any form of independent verification or validation of staff actions, this policy serves to provide guidelines and set limits on the extent to which an RSA can be modified to meet the needs of a transfer.
> 
> Timetable for implementation: Immediate
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> This communication is confidential.  Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Mon Jun  6 13:29:30 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 6 Jun 2011 10:29:30 -0700
Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1049E2678C1C@ROCH-EXCH1.corp.pvt>
References: <4DDFA799.6060005@arin.net>
	<2E2FECEBAE57CC4BAACDE67638305F1049E2678C1C@ROCH-EXCH1.corp.pvt>
Message-ID: <5A6ED9C0-62F1-4F8A-9FA0-204CE9200EAE@delong.com>

Huh? This doesn't create strangulation by RSA, it limits the extent to which ARIN can
modify the RSA for individual companies in a manner different from what others
sign.

It is strictly a limitation on the amount of lattitude staff has to customize an LRSA for
a particular organization. It does not in any way limit policy or general modifications
to the RSA.

If you feel that this somehow causes strangulation by RSA, could you elaborate on
what exactly makes you think this?

Thanks,

Owen

On Jun 6, 2011, at 9:43 AM, Azinger, Marla wrote:

> Im opposed to this proposal.
> 
> Strangulation by RSA doesn't need to occur and it would not improve the current address management situation.
> 
> Cheers
> Marla
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Friday, May 27, 2011 6:31 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-prop-152 RSA Modification Limits
> 
> ARIN-prop-152 RSA Modification Limits
> 
> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> ARIN-prop-152 RSA Modification Limits
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1
> 
> Date: 27 May 2011
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Add the following to section 8.1 of the NRPM
> 
> All transfers conducted under section 8 of the NRPM shall require the recipient to sign an RSA which provides at least the same limitations and restrictions as the standard RSA that would be used with any new allocation or assignment of number resources in at least the following
> areas:
> 
>  a. Justified Need Requirements
>  b. Subject to and Effect of NRPM 12
>  c. Requirement for an annual fee to be paid
>  d. Subject to future policy revisions adopted by the community
> 
> The above requirements may be waived to the extent necessary to meet a court order or settlement, but, such court order must be public or such settlement must include terms allowing the settlement terms to be published by ARIN, including the list of affected addresses and the exact resulting RSA. ARIN shall publish the terms of any such settlement and the resulting RSA within 10 days of drafting the settlement or RSA whichever comes later.
> 
> Rationale:
> 
> There have been a tremendous number of questions of late as to whether ARIN policies were followed and to what extent the modified LRSA issued to some transfer recipients allows such policy to be enforced. Since it is not possible to make the modified LRSAs public and it is not possible for the community to exercise any form of independent verification or validation of staff actions, this policy serves to provide guidelines and set limits on the extent to which an RSA can be modified to meet the needs of a transfer.
> 
> Timetable for implementation: Immediate
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> This communication is confidential.  Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From Marla.Azinger at FTR.com  Mon Jun  6 19:55:32 2011
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Mon, 6 Jun 2011 19:55:32 -0400
Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for
	IPv4	Transfers
In-Reply-To: <4DD3FC73.3050502@arin.net>
References: <4DD3FC73.3050502@arin.net>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1049E267900C@ROCH-EXCH1.corp.pvt>

I don't support this as written.

1. I would like to see the two parts separated into different proposals.
2. I would need to see how current policy on the table goes before trying to change anything more in section 8.3
3. I would support  policy that says "ARIN will not use utilization as a measure of policy compliance for addresses transferred."  Conservation in the grand scheme has been achieved as much as possible.  At this point in time any hoarding that might occur is really short term in the grand scheme.  The worst case scerio that was used as a fear factor (scenerio was that some large entity would by up all the remaining space on the market and force other business out of business) in the past, doesnt even look possible in the present, so protecting against hoarding on the grand scheme is really pointless.  Taking action to protect against this could even possibly be more damaging then helpful when you consider the services that could end up in a temporary halt because they werent ablet to create a transition time frame.

Cheers
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Wednesday, May 18, 2011 10:06 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers

ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers

Corrected proposal name.

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

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

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

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

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

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

Regards,

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


## * ##


ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers

Proposal Originator: Mike Burns

Proposal Version: 1

Date: 18 May 2011

Proposal type: modify

Policy term: permanent

Policy statement:

Replace Section 8.3 with

8.3 ARIN will process and record IPv4 address transfer requests.

Conditions on the IPv4 address block:

     - The minimum transfer size is a /24

     - The address block must be in the range of addresses administered
       by ARIN

Conditions on source of the transfer:

     - The source entity must be the current rights holder of the
       IPv4 address resources, and not be involved in any dispute as to
       the status of those resources.

     - The source entity will be ineligible to receive any further IPv4
       address allocations or assignments from ARIN for a period of 12
       months after the transfer, or until the exhaustion of ARIN's
       IPv4 space, whichever occurs first.

     - The source entity must not have received an allocation from
       ARIN for the 12 months prior to the transfer.


   Conditions on recipient of the transfer:

     - The recipient entity must be a current ARIN account holder.

     - The recipient must sign an RSA with ARIN.

     - The recipient entity of the transferred resources will be subject
       to current ARIN policies. In particular, in any subsequent ARIN
       IPv4 address allocation request, the recipient will be required
       to account for the efficient utilization of all IPv4 address
       space held, including all transferred resources.

     - If the recipient has already received the equivalent of a /12
       of addresses in the prior 12 months, the recipient must
       demonstrate the need for additional resources in the exact amount
       which they can justify under current ARIN policies.

and request the AC to modify section 8 of the current RSA to remove references to "intended purposes."

Replace
ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes.  Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement.

with

ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies.  Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or
(iii) terminate this Agreement.

and add to the NRPM Section 12:

10.    ARIN will not use utilization as a measure of policy compliance
for addresses transferred under 8.3.


Rationale:

Current ARIN policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network, or to those who agree to sign either an RSA or LRSA with ARIN and subject the buyer to needs analysis and the seller to a potential ARIN review under RSA section 8.

It is currently anticipated that the IPv4 unallocated address pool will be exhausted within a couple of years at ARIN, and earlier than that in other regions, and the  transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks.

The underlying proposition behind this policy proposal is that the registry of IPv4 addresses operated by ARIN is of general utility and value only while it accurately describes the current state of address distribution. If a class of address movement transactions are excluded from being entered in the registry, then the registry will have decreasing value to the broader community, and the integrity of the network itself is thereby compromised.  This proposal's central aim is to ensure the continuing utility and value of the ARIN address registry by allowing the registry to record transactions where IPv4 addresses are transfered between ARIN account holders.

It proposes that ARIN will recognise and register a transfer of addresses where the parties to the transfer are 'known' to ARIN and that the address block being transferred is part of ARIN's current address set.

The proposal does not prescribe how such transfers may occur, nor impose any further constraints on the transfer or on the parties involved other than those described in this proposal.

Timetable for implementation: immediate.




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

This communication is confidential.  Frontier only sends and receives email on the basis of the terms set out at http://www.frontier.com/email_disclaimer.


From mike at nationwideinc.com  Mon Jun  6 23:11:23 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 6 Jun 2011 23:11:23 -0400
Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements
	forIPv4	Transfers
References: <4DD3FC73.3050502@arin.net>
	<2E2FECEBAE57CC4BAACDE67638305F1049E267900C@ROCH-EXCH1.corp.pvt>
Message-ID: <77EE0A842F05467685B20CF260AF7962@video>

Hi Marla and thanks for the feedback.

The reason for the two items being part of the one proposal is that we need 
to change the RSA to prevent ARIN from initiating a review and revokation 
immediately after a needs-free transfer.

If we just take your item 3, which I love, and leave out the changes to the 
RSA, we leave the door open for a needs test on the newly transferred 
addresses, effectively mooting the idea of a needs-free transfer.

The limit of the /12 of needs free transfers is something I included due to 
feedback about protection from hoarders and speculators.  I would hope that 
if data shows that this limit precludes the development of legitimate 
business pursuits which require larger needs-free transfers, for example if 
the market developed to a point where it was economically desirable for a 
large wholesaler of addresses to traffic in larger amounts, I would support 
a review of this limit.

I share your view that the fear of market manipulation is overblown, and 
considered this a halfway step which could be revisited if our hunch is 
correct, and no such market cornering appears to occur.

I thought it important that the transferee sign some kind of registration 
agreement, but I wanted one which would not be so onerous as to cause 
transactions to happen "off the books."  My proposed changes to the RSA are 
limited to removing ARIN's review and revokation procedures for utilization. 
By this I meant to induce even legacy transferees to sign the RSA, and to 
provide equal footing for existing RSA signatories who may wish to sell some 
of their allocation without risking the triggering of a section 12 review.

As to  your second point, my argument is that existing 8.3 policy was 
manhandled in the public MS/Nortel deal, and in particular the needs-test 
presented the element which most directly risked a transfer from Nortel to 
MS without including ARIN at all.  Other aspects of 8.3 which were hard to 
find in the public details of the deal include the requirement of the seller 
to sign an RSA or LRSA, the requirement of the buyer to sign an RSA, the 
requirement of single aggregate transfer, and the requirement for the 
addresses to be issued back to ARIN for reissuance to the buyer. Most of 
these things were finessed through semantics, but that couldn't happen with 
the needs-test. Fortunately MS established a need which matched the 
negotiated sale amount.

So I think leaving 8.3 as it is to see how it goes runs the risk that the 
market will start off on the wrong foot, with ARIN transfer requirements not 
really meshing with the legal realities of legacy transfers.  Better in my 
mind for ARIN to initiate a liquid and vital market with protections for 
buyers and sellers from ARIN transactional hurdles which risk accurate Whois 
registration.


Regards,
Mike Burns


----- Original Message ----- 
From: "Azinger, Marla" <Marla.Azinger at FTR.com>
To: "ARIN" <info at arin.net>; <arin-ppml at arin.net>
Sent: Monday, June 06, 2011 7:55 PM
Subject: Re: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements forIPv4 
Transfers


>I don't support this as written.
>
> 1. I would like to see the two parts separated into different proposals.
> 2. I would need to see how current policy on the table goes before trying 
> to change anything more in section 8.3
> 3. I would support  policy that says "ARIN will not use utilization as a 
> measure of policy compliance for addresses transferred."  Conservation in 
> the grand scheme has been achieved as much as possible.  At this point in 
> time any hoarding that might occur is really short term in the grand 
> scheme.  The worst case scerio that was used as a fear factor (scenerio 
> was that some large entity would by up all the remaining space on the 
> market and force other business out of business) in the past, doesnt even 
> look possible in the present, so protecting against hoarding on the grand 
> scheme is really pointless.  Taking action to protect against this could 
> even possibly be more damaging then helpful when you consider the services 
> that could end up in a temporary halt because they werent ablet to create 
> a transition time frame.
>
> Cheers
> Marla
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On 
> Behalf Of ARIN
> Sent: Wednesday, May 18, 2011 10:06 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-prop-151 Limiting Needs Requirements for IPv4 
> Transfers
>
> ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers
>
> Corrected proposal name.
>
> ARIN received the following policy proposal and is posting it to the 
> Public Policy Mailing List (PPML) in accordance with the Policy 
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next 
> regularly scheduled meeting (if the period before the next regularly 
> scheduled meeting is less than 10 days, then the period may be extended to 
> the subsequent regularly scheduled meeting). The AC will decide how to 
> utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the proposal on the PPML, 
> particularly their support or non-support and the reasoning behind their 
> opinion. Such participation contributes to a thorough vetting and provides 
> important guidance to the AC in their deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> ARIN-prop-151 Limiting Needs Requirements for IPv4 Transfers
>
> Proposal Originator: Mike Burns
>
> Proposal Version: 1
>
> Date: 18 May 2011
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> Replace Section 8.3 with
>
> 8.3 ARIN will process and record IPv4 address transfer requests.
>
> Conditions on the IPv4 address block:
>
>     - The minimum transfer size is a /24
>
>     - The address block must be in the range of addresses administered
>       by ARIN
>
> Conditions on source of the transfer:
>
>     - The source entity must be the current rights holder of the
>       IPv4 address resources, and not be involved in any dispute as to
>       the status of those resources.
>
>     - The source entity will be ineligible to receive any further IPv4
>       address allocations or assignments from ARIN for a period of 12
>       months after the transfer, or until the exhaustion of ARIN's
>       IPv4 space, whichever occurs first.
>
>     - The source entity must not have received an allocation from
>       ARIN for the 12 months prior to the transfer.
>
>
>   Conditions on recipient of the transfer:
>
>     - The recipient entity must be a current ARIN account holder.
>
>     - The recipient must sign an RSA with ARIN.
>
>     - The recipient entity of the transferred resources will be subject
>       to current ARIN policies. In particular, in any subsequent ARIN
>       IPv4 address allocation request, the recipient will be required
>       to account for the efficient utilization of all IPv4 address
>       space held, including all transferred resources.
>
>     - If the recipient has already received the equivalent of a /12
>       of addresses in the prior 12 months, the recipient must
>       demonstrate the need for additional resources in the exact amount
>       which they can justify under current ARIN policies.
>
> and request the AC to modify section 8 of the current RSA to remove 
> references to "intended purposes."
>
> Replace
> ARIN may review, at any time, Applicant's use of previously allocated or 
> assigned number resources or Services received from ARIN to determine if 
> Applicant is complying with this Agreement and the Policies and is using 
> the Services for their intended purposes.  Without limiting the foregoing, 
> if Applicant is a holder of a direct allocation or assignment from ARIN, 
> Applicant agrees that it will use the number resources solely for uses 
> consistent with its application and this Agreement, including, for 
> example, its internal infrastructure or to provide Internet access to its 
> customer base. If ARIN determines that the number resources or any other 
> Services are not being used in compliance with this Agreement, the 
> Policies, or the purposes for which they are intended, ARIN may: (i) 
> revoke the number resources; (ii) cease providing the Services to 
> Applicant; and/or (iii) terminate this Agreement.
>
> with
>
> ARIN may review, at any time, any Applicant's use of previously allocated 
> or assigned number resources or Services received from ARIN to determine 
> if Applicant is complying with this Agreement and the Policies.  Without 
> limiting the foregoing, if Applicant is a holder of a direct allocation or 
> direct assignment from ARIN, Applicant agrees that it will use the number 
> resources solely for uses consistent with this Agreement, including, for 
> example, its internal infrastructure or to provide Internet access to its 
> customer base. If ARIN determines that the number resources or any other 
> Services are not being used in compliance with this Agreement or the 
> Policies, ARIN may: (i) revoke the number resources; (ii) cease providing 
> the Services to Applicant; and/or
> (iii) terminate this Agreement.
>
> and add to the NRPM Section 12:
>
> 10.    ARIN will not use utilization as a measure of policy compliance
> for addresses transferred under 8.3.
>
>
> Rationale:
>
> Current ARIN policies relating to the registration of transfer of address 
> holdings limit the eligibility of registration of transfers to those 
> relating to mergers and acquisitions of entities that are administering an 
> operational network, or to those who agree to sign either an RSA or LRSA 
> with ARIN and subject the buyer to needs analysis and the seller to a 
> potential ARIN review under RSA section 8.
>
> It is currently anticipated that the IPv4 unallocated address pool will be 
> exhausted within a couple of years at ARIN, and earlier than that in other 
> regions, and the  transition to IPv6-based service delivery is likely to 
> take longer than the remaining period of unallocated address availability. 
> Accordingly, it is likely that demand for IPv4 addresses will continue 
> beyond the time of unallocated address pool exhaustion, leading to a 
> period of movement of IPv4 address blocks between address holders to meet 
> such continuing demand for IPv4 address blocks.
>
> The underlying proposition behind this policy proposal is that the 
> registry of IPv4 addresses operated by ARIN is of general utility and 
> value only while it accurately describes the current state of address 
> distribution. If a class of address movement transactions are excluded 
> from being entered in the registry, then the registry will have decreasing 
> value to the broader community, and the integrity of the network itself is 
> thereby compromised.  This proposal's central aim is to ensure the 
> continuing utility and value of the ARIN address registry by allowing the 
> registry to record transactions where IPv4 addresses are transfered 
> between ARIN account holders.
>
> It proposes that ARIN will recognise and register a transfer of addresses 
> where the parties to the transfer are 'known' to ARIN and that the address 
> block being transferred is part of ARIN's current address set.
>
> The proposal does not prescribe how such transfers may occur, nor impose 
> any further constraints on the transfer or on the parties involved other 
> than those described in this proposal.
>
> Timetable for implementation: immediate.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> This communication is confidential.  Frontier only sends and receives 
> email on the basis of the terms set out at 
> http://www.frontier.com/email_disclaimer.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 narten at us.ibm.com  Fri Jun 10 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 10 Jun 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201106100453.p5A4r2Aa007992@rotala.raleigh.ibm.com>

Total of 12 messages in the last 7 days.
 
script run at: Fri Jun 10 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    3 | 22.94% |    23765 | owen at delong.com
 16.67% |    2 | 21.41% |    22176 | marla.azinger at ftr.com
  8.33% |    1 | 16.44% |    17032 | mike at nationwideinc.com
  8.33% |    1 |  8.43% |     8732 | bensons at queuefull.net
  8.33% |    1 |  6.82% |     7064 | kkargel at polartel.com
  8.33% |    1 |  6.53% |     6761 | narten at us.ibm.com
  8.33% |    1 |  6.21% |     6429 | joelja at bogus.com
  8.33% |    1 |  6.05% |     6270 | farmer at umn.edu
  8.33% |    1 |  5.16% |     5345 | rbf+arin-ppml at panix.com
--------+------+--------+----------+------------------------
100.00% |   12 |100.00% |   103574 | Total


From info at arin.net  Wed Jun 15 08:29:27 2011
From: info at arin.net (ARIN)
Date: Wed, 15 Jun 2011 08:29:27 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <4DDC0155.6000501@arin.net>
References: <4DDC0155.6000501@arin.net>
Message-ID: <4DF8A5A7.5020604@arin.net>

The minutes of the May meeting of the ARIN Advisory Council are
available at:
https://www.arin.net/about_us/ac/index.html


> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
> with these decisions may initiate a petition. The petition to advance
> these proposals would be the "Discussion Petition." The deadline to
> begin a petition will be five business days after the AC's draft meeting
> minutes are published.

The deadline for petitions is 22 June 2011.

Regards,

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


ARIN wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 19 May 2011 and made decisions about
> several draft policies and proposals.
>
> The AC recommended the following draft policies to the ARIN Board for
> adoption:
>
>   ARIN-2011-3: Better IPv6 Allocations for ISPs (revised)
>   ARIN-2011-4: Reserved Pool for Critical Infrastructure
>   ARIN-2011-5: Shared Transition Space for IPv4 Address Extension
>   ARIN-2011-6: Returned IPv4 Addresses
>
> ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was
> removed. This was an oversight; it was something that was discussed
> before and during Last Call.
>
> The following draft policy remains on the AC's docket (motions to send
> to last call and to abandon were unsuccessful):
>
>   ARIN-2011-1: Globally Coordinated Transfer Policy
>
> The AC selected the following proposal as a draft policy for adoption
> discussion online and at the ARIN XXVIII Public Policy Meeting in
> Philadelphia in October. The draft policy will be posted shortly to the
> PPML.
>
>   ARIN-prop-126 Compliance Requirement
>
> The AC accepted the following proposals on to the AC's docket for
> development and evaluation:
>
>   ARIN-prop-140 Business Failure Clarification
>   ARIN-prop-141 Combined M&A and Specified Transfers
>   ARIN-prop-144 Remove Single Aggregate requirement from Specified 
> Transfer
>   ARIN-prop-146 Clarify Justified Need for Transfers
>   ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception
>
> The AC abandoned the following proposal:
>
>   ARIN-prop-139 No reassignment without network service
>   ARIN-prop-142 Define RSA
>   ARIN-prop-143 Clarify Specified Transfer RSA Requirement
>   ARIN-prop-145 STLS Listing Immunity
>
> The AC chose to abandon prop-139 because the AC determined that there
> was a significant lack of support in the community based on its
> observations of the public policy mailing list. Reasons for the lack of
> support expressed on PPML included the perception that the problems
> addressed by the proposal are not a significant issue in the ARIN
> region, that it would disallow activity generally seen as beneficial,
> that such restrictions would be beyond ARIN's scope, and that the
> restriction may be difficult to enforce.  The author of the proposal
> also suggested abandonment which further underscored the AC's conclusion.
>
> The AC abandoned prop-142 because the majority of the AC felt that the
> RSA is an adjunct document to the NRPM and its definition should not
> reside in policy.
>
> The Advisory Council of ARIN abandoned prop-143: Clarify Specified
> Transfer RSA Requirement. The AC believes that the content and terms of
> contracts between ARIN and holders of address space is an operational
> and legal issue. Prescribing that content is not an appropriate function
> of the ARIN Policy Development Process. The proper avenue for input
> regrading such issues is the ARIN Consultation and Suggestion Process
> (ACSP).
>
> The AC chose to abandon prop-145 because the AC agreed with ARIN staff
> that this is an issue for the terms of service for the STLS and as such
> is outside the scope of the PDP and NRPM.  The AC also believes that
> except in cases of fraud, it is unlikely that ARIN staff would forcibly
> revoke resources that have already been approved to be on the STLS.  The
> AC advises the community to use the ACSP if they would like to provide
> ARIN input on the terms of service for the STLS or the L/RSA.
>
> The AC thanks the authors and the community for their continuing effort
> and contributions to these and all other policy considerations.
>
> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
> with these decisions may initiate a petition. The petition to advance
> these proposals would be the "Discussion Petition." The deadline to
> begin a petition will be five business days after the AC's draft meeting
> minutes are published. For more information on starting and
> participating in petitions, see PDP Petitions at:
> https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
>




From matthew at matthew.at  Thu Jun 16 06:27:26 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 16 Jun 2011 13:27:26 +0300
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <4DF8A5A7.5020604@arin.net>
References: <4DDC0155.6000501@arin.net> <4DF8A5A7.5020604@arin.net>
Message-ID: <733302E1-5C48-4AEF-845C-080100303534@matthew.at>


On Jun 15, 2011, at 3:29 PM, ARIN wrote:

> The minutes of the May meeting of the ARIN Advisory Council are
> available at:
> https://www.arin.net/about_us/ac/index.html
> 
> 
>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>> with these decisions may initiate a petition. The petition to advance
>> these proposals would be the "Discussion Petition." The deadline to
>> begin a petition will be five business days after the AC's draft meeting
>> minutes are published.
> 
> The deadline for petitions is 22 June 2011.

My reading of the minutes suggests that 144 was not in fact abandoned, but that 145 was.

Matthew Kaufman



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

Total of 3 messages in the last 7 days.
 
script run at: Fri Jun 17 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 45.11% |     9126 | info at arin.net
 33.33% |    1 | 27.66% |     5596 | narten at us.ibm.com
 33.33% |    1 | 27.23% |     5508 | matthew at matthew.at
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    20230 | Total


From scottleibrand at gmail.com  Sat Jun 18 19:10:40 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sat, 18 Jun 2011 16:10:40 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <733302E1-5C48-4AEF-845C-080100303534@matthew.at>
References: <4DDC0155.6000501@arin.net> <4DF8A5A7.5020604@arin.net>
	<733302E1-5C48-4AEF-845C-080100303534@matthew.at>
Message-ID: <BANLkTikH1h88J6Dh3BRXgZ2Ych8sZr5Mpw@mail.gmail.com>

On Thu, Jun 16, 2011 at 3:27 AM, Matthew Kaufman <matthew at matthew.at> wrote:
>
> On Jun 15, 2011, at 3:29 PM, ARIN wrote:
>
> > The minutes of the May meeting of the ARIN Advisory Council are
> > available at:
> > https://www.arin.net/about_us/ac/index.html
> >
> >
> >> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
> >> with these decisions may initiate a petition. The petition to advance
> >> these proposals would be the "Discussion Petition." The deadline to
> >> begin a petition will be five business days after the AC's draft meeting
> >> minutes are published.
> >
> > The deadline for petitions is 22 June 2011.
>
> My reading of the minutes suggests that 144 was not in fact abandoned, but that 145 was.

You are correct. ??ARIN-Prop-144: Remove Single Aggregate Requirement
was accepted onto the AC's docket.  ARIN-Prop-145: STLS Listing
Immunity was abandoned by the AC.

-Scott


From owen at delong.com  Sat Jun 18 19:55:19 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 18 Jun 2011 16:55:19 -0700
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM 8.3
Message-ID: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>

There seems to be some confusion (or at least some people perceive some confusion)
around this proposal.

The intent of this proposal is strictly to restore the original community intent to the
"single aggregate" clause in NRPM 8.3.

Under current staff interpretation, the clause is bound to the justification rather than
the resources transferred. The clear and obvious intent of the language is that it
be bound to the resources transferred and not the justification. As such, this proposal
seeks to achieve that end.

Yes, this is in direct opposition to proposal 144 which seeks to remove the single
aggregate clause altogether.

There seems to be perception among some AC members that there is no support
for this proposal in the community, so, I am asking anyone who spoke up and/or
anyone who does support this proposal to state their support for it here on the
list.

Thanks,

Owen



From gary.buhrmaster at gmail.com  Sat Jun 18 20:13:24 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Sun, 19 Jun 2011 00:13:24 +0000
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM
	8.3
In-Reply-To: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
References: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
Message-ID: <BANLkTikTzfzKHQMbO_SuA7KEqfRshBxwjA@mail.gmail.com>

On Sat, Jun 18, 2011 at 23:55, Owen DeLong <owen at delong.com> wrote:
,,,,,
> There seems to be perception among some AC members that there is no support
> for this proposal in the community, so, I am asking anyone who spoke up and/or
> anyone who does support this proposal to state their support for it here on the
> list.


Here is what I said before on this (edited for brevity):

On Sun, May 29, 2011 at 22:54, Gary Buhrmaster
<gary.buhrmaster at gmail.com> wrote:
......
> However, that all said, I think it is important that if the intent
> of the consensus is not being implemented (because of vague
> or inconsistent language), we should try to *just fix that* now
> (and let another policy proposal open all the discussion on
> what is the "right"/"best"/"different" policy).
>
> So, I support this proposal moving forward to correct the
> implementation to match consensus.

....


From matthew at matthew.at  Sat Jun 18 23:12:04 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 18 Jun 2011 20:12:04 -0700
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM
 8.3
In-Reply-To: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
References: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
Message-ID: <4DFD6904.2070700@matthew.at>

On 6/18/2011 4:55 PM, Owen DeLong wrote:
> Under current staff interpretation, the clause is bound to the justification rather than
> the resources transferred. The clear and obvious intent of the language is that it
> be bound to the resources transferred and not the justification. As such, this proposal
> seeks to achieve that end.

Opposed. Just requires lots of serial transfers for no particularly good 
reason, impedes the market for those with legitimate need.

> Yes, this is in direct opposition to proposal 144 which seeks to remove the single
> aggregate clause altogether.

And I'm opposed to 153 no matter how 144 goes.

Matthew Kaufman



From ikiris at gmail.com  Sun Jun 19 00:51:40 2011
From: ikiris at gmail.com (Blake Dunlap)
Date: Sat, 18 Jun 2011 23:51:40 -0500
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM
	8.3
In-Reply-To: <4DFD6904.2070700@matthew.at>
References: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
	<4DFD6904.2070700@matthew.at>
Message-ID: <BANLkTimKMP_93apVOr=UZjv8h1+eAjmqDQ@mail.gmail.com>

Support as it was definitely the community intent when it was passed
originally.

-Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110618/9ab2306f/attachment.htm>

From mike at nationwideinc.com  Sun Jun 19 09:04:02 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Sun, 19 Jun 2011 09:04:02 -0400
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in
	NRPM8.3
References: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
	<4DFD6904.2070700@matthew.at>
Message-ID: <72218DEFDBAF441483AFA4646A41656A@video>



> On 6/18/2011 4:55 PM, Owen DeLong wrote:
>> Under current staff interpretation, the clause is bound to the 
>> justification rather than
>> the resources transferred. The clear and obvious intent of the language 
>> is that it
>> be bound to the resources transferred and not the justification. As such, 
>> this proposal
>> seeks to achieve that end.
>
> Opposed. Just requires lots of serial transfers for no particularly good 
> reason, impedes the market for those with legitimate need.
>
>> Yes, this is in direct opposition to proposal 144 which seeks to remove 
>> the single
>> aggregate clause altogether.
>
> And I'm opposed to 153 no matter how 144 goes.
>
> Matthew Kaufman

I am also opposed to 153.
Although I agree that this was the clear intention of the transfer policy, 
the fact that ARIN staff chose a different interpretation is evidence that 
the policy is too restrictive.

When faced with a real-world legacy transfer which appeared to be on the way 
to the approval of the bankruptcy judge, ARIN was unable to change the 
transaction enough to match policy, and so chose to change policy 
interpretation to match the transaction.

The lesson to be learned from this is that by continuing to have a transfer 
policy which places ARIN in the position of having to approve or disapprove 
a transaction based on things which do not concern the buyer or the seller, 
we run the risk that the buyer and seller will sidestep the process and 
prosecute the deal without notifying ARIN.

I am opposed to any policy which risks off-the-books transactions due to 
transactional impediments.

We all understand the motive of aggregation, which fuels the 
single-aggregate restriction.
But we have to balance that against our primary responsibility (per RFC2050) 
to maintain an accurate Whois registry.

Regards,

Mike Burns



From info at arin.net  Mon Jun 20 14:01:06 2011
From: info at arin.net (ARIN)
Date: Mon, 20 Jun 2011 14:01:06 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <4DF8A5A7.5020604@arin.net>
References: <4DDC0155.6000501@arin.net> <4DF8A5A7.5020604@arin.net>
Message-ID: <4DFF8AE2.6010907@arin.net>

> The AC abandoned proposals 139, 142, 143 and 144.

Correction. The AC abandoned proposals 139, 142, 143 and 145.

The deadline for petitions for these proposals is 22 June 2011.

Regards,

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

ARIN wrote:
> The minutes of the May meeting of the ARIN Advisory Council are
> available at:
> https://www.arin.net/about_us/ac/index.html
>
>
>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>> with these decisions may initiate a petition. The petition to advance
>> these proposals would be the "Discussion Petition." The deadline to
>> begin a petition will be five business days after the AC's draft meeting
>> minutes are published.
>
> The deadline for petitions is 22 June 2011.
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ARIN wrote:
>> In accordance with the ARIN Policy Development Process the ARIN Advisory
>> Council (AC) held a meeting on 19 May 2011 and made decisions about
>> several draft policies and proposals.
>>
>> The AC recommended the following draft policies to the ARIN Board for
>> adoption:
>>
>>   ARIN-2011-3: Better IPv6 Allocations for ISPs (revised)
>>   ARIN-2011-4: Reserved Pool for Critical Infrastructure
>>   ARIN-2011-5: Shared Transition Space for IPv4 Address Extension
>>   ARIN-2011-6: Returned IPv4 Addresses
>>
>> ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was
>> removed. This was an oversight; it was something that was discussed
>> before and during Last Call.
>>
>> The following draft policy remains on the AC's docket (motions to send
>> to last call and to abandon were unsuccessful):
>>
>>   ARIN-2011-1: Globally Coordinated Transfer Policy
>>
>> The AC selected the following proposal as a draft policy for adoption
>> discussion online and at the ARIN XXVIII Public Policy Meeting in
>> Philadelphia in October. The draft policy will be posted shortly to the
>> PPML.
>>
>>   ARIN-prop-126 Compliance Requirement
>>
>> The AC accepted the following proposals on to the AC's docket for
>> development and evaluation:
>>
>>   ARIN-prop-140 Business Failure Clarification
>>   ARIN-prop-141 Combined M&A and Specified Transfers
>>   ARIN-prop-144 Remove Single Aggregate requirement from Specified 
>> Transfer
>>   ARIN-prop-146 Clarify Justified Need for Transfers
>>   ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception
>>
>> The AC abandoned the following proposal:
>>
>>   ARIN-prop-139 No reassignment without network service
>>   ARIN-prop-142 Define RSA
>>   ARIN-prop-143 Clarify Specified Transfer RSA Requirement
>>   ARIN-prop-145 STLS Listing Immunity
>>
>> The AC chose to abandon prop-139 because the AC determined that there
>> was a significant lack of support in the community based on its
>> observations of the public policy mailing list. Reasons for the lack of
>> support expressed on PPML included the perception that the problems
>> addressed by the proposal are not a significant issue in the ARIN
>> region, that it would disallow activity generally seen as beneficial,
>> that such restrictions would be beyond ARIN's scope, and that the
>> restriction may be difficult to enforce.  The author of the proposal
>> also suggested abandonment which further underscored the AC's 
>> conclusion.
>>
>> The AC abandoned prop-142 because the majority of the AC felt that the
>> RSA is an adjunct document to the NRPM and its definition should not
>> reside in policy.
>>
>> The Advisory Council of ARIN abandoned prop-143: Clarify Specified
>> Transfer RSA Requirement. The AC believes that the content and terms of
>> contracts between ARIN and holders of address space is an operational
>> and legal issue. Prescribing that content is not an appropriate function
>> of the ARIN Policy Development Process. The proper avenue for input
>> regrading such issues is the ARIN Consultation and Suggestion Process
>> (ACSP).
>>
>> The AC chose to abandon prop-145 because the AC agreed with ARIN staff
>> that this is an issue for the terms of service for the STLS and as such
>> is outside the scope of the PDP and NRPM.  The AC also believes that
>> except in cases of fraud, it is unlikely that ARIN staff would forcibly
>> revoke resources that have already been approved to be on the STLS.  The
>> AC advises the community to use the ACSP if they would like to provide
>> ARIN input on the terms of service for the STLS or the L/RSA.
>>
>> The AC thanks the authors and the community for their continuing effort
>> and contributions to these and all other policy considerations.
>>
>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>> with these decisions may initiate a petition. The petition to advance
>> these proposals would be the "Discussion Petition." The deadline to
>> begin a petition will be five business days after the AC's draft meeting
>> minutes are published. For more information on starting and
>> participating in petitions, see PDP Petitions at:
>> https://www.arin.net/policy/pdp_petitions.html
>>
>> Draft Policy and Proposal texts are available at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>



From hannigan at gmail.com  Mon Jun 20 15:01:40 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 20 Jun 2011 15:01:40 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <4DFF8AE2.6010907@arin.net>
References: <4DDC0155.6000501@arin.net> <4DF8A5A7.5020604@arin.net>
	<4DFF8AE2.6010907@arin.net>
Message-ID: <BANLkTikWTcmVWqoUFsDT0QSDysaHFLDDug@mail.gmail.com>

145 is ARIN-prop-145 STLS Listing Immunity. Procedurally, shouldn't
the date for petition be extended based on the official reporting
error?

I voted against this proposal, but in fairness to future proposals, it
might be worth examining a procedural remedy as well as this official
correction. Or not.


Best,

-M<



On Mon, Jun 20, 2011 at 2:01 PM, ARIN <info at arin.net> wrote:
>> The AC abandoned proposals 139, 142, 143 and 144.
>
> Correction. The AC abandoned proposals 139, 142, 143 and 145.
>
> The deadline for petitions for these proposals is 22 June 2011.
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
> ARIN wrote:
>>
>> The minutes of the May meeting of the ARIN Advisory Council are
>> available at:
>> https://www.arin.net/about_us/ac/index.html
>>
>>
>>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>>> with these decisions may initiate a petition. The petition to advance
>>> these proposals would be the "Discussion Petition." The deadline to
>>> begin a petition will be five business days after the AC's draft meeting
>>> minutes are published.
>>
>> The deadline for petitions is 22 June 2011.
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ARIN wrote:
>>>
>>> In accordance with the ARIN Policy Development Process the ARIN Advisory
>>> Council (AC) held a meeting on 19 May 2011 and made decisions about
>>> several draft policies and proposals.
>>>
>>> The AC recommended the following draft policies to the ARIN Board for
>>> adoption:
>>>
>>> ?ARIN-2011-3: Better IPv6 Allocations for ISPs (revised)
>>> ?ARIN-2011-4: Reserved Pool for Critical Infrastructure
>>> ?ARIN-2011-5: Shared Transition Space for IPv4 Address Extension
>>> ?ARIN-2011-6: Returned IPv4 Addresses
>>>
>>> ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was
>>> removed. This was an oversight; it was something that was discussed
>>> before and during Last Call.
>>>
>>> The following draft policy remains on the AC's docket (motions to send
>>> to last call and to abandon were unsuccessful):
>>>
>>> ?ARIN-2011-1: Globally Coordinated Transfer Policy
>>>
>>> The AC selected the following proposal as a draft policy for adoption
>>> discussion online and at the ARIN XXVIII Public Policy Meeting in
>>> Philadelphia in October. The draft policy will be posted shortly to the
>>> PPML.
>>>
>>> ?ARIN-prop-126 Compliance Requirement
>>>
>>> The AC accepted the following proposals on to the AC's docket for
>>> development and evaluation:
>>>
>>> ?ARIN-prop-140 Business Failure Clarification
>>> ?ARIN-prop-141 Combined M&A and Specified Transfers
>>> ?ARIN-prop-144 Remove Single Aggregate requirement from Specified
>>> Transfer
>>> ?ARIN-prop-146 Clarify Justified Need for Transfers
>>> ?ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception
>>>
>>> The AC abandoned the following proposal:
>>>
>>> ?ARIN-prop-139 No reassignment without network service
>>> ?ARIN-prop-142 Define RSA
>>> ?ARIN-prop-143 Clarify Specified Transfer RSA Requirement
>>> ?ARIN-prop-145 STLS Listing Immunity
>>>
>>> The AC chose to abandon prop-139 because the AC determined that there
>>> was a significant lack of support in the community based on its
>>> observations of the public policy mailing list. Reasons for the lack of
>>> support expressed on PPML included the perception that the problems
>>> addressed by the proposal are not a significant issue in the ARIN
>>> region, that it would disallow activity generally seen as beneficial,
>>> that such restrictions would be beyond ARIN's scope, and that the
>>> restriction may be difficult to enforce. ?The author of the proposal
>>> also suggested abandonment which further underscored the AC's conclusion.
>>>
>>> The AC abandoned prop-142 because the majority of the AC felt that the
>>> RSA is an adjunct document to the NRPM and its definition should not
>>> reside in policy.
>>>
>>> The Advisory Council of ARIN abandoned prop-143: Clarify Specified
>>> Transfer RSA Requirement. The AC believes that the content and terms of
>>> contracts between ARIN and holders of address space is an operational
>>> and legal issue. Prescribing that content is not an appropriate function
>>> of the ARIN Policy Development Process. The proper avenue for input
>>> regrading such issues is the ARIN Consultation and Suggestion Process
>>> (ACSP).
>>>
>>> The AC chose to abandon prop-145 because the AC agreed with ARIN staff
>>> that this is an issue for the terms of service for the STLS and as such
>>> is outside the scope of the PDP and NRPM. ?The AC also believes that
>>> except in cases of fraud, it is unlikely that ARIN staff would forcibly
>>> revoke resources that have already been approved to be on the STLS. ?The
>>> AC advises the community to use the ACSP if they would like to provide
>>> ARIN input on the terms of service for the STLS or the L/RSA.
>>>
>>> The AC thanks the authors and the community for their continuing effort
>>> and contributions to these and all other policy considerations.
>>>
>>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>>> with these decisions may initiate a petition. The petition to advance
>>> these proposals would be the "Discussion Petition." The deadline to
>>> begin a petition will be five business days after the AC's draft meeting
>>> minutes are published. For more information on starting and
>>> participating in petitions, see PDP Petitions at:
>>> https://www.arin.net/policy/pdp_petitions.html
>>>
>>> Draft Policy and Proposal texts are available at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> Regards,
>>>
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From owen at delong.com  Mon Jun 20 16:29:38 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 20 Jun 2011 13:29:38 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - May 2011
In-Reply-To: <BANLkTikWTcmVWqoUFsDT0QSDysaHFLDDug@mail.gmail.com>
References: <4DDC0155.6000501@arin.net> <4DF8A5A7.5020604@arin.net>
	<4DFF8AE2.6010907@arin.net>
	<BANLkTikWTcmVWqoUFsDT0QSDysaHFLDDug@mail.gmail.com>
Message-ID: <ADBD19B1-2B10-4C79-B9D3-5D8EC72384A5@delong.com>

No... THe date is based on when it comes out in the minutes. The reporting
error did not affect the minutes or the date the minutes were published.

Owen

On Jun 20, 2011, at 12:01 PM, Martin Hannigan wrote:

> 145 is ARIN-prop-145 STLS Listing Immunity. Procedurally, shouldn't
> the date for petition be extended based on the official reporting
> error?
> 
> I voted against this proposal, but in fairness to future proposals, it
> might be worth examining a procedural remedy as well as this official
> correction. Or not.
> 
> 
> Best,
> 
> -M<
> 
> 
> 
> On Mon, Jun 20, 2011 at 2:01 PM, ARIN <info at arin.net> wrote:
>>> The AC abandoned proposals 139, 142, 143 and 144.
>> 
>> Correction. The AC abandoned proposals 139, 142, 143 and 145.
>> 
>> The deadline for petitions for these proposals is 22 June 2011.
>> 
>> Regards,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> ARIN wrote:
>>> 
>>> The minutes of the May meeting of the ARIN Advisory Council are
>>> available at:
>>> https://www.arin.net/about_us/ac/index.html
>>> 
>>> 
>>>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>>>> with these decisions may initiate a petition. The petition to advance
>>>> these proposals would be the "Discussion Petition." The deadline to
>>>> begin a petition will be five business days after the AC's draft meeting
>>>> minutes are published.
>>> 
>>> The deadline for petitions is 22 June 2011.
>>> 
>>> Regards,
>>> 
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> 
>>> ARIN wrote:
>>>> 
>>>> In accordance with the ARIN Policy Development Process the ARIN Advisory
>>>> Council (AC) held a meeting on 19 May 2011 and made decisions about
>>>> several draft policies and proposals.
>>>> 
>>>> The AC recommended the following draft policies to the ARIN Board for
>>>> adoption:
>>>> 
>>>>  ARIN-2011-3: Better IPv6 Allocations for ISPs (revised)
>>>>  ARIN-2011-4: Reserved Pool for Critical Infrastructure
>>>>  ARIN-2011-5: Shared Transition Space for IPv4 Address Extension
>>>>  ARIN-2011-6: Returned IPv4 Addresses
>>>> 
>>>> ARIN-2011-3 was revised. The renumbering requirement in 6.5.7 was
>>>> removed. This was an oversight; it was something that was discussed
>>>> before and during Last Call.
>>>> 
>>>> The following draft policy remains on the AC's docket (motions to send
>>>> to last call and to abandon were unsuccessful):
>>>> 
>>>>  ARIN-2011-1: Globally Coordinated Transfer Policy
>>>> 
>>>> The AC selected the following proposal as a draft policy for adoption
>>>> discussion online and at the ARIN XXVIII Public Policy Meeting in
>>>> Philadelphia in October. The draft policy will be posted shortly to the
>>>> PPML.
>>>> 
>>>>  ARIN-prop-126 Compliance Requirement
>>>> 
>>>> The AC accepted the following proposals on to the AC's docket for
>>>> development and evaluation:
>>>> 
>>>>  ARIN-prop-140 Business Failure Clarification
>>>>  ARIN-prop-141 Combined M&A and Specified Transfers
>>>>  ARIN-prop-144 Remove Single Aggregate requirement from Specified
>>>> Transfer
>>>>  ARIN-prop-146 Clarify Justified Need for Transfers
>>>>  ARIN-prop-147 Set Transfer Need to 24 months and Clarify Exception
>>>> 
>>>> The AC abandoned the following proposal:
>>>> 
>>>>  ARIN-prop-139 No reassignment without network service
>>>>  ARIN-prop-142 Define RSA
>>>>  ARIN-prop-143 Clarify Specified Transfer RSA Requirement
>>>>  ARIN-prop-145 STLS Listing Immunity
>>>> 
>>>> The AC chose to abandon prop-139 because the AC determined that there
>>>> was a significant lack of support in the community based on its
>>>> observations of the public policy mailing list. Reasons for the lack of
>>>> support expressed on PPML included the perception that the problems
>>>> addressed by the proposal are not a significant issue in the ARIN
>>>> region, that it would disallow activity generally seen as beneficial,
>>>> that such restrictions would be beyond ARIN's scope, and that the
>>>> restriction may be difficult to enforce.  The author of the proposal
>>>> also suggested abandonment which further underscored the AC's conclusion.
>>>> 
>>>> The AC abandoned prop-142 because the majority of the AC felt that the
>>>> RSA is an adjunct document to the NRPM and its definition should not
>>>> reside in policy.
>>>> 
>>>> The Advisory Council of ARIN abandoned prop-143: Clarify Specified
>>>> Transfer RSA Requirement. The AC believes that the content and terms of
>>>> contracts between ARIN and holders of address space is an operational
>>>> and legal issue. Prescribing that content is not an appropriate function
>>>> of the ARIN Policy Development Process. The proper avenue for input
>>>> regrading such issues is the ARIN Consultation and Suggestion Process
>>>> (ACSP).
>>>> 
>>>> The AC chose to abandon prop-145 because the AC agreed with ARIN staff
>>>> that this is an issue for the terms of service for the STLS and as such
>>>> is outside the scope of the PDP and NRPM.  The AC also believes that
>>>> except in cases of fraud, it is unlikely that ARIN staff would forcibly
>>>> revoke resources that have already been approved to be on the STLS.  The
>>>> AC advises the community to use the ACSP if they would like to provide
>>>> ARIN input on the terms of service for the STLS or the L/RSA.
>>>> 
>>>> The AC thanks the authors and the community for their continuing effort
>>>> and contributions to these and all other policy considerations.
>>>> 
>>>> The AC abandoned proposals 139, 142, 143 and 144. Anyone dissatisfied
>>>> with these decisions may initiate a petition. The petition to advance
>>>> these proposals would be the "Discussion Petition." The deadline to
>>>> begin a petition will be five business days after the AC's draft meeting
>>>> minutes are published. For more information on starting and
>>>> participating in petitions, see PDP Petitions at:
>>>> https://www.arin.net/policy/pdp_petitions.html
>>>> 
>>>> Draft Policy and Proposal texts are available at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>> 
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>> 
>>>> Regards,
>>>> 
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 frnkblk at iname.com  Tue Jun 21 00:13:57 2011
From: frnkblk at iname.com (Frank Bulk)
Date: Mon, 20 Jun 2011 23:13:57 -0500
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM
	8.3
In-Reply-To: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
References: <8EB07668-8345-4E4F-BA6C-FAFB13A795EE@delong.com>
Message-ID: <001501cc2fc9$a412cfd0$ec386f70$@iname.com>

Support.  This was the community's intent.  

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Saturday, June 18, 2011 6:55 PM
To: arin ppml
Subject: [arin-ppml] Proposition 153 -- Correct erroneous syntax in NRPM 8.3

There seems to be some confusion (or at least some people perceive some
confusion)
around this proposal.

The intent of this proposal is strictly to restore the original community
intent to the
"single aggregate" clause in NRPM 8.3.

Under current staff interpretation, the clause is bound to the justification
rather than
the resources transferred. The clear and obvious intent of the language is
that it
be bound to the resources transferred and not the justification. As such,
this proposal
seeks to achieve that end.

Yes, this is in direct opposition to proposal 144 which seeks to remove the
single
aggregate clause altogether.

There seems to be perception among some AC members that there is no support
for this proposal in the community, so, I am asking anyone who spoke up
and/or
anyone who does support this proposal to state their support for it here on
the
list.

Thanks,

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 BillD at cait.wustl.edu  Tue Jun 21 10:30:24 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 21 Jun 2011 09:30:24 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers - Shepherd's
	Inquiry
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>

Hello,

Please provide you immediate, concise feeback which states your position
for or against the DP as changed from its earlier version and any
reasoning you may wish to provide.

I am proposing that the original Draft Policy 2011-1: Globally
Coordinated Transfer Policy
<https://www.arin.net/policy/proposals/2011_1.html>  ....

Be renamed.... Draft Policy 2011-1: Inter-RIR Transfers...

and that the DP text be modified to the following to accommodate the
many insights and concerns shared with me and the AC by members of the
community and the AC itself.

"Address resources may be transferred.... in or out of the ARIN region
to those who demonstrate need and plan to deploy them for a networking
purpose within 3 months. Such transfers will take place between RIRs who
share compatible, needs-based policies on behalf of entities agreeing to
the transfer and which otherwise meet both RIR's policies. Transferred
resources will become part of the resource holdings of the recipient RIR
unless otherwise agreed by both RIRs."

Reasoning....It is explicit about..

in or out of region,
that transfers are between RIRs that support needs-based policies, 
that RIRs have to agree, 
that parties meet all of both RIR policies 
that it is needs based, and the need is for a networking purpose, 
that the receiving RIR is entitled to the addresses

I think all these details were raised as objections at one time or
another...so it seems best to waste a few more words to be explicit.

It is not explicit about...
block sizes
utilization of prior allocations, assignments or transfers
RFC 2050
subsequent transfers

Nor should it be, IMO

Thank you for your continuing involvement in the ARIN Policy Development
Process.

Best,

Bill Darte
Primary Shepherd DP 2011-1

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

From mike at nationwideinc.com  Tue Jun 21 11:14:14 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 21 Jun 2011 11:14:14 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd'sInquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
Message-ID: <F0AA69554939428FB349AE72ED425CAD@mike>

Hello Bill,

Opposed because it prevents the regions with the largest number of allocations from transferring to the region with the highest demand due to language about needs-based policies.
Stewards of these  resources should seek cooperation between regions and not seek to exacerbate nuances of difference about views of stewardship at the cost of ostracizing those who think differently.
Is it really necessary to poke APNIC in the eye just because their stewards consider these needs policies a risk to Whois accuracy?
Even if we believe their conclusion is wrong, is it worth the discord engendered by the proposed language?
Can't we operate on the basis that each registry community is acting as honest stewards and not erect barriers when we disagree?

I mean, we still have to agree to any transfers. Leaving us free to make decisions based on individual circumstances, rather than explicitly excluding all Asian transfers.

All we are doing is driving such transfers underground.

(Since Bill is looking for concise feedback and not a rehash of prior discussions, please consider my questions rhetorical.)

Maybe I would change the language from "needs-based policies on behalf of entities" to "needs-based policies applying to entities" because I think it is more accurate.

Regards,
Mike Burns










  ----- Original Message ----- 
  From: Bill Darte 
  To: arin ppml 
  Cc: Robert E. Seastrom 
  Sent: Tuesday, June 21, 2011 10:30 AM
  Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers - Shepherd'sInquiry


  Hello,

  Please provide you immediate, concise feeback which states your position for or against the DP as changed from its earlier version and any reasoning you may wish to provide.

  I am proposing that the original Draft Policy 2011-1: Globally Coordinated Transfer Policy ....

  Be renamed.... Draft Policy 2011-1: Inter-RIR Transfers...

  and that the DP text be modified to the following to accommodate the many insights and concerns shared with me and the AC by members of the community and the AC itself.

  "Address resources may be transferred.... in or out of the ARIN region to those who demonstrate need and plan to deploy them for a networking purpose within 3 months. Such transfers will take place between RIRs who share compatible, needs-based policies on behalf of entities agreeing to the transfer and which otherwise meet both RIR's policies. Transferred resources will become part of the resource holdings of the recipient RIR unless otherwise agreed by both RIRs."

  Reasoning....It is explicit about..

  in or out of region,
  that transfers are between RIRs that support needs-based policies, 
  that RIRs have to agree, 
  that parties meet all of both RIR policies 
  that it is needs based, and the need is for a networking purpose, 
  that the receiving RIR is entitled to the addresses

  I think all these details were raised as objections at one time or another...so it seems best to waste a few more words to be explicit.

  It is not explicit about...
  block sizes
  utilization of prior allocations, assignments or transfers
  RFC 2050
  subsequent transfers

  Nor should it be, IMO

  Thank you for your continuing involvement in the ARIN Policy Development Process.

  Best,

  Bill Darte
  Primary Shepherd DP 2011-1



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


  _______________________________________________
  PPML
  You are receiving this message because you are subscribed to
  the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
  Unsubscribe or manage 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/20110621/6005d0ea/attachment.htm>

From BillD at cait.wustl.edu  Tue Jun 21 11:20:51 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 21 Jun 2011 10:20:51 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd'sInquiry
In-Reply-To: <F0AA69554939428FB349AE72ED425CAD@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<F0AA69554939428FB349AE72ED425CAD@mike>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA13C@ex1.cait.wustl.edu>

Mike,
 
Thanks for your reply and the crispness with which you stated your
objection.  I think this is precisely the sort of feedback I and the
community are looking for (and need) in order to go into the Philly
meeting with a chance to finally debate the really pertinent sticking
points, resolve to act, and do so to get an Inter-RIR transfer policy in
place.
 
bd


________________________________

	From: Mike Burns [mailto:mike at nationwideinc.com] 
	Sent: Tuesday, June 21, 2011 10:14 AM
	To: Bill Darte; arin ppml
	Cc: Robert E. Seastrom
	Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
Transfers - Shepherd'sInquiry
	
	
	Hello Bill,
	 
	Opposed because it prevents the regions with the largest number
of allocations from transferring to the region with the highest demand
due to language about needs-based policies.
	Stewards of these  resources should seek cooperation between
regions and not seek to exacerbate nuances of difference about views of
stewardship at the cost of ostracizing those who think differently.
	Is it really necessary to poke APNIC in the eye just because
their stewards consider these needs policies a risk to Whois accuracy?
	Even if we believe their conclusion is wrong, is it worth the
discord engendered by the proposed language?
	Can't we operate on the basis that each registry community is
acting as honest stewards and not erect barriers when we disagree?
	 
	I mean, we still have to agree to any transfers. Leaving us free
to make decisions based on individual circumstances, rather than
explicitly excluding all Asian transfers.
	 
	All we are doing is driving such transfers underground.
	 
	(Since Bill is looking for concise feedback and not a rehash of
prior discussions, please consider my questions rhetorical.)
	 
	Maybe I would change the language from "needs-based policies on
behalf of entities" to "needs-based policies applying to entities"
because I think it is more accurate.
	 
	Regards,
	Mike Burns
	 
	 
	 
	 
	 
	 
	 
	 
	 
	 

		----- Original Message ----- 
		From: Bill Darte <mailto:BillD at cait.wustl.edu>  
		To: arin ppml <mailto:ppml at arin.net>  
		Cc: Robert E. Seastrom <mailto:rs at seastrom.com>  
		Sent: Tuesday, June 21, 2011 10:30 AM
		Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
Transfers - Shepherd'sInquiry

		Hello,

		Please provide you immediate, concise feeback which
states your position for or against the DP as changed from its earlier
version and any reasoning you may wish to provide.

		I am proposing that the original Draft Policy 2011-1:
Globally Coordinated Transfer Policy
<https://www.arin.net/policy/proposals/2011_1.html>  ....

		Be renamed.... Draft Policy 2011-1: Inter-RIR
Transfers...

		and that the DP text be modified to the following to
accommodate the many insights and concerns shared with me and the AC by
members of the community and the AC itself.

		"Address resources may be transferred.... in or out of
the ARIN region to those who demonstrate need and plan to deploy them
for a networking purpose within 3 months. Such transfers will take place
between RIRs who share compatible, needs-based policies on behalf of
entities agreeing to the transfer and which otherwise meet both RIR's
policies. Transferred resources will become part of the resource
holdings of the recipient RIR unless otherwise agreed by both RIRs."

		Reasoning....It is explicit about..

		in or out of region,
		that transfers are between RIRs that support needs-based
policies, 
		that RIRs have to agree, 
		that parties meet all of both RIR policies 
		that it is needs based, and the need is for a networking
purpose, 
		that the receiving RIR is entitled to the addresses

		I think all these details were raised as objections at
one time or another...so it seems best to waste a few more words to be
explicit.

		It is not explicit about...
		block sizes
		utilization of prior allocations, assignments or
transfers
		RFC 2050
		subsequent transfers

		Nor should it be, IMO

		Thank you for your continuing involvement in the ARIN
Policy Development Process.

		Best,

		Bill Darte
		Primary Shepherd DP 2011-1

		
________________________________


		

		_______________________________________________
		PPML
		You are receiving this message because you are
subscribed to
		the ARIN Public Policy Mailing List
(ARIN-PPML at arin.net).
		Unsubscribe or manage 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/20110621/555eda71/attachment.htm>

From joe at oregon.uoregon.edu  Tue Jun 21 10:49:12 2011
From: joe at oregon.uoregon.edu (Joe St Sauver)
Date: Tue, 21 Jun 2011 07:49:12 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
Message-ID: <11062107491193_F0DA@oregon.uoregon.edu>

Regarding "Draft Policy 2011-1: Inter-RIR Transfers"

and the proviso that:

   "Address resources may be transferred.... in or out of the ARIN region
   to those who demonstrate need and plan to deploy them for a networking
   purpose within 3 months. Such transfers will take place between RIRs who
   share compatible, needs-based policies on behalf of entities agreeing to
   the transfer and which otherwise meet both RIR's policies. Transferred
   resources will become part of the resource holdings of the recipient RIR
   unless otherwise agreed by both RIRs."

I am opposed to inter-RIR transfer policies, including this one. Let me
mention just a few reasons why.


I. Resource Firebreak Issues.

In thinking about this and similar policies, consider where addresses would 
likely come from and where addresses would probably go given current 
circumstances (and assuming that all RIRs agreed to participate in the 
policy).

RIRs with remaining IPv4 address resources ("supplier RIRs")

-- AFRINIC
-- LACNIC

RIRs with a likely immediate-term demand for additional IPv4 addresses
("consumer RIRs"):

-- APNIC
-- RIPE NCC
-- ARIN

Thus the flow of address space would thus likely be *from* the developing
nations of the southern hemisphere (except Australasia) *to* the developed 
nations of the northern hemisphere.

Countries in the southern hemisphere (which have historically been handicapped 
by the high price of connectivity) have just recently begun to see improved
fiber access and a resulting drop in market prices. With their large areas 
and large populations, they will likely have a substantial demand for number 
resources in most forseeable medium-term scenarios. If the critical resources
they will eventually require will have been "exported" piece meal to Asia, 
Europe, or North America, our southern-hemisphere neighbors will find it hard 
to realize their full potential as Internet citizens.

The existing region-based RIR system thus serves as a "firebreak" of sorts, 
protecting each RIR's resources from being treated as one common comingled 
pool that can be (effectively) drawn down in its entirity by any region
willing to do so.

I don't want to see that "firebreak," small though it may be, breached. I 
think it serves an important purpose when it comes to protecting resources 
in developing regions such as AFRINIC and LACNIC.


II. Additional Resources Should Not Be Allowed to Potential Feed Regions 
with Unchecked Abuse Issues.

Some have also argued that RIRs vary substantially when it comes to 
their interest in policing number resource misue and abuse. An interesting
exercise when it comes to measuring one dimension of that issue is to go to 
Spamhaus and see how many SBL listings are associated with each of
the RIRs. At the time I checked just now:

-- http://www.spamhaus.org/sbl/listings.lasso?isp=afrinic
   4 listings

-- http://www.spamhaus.org/sbl/listings.lasso?isp=apnic
   18 listings

-- http://www.spamhaus.org/sbl/listings.lasso?isp=lacnic
   28 listings

-- http://www.spamhaus.org/sbl/listings.lasso?isp=arin
   250 listings

-- http://www.spamhaus.org/sbl/listings.lasso?isp=ripe
   I quote, "has far too many records to list. This ISP has an extremely
   serious spam problem."

Although I've looked at a LOT of SBL listings over the years, this is
absolutely the first and ONLY time I've EVER seen a "too many to list"
response from the Spamhaus by-ISP SBL listings.

Thus, I would also oppose inter-RIR transfers if those transfers might
potentially serve to enable further messaging abuse by supplying "raw 
materials" to areas where number resources are apparently experiencing 
rampant abuse. (If all or many of those issues have been taken care of, 
and Spamhaus is just running behind on removals, my apologies)


III. Tracking and Documenting Address Usage Becomes Harder.

Currently it is possible to track address usage because we know (at 
a /8 granularity) which regions have a given block. If we suddenly
begin allowing /16s here and /19s there to be carved off and transfer
out or transfered in, our ability to track usage by region will quickly
be lost (or become a tiresome and highly granular bookkeeping exercise).

Moreover, IP whois currently relies on that assignment by /8s to 
direct IP whois queries to an appropriate RIR whois server. If inter
region transfers are allowed, whois queries will now potentially need
to support still more redirection, and protection against whois 
redirection loops will likely even become necessary. And do we want 
the RIRs to need to update their whois to deal with (redirect) thousands 
or tens of thousands of tiny blocks that may be transfered out of region? 
Jeez, again, what a bookkeeping mess!


For all these and other reasons, I oppose inter-RIR transfers, including
the current proposed policy.

Thanks for considering these comments,

Regards,

Joe

Disclaimer: all opinions expressed are strictly my own and do not 
necessarily represent the opinion of any other organization or entity.


From bill at herrin.us  Tue Jun 21 12:25:38 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 21 Jun 2011 12:25:38 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
Message-ID: <BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>

On Tue, Jun 21, 2011 at 10:30 AM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Please provide you immediate, concise feeback which states your position for
> or against the DP as changed from its earlier version and any reasoning you
> may wish to provide.
>
> "Address resources may be transferred.... in or out of the ARIN region to
> those who demonstrate need and plan to deploy them for a networking purpose
> within 3 months. Such transfers will take place between RIRs who share
> compatible, needs-based policies on behalf of entities agreeing to the
> transfer and which otherwise meet both RIR's policies. Transferred resources
> will become part of the resource holdings of the recipient RIR unless
> otherwise agreed by both RIRs."

Hi Bill,

Oppose.

1. "compatible needs-based policies" is too vague to enforce.
Including "needs-based" is nothing more than a poison pill aimed at
APNIC but even if you take that out, how the heck is ARIN supposed to
determine when another region's policies are "compatible?" The focus
belongs on the registrant who either meets both registries' policies
for receiving addresses or he doesn't.

Other than that, the language looks reasonable to me.

2. The timing of this proposal is bad. Pushing this policy prior to
the exhaustion of ARIN's free pool invites an out-region address grab.
This draft policy belongs on next year's agenda when the only
addresses left to move are registrant to registrant transfers.

Regards,
Bill Herrin



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


From owen at delong.com  Tue Jun 21 12:34:20 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2011 09:34:20 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
Message-ID: <69B95946-460C-44F2-8023-B0643230B791@delong.com>


On Jun 21, 2011, at 9:25 AM, William Herrin wrote:

> On Tue, Jun 21, 2011 at 10:30 AM, Bill Darte <BillD at cait.wustl.edu> wrote:
>> Please provide you immediate, concise feeback which states your position for
>> or against the DP as changed from its earlier version and any reasoning you
>> may wish to provide.
>> 
>> "Address resources may be transferred.... in or out of the ARIN region to
>> those who demonstrate need and plan to deploy them for a networking purpose
>> within 3 months. Such transfers will take place between RIRs who share
>> compatible, needs-based policies on behalf of entities agreeing to the
>> transfer and which otherwise meet both RIR's policies. Transferred resources
>> will become part of the resource holdings of the recipient RIR unless
>> otherwise agreed by both RIRs."
> 
> Hi Bill,
> 
> Oppose.
> 
> 1. "compatible needs-based policies" is too vague to enforce.
> Including "needs-based" is nothing more than a poison pill aimed at
> APNIC but even if you take that out, how the heck is ARIN supposed to
> determine when another region's policies are "compatible?" The focus
> belongs on the registrant who either meets both registries' policies
> for receiving addresses or he doesn't.
> 
The problem with that approach is that it doesn't prevent the target
registrant from subsequently transferring the addresses according only
to the local RIR's policy and then coming back for another inter-RIR
transfer.

> Other than that, the language looks reasonable to me.
> 
> 2. The timing of this proposal is bad. Pushing this policy prior to
> the exhaustion of ARIN's free pool invites an out-region address grab.
> This draft policy belongs on next year's agenda when the only
> addresses left to move are registrant to registrant transfers.
> 
There is at least one region where this is already the case. As such,
the policy is timely now. Admittedly this policy as written would not
help that region unless they choose to restore a needs-basis to
their policy framework, but I don't see any way to allow transfers
and preserve needs basis on the resources unless that is a
requirement.

Owen



From hannigan at gmail.com  Tue Jun 21 12:51:11 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 12:51:11 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
Message-ID: <BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>

On Tue, Jun 21, 2011 at 10:30 AM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Hello,
>
> Please provide you immediate, concise feeback which states your position for
> or against the DP as changed from its earlier version and any reasoning you
> may wish to provide.
>
> I am proposing that the original Draft Policy 2011-1: Globally Coordinated
> Transfer Policy?....
>
> Be renamed.... Draft Policy 2011-1: Inter-RIR Transfers...


[ clip ]

>
> Reasoning....It is explicit about..

>
> in or out of region,
> that transfers are between RIRs that support needs-based policies,
> that RIRs have to agree,
> that parties meet all of both RIR policies
> that it is needs based, and the need is for a networking purpose,
> that the receiving RIR is entitled to the addresses
>
> I think all these details were raised as objections at one time or
> another...so it seems best to waste a few more words to be explicit.
>
> It is not explicit about...
> block sizes
> utilization of prior allocations, assignments or transfers
> RFC 2050
> subsequent transfers
>
> Nor should it be, IMO

What about transfers that are later returned to the RIR that received?
What about addresses that were transferred en masse to an RIR that
suddenly changes its policies (as they are more than entitled to) and
abandons needs as a basis for allocations and proceeds to profit from
the addresses? These aren't hypothetical considerations. What about
regions that have more than adequate addresses to facilitate regional
needs considering that some are locking down their addresses to be
used in-region only? There are a lot of unanswered questions with
respect to this proposal regardless of what it may be named.

I've read Mike Burns comments. I agree with him, mostly, be he seems
to argue (knowingly or not) for allowing market forces to operate as
they would which doesn't require a policy like this. Others are
arguing that we need to "help other regions". I agree, but sending our
colleagues life rafts with holes in them won't help.

I'm not in favor of this proposal. Renaming this policy and
resuscitating it from certain death globally is an inadequate way to
address all of the complicated questions that may/would/continue to be
asked in order to move it through those difficult processes regardless
of which policy regime supporters attempt to push it through.

There also appears to be a lack of agreement in the community and on the AC:

"The motion to forward to Last Call failed with 8 against (DA, OD, DF,
MH, SH, CM, BS, JS) and 3 in favor (SL, BD, CG) via roll call."

Is abandonment on the table? If not, why would we not consider abandoning?


Best,

-M<


From bill at herrin.us  Tue Jun 21 13:37:04 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 21 Jun 2011 13:37:04 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <69B95946-460C-44F2-8023-B0643230B791@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<69B95946-460C-44F2-8023-B0643230B791@delong.com>
Message-ID: <BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>

On Tue, Jun 21, 2011 at 12:34 PM, Owen DeLong <owen at delong.com> wrote:
> On Jun 21, 2011, at 9:25 AM, William Herrin wrote:
>> Oppose.
>>
>> 1. "compatible needs-based policies" is too vague to enforce.
>> Including "needs-based" is nothing more than a poison pill aimed at
>> APNIC but even if you take that out, how the heck is ARIN supposed to
>> determine when another region's policies are "compatible?" The focus
>> belongs on the registrant who either meets both registries' policies
>> for receiving addresses or he doesn't.
>>
> The problem with that approach is that it doesn't prevent the target
> registrant from subsequently transferring the addresses according only
> to the local RIR's policy and then coming back for another inter-RIR
> transfer.

Hi Owen,

Then that problem exists in ARIN policy and should be corrected in
ARIN policy so that ARIN considers the disposition of all current and
previously allocated resources when approving a new one. Otherwise
you're asking folks in other regions to meet a higher standard than
folks in our own region.


>> 2. The timing of this proposal is bad. Pushing this policy prior to
>> the exhaustion of ARIN's free pool invites an out-region address grab.
>> This draft policy belongs on next year's agenda when the only
>> addresses left to move are registrant to registrant transfers.
>>
> There is at least one region where this is already the case. As such,
> the policy is timely now.

There's a region in which ARIN's free pool is exhausted? Which one?

Regards,
Bill Herrin


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


From owen at delong.com  Tue Jun 21 14:23:37 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2011 11:23:37 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<69B95946-460C-44F2-8023-B0643230B791@delong.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
Message-ID: <D1DC7B29-1EBE-46A2-8487-DDEBF87E2F0F@delong.com>


On Jun 21, 2011, at 10:37 AM, William Herrin wrote:

> On Tue, Jun 21, 2011 at 12:34 PM, Owen DeLong <owen at delong.com> wrote:
>> On Jun 21, 2011, at 9:25 AM, William Herrin wrote:
>>> Oppose.
>>> 
>>> 1. "compatible needs-based policies" is too vague to enforce.
>>> Including "needs-based" is nothing more than a poison pill aimed at
>>> APNIC but even if you take that out, how the heck is ARIN supposed to
>>> determine when another region's policies are "compatible?" The focus
>>> belongs on the registrant who either meets both registries' policies
>>> for receiving addresses or he doesn't.
>>> 
>> The problem with that approach is that it doesn't prevent the target
>> registrant from subsequently transferring the addresses according only
>> to the local RIR's policy and then coming back for another inter-RIR
>> transfer.
> 
> Hi Owen,
> 
> Then that problem exists in ARIN policy and should be corrected in
> ARIN policy so that ARIN considers the disposition of all current and
> previously allocated resources when approving a new one. Otherwise
> you're asking folks in other regions to meet a higher standard than
> folks in our own region.
> 
I'm not sure I follow you here Bill. What I'm saying is I don't want ARIN
to transfer resources to a region where the RIR does not preserve a
needs-basis on subsequent transfers of the addresses. ARIN does
preserve that requirement as the policy is currently written and I assure
you I will remain opposed to and am opposed to the proposals that
seek to change that.

> 
>>> 2. The timing of this proposal is bad. Pushing this policy prior to
>>> the exhaustion of ARIN's free pool invites an out-region address grab.
>>> This draft policy belongs on next year's agenda when the only
>>> addresses left to move are registrant to registrant transfers.
>>> 
>> There is at least one region where this is already the case. As such,
>> the policy is timely now.
> 
> There's a region in which ARIN's free pool is exhausted? Which one?
> 
There is a region in which that region's free pool is exhausted.

Owen



From bill at herrin.us  Tue Jun 21 14:45:41 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 21 Jun 2011 14:45:41 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <D1DC7B29-1EBE-46A2-8487-DDEBF87E2F0F@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<69B95946-460C-44F2-8023-B0643230B791@delong.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
	<D1DC7B29-1EBE-46A2-8487-DDEBF87E2F0F@delong.com>
Message-ID: <BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>

On Tue, Jun 21, 2011 at 2:23 PM, Owen DeLong <owen at delong.com> wrote:
> I'm not sure I follow you here Bill. What I'm saying is I don't want ARIN
> to transfer resources to a region where the RIR does not preserve a
> needs-basis on subsequent transfers of the addresses. ARIN does
> preserve that requirement as the policy is currently written and I assure
> you I will remain opposed to and am opposed to the proposals that
> seek to change that.

Hi Owen,

I don't think we can't expect to control what the registrant does in
the future after we've released the resource to that region. When we
transfer the resource, we cede control to that region. If we want to
exclude a region because of the region's policies, the appropriate way
to do that is with a global policy to the effect of:

"RIRs may at their discretion institute bilateral number resource
transfer agreements permitting IPv4 address blocks no longer than /24
to be transferred between regions."

Not with vague language about compatible policies and needs basis.

I do think we can refuse transfers to entities whose prior behavior
has depleted them of the resources they now wish to transfer from our
region. This can be addressed under "meet both RIR's policies" by
setting local policy which applies to registrants requesting addresses
and transfers inside the ARIN region as well.


> On Jun 21, 2011, at 10:37 AM, William Herrin wrote:
>>>> 2. The timing of this proposal is bad. Pushing this policy prior to
>>>> the exhaustion of ARIN's free pool invites an out-region address grab.
>>>> This draft policy belongs on next year's agenda when the only
>>>> addresses left to move are registrant to registrant transfers.
>>>>
>>> There is at least one region where this is already the case. As such,
>>> the policy is timely now.
>>
>> There's a region in which ARIN's free pool is exhausted? Which one?
>>
> There is a region in which that region's free pool is exhausted.

I respect your opinion, but mine is that they made their bed and
should lie in it until ARIN's free pool is also exhausted. That's what
I'm saying.

Regards,
Bill Herrin


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


From owen at delong.com  Tue Jun 21 16:26:27 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2011 13:26:27 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<69B95946-460C-44F2-8023-B0643230B791@delong.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
	<D1DC7B29-1EBE-46A2-8487-DDEBF87E2F0F@delong.com>
	<BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
Message-ID: <300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>


On Jun 21, 2011, at 11:45 AM, William Herrin wrote:

> On Tue, Jun 21, 2011 at 2:23 PM, Owen DeLong <owen at delong.com> wrote:
>> I'm not sure I follow you here Bill. What I'm saying is I don't want ARIN
>> to transfer resources to a region where the RIR does not preserve a
>> needs-basis on subsequent transfers of the addresses. ARIN does
>> preserve that requirement as the policy is currently written and I assure
>> you I will remain opposed to and am opposed to the proposals that
>> seek to change that.
> 
> Hi Owen,
> 
> I don't think we can't expect to control what the registrant does in
> the future after we've released the resource to that region. When we
> transfer the resource, we cede control to that region. If we want to
> exclude a region because of the region's policies, the appropriate way
> to do that is with a global policy to the effect of:
> 
> "RIRs may at their discretion institute bilateral number resource
> transfer agreements permitting IPv4 address blocks no longer than /24
> to be transferred between regions."
> 
I'm not attempting to exert control over what the registrant does after
we release the resources. I'm attempting to ensure that resources don't
get released into regions with incompatible policies that eschew good
stewardship of said resources.

This isn't really a global policy matter and it would be virtually impossible
to get a global policy in this area. Global policies require the concurrence
of all 5 RIR communities. I think that a unilateral policy within the ARIN
region that specifies under what circumstances ARIN would or would not
be willing to transfer resources to another region is a fine way to implement
this. The other RIRs would, of course, have to implement something similar
if they wanted to transfer resources to/from ARIN on behalf of their
constituents.

> Not with vague language about compatible policies and needs basis.
> 

If you don't like the vagueness of the current language, propose more
specific language

Personally I think that the current language is about as specific as we can
get, conveys the community intent and allows ARIN staff the latitude to adapt
to changing situations while still preserving the general intent of the policy.

> I do think we can refuse transfers to entities whose prior behavior
> has depleted them of the resources they now wish to transfer from our
> region. This can be addressed under "meet both RIR's policies" by
> setting local policy which applies to registrants requesting addresses
> and transfers inside the ARIN region as well.
> 

I don't have a problem with that idea, but, that policy would have to be on the
books before I could consider it as a factor in adopting a policy that supports
inter-region transfers. Since there is currently no such policy in the NRPM
or even in any of the current proposals, that is not the case.

> 
>> On Jun 21, 2011, at 10:37 AM, William Herrin wrote:
>>>>> 2. The timing of this proposal is bad. Pushing this policy prior to
>>>>> the exhaustion of ARIN's free pool invites an out-region address grab.
>>>>> This draft policy belongs on next year's agenda when the only
>>>>> addresses left to move are registrant to registrant transfers.
>>>>> 
>>>> There is at least one region where this is already the case. As such,
>>>> the policy is timely now.
>>> 
>>> There's a region in which ARIN's free pool is exhausted? Which one?
>>> 
>> There is a region in which that region's free pool is exhausted.
> 
> I respect your opinion, but mine is that they made their bed and
> should lie in it until ARIN's free pool is also exhausted. That's what
> I'm saying.
> 

I'm not entirely sure what you mean by that. They have roughly 1/2 of the
world population within their region and only 22% of the IPv4 address space.

Do you mean they should be somehow penalized because they didn't
catch on to the internet when it was first being developed in the US?

Do you mean that you believe there is some reason they should not have
any access to the nearly 6 /8s in the ARIN free pool due to some action
on the part of the APNIC community?

I'm just not sure what bed you are saying they have made.

I don't want to allow transfers into their region so long as the result is to
free the resources from rational RIR based policy including needs basis.
However, this proposal would preserve that protection, so, other than
the issue of APNIC abandoning needs basis, I'm sorry, but, I'm at a loss
as to the nature of the bed you speak of.

Owen



From scottleibrand at gmail.com  Tue Jun 21 16:49:59 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 21 Jun 2011 13:49:59 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <11062107491193_F0DA@oregon.uoregon.edu>
References: <11062107491193_F0DA@oregon.uoregon.edu>
Message-ID: <7469120707968675254@unknownmsgid>

On Jun 21, 2011, at 9:25 AM, "Joe St Sauver" <joe at oregon.uoregon.edu> wrote:

> Regarding "Draft Policy 2011-1: Inter-RIR Transfers"
>
> and the proviso that:
>
>   "Address resources may be transferred.... in or out of the ARIN region
>   to those who demonstrate need and plan to deploy them for a networking
>   purpose within 3 months. Such transfers will take place between RIRs who
>   share compatible, needs-based policies on behalf of entities agreeing to
>   the transfer and which otherwise meet both RIR's policies. Transferred
>   resources will become part of the resource holdings of the recipient RIR
>   unless otherwise agreed by both RIRs."
>
> I am opposed to inter-RIR transfer policies, including this one. Let me
> mention just a few reasons why.
>
>
> I. Resource Firebreak Issues.
>
> In thinking about this and similar policies, consider where addresses would
> likely come from and where addresses would probably go given current
> circumstances (and assuming that all RIRs agreed to participate in the
> policy).
>
> RIRs with remaining IPv4 address resources ("supplier RIRs")
>
> -- AFRINIC
> -- LACNIC
>
> RIRs with a likely immediate-term demand for additional IPv4 addresses
> ("consumer RIRs"):
>
> -- APNIC
> -- RIPE NCC
> -- ARIN
>
> Thus the flow of address space would thus likely be *from* the developing
> nations of the southern hemisphere (except Australasia) *to* the developed
> nations of the northern hemisphere.
>
> Countries in the southern hemisphere (which have historically been handicapped
> by the high price of connectivity) have just recently begun to see improved
> fiber access and a resulting drop in market prices. With their large areas
> and large populations, they will likely have a substantial demand for number
> resources in most forseeable medium-term scenarios. If the critical resources
> they will eventually require will have been "exported" piece meal to Asia,
> Europe, or North America, our southern-hemisphere neighbors will find it hard
> to realize their full potential as Internet citizens.
>
> The existing region-based RIR system thus serves as a "firebreak" of sorts,
> protecting each RIR's resources from being treated as one common comingled
> pool that can be (effectively) drawn down in its entirity by any region
> willing to do so.
>
> I don't want to see that "firebreak," small though it may be, breached. I
> think it serves an important purpose when it comes to protecting resources
> in developing regions such as AFRINIC and LACNIC.


Adopting an inter-RIR transfer policy in the ARIN region would not
allow transfers from (or to) AfriNIC or LACNIC unless they passed
similar policy. As you mention, that looks unlikely. AfriNIC seems to
support a policy to prevent usage of their resources out of region.
LACNIC is discussing a similar proposal, but it's much further from
consensus.

If we pass an inter-RIR transfer policy that allows it, the most
likely effect would be transfers from ARIN to APNIC.

-Scott


>
>
> II. Additional Resources Should Not Be Allowed to Potential Feed Regions
> with Unchecked Abuse Issues.
>
> Some have also argued that RIRs vary substantially when it comes to
> their interest in policing number resource misue and abuse. An interesting
> exercise when it comes to measuring one dimension of that issue is to go to
> Spamhaus and see how many SBL listings are associated with each of
> the RIRs. At the time I checked just now:
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=afrinic
>   4 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=apnic
>   18 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=lacnic
>   28 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=arin
>   250 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=ripe
>   I quote, "has far too many records to list. This ISP has an extremely
>   serious spam problem."
>
> Although I've looked at a LOT of SBL listings over the years, this is
> absolutely the first and ONLY time I've EVER seen a "too many to list"
> response from the Spamhaus by-ISP SBL listings.
>
> Thus, I would also oppose inter-RIR transfers if those transfers might
> potentially serve to enable further messaging abuse by supplying "raw
> materials" to areas where number resources are apparently experiencing
> rampant abuse. (If all or many of those issues have been taken care of,
> and Spamhaus is just running behind on removals, my apologies)
>
>
> III. Tracking and Documenting Address Usage Becomes Harder.
>
> Currently it is possible to track address usage because we know (at
> a /8 granularity) which regions have a given block. If we suddenly
> begin allowing /16s here and /19s there to be carved off and transfer
> out or transfered in, our ability to track usage by region will quickly
> be lost (or become a tiresome and highly granular bookkeeping exercise).
>
> Moreover, IP whois currently relies on that assignment by /8s to
> direct IP whois queries to an appropriate RIR whois server. If inter
> region transfers are allowed, whois queries will now potentially need
> to support still more redirection, and protection against whois
> redirection loops will likely even become necessary. And do we want
> the RIRs to need to update their whois to deal with (redirect) thousands
> or tens of thousands of tiny blocks that may be transfered out of region?
> Jeez, again, what a bookkeeping mess!
>
>
> For all these and other reasons, I oppose inter-RIR transfers, including
> the current proposed policy.
>
> Thanks for considering these comments,
>
> Regards,
>
> Joe
>
> Disclaimer: all opinions expressed are strictly my own and do not
> necessarily represent the opinion of any other organization or entity.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From BillD at cait.wustl.edu  Tue Jun 21 16:55:37 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 21 Jun 2011 15:55:37 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>

 

> -----Original Message-----
> From: Martin Hannigan [mailto:hannigan at gmail.com] 
> Sent: Tuesday, June 21, 2011 11:51 AM
> To: Bill Darte
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - Shepherd's Inquiry
> 
> On Tue, Jun 21, 2011 at 10:30 AM, Bill Darte 
> <BillD at cait.wustl.edu> wrote:
> > Hello,
> >
> > Please provide you immediate, concise feeback which states your 
> > position for or against the DP as changed from its earlier 
> version and 
> > any reasoning you may wish to provide.
> >
> > I am proposing that the original Draft Policy 2011-1: Globally 
> > Coordinated Transfer Policy?....
> >
> > Be renamed.... Draft Policy 2011-1: Inter-RIR Transfers...
> 
> 
> [ clip ]
> 
> >
> > Reasoning....It is explicit about..
> 
> >
> > in or out of region,
> > that transfers are between RIRs that support needs-based policies, 
> > that RIRs have to agree, that parties meet all of both RIR policies 
> > that it is needs based, and the need is for a networking 
> purpose, that 
> > the receiving RIR is entitled to the addresses
> >
> > I think all these details were raised as objections at one time or 
> > another...so it seems best to waste a few more words to be explicit.
> >
> > It is not explicit about...
> > block sizes
> > utilization of prior allocations, assignments or transfers RFC 2050 
> > subsequent transfers
> >
> > Nor should it be, IMO
> 
> What about transfers that are later returned to the RIR that received?
> What about addresses that were transferred en masse to an RIR 
> that suddenly changes its policies (as they are more than 
> entitled to) and abandons needs as a basis for allocations 
> and proceeds to profit from the addresses? These aren't 
> hypothetical considerations. What about regions that have 
> more than adequate addresses to facilitate regional needs 
> considering that some are locking down their addresses to be 
> used in-region only? There are a lot of unanswered questions 
> with respect to this proposal regardless of what it may be named.
> 
> I've read Mike Burns comments. I agree with him, mostly, be 
> he seems to argue (knowingly or not) for allowing market 
> forces to operate as they would which doesn't require a 
> policy like this. Others are arguing that we need to "help 
> other regions". I agree, but sending our colleagues life 
> rafts with holes in them won't help.
> 
> I'm not in favor of this proposal. Renaming this policy and 
> resuscitating it from certain death globally is an inadequate 
> way to address all of the complicated questions that 
> may/would/continue to be asked in order to move it through 
> those difficult processes regardless of which policy regime 
> supporters attempt to push it through.
> 
> There also appears to be a lack of agreement in the community 
> and on the AC:
> 
> "The motion to forward to Last Call failed with 8 against 
> (DA, OD, DF, MH, SH, CM, BS, JS) and 3 in favor (SL, BD, CG) 
> via roll call."
> 
> Is abandonment on the table? If not, why would we not 
> consider abandoning?

The simple answere to your question is that many of the NO votes for forwarding to last call were based upon 'clarity' issues not on the overall sentiment of the community as voiced on the PPML and at the Puerto Rico Public Policy Meeting.  I am pursuing that clarity and incoporating other feedback from PR PPM and the AC meeting where the votes you identify were taken.

I will also consider the questions you pose above as part of my shepherd's duty.  I'm sure the rest of community will also incorporate those considerations.

Best,

bd



> 
> 
> Best,
> 
> -M<
> 


From hannigan at gmail.com  Tue Jun 21 17:08:45 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 17:08:45 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
Message-ID: <BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>

On Tue, Jun 21, 2011 at 4:55 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>
>
>> -----Original Message-----
>> From: Martin Hannigan [mailto:hannigan at gmail.com]
>> Sent: Tuesday, June 21, 2011 11:51 AM
>> To: Bill Darte
>> Cc: arin ppml; Robert E. Seastrom
>> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
>> Transfers - Shepherd's Inquiry
>>
>> On Tue, Jun 21, 2011 at 10:30 AM, Bill Darte
>> <BillD at cait.wustl.edu> wrote:
>> > Hello,
>> >
>> > Please provide you immediate, concise feeback which states your
>> > position for or against the DP as changed from its earlier
>> version and
>> > any reasoning you may wish to provide.
>> >
>> > I am proposing that the original Draft Policy 2011-1: Globally
>> > Coordinated Transfer Policy?....
>> >
>> > Be renamed.... Draft Policy 2011-1: Inter-RIR Transfers...
>>
>>
>> [ clip ]
>>
>> >
>> > Reasoning....It is explicit about..
>>
>> >
>> > in or out of region,
>> > that transfers are between RIRs that support needs-based policies,
>> > that RIRs have to agree, that parties meet all of both RIR policies
>> > that it is needs based, and the need is for a networking
>> purpose, that
>> > the receiving RIR is entitled to the addresses
>> >
>> > I think all these details were raised as objections at one time or
>> > another...so it seems best to waste a few more words to be explicit.
>> >
>> > It is not explicit about...
>> > block sizes
>> > utilization of prior allocations, assignments or transfers RFC 2050
>> > subsequent transfers
>> >
>> > Nor should it be, IMO
>>
>> What about transfers that are later returned to the RIR that received?
>> What about addresses that were transferred en masse to an RIR
>> that suddenly changes its policies (as they are more than
>> entitled to) and abandons needs as a basis for allocations
>> and proceeds to profit from the addresses? These aren't
>> hypothetical considerations. What about regions that have
>> more than adequate addresses to facilitate regional needs
>> considering that some are locking down their addresses to be
>> used in-region only? There are a lot of unanswered questions
>> with respect to this proposal regardless of what it may be named.
>>
>> I've read Mike Burns comments. I agree with him, mostly, be
>> he seems to argue (knowingly or not) for allowing market
>> forces to operate as they would which doesn't require a
>> policy like this. Others are arguing that we need to "help
>> other regions". I agree, but sending our colleagues life
>> rafts with holes in them won't help.
>>
>> I'm not in favor of this proposal. Renaming this policy and
>> resuscitating it from certain death globally is an inadequate
>> way to address all of the complicated questions that
>> may/would/continue to be asked in order to move it through
>> those difficult processes regardless of which policy regime
>> supporters attempt to push it through.
>>
>> There also appears to be a lack of agreement in the community
>> and on the AC:
>>
>> "The motion to forward to Last Call failed with 8 against
>> (DA, OD, DF, MH, SH, CM, BS, JS) and 3 in favor (SL, BD, CG)
>> via roll call."
>>
>> Is abandonment on the table? If not, why would we not
>> consider abandoning?
>
> The simple answere to your question is that many of the NO votes for forwarding to last call were based upon 'clarity' issues not on the overall sentiment of the community as voiced on the PPML and at the Puerto Rico Public Policy Meeting. ?I am pursuing that clarity and incoporating other feedback from PR PPM and the AC meeting where the votes you identify were taken.
>
> I will also consider the questions you pose above as part of my shepherd's duty. ?I'm sure the rest of community will also incorporate those considerations.
>

I guess I'm not clear on what the consensus looks like at this point
since I'm under the impression that there is a significant lack of
support community wise.

But fair enough. Considering the lack of support overall though, I'd
strongly suggest abandonment as a serious issue for continued AC
discussion.


Best,

-M<


From mike at nationwideinc.com  Tue Jun 21 17:21:12 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 21 Jun 2011 17:21:12 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com><69B95
	946-460C-44F2-8023-B0643230B791@delong.com><BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com><D1DC7B29-1EBE-46A2-8487-DDEBF87
	E2F0F@delong.com><BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
	<300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>
Message-ID: <698EEF74F389473DB3DE7C42F993C357@mike>

When the language says both RIRs have to agree to the transfer, what does 
that actually mean?
That the AC agrees, or that there is a vote at a policy meeting, or a count 
of approvals on a mailing list?
Or that ARIN staff agrees?

Because if it's the latter, that it becomes a staff decision like any other 
transfer, why can't we just leave it to ARIN staff and see what happens, and 
if we don't like it we can voice our concerns to the ARIN staff later. 
Surely it is quicker to do this than to create a whole global policy.

I think the proposal is more likely to pass globally if it is not larded 
with the particular concerns of each registry.
We should leave the language requiring both RIRs to agree, that gives us 
flexibility in observing some transactions and then if we decide as a 
community that we don't like the direction they are headed in we can let the 
ARIN staff know that the community does not wish for transfers to be 
approved if they meet this or that contingency.

Thus if we have evidence of speculation, market manipulation, dangerous 
levels of addresses fleeing our region, we can use the "RIRs must agree" 
language to restrict those transfers.

But we don't lose this opportunity to create a wider market for the transfer 
of addresses from those who want to sell them to those who need them.

Consider that we are essentially blocking transfers to APNIC members who 
have a real and justifiable need for addresses just so we can be sure 
somebody doesn't sneak in and use their open transfer policy to act 
nefariously.  This is the region with the highest demand, and the insistence 
on maintaining our particular interpretation of stewardship has the result 
of shutting off transfers from the region with highest supply to all APNIC 
members, whether they can demonstrate need or not.

We could even drop the needs language, pass the policy, but let ARIN staff 
know the community does not want any transfers approved currently. Then we 
could open the door in the future to such transfers just by letting ARIN 
staff know that the community has revised its decision. This way we don't 
lose progress on this global policy.

Or we could let ARIN staff know the community currently wants to restrict 
transfers to those with justifiable need, and let ARIN staff review any 
needs justification which is voluntarily submitted with the transfer 
application. At least this way we don't throw the baby out with the bath 
water.

I would support the policy if all language related to needs is eliminated, 
but the requirement of both RIRs to agree is maintained.

Regards,
Mike
issues. 



From hannigan at gmail.com  Tue Jun 21 17:26:26 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 17:26:26 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
In-Reply-To: <698EEF74F389473DB3DE7C42F993C357@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
	<BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
	<300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>
	<698EEF74F389473DB3DE7C42F993C357@mike>
Message-ID: <BANLkTi=thxJB1=GBRd49Vb-ycqtBR5TBNQ@mail.gmail.com>

On Tue, Jun 21, 2011 at 5:21 PM, Mike Burns <mike at nationwideinc.com> wrote:
> When the language says both RIRs have to agree to the transfer, what does
> that actually mean?

It means that the proposal is completely unpredictable implementation
wise or operationally.

Best,

-M<


From scottleibrand at gmail.com  Tue Jun 21 17:35:24 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 21 Jun 2011 14:35:24 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
In-Reply-To: <698EEF74F389473DB3DE7C42F993C357@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com> <69B95
	946-460C-44F2-8023-B0643230B791@delong.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
	<D1DC7B29-1EBE-46A2-8487-DDEBF87 E2F0F@delong.com>
	<BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
	<300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>
	<698EEF74F389473DB3DE7C42F993C357@mike>
Message-ID: <1942679660271362084@unknownmsgid>

Mike,

There is no need for a global (or globally coordinated) policy to
enable inter-RIR transfers.  APNIC already allows them, so if we pass
a local policy that allows for outbound transfers to APNIC, staff can
start processing such transfer requests as soon as they implement the
policy.

This policy, as written, would not yet allow that, due to the
requirement for needs-based transfer policies in both RIRs.

Scott

On Jun 21, 2011, at 2:21 PM, Mike Burns <mike at nationwideinc.com> wrote:

> When the language says both RIRs have to agree to the transfer, what does that actually mean?
> That the AC agrees, or that there is a vote at a policy meeting, or a count of approvals on a mailing list?
> Or that ARIN staff agrees?
>
> Because if it's the latter, that it becomes a staff decision like any other transfer, why can't we just leave it to ARIN staff and see what happens, and if we don't like it we can voice our concerns to the ARIN staff later. Surely it is quicker to do this than to create a whole global policy.
>
> I think the proposal is more likely to pass globally if it is not larded with the particular concerns of each registry.
> We should leave the language requiring both RIRs to agree, that gives us flexibility in observing some transactions and then if we decide as a community that we don't like the direction they are headed in we can let the ARIN staff know that the community does not wish for transfers to be approved if they meet this or that contingency.
>
> Thus if we have evidence of speculation, market manipulation, dangerous levels of addresses fleeing our region, we can use the "RIRs must agree" language to restrict those transfers.
>
> But we don't lose this opportunity to create a wider market for the transfer of addresses from those who want to sell them to those who need them.
>
> Consider that we are essentially blocking transfers to APNIC members who have a real and justifiable need for addresses just so we can be sure somebody doesn't sneak in and use their open transfer policy to act nefariously.  This is the region with the highest demand, and the insistence on maintaining our particular interpretation of stewardship has the result of shutting off transfers from the region with highest supply to all APNIC members, whether they can demonstrate need or not.
>
> We could even drop the needs language, pass the policy, but let ARIN staff know the community does not want any transfers approved currently. Then we could open the door in the future to such transfers just by letting ARIN staff know that the community has revised its decision. This way we don't lose progress on this global policy.
>
> Or we could let ARIN staff know the community currently wants to restrict transfers to those with justifiable need, and let ARIN staff review any needs justification which is voluntarily submitted with the transfer application. At least this way we don't throw the baby out with the bath water.
>
> I would support the policy if all language related to needs is eliminated, but the requirement of both RIRs to agree is maintained.
>
> Regards,
> Mike
> issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bill at herrin.us  Tue Jun 21 17:36:35 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 21 Jun 2011 17:36:35 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
Message-ID: <BANLkTikp23ZnM-FaXH+YzV8G5pXNU2tCJQ@mail.gmail.com>

On Tue, Jun 21, 2011 at 5:08 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> But fair enough. Considering the lack of support overall though, I'd
> strongly suggest abandonment as a serious issue for continued AC
> discussion.

Hi Martin,

I suggest abandonment following the show of significant lack of
support in Philly. Unless there's a reason the topic shouldn't come up
at the meeting?


On Tue, Jun 21, 2011 at 5:21 PM, Mike Burns <mike at nationwideinc.com> wrote:
> When the language says both RIRs have to agree to the transfer, what does
> that actually mean?

Hi Mike,

The language doesn't say the RIRs have to agree to the transfer. The
rationale says that. The language says the registrant's request must
"meet both RIR's policies."

Regards,
Bill Herrin


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


From bill at herrin.us  Tue Jun 21 17:54:42 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 21 Jun 2011 17:54:42 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTi=pRxmU49TFau3wuMbBkd5aMEhGpQ@mail.gmail.com>
	<69B95946-460C-44F2-8023-B0643230B791@delong.com>
	<BANLkTikvinmTBxxO2DS_ONAeRwLeHbrK0Q@mail.gmail.com>
	<D1DC7B29-1EBE-46A2-8487-DDEBF87E2F0F@delong.com>
	<BANLkTinHX6ZzonxoqL8w2wFrQt-+3S2-oA@mail.gmail.com>
	<300E7AB9-FF40-4200-B0E6-E3846A71AAED@delong.com>
Message-ID: <BANLkTimCDKa+bA+BEVOGoZVo6rckRsTV5g@mail.gmail.com>

On Tue, Jun 21, 2011 at 4:26 PM, Owen DeLong <owen at delong.com> wrote:
> I'm not entirely sure what you mean by that. They have roughly 1/2 of the
> world population within their region and only 22% of the IPv4 address space.
>
> Do you mean they should be somehow penalized because they didn't
> catch on to the internet when it was first being developed in the US?
>
> Do you mean that you believe there is some reason they should not have
> any access to the nearly 6 /8s in the ARIN free pool due to some action
> on the part of the APNIC community?

Hey, I have an idea. Let's give all the remaining U.S. Federal land to
the various native American tribes. At least there our predecessors
acquired it in a manner that was wrong and surely the dual gifts of
Yellowstone and D.C. will atone for their sins.

No, on second thought let's not.

Regards,
Bill Herrin




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


From owen at delong.com  Tue Jun 21 18:04:19 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2011 15:04:19 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
Message-ID: <D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>

>> 
>> The simple answere to your question is that many of the NO votes for forwarding to last call were based upon 'clarity' issues not on the overall sentiment of the community as voiced on the PPML and at the Puerto Rico Public Policy Meeting.  I am pursuing that clarity and incoporating other feedback from PR PPM and the AC meeting where the votes you identify were taken.
>> 
>> I will also consider the questions you pose above as part of my shepherd's duty.  I'm sure the rest of community will also incorporate those considerations.
>> 
> 
> I guess I'm not clear on what the consensus looks like at this point
> since I'm under the impression that there is a significant lack of
> support community wise.
> 
> But fair enough. Considering the lack of support overall though, I'd
> strongly suggest abandonment as a serious issue for continued AC
> discussion.
> 

I think there was strong community support for 2001-1 as it was written at the Puerto Rico meeting.

I think there was widespread belief that the language needed clarification in a couple of areas
and someone was hung up on trying to deprecate RFC-2050 for reasons passing understanding.

Now we've got an entirely different proposal on the table from Bill, but, it at least appears to
preserve all the same intent. As such, I can get on board with bringing that modification to
Philly as a new draft policy for further community discussion towards adoption.

Alternatively, there were very minor issues with the original 2011-1 that we had some simple
language tweaks to address. I have expressed support for those and would favor bringing
that language to a vote for forwarding to last call at our meeting on Thursday.

I won't pretend to speak for the rest of the AC, but, I do not feel that abandonment is appropriate
given the strong community support for the proposal before we started mucking with it after
the PR meeting. We owe it to the community to find a way to come to agreement on the
changes suggested by the community and bring the result either to last call or to the
next PPM at the very least.

Owen



From hannigan at gmail.com  Tue Jun 21 18:17:39 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 18:17:39 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTikp23ZnM-FaXH+YzV8G5pXNU2tCJQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTikp23ZnM-FaXH+YzV8G5pXNU2tCJQ@mail.gmail.com>
Message-ID: <BANLkTik8LUBy7SartrNGTO6e2pnMhqi0EA@mail.gmail.com>

On Tue, Jun 21, 2011 at 5:36 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Jun 21, 2011 at 5:08 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>> But fair enough. Considering the lack of support overall though, I'd
>> strongly suggest abandonment as a serious issue for continued AC
>> discussion.

> Hi Martin,

> I suggest abandonment following the show of significant lack of
> support in Philly. Unless there's a reason the topic shouldn't come up
> at the meeting?


That sounds reasonable including last-call not being a consideration
in the near term and that any further formal action is postponed until
Philadelphia. I'm having a hard time correlating thinking that this is
close to acceptable or near consensus considering the feedback that
I'm reading in this thread and what has been reported from the AC
meeting in the posted minutes.


Best,

-M<


From BillD at cait.wustl.edu  Tue Jun 21 20:11:22 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 21 Jun 2011 19:11:22 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>

Owen,
Others on the AC would be interested as I am I'm sure in seeing the
tweaks you propose and or course you are welcome to make a motion to
send that new text to last call.
My current effort is an attempt to air the issues once again in a
focused way so that if a motion like yours fails to achieve 8 votes in
the AC, we have a contingency plan.
I support your effort.
bd 

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, June 21, 2011 5:04 PM
> To: Martin Hannigan
> Cc: Bill Darte; arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - Shepherd's Inquiry
> 
> >> 
> >> The simple answere to your question is that many of the NO 
> votes for forwarding to last call were based upon 'clarity' 
> issues not on the overall sentiment of the community as 
> voiced on the PPML and at the Puerto Rico Public Policy 
> Meeting.  I am pursuing that clarity and incoporating other 
> feedback from PR PPM and the AC meeting where the votes you 
> identify were taken.
> >> 
> >> I will also consider the questions you pose above as part 
> of my shepherd's duty.  I'm sure the rest of community will 
> also incorporate those considerations.
> >> 
> > 
> > I guess I'm not clear on what the consensus looks like at 
> this point 
> > since I'm under the impression that there is a significant lack of 
> > support community wise.
> > 
> > But fair enough. Considering the lack of support overall 
> though, I'd 
> > strongly suggest abandonment as a serious issue for continued AC 
> > discussion.
> > 
> 
> I think there was strong community support for 2001-1 as it 
> was written at the Puerto Rico meeting.
> 
> I think there was widespread belief that the language needed 
> clarification in a couple of areas and someone was hung up on 
> trying to deprecate RFC-2050 for reasons passing understanding.
> 
> Now we've got an entirely different proposal on the table 
> from Bill, but, it at least appears to preserve all the same 
> intent. As such, I can get on board with bringing that 
> modification to Philly as a new draft policy for further 
> community discussion towards adoption.
> 
> Alternatively, there were very minor issues with the original 
> 2011-1 that we had some simple language tweaks to address. I 
> have expressed support for those and would favor bringing 
> that language to a vote for forwarding to last call at our 
> meeting on Thursday.
> 
> I won't pretend to speak for the rest of the AC, but, I do 
> not feel that abandonment is appropriate given the strong 
> community support for the proposal before we started mucking 
> with it after the PR meeting. We owe it to the community to 
> find a way to come to agreement on the changes suggested by 
> the community and bring the result either to last call or to 
> the next PPM at the very least.
> 
> Owen
> 
> 


From hannigan at gmail.com  Tue Jun 21 20:22:45 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 20:22:45 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>
Message-ID: <BANLkTikp5eDcY2SNbmjPyLTwTWD2PCTt8w@mail.gmail.com>

On Tue, Jun 21, 2011 at 8:11 PM, Bill Darte <BillD at cait.wustl.edu> wrote:

> Owen,
> Others on the AC would be interested as I am I'm sure in seeing the
> tweaks you propose and or course you are welcome to make a motion to
> send that new text to last call.
> My current effort is an attempt to air the issues once again in a
> focused way so that if a motion like yours fails to achieve 8 votes in
> the AC, we have a contingency plan.
> I support your effort.

[ .. ]

>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Tuesday, June 21, 2011 5:04 PM


>>
>> Alternatively, there were very minor issues with the original
>> 2011-1 that we had some simple language tweaks to address. I
>> have expressed support for those and would favor bringing
>> that language to a vote for forwarding to last call at our
>> meeting on Thursday.


There's less than 48 hours to the Thursday AC meeting. Making
modifications to rush things to last call is challenging based on the
public feedback that we have and the large dissent noted in the latest
AC minutes regardless of the reasoning.

Submit edits prior to the Thursday meeting leaves me wondering how
everyone will be able to review, think, discuss and then vote on them
with so little time available to consider.

Section 4.3 of the PDP implies that last call is a state of consensus.
I think we're  far from that to be considering rushing things like
Owen, or anyone, is proposing.

Best,

-M<


From hannigan at gmail.com  Tue Jun 21 20:54:25 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 20:54:25 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTikp5eDcY2SNbmjPyLTwTWD2PCTt8w@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>
	<BANLkTikp5eDcY2SNbmjPyLTwTWD2PCTt8w@mail.gmail.com>
Message-ID: <BANLkTik7882XqZtuhHRiJs_hON1ztCn81A@mail.gmail.com>

On Tue, Jun 21, 2011 at 8:22 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> On Tue, Jun 21, 2011 at 8:11 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>
>> Owen,
>> Others on the AC would be interested as I am I'm sure in seeing the
>> tweaks you propose and or course you are welcome to make a motion to
>> send that new text to last call.
>> My current effort is an attempt to air the issues once again in a
>> focused way so that if a motion like yours fails to achieve 8 votes in
>> the AC, we have a contingency plan.
>> I support your effort.
>
> [ .. ]
>
>>> -----Original Message-----
>>> From: Owen DeLong [mailto:owen at delong.com]
>>> Sent: Tuesday, June 21, 2011 5:04 PM
>
>
>>>
>>> Alternatively, there were very minor issues with the original
>>> 2011-1 that we had some simple language tweaks to address. I
>>> have expressed support for those and would favor bringing
>>> that language to a vote for forwarding to last call at our
>>> meeting on Thursday.
>
>
> There's less than 48 hours to the Thursday AC meeting. Making
> modifications to rush things to last call is challenging based on the
> public feedback that we have and the large dissent noted in the latest
> AC minutes regardless of the reasoning.
>
> Submit edits prior to the Thursday meeting leaves me wondering how
> everyone will be able to review, think, discuss and then vote on them
> with so little time available to consider.
>
> Section 4.3 of the PDP implies that last call is a state of consensus.
> I think we're ?far from that to be considering rushing things like
> Owen, or anyone, is proposing.
>


Since Owen is already working the AC to try and rush this through
privately, let me clarify; these changes are posted to PPML less than
48 hours which doesn't seem like an adequate amount of time to
address. It also seems clear that some advocates are willing to do
_anything_ to get this through including shifting their opinion and
ignoring the feedback on this list. That alone should be enough to
stall this for a bit and to answer the significant unanswered
questions.

> Section 4.3 of the PDP implies that last call is a state of consensus.

I'm still very curious and wouldn't mind seeing Bill or Owen explain
how we've reached anything near consensus. Unless there's a dramatic
shift in the attitude of posters to this thread, I'm planning on
suggesting that the AC postpone until a later date.

Best,

-M<


From owen at delong.com  Tue Jun 21 21:15:01 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2011 18:15:01 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTik7882XqZtuhHRiJs_hON1ztCn81A@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>
	<BANLkTikp5eDcY2SNbmjPyLTwTWD2PCTt8w@mail.gmail.com>
	<BANLkTik7882XqZtuhHRiJs_hON1ztCn81A@mail.gmail.com>
Message-ID: <87642621-1BF3-4797-B9B3-3FE05FB75D9C@delong.com>


On Jun 21, 2011, at 5:54 PM, Martin Hannigan wrote:

> On Tue, Jun 21, 2011 at 8:22 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>> On Tue, Jun 21, 2011 at 8:11 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
>> 
>>> Owen,
>>> Others on the AC would be interested as I am I'm sure in seeing the
>>> tweaks you propose and or course you are welcome to make a motion to
>>> send that new text to last call.
>>> My current effort is an attempt to air the issues once again in a
>>> focused way so that if a motion like yours fails to achieve 8 votes in
>>> the AC, we have a contingency plan.
>>> I support your effort.
>> 
>> [ .. ]
>> 
>>>> -----Original Message-----
>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>> Sent: Tuesday, June 21, 2011 5:04 PM
>> 
>> 
>>>> 
>>>> Alternatively, there were very minor issues with the original
>>>> 2011-1 that we had some simple language tweaks to address. I
>>>> have expressed support for those and would favor bringing
>>>> that language to a vote for forwarding to last call at our
>>>> meeting on Thursday.
>> 
>> 
>> There's less than 48 hours to the Thursday AC meeting. Making
>> modifications to rush things to last call is challenging based on the
>> public feedback that we have and the large dissent noted in the latest
>> AC minutes regardless of the reasoning.
>> 
>> Submit edits prior to the Thursday meeting leaves me wondering how
>> everyone will be able to review, think, discuss and then vote on them
>> with so little time available to consider.
>> 
>> Section 4.3 of the PDP implies that last call is a state of consensus.
>> I think we're  far from that to be considering rushing things like
>> Owen, or anyone, is proposing.
>> 
> 
> 
> Since Owen is already working the AC to try and rush this through
> privately, let me clarify; these changes are posted to PPML less than
> 48 hours which doesn't seem like an adequate amount of time to
> address. It also seems clear that some advocates are willing to do
> _anything_ to get this through including shifting their opinion and
> ignoring the feedback on this list. That alone should be enough to
> stall this for a bit and to answer the significant unanswered
> questions.
> 

I don't think that is a fair characterization of my actions, Marty. All I have
done is express to the AC that I felt that language that was proposed
to the AC should be brought to last call. That language was posted to
the AC list over a week ago.

Frankly, I'm fine if the community wants to abandon all inter-RIR
transfer policies, but, that is not the sense I have of what the community
wanted from the San Juan meeting and the few voices of dissent in
the current thread today were a few voices of dissent around that time as
well. I have no reason to believe that the majority of the community
members who expressed strong favor for this policy with a few minor
issues addressed have changed their minds. Do you?


>> Section 4.3 of the PDP implies that last call is a state of consensus.
> 
> I'm still very curious and wouldn't mind seeing Bill or Owen explain
> how we've reached anything near consensus. Unless there's a dramatic
> shift in the attitude of posters to this thread, I'm planning on
> suggesting that the AC postpone until a later date.
> 

That is certainly your right. Personally, I think that you are ignoring the
historical context of the policy from the period leading up to and
including the San Juan meeting. Since then, the AC has struggled
with this policy and failed to achieve consensus on the exact
changes needed, but, there was strong and clear community
consensus to move something along these lines forward at the
San Juan meeting and on the list prior to the meeting.

However, let's discuss the issues as they stand and not engage in
personal attacks on PPML.

Owen



From hannigan at gmail.com  Tue Jun 21 22:39:00 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 21 Jun 2011 22:39:00 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <87642621-1BF3-4797-B9B3-3FE05FB75D9C@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<D80968F0-129F-46E6-BB2E-340C4721B352@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA18B@ex1.cait.wustl.edu>
	<BANLkTikp5eDcY2SNbmjPyLTwTWD2PCTt8w@mail.gmail.com>
	<BANLkTik7882XqZtuhHRiJs_hON1ztCn81A@mail.gmail.com>
	<87642621-1BF3-4797-B9B3-3FE05FB75D9C@delong.com>
Message-ID: <BANLkTi==ysm1-X8wViWCY-ddi8agB3cvUw@mail.gmail.com>

On Tue, Jun 21, 2011 at 9:15 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Jun 21, 2011, at 5:54 PM, Martin Hannigan wrote:
>
>> On Tue, Jun 21, 2011 at 8:22 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>>> On Tue, Jun 21, 2011 at 8:11 PM, Bill Darte <BillD at cait.wustl.edu> wrote:


>>>>> -----Original Message-----
>>>>> From: Owen DeLong [mailto:owen at delong.com]
>>>>> Sent: Tuesday, June 21, 2011 5:04


>>> Section 4.3 of the PDP implies that last call is a state of consensus.
>>> I think we're ?far from that to be considering rushing things like
>>> Owen, or anyone, is proposing.

[ clip ]


> Frankly, I'm fine if the community wants to abandon all inter-RIR
> transfer policies, but, that is not the sense I have of what the community
> wanted from the San Juan meeting and the few voices of dissent in
> the current thread today were a few voices of dissent around that time as
> well. I have no reason to believe that the majority of the community
> members who expressed strong favor for this policy with a few minor
> issues addressed have changed their minds. Do you?

As I mentioned below, if you'd like to argue why there is consensus to
do anything but hold this for Philadelphia, I'd be interested in
hearing it. What you are saying above though is that you are defining
consensus on a per modification basis with a lack of interest
supporting previous parties comments. I'm not sure that it is in our
interest to have such a loose interpretation of how to get to what the
community wants to input to the AC.

>>> Section 4.3 of the PDP implies that last call is a state of consensus.

[ clip ]

> That is certainly your right. Personally, I think that you are ignoring the
> historical context of the policy from the period leading up to and
> including the San Juan meeting. Since then, the AC has struggled


You mean a previous version of the proposal?


> with this policy and failed to achieve consensus on the exact
> changes needed, but, there was strong and clear community
> consensus to move something along these lines forward at the
> San Juan meeting and on the list prior to the meeting.

I disagree. This policy has been on the border of collapse since it
began being word smithed.


> However, let's discuss the issues as they stand and not engage in
> personal attacks on PPML.


I think that these are important and serious issues. Opposing your
viewpoints are far from personal attacks.

Best,

-M<


From mysidia at gmail.com  Wed Jun 22 01:03:07 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 22 Jun 2011 00:03:07 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <7469120707968675254@unknownmsgid>
References: <11062107491193_F0DA@oregon.uoregon.edu>
	<7469120707968675254@unknownmsgid>
Message-ID: <BANLkTi=CLu1X7ii1_3vW-VDb25okB__C0A@mail.gmail.com>

On Tue, Jun 21, 2011 at 3:49 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> If we pass an inter-RIR transfer policy that allows it, the most
> likely effect would be transfers from ARIN to APNIC.
> -Scott

I also think that's the most likely effect, and I oppose global (or
otherwise) Inter-RIR
transfer policies that allow a transfer of prefixes longer than a /8
between RIRs,
even with  a stipulation of "RIRs that support needs based policies"

No region is going to avoid IPv4 address exhaustion,  and Inter-RIR transfer
seems like an end-run around regions'  address management policies,
which would serve to introduce yet more uncertainty;  RIR policy should be
"Encourage networks to migrate to IPv6";  instead of encourage networks
to seek other region delegated addresses for networks out-of-region.


I am especially opposed to any Inter-RIR specified transfer policy or
practice of allowing an RIR member/organization to unilaterally remove
resources they are assigned from the jurisdiction of their  RIR,
or registry that delegates their resources.


RIR member interests in making Inter-RIR transfers will likely be financial/
self-serving and  not necessarily be in line with the community's best interests
in regards to  Inter-RIR transfer and considerations such as justified need.

Returning resources not needed in a  region to IANA is
more controllable and far safer.

Another safer possibility might be some form of "Revokable Inter-RIR
delegation";
allowing a RIR to delegate a resource to another RIR  (or other
Cross-regional LIR),
for cross-regional usage, for good justification, for the duration
which that resource is
maintained, and requiring all involved RIR/LIRs' policies be followed regarding
all further subdelegation  (including maintenance fees from both RIRs)
and continued justified need for the allocation.


Not only do inter-RIR transfer remove needed resources from the region, but
would fragment RIR managed address space.   A main reason a resource holder
would be interested in Inter-RIR transfer is likely to be 'policy shopping'.


What specific RIR a specific block of address space is designated to should
be determined by the IANA delegation,  not  individual RIR region
resource holders.
This is significant for filtering and other operational reasons.


If a  European or Asian organization should acquire or merge with an
organization
in the ARIN region;  that organization can and should enter agreement with ARIN
to continue to maintain IP resources for networks in the region,  and
continue under
the ARIN policies for those resources.

--
-JH


From cgrundemann at gmail.com  Wed Jun 22 11:21:27 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 22 Jun 2011 09:21:27 -0600
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
Message-ID: <BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>

On Tue, Jun 21, 2011 at 15:08, Martin Hannigan <hannigan at gmail.com> wrote:

> I guess I'm not clear on what the consensus looks like at this point
> since I'm under the impression that there is a significant lack of
> support community wise.

>From the straw poll at the PPM in San Juan (116 in the room):
1) 2011-1 as written? 18 in favor, 11 against
2) The principle of creating an inter-RIR transfer policy? 41 in
favor, 1 against
3) The principle of a needs-based inter-RIR transfer policy? 36 in
favor, 2 against

I believe that is exactly what rough consensus looks like. I am forced
to characterize that as a _significant *show* of support_ and denounce
your claim to the contrary.

> But fair enough. Considering the lack of support overall though, I'd
> strongly suggest abandonment as a serious issue for continued AC
> discussion.

Repeating a falsehood does not make it so. The community as a whole
has very clearly asked us to work on this policy.

I have asked you before and will ask again: What has changed your
opinion so violently on this topic since we wrote this proposal
together 8 months ago?

Cheers,
~Chris

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



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


From hannigan at gmail.com  Wed Jun 22 11:29:24 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 22 Jun 2011 11:29:24 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
Message-ID: <BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>

On Wed, Jun 22, 2011 at 11:21 AM, Chris Grundemann
<cgrundemann at gmail.com> wrote:
> On Tue, Jun 21, 2011 at 15:08, Martin Hannigan <hannigan at gmail.com> wrote:
>
>> I guess I'm not clear on what the consensus looks like at this point
>> since I'm under the impression that there is a significant lack of
>> support community wise.
>
> From the straw poll at the PPM in San Juan (116 in the room):
> 1) 2011-1 as written? 18 in favor, 11 against
> 2) The principle of creating an inter-RIR transfer policy? 41 in
> favor, 1 against
> 3) The principle of a needs-based inter-RIR transfer policy? 36 in
> favor, 2 against
>
> I believe that is exactly what rough consensus looks like. I am forced
> to characterize that as a _significant *show* of support_ and denounce
> your claim to the contrary.
>
>> But fair enough. Considering the lack of support overall though, I'd
>> strongly suggest abandonment as a serious issue for continued AC
>> discussion.
>
> Repeating a falsehood does not make it so. The community as a whole
> has very clearly asked us to work on this policy.

With the current commentary in the thread offers a much different
picture. If you're saying that today and commenting on this proposal
now we have consensus. you are incorrect.


Best,

-M<


From scottleibrand at gmail.com  Wed Jun 22 11:42:16 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 22 Jun 2011 08:42:16 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
Message-ID: <3616067634770048478@unknownmsgid>

As much as I support inter-RIR transfers, and agree with Chris that we
had strong support for this at San Juan, I think Marty is right that
opinion on PPML is much more divided. I personally think that is
because of the moderating and pragmaticizing influence of in-person
discussion, not because overall sentiment has changed. But regardless,
I won't oppose sending it for another round of discussion in Philly.

After Thursday, I also plan to float some other ideas (which we've
discussed here on the AC list) on PPML for inter-RIR transfer policy
that avoids the requirement for needs-based local transfer policy at
the receiving RIR. I think that will be necessary to actually allow
any inter-RIR transfers to APNIC. Since the current proposals are
no-ops unless APNIC changes their transfer policy in Busan, I'm ok
waiting to discuss them at Philly as well.

Scott

On Jun 22, 2011, at 8:30 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Wed, Jun 22, 2011 at 11:21 AM, Chris Grundemann
> <cgrundemann at gmail.com> wrote:
>> On Tue, Jun 21, 2011 at 15:08, Martin Hannigan <hannigan at gmail.com> wrote:
>>
>>> I guess I'm not clear on what the consensus looks like at this point
>>> since I'm under the impression that there is a significant lack of
>>> support community wise.
>>
>> From the straw poll at the PPM in San Juan (116 in the room):
>> 1) 2011-1 as written? 18 in favor, 11 against
>> 2) The principle of creating an inter-RIR transfer policy? 41 in
>> favor, 1 against
>> 3) The principle of a needs-based inter-RIR transfer policy? 36 in
>> favor, 2 against
>>
>> I believe that is exactly what rough consensus looks like. I am forced
>> to characterize that as a _significant *show* of support_ and denounce
>> your claim to the contrary.
>>
>>> But fair enough. Considering the lack of support overall though, I'd
>>> strongly suggest abandonment as a serious issue for continued AC
>>> discussion.
>>
>> Repeating a falsehood does not make it so. The community as a whole
>> has very clearly asked us to work on this policy.
>
> With the current commentary in the thread offers a much different
> picture. If you're saying that today and commenting on this proposal
> now we have consensus. you are incorrect.
>
>
> Best,
>
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From cgrundemann at gmail.com  Wed Jun 22 11:49:03 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 22 Jun 2011 09:49:03 -0600
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
Message-ID: <BANLkTi=9M5xZKYegFk=BA14t5_1ACNBw6Q@mail.gmail.com>

On Wed, Jun 22, 2011 at 09:29, Martin Hannigan <hannigan at gmail.com> wrote:
>
> With the current commentary in the thread offers a much different
> picture. If you're saying that today and commenting on this proposal
> now we have consensus. you are incorrect.

You're saying that we should give four active voices today more weight
then the 116 folks that showed up in San Juan? While I deeply respect
all the opinions stated in this thread, I have a hard time ignoring 41
people because 4 say I should.

We obviously won't agree so I'll leave the debate on consensus here.

Cheers,
~Chris

>
> Best,
>
> -M<
>



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


From joe at oregon.uoregon.edu  Wed Jun 22 12:02:39 2011
From: joe at oregon.uoregon.edu (Joe St Sauver)
Date: Wed, 22 Jun 2011 09:02:39 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
Message-ID: <11062209023926_F51F@oregon.uoregon.edu>

Jimmy Hess commented:

#Returning resources not needed in a region to IANA is more controllable and 
#far safer.

I would certainly not object to any RIR that wanted to return an excess /8 
to IANA doing so, but I view that as a far different issue than direct
inter-RIR transfers.

#Another safer possibility might be some form of "Revokable Inter-RIR
#delegation"; allowing a RIR to delegate a resource to another RIR  (or 
#other Cross-regional LIR), for cross-regional usage, for good 
#justification, for the duration which that resource is maintained, and 
#requiring all involved RIR/LIRs' policies be followed regarding
#all further subdelegation  (including maintenance fees from both RIRs)
#and continued justified need for the allocation.

I believe this would be kin to recording covenants and riders on real
estate transactions, and I'd oppose any attempt at doing that -- the
process would be extremely cumbersome and would effectively create 
multiple "classes" of addresses (beyond things like the PI/PA distinctions
that exist already).

Regards,

Joe

Disclaimer: all opinions expressed are my own.


From BillD at cait.wustl.edu  Wed Jun 22 12:27:54 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Jun 2011 11:27:54 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <3616067634770048478@unknownmsgid>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA1C9@ex1.cait.wustl.edu>

As you know I have proposed alternate language that tries to incorporate
some things and eliminate others that are controversial.  I have done
this because I sense that stalemate still exists on the current DP and
while I absolutely support and encourage Owen in his interest for
bringing it to another vote, I don't see it being sent to last call.  My
effort is parallel and aimed at Philly.

I welcome your new ideas on what I believe is the chief obstacle of
needs-based policy in recipient RIRs.   Personally and for the
record...all this is still deck chairs for me.  I think that even in the
short to intermediate term this wrangling only affects the Internet
governance issue.  

Few will recall, but I openly advocated for accepting 2009-3 in its
original format as I believed it was insignificant in consequence and
not doing so had many undesirous effects.

So, again, I welcome the discussion of the pros and cons of the whole
issue top to bottom.

Thanks!

bd 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Wednesday, June 22, 2011 10:42 AM
> To: Martin Hannigan
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - Shepherd's Inquiry
> 
> As much as I support inter-RIR transfers, and agree with 
> Chris that we had strong support for this at San Juan, I 
> think Marty is right that opinion on PPML is much more 
> divided. I personally think that is because of the moderating 
> and pragmaticizing influence of in-person discussion, not 
> because overall sentiment has changed. But regardless, I 
> won't oppose sending it for another round of discussion in Philly.
> 
> After Thursday, I also plan to float some other ideas (which 
> we've discussed here on the AC list) on PPML for inter-RIR 
> transfer policy that avoids the requirement for needs-based 
> local transfer policy at the receiving RIR. I think that will 
> be necessary to actually allow any inter-RIR transfers to 
> APNIC. Since the current proposals are no-ops unless APNIC 
> changes their transfer policy in Busan, I'm ok waiting to 
> discuss them at Philly as well.
> 
> Scott
> 
> On Jun 22, 2011, at 8:30 AM, Martin Hannigan 
> <hannigan at gmail.com> wrote:
> 
> > On Wed, Jun 22, 2011 at 11:21 AM, Chris Grundemann 
> > <cgrundemann at gmail.com> wrote:
> >> On Tue, Jun 21, 2011 at 15:08, Martin Hannigan 
> <hannigan at gmail.com> wrote:
> >>
> >>> I guess I'm not clear on what the consensus looks like at 
> this point 
> >>> since I'm under the impression that there is a 
> significant lack of 
> >>> support community wise.
> >>
> >> From the straw poll at the PPM in San Juan (116 in the room):
> >> 1) 2011-1 as written? 18 in favor, 11 against
> >> 2) The principle of creating an inter-RIR transfer policy? 41 in 
> >> favor, 1 against
> >> 3) The principle of a needs-based inter-RIR transfer policy? 36 in 
> >> favor, 2 against
> >>
> >> I believe that is exactly what rough consensus looks like. I am 
> >> forced to characterize that as a _significant *show* of 
> support_ and 
> >> denounce your claim to the contrary.
> >>
> >>> But fair enough. Considering the lack of support overall 
> though, I'd 
> >>> strongly suggest abandonment as a serious issue for continued AC 
> >>> discussion.
> >>
> >> Repeating a falsehood does not make it so. The community 
> as a whole 
> >> has very clearly asked us to work on this policy.
> >
> > With the current commentary in the thread offers a much different 
> > picture. If you're saying that today and commenting on this 
> proposal 
> > now we have consensus. you are incorrect.
> >
> >
> > Best,
> >
> > -M<
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From bill at herrin.us  Wed Jun 22 12:43:31 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 22 Jun 2011 12:43:31 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
Message-ID: <BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>

On Wed, Jun 22, 2011 at 11:21 AM, Chris Grundemann
<cgrundemann at gmail.com> wrote:
> On Tue, Jun 21, 2011 at 15:08, Martin Hannigan <hannigan at gmail.com> wrote:
>> I guess I'm not clear on what the consensus looks like at this point
>> since I'm under the impression that there is a significant lack of
>> support community wise.
>
> >From the straw poll at the PPM in San Juan (116 in the room):
> 1) 2011-1 as written? 18 in favor, 11 against
> 2) The principle of creating an inter-RIR transfer policy? 41 in
> favor, 1 against
> 3) The principle of a needs-based inter-RIR transfer policy? 36 in
> favor, 2 against
>
> I believe that is exactly what rough consensus looks like. I am forced
> to characterize that as a _significant *show* of support_ and denounce
> your claim to the contrary.

Chris,

I'd say that points 2 and 3 is what consensus looks like. Point 1
looks like a bunch of the folks who show up from out-region raising
their hands -- not anything vaguely like ARIN-region consensus. This
seems confirmed by the views expressed on the PPML.

You'll get better attendance of ARIN-region net ops in Philly. If you
ask the same questions, you'll get much clearer results.

Regards,
Bill Herrin


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


From bill at herrin.us  Wed Jun 22 12:44:48 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 22 Jun 2011 12:44:48 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
Message-ID: <BANLkTin15tVmP5KL2P_gzGANsB9WK-DUbg@mail.gmail.com>

On Wed, Jun 22, 2011 at 12:43 PM, William Herrin <bill at herrin.us> wrote:
> You'll get better attendance of ARIN-region net ops in Philly. If you
> ask the same questions, you'll get much clearer results.

[because it's a joint NANOG/ARIN meeting and a lot of the net ops stay
over for ARIN where they don't bother going to the ARIN-only meeting]


-- 
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 cgrundemann at gmail.com  Wed Jun 22 13:55:31 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 22 Jun 2011 11:55:31 -0600
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
Message-ID: <BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com>

On Wed, Jun 22, 2011 at 10:43, William Herrin <bill at herrin.us> wrote:

> I'd say that points 2 and 3 is what consensus looks like.

Exactly.


From bill at herrin.us  Wed Jun 22 15:02:50 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 22 Jun 2011 15:02:50 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
	<BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com>
Message-ID: <BANLkTimEjzkAaB2Ga5RjkPDJLzxhjK==Kw@mail.gmail.com>

On Wed, Jun 22, 2011 at 1:55 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> On Wed, Jun 22, 2011 at 10:43, William Herrin <bill at herrin.us> wrote:
>> I'd say that points 2 and 3 is what consensus looks like.
>
> Exactly.

Hi Chris,

Then what's your beef with what Marty said? I saw the part where he
claimed the proposal on the table does not have consensus. He's right.
Did I miss some other part where he claimed there was no consensus to
pursue development of an acceptable inter-RIR transfer process?


Even I want to see inter-RIR transfers. I just don't want to see them
directly or indirectly drain ARIN's remaining free pool. Vague
statements on the principles of need don't get that job done. Neither
do proposals containing obvious poison pills for APNIC.

And frankly I'm very against creating global policy that restricts RIR
choices in a sidewise manner. This is a little like the federal law
the revokes highway funds for any state that doesn't set the drinking
age at 21. What happens five years from now when *we* see the wisdom
of stepping away from what by then could be an expensive nuisance
justification process for IPv4 transfers?

Regardless, there is most emphatically no consensus that 2011-1 should
be the law of the land and it would be inappropriate to move it last
call at this time.

Regards,
Bill Herrin


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


From kkargel at polartel.com  Wed Jun 22 15:55:36 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 22 Jun 2011 14:55:36 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTimEjzkAaB2Ga5RjkPDJLzxhjK==Kw@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com>
	<BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com>
	<BANLkTimEjzkAaB2Ga5RjkPDJLzxhjK==Kw@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D55F@MAIL1.polartel.local>

{evil top post}

I *think* I agree with what Bill is saying.  ARIN should be free to do inter-RIR transfers with caveats.  IMHO the transfers should not be longer than /8 unless they complete a /8 for the receiver, and there should be no transfers if ARIN has a current or foreseeable need.

Kevin


 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Wednesday, June 22, 2011 2:03 PM
> To: Chris Grundemann
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
> Shepherd's Inquiry
> 
> On Wed, Jun 22, 2011 at 1:55 PM, Chris Grundemann <cgrundemann at gmail.com>
> wrote:
> > On Wed, Jun 22, 2011 at 10:43, William Herrin <bill at herrin.us> wrote:
> >> I'd say that points 2 and 3 is what consensus looks like.
> >
> > Exactly.
> 
> Hi Chris,
> 
> Then what's your beef with what Marty said? I saw the part where he
> claimed the proposal on the table does not have consensus. He's right.
> Did I miss some other part where he claimed there was no consensus to
> pursue development of an acceptable inter-RIR transfer process?
> 
> 
> Even I want to see inter-RIR transfers. I just don't want to see them
> directly or indirectly drain ARIN's remaining free pool. Vague
> statements on the principles of need don't get that job done. Neither
> do proposals containing obvious poison pills for APNIC.
> 
> And frankly I'm very against creating global policy that restricts RIR
> choices in a sidewise manner. This is a little like the federal law
> the revokes highway funds for any state that doesn't set the drinking
> age at 21. What happens five years from now when *we* see the wisdom
> of stepping away from what by then could be an expensive nuisance
> justification process for IPv4 transfers?
> 
> Regardless, there is most emphatically no consensus that 2011-1 should
> be the law of the land and it would be inappropriate to move it last
> call at this time.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From BillD at cait.wustl.edu  Wed Jun 22 16:08:40 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Jun 2011 15:08:40 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <8695009A81378E48879980039EEDAD28010C52D55F@MAIL1.polartel.local>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com><BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com><BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com><BANLkTimEjzkAaB2Ga5RjkPDJLzxhjK==Kw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28010C52D55F@MAIL1.polartel.local>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA204@ex1.cait.wustl.edu>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Wednesday, June 22, 2011 2:56 PM
> To: 'William Herrin'; Chris Grundemann
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - Shepherd's Inquiry
> 
> {evil top post}
> 
> I *think* I agree with what Bill is saying.  ARIN should be 
> free to do inter-RIR transfers with caveats.  IMHO the 
> transfers should not be longer than /8 unless they complete a 
> /8 for the receiver, and there should be no transfers if ARIN 
> has a current or foreseeable need.

Kevin...and your belief that ARIN should keep all that space that could come available anytime in the future and forever (assuming the possibility of any future foreseeable need), even though the space may have been legacy and allocated wastefully (classfully) to those recipients before the world, commercial Internet emerged?  First come first served...but if those addresses 'come again' how is it reasonable that only ARIN should benefit from the emergence of a public good in the new reality of a global Internet and global need?

Curious only...as an individual member of the community.

bd

> 
> Kevin
> 
> 
>  
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] 
> > On Behalf Of William Herrin
> > Sent: Wednesday, June 22, 2011 2:03 PM
> > To: Chris Grundemann
> > Cc: arin ppml; Robert E. Seastrom
> > Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - 
> > Shepherd's Inquiry
> > 
> > On Wed, Jun 22, 2011 at 1:55 PM, Chris Grundemann 
> > <cgrundemann at gmail.com>
> > wrote:
> > > On Wed, Jun 22, 2011 at 10:43, William Herrin 
> <bill at herrin.us> wrote:
> > >> I'd say that points 2 and 3 is what consensus looks like.
> > >
> > > Exactly.
> > 
> > Hi Chris,
> > 
> > Then what's your beef with what Marty said? I saw the part where he 
> > claimed the proposal on the table does not have consensus. 
> He's right.
> > Did I miss some other part where he claimed there was no 
> consensus to 
> > pursue development of an acceptable inter-RIR transfer process?
> > 
> > 
> > Even I want to see inter-RIR transfers. I just don't want 
> to see them 
> > directly or indirectly drain ARIN's remaining free pool. Vague 
> > statements on the principles of need don't get that job 
> done. Neither 
> > do proposals containing obvious poison pills for APNIC.
> > 
> > And frankly I'm very against creating global policy that 
> restricts RIR 
> > choices in a sidewise manner. This is a little like the federal law 
> > the revokes highway funds for any state that doesn't set 
> the drinking 
> > age at 21. What happens five years from now when *we* see 
> the wisdom 
> > of stepping away from what by then could be an expensive nuisance 
> > justification process for IPv4 transfers?
> > 
> > Regardless, there is most emphatically no consensus that 
> 2011-1 should 
> > be the law of the land and it would be inappropriate to 
> move it last 
> > call at this time.
> > 
> > Regards,
> > Bill Herrin
> > 
> > 
> > --
> > William D. Herrin ................ herrin at dirtside.com? 
> bill at herrin.us
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> 
> > Falls Church, VA 22042-3004 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From kkargel at polartel.com  Wed Jun 22 16:23:23 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 22 Jun 2011 15:23:23 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA204@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com><BANLkTim9ciQ0=vQxeMjwtyS7qzKwoV=toQ@mail.gmail.com><BANLkTi=JdpYy-A=3USzEMC8ad4RqO8sxVw@mail.gmail.com><BANLkTimEjzkAaB2Ga5RjkPDJLzxhjK==Kw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD28010C52D55F@MAIL1.polartel.local>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA204@ex1.cait.wustl.edu>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D561@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Bill Darte [mailto:BillD at cait.wustl.edu]
> Sent: Wednesday, June 22, 2011 3:09 PM
> To: Kevin Kargel; William Herrin; Chris Grundemann
> Cc: arin ppml; Robert E. Seastrom
> Subject: RE: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
> Shepherd's Inquiry
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > Sent: Wednesday, June 22, 2011 2:56 PM
> > To: 'William Herrin'; Chris Grundemann
> > Cc: arin ppml; Robert E. Seastrom
> > Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
> > Transfers - Shepherd's Inquiry
> >
> > {evil top post}
> >
> > I *think* I agree with what Bill is saying.  ARIN should be
> > free to do inter-RIR transfers with caveats.  IMHO the
> > transfers should not be longer than /8 unless they complete a
> > /8 for the receiver, and there should be no transfers if ARIN
> > has a current or foreseeable need.
> 
> Kevin...and your belief that ARIN should keep all that space that could
> come available anytime in the future and forever (assuming the possibility
> of any future foreseeable need), even though the space may have been
> legacy and allocated wastefully (classfully) to those recipients before
> the world, commercial Internet emerged?  First come first served...but if
> those addresses 'come again' how is it reasonable that only ARIN should
> benefit from the emergence of a public good in the new reality of a global
> Internet and global need?
> 
> Curious only...as an individual member of the community.
> 
> bd 

My belief is that if ARIN holds authority for an ip block *and* if ARIN has a need for that IP block then ARIN should not relinquish it.  Why should ARIN relinquish a resource they have need for?  Is that simply enough said?

If ARIN currently holds authority for an IP block and ARIN has no need for it then ARIN should be able to (not be required to) transfer the IP block *IF* the IP block can be transferred responsibly to a party that can justify a current need for it as ARIN staff deems proper and according to established policy.  

I think this is a simple and straightforward approach that does take the worlds needs in to consideration after ARIN's needs are met.  From what I have seen the other RIR's are not going to place ARIN's needs above their own either.


> 
> >
> > Kevin
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net]
> > > On Behalf Of William Herrin
> > > Sent: Wednesday, June 22, 2011 2:03 PM
> > > To: Chris Grundemann
> > > Cc: arin ppml; Robert E. Seastrom
> > > Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
> > Transfers -
> > > Shepherd's Inquiry
> > >
> > > On Wed, Jun 22, 2011 at 1:55 PM, Chris Grundemann
> > > <cgrundemann at gmail.com>
> > > wrote:
> > > > On Wed, Jun 22, 2011 at 10:43, William Herrin
> > <bill at herrin.us> wrote:
> > > >> I'd say that points 2 and 3 is what consensus looks like.
> > > >
> > > > Exactly.
> > >
> > > Hi Chris,
> > >
> > > Then what's your beef with what Marty said? I saw the part where he
> > > claimed the proposal on the table does not have consensus.
> > He's right.
> > > Did I miss some other part where he claimed there was no
> > consensus to
> > > pursue development of an acceptable inter-RIR transfer process?
> > >
> > >
> > > Even I want to see inter-RIR transfers. I just don't want
> > to see them
> > > directly or indirectly drain ARIN's remaining free pool. Vague
> > > statements on the principles of need don't get that job
> > done. Neither
> > > do proposals containing obvious poison pills for APNIC.
> > >
> > > And frankly I'm very against creating global policy that
> > restricts RIR
> > > choices in a sidewise manner. This is a little like the federal law
> > > the revokes highway funds for any state that doesn't set
> > the drinking
> > > age at 21. What happens five years from now when *we* see
> > the wisdom
> > > of stepping away from what by then could be an expensive nuisance
> > > justification process for IPv4 transfers?
> > >
> > > Regardless, there is most emphatically no consensus that
> > 2011-1 should
> > > be the law of the land and it would be inappropriate to
> > move it last
> > > call at this time.
> > >
> > > Regards,
> > > Bill Herrin
> > >
> > >
> > > --
> > > William D. Herrin ................ herrin at dirtside.com
> > bill at herrin.us
> > > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > > Falls Church, VA 22042-3004
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed
> > to the ARIN
> > > Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >


From owen at delong.com  Wed Jun 22 16:57:10 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jun 2011 13:57:10 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <3616067634770048478@unknownmsgid>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
Message-ID: <A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>

> After Thursday, I also plan to float some other ideas (which we've
> discussed here on the AC list) on PPML for inter-RIR transfer policy
> that avoids the requirement for needs-based local transfer policy at
> the receiving RIR. I think that will be necessary to actually allow
> any inter-RIR transfers to APNIC. Since the current proposals are
> no-ops unless APNIC changes their transfer policy in Busan, I'm ok
> waiting to discuss them at Philly as well.
> 

First, the current proposals are not no-ops. They happen to exclude
APNIC unless APNIC happens to change their policy. I see this as
the right thing to do. I will strenuously oppose any policy that favors the
elimination of needs basis and the abandonment of our stewardship in
that direction.

Owen



From mike at nationwideinc.com  Wed Jun 22 17:48:52 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Wed, 22 Jun 2011 17:48:52 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
Message-ID: <0331D5C3EA74461286B111A482D85E4A@mike>

>
> First, the current proposals are not no-ops. They happen to exclude
> APNIC unless APNIC happens to change their policy. I see this as
> the right thing to do. I will strenuously oppose any policy that favors 
> the
> elimination of needs basis and the abandonment of our stewardship in
> that direction.
>
> Owen
>

Owen,

You know there are Asian companies with justifiable need who will be 
prevented from accessing the mother lode of available address space in ARIN 
simply because you believe that your notion of stewardship is superior to 
the APNIC community's.

Basically you are holding those companies' justifiable need hostage to the 
fears you have about market speculators and the like.

Nevermind that there is no evidence of that speculation happening and 
nevermind that APNIC has a real, honest need, and nevermind that ARIN has 
the benefit of huge legacy allocations.
And nevermind that the stewards at APNIC debated and decided that their 
primary stewardship of Whois demanded changes to their needs policies for 
transfers.

The effect of your strenous opposition will be the prevention of unused 
addresses being put to use by those with a justifiable need, just so you can 
prevent anybody without a justifiable need from possibly getting space.

So you are standing between those with a need and those with unused space 
and preventing the transfer. Now that's stewardship.
I mean, wouldn't you even consider dropping the needs language from the 
proposal and relying on ARIN staff to discern nefarious practices and not 
agree to the transfer?
Do you really think there are wild horses worth of speculators just waiting 
for the door to open a crack, then rush in to drain all available space 
before the ARIN staff knew what was happening?
I really think that's a stretch. Yet you are using that fear to effectively 
block all transfers to APNIC.

And to say the current proposals "happen to exclude" APNIC is disingenous. 
The language we are debating could just as easily say "No APNIC members need 
apply" and have the same effect.

And as usual, you ignore the threat to the registration function of standing 
between willing buyers and willing sellers, with willing network operators 
ready to carry the traffic waiting in the wings.

I know you will point the finger at the APNIC stewards and insist they 
revert to a needs test, but you are effectively using the justifiable but 
unmet need of the APNIC members as blackmail to force them to effect that 
change.

Regards,
Mike









From jeffrey.lyon at blacklotus.net  Wed Jun 22 18:04:03 2011
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 22 Jun 2011 18:04:03 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <3616067634770048478@unknownmsgid>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
Message-ID: <BANLkTiksZv+XJvycUeKH+p_zJ07w9x-rTA@mail.gmail.com>

I remain vehemently against this policy. APNIC's justified need is not
ARIN's concern, ARIN's justified need is.

Jeff

On Wed, Jun 22, 2011 at 11:42 AM, Scott Leibrand
<scottleibrand at gmail.com> wrote:
> As much as I support inter-RIR transfers, and agree with Chris that we
> had strong support for this at San Juan, I think Marty is right that
> opinion on PPML is much more divided. I personally think that is
> because of the moderating and pragmaticizing influence of in-person
> discussion, not because overall sentiment has changed. But regardless,
> I won't oppose sending it for another round of discussion in Philly.
>
> After Thursday, I also plan to float some other ideas (which we've
> discussed here on the AC list) on PPML for inter-RIR transfer policy
> that avoids the requirement for needs-based local transfer policy at
> the receiving RIR. I think that will be necessary to actually allow
> any inter-RIR transfers to APNIC. Since the current proposals are
> no-ops unless APNIC changes their transfer policy in Busan, I'm ok
> waiting to discuss them at Philly as well.
>
> Scott
>
> On Jun 22, 2011, at 8:30 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>
>> On Wed, Jun 22, 2011 at 11:21 AM, Chris Grundemann
>> <cgrundemann at gmail.com> wrote:
>>> On Tue, Jun 21, 2011 at 15:08, Martin Hannigan <hannigan at gmail.com> wrote:
>>>
>>>> I guess I'm not clear on what the consensus looks like at this point
>>>> since I'm under the impression that there is a significant lack of
>>>> support community wise.
>>>
>>> From the straw poll at the PPM in San Juan (116 in the room):
>>> 1) 2011-1 as written? 18 in favor, 11 against
>>> 2) The principle of creating an inter-RIR transfer policy? 41 in
>>> favor, 1 against
>>> 3) The principle of a needs-based inter-RIR transfer policy? 36 in
>>> favor, 2 against
>>>
>>> I believe that is exactly what rough consensus looks like. I am forced
>>> to characterize that as a _significant *show* of support_ and denounce
>>> your claim to the contrary.
>>>
>>>> But fair enough. Considering the lack of support overall though, I'd
>>>> strongly suggest abandonment as a serious issue for continued AC
>>>> discussion.
>>>
>>> Repeating a falsehood does not make it so. The community as a whole
>>> has very clearly asked us to work on this policy.
>>
>> With the current commentary in the thread offers a much different
>> picture. If you're saying that today and commenting on this proposal
>> now we have consensus. you are incorrect.
>>
>>
>> Best,
>>
>> -M<
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions


From owen at delong.com  Wed Jun 22 18:05:17 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jun 2011 15:05:17 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
In-Reply-To: <0331D5C3EA74461286B111A482D85E4A@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<0331D5C3EA74461286B111A482D85E4A@mike>
Message-ID: <9527133D-9380-4D0D-87D7-E4D38893118A@delong.com>


On Jun 22, 2011, at 2:48 PM, Mike Burns wrote:

>> 
>> First, the current proposals are not no-ops. They happen to exclude
>> APNIC unless APNIC happens to change their policy. I see this as
>> the right thing to do. I will strenuously oppose any policy that favors the
>> elimination of needs basis and the abandonment of our stewardship in
>> that direction.
>> 
>> Owen
>> 
> 
> Owen,
> 
> You know there are Asian companies with justifiable need who will be prevented from accessing the mother lode of available address space in ARIN simply because you believe that your notion of stewardship is superior to the APNIC community's.
> 
Yes. Regrettably, APNIC's policy decisions will preclude some of their organizations from being able to acquire addresses from the ARIN region if we pass 2011-1. Hopefully they will choose to act in their region to correct this imbalance of policy if they feel participating in such transfers is of benefit to their community.

> Basically you are holding those companies' justifiable need hostage to the fears you have about market speculators and the like.
> 
Not how I would characterize it, but, I understand your perspective.

> Nevermind that there is no evidence of that speculation happening and nevermind that APNIC has a real, honest need, and nevermind that ARIN has the benefit of huge legacy allocations.
> And nevermind that the stewards at APNIC debated and decided that their primary stewardship of Whois demanded changes to their needs policies for transfers.
> 

Seriously? You really think the fact that it hasn't been proven yet in any way provides a compelling case that it won't? ROFL.
I'm well aware of the fact that you agree with them. I'm well aware of your preference to dispense with needs-basis altogether. I'm well aware of the fact that you think speculators and the offering of IP addresses to the highest bidder without concern for the consequences is a good idea. On each and every one of these points, we have well established different opinions.

> The effect of your strenous opposition will be the prevention of unused addresses being put to use by those with a justifiable need, just so you can prevent anybody without a justifiable need from possibly getting space.

I'm sure the addresses will get used by people with justifiable need. If it isn't those people in Asia of whom you speak, it will be others.


> 
> So you are standing between those with a need and those with unused space and preventing the transfer. Now that's stewardship.

I am standing between those with a policy that precludes preservation of needs basis and a pool of available addresses which can be held for those who definitely have need. Yes, there are people in Asia who will suffer under the APNIC policy and that is regrettable. However, the policy problems in APNIC are an issue for the APNIC community (in which I do participate). Even if APNIC wants to preserve their current lack of needs basis, I would consider it sufficient if they adopted a policy that stated addresses transferred in from other regions would remain subject to needs-basis for subsequent transfer, or, would be returned to the original region when no longer in use by the original transferee.

It is not my goal to change APNIC policy, preclude their ability to set their own policies, or, in any way punish APNIC for the policies they have set. However, it is my goal to prevent the flow of addresses from a needs-based policy environment to the IP equivalent of the wild west.

> I mean, wouldn't you even consider dropping the needs language from the proposal and relying on ARIN staff to discern nefarious practices and not agree to the transfer?

No, I would not.

> Do you really think there are wild horses worth of speculators just waiting for the door to open a crack, then rush in to drain all available space before the ARIN staff knew what was happening?
> I really think that's a stretch. Yet you are using that fear to effectively block all transfers to APNIC.

I am not using fear at all. You insist on calling it fear. In my opinion, it is the only responsible policy. In my opinion, the good of the community requires a preservation of needs-basis in policy with regards to who is eligible to receive addresses. This isn't about fear, it's about doing the correct thing in the best interests of the community. In the San Juan meeting, the community expressed overwhelming consensus for the idea that needs-basis should be preserved in this policy. Even if I didn't agree with them, I would still feel obliged to follow that mandate.

> 
> And to say the current proposals "happen to exclude" APNIC is disingenous. The language we are debating could just as easily say "No APNIC members need apply" and have the same effect.
> 

APNIC made an unfortunate policy choice that goes against the principles preserved by 80% of the RIRs. I really don't think it is fair to criticize ARIN or the ARIN community for remaining aligned with the other 60% of RIRs instead of choosing to support a single RIR that has abandoned a fundamental principle of the RIR system.

> And as usual, you ignore the threat to the registration function of standing between willing buyers and willing sellers, with willing network operators ready to carry the traffic waiting in the wings.
> 

I do not ignore it, I simply do not believe it represents the level of threat you claim or that addresses transferred outside of policy will retain anywhere near the usefulness that you claim. As I result, I believe that problem will be limited in scope. In fact, it is you who are motivated by fear. Fear of off-the-books transfers. I don't think these represent a significant threat and so that fear does not motivate me at this time.

> I know you will point the finger at the APNIC stewards and insist they revert to a needs test, but you are effectively using the justifiable but unmet need of the APNIC members as blackmail to force them to effect that change.
> 

I do not care whether APNIC reverts to a needs-basis test or not. However, if they want resources from the ARIN region, I see no reason we should transfer those resources into their region when we know such a test does not exist.

Owen



From bill at herrin.us  Wed Jun 22 18:33:15 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 22 Jun 2011 18:33:15 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
Message-ID: <BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>

On Wed, Jun 22, 2011 at 4:57 PM, Owen DeLong <owen at delong.com> wrote:
>> Since the current proposals are
>> no-ops unless APNIC changes their transfer policy in Busan, I'm ok
>> waiting to discuss them at Philly as well.
>
> First, the current proposals are not no-ops. They happen to exclude
> APNIC unless APNIC happens to change their policy.

Folks,

I was privately reminded that 2011-1 is intended to be an ARIN-local
policy rather than a global policy ratified by all five RIRs. It's
intended to express the criteria under which we'll participate in
address transfers, not set global policy.

With that in mind, I suggest some more concrete language:

"Where the Board of Trustees unanimously determines that another RIR
implements needs-based addressing policies comparable to ARIN's, ARIN
shall endeavor to establish bilateral and reciprocal agreements which
permit registrants to transfer addresses between regions.

Both registrants involved in transfers under such agreements shall
meet the local policy requirements of both registries. The transfer
shall be revoked unless the recipient puts received resources to use
for a networking purpose within 3 months of receipt. Transferred
resources become part of the resource holdings of the recipient RIR
unless otherwise agreed by both RIRs.

Such transfer agreements shall terminate immediately upon a plurality
determination by the Board that the other RIR no longer implements a
comparable, needs-based addressing policy."


In the above, I tried to stay true to Bill's language while correcting
the problems with vagueness about when ARIN will or won't transfer.
Bill's original language was:

"Address resources may be transferred.... in or out of the ARIN region
to those who demonstrate need and plan to deploy them for a networking
purpose within 3 months. Such transfers will take place between RIRs
who share compatible, needs-based policies on behalf of entities
agreeing to the transfer and which otherwise meet both RIR's policies.
Transferred resources will become part of the resource holdings of the
recipient RIR unless otherwise agreed by both RIRs."


Suggested additions:

"within 3 months of receipt and continues using it for said purpose
for at least 1 year."

"ARIN registrants which have received IPv4 addresses from the ARIN
free pool within the last 2 years are ineligible to offer addresses
for transfer to another region. ARIN registrants which transfer
addresses outregion are ineligible to receive additional IPv4
addresses from the ARIN free pool."


Transfers should not be allowed to deplete the remaining free pool;
we'll exhaust that soon enough all by ourselves.

Thoughts?

Regards,
Bill Herrin



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


From owen at delong.com  Wed Jun 22 18:47:06 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jun 2011 15:47:06 -0700
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
Message-ID: <30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com>


On Jun 22, 2011, at 3:33 PM, William Herrin wrote:

> On Wed, Jun 22, 2011 at 4:57 PM, Owen DeLong <owen at delong.com> wrote:
>>> Since the current proposals are
>>> no-ops unless APNIC changes their transfer policy in Busan, I'm ok
>>> waiting to discuss them at Philly as well.
>> 
>> First, the current proposals are not no-ops. They happen to exclude
>> APNIC unless APNIC happens to change their policy.
> 
> Folks,
> 
> I was privately reminded that 2011-1 is intended to be an ARIN-local
> policy rather than a global policy ratified by all five RIRs. It's
> intended to express the criteria under which we'll participate in
> address transfers, not set global policy.
> 
> With that in mind, I suggest some more concrete language:
> 
> "Where the Board of Trustees unanimously determines that another RIR
> implements needs-based addressing policies comparable to ARIN's, ARIN
> shall endeavor to establish bilateral and reciprocal agreements which
> permit registrants to transfer addresses between regions.
> 
> Both registrants involved in transfers under such agreements shall
> meet the local policy requirements of both registries. The transfer
> shall be revoked unless the recipient puts received resources to use
> for a networking purpose within 3 months of receipt. Transferred
> resources become part of the resource holdings of the recipient RIR
> unless otherwise agreed by both RIRs.
> 
> Such transfer agreements shall terminate immediately upon a plurality
> determination by the Board that the other RIR no longer implements a
> comparable, needs-based addressing policy."
> 
> 

I think the above is a fine policy and encourage you to submit it as a proposal.

I'm not sure it's within the bounds of modifying 2011-1.

> In the above, I tried to stay true to Bill's language while correcting
> the problems with vagueness about when ARIN will or won't transfer.
> Bill's original language was:
> 
> "Address resources may be transferred.... in or out of the ARIN region
> to those who demonstrate need and plan to deploy them for a networking
> purpose within 3 months. Such transfers will take place between RIRs
> who share compatible, needs-based policies on behalf of entities
> agreeing to the transfer and which otherwise meet both RIR's policies.
> Transferred resources will become part of the resource holdings of the
> recipient RIR unless otherwise agreed by both RIRs."
> 
> 
> Suggested additions:
> 
> "within 3 months of receipt and continues using it for said purpose
> for at least 1 year."
> 
> "ARIN registrants which have received IPv4 addresses from the ARIN
> free pool within the last 2 years are ineligible to offer addresses
> for transfer to another region. ARIN registrants which transfer
> addresses outregion are ineligible to receive additional IPv4
> addresses from the ARIN free pool."
> 
I would support both of these, as well. Especially the latter one.

> 
> Transfers should not be allowed to deplete the remaining free pool;
> we'll exhaust that soon enough all by ourselves.
> 
Agreed.

> Thoughts?
> 
See above. ;-)

Owen



From bill at herrin.us  Wed Jun 22 19:03:13 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 22 Jun 2011 19:03:13 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
	<30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com>
Message-ID: <BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>

On Wed, Jun 22, 2011 at 6:47 PM, Owen DeLong <owen at delong.com> wrote:
> On Jun 22, 2011, at 3:33 PM, William Herrin wrote:
>> "Where the Board of Trustees unanimously determines that another RIR
>> implements needs-based addressing policies comparable to ARIN's, ARIN
>> shall endeavor to establish bilateral and reciprocal agreements which
>> permit registrants to transfer addresses between regions.
>>
>> Both registrants involved in transfers under such agreements shall
>> meet the local policy requirements of both registries. The transfer
>> shall be revoked unless the recipient puts received resources to use
>> for a networking purpose within 3 months of receipt. Transferred
>> resources become part of the resource holdings of the recipient RIR
>> unless otherwise agreed by both RIRs.
>>
>> Such transfer agreements shall terminate immediately upon a plurality
>> determination by the Board that the other RIR no longer implements a
>> comparable, needs-based addressing policy."


> I think the above is a fine policy and encourage you to submit it as a proposal.

2011-1 is Bill Darte's show. If he wants this text, he's more than
welcome to it.

If you want me to spend my time championing other people's projects,
feel free to elect me.

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  Thu Jun 23 09:57:48 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 23 Jun 2011 09:57:48 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
	<30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com>
	<BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>
Message-ID: <BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>

On Wed, Jun 22, 2011 at 7:03 PM, William Herrin <bill at herrin.us> wrote:


[ clip ]


>>> shall be revoked unless the recipient puts received resources to use
>>> for a networking purpose within 3 months of receipt. Transferred
>>> resources become part of the resource holdings of the recipient RIR
>>> unless otherwise agreed by both RIRs.


Why not allow "anyone" to come to ARIN and request resources under the
same conditions that the rest of us do?

It potentially conflicts with "ICP 2", but that might be a good
problem to have all considered.

Best,

-M<


From BillD at cait.wustl.edu  Thu Jun 23 10:03:15 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 23 Jun 2011 09:03:15 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
	Shepherd's Inquiry
In-Reply-To: <BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com><BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com><30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com><BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>
	<BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087CDA257@ex1.cait.wustl.edu>

Well now, that's an interesting idea....
Have to investigate the ramifications as you say...but, hmmmmm. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
> Sent: Thursday, June 23, 2011 8:58 AM
> To: William Herrin
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
> Transfers - Shepherd's Inquiry
> 
> On Wed, Jun 22, 2011 at 7:03 PM, William Herrin 
> <bill at herrin.us> wrote:
> 
> 
> [ clip ]
> 
> 
> >>> shall be revoked unless the recipient puts received 
> resources to use 
> >>> for a networking purpose within 3 months of receipt. Transferred 
> >>> resources become part of the resource holdings of the 
> recipient RIR 
> >>> unless otherwise agreed by both RIRs.
> 
> 
> Why not allow "anyone" to come to ARIN and request resources 
> under the same conditions that the rest of us do?
> 
> It potentially conflicts with "ICP 2", but that might be a 
> good problem to have all considered.
> 
> Best,
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From mike at nationwideinc.com  Thu Jun 23 10:09:59 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 10:09:59 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com><30D394EF-2F22-40AD-8C20-345D6B465D95
	@delong.com><BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com><BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA257@ex1.cait.wustl.edu>
Message-ID: <2A9D25B677CA43B4848F81F42695CCFA@mike>

I would not agree.
In my mind we have been talking about transfers of already allocated 
addresses, not new allocations from our free pool.
Maybe I misunderstood, but I object to draining our free pool in this way, 
and I support language which prevents recent ARIN allocants from 
transferring and then getting new addresses from the pool, for the same 
reasons.
Although this is an elegant idea, I doubt the community is ready to drain 
the pool so directly.


Regards,
Mike




----- Original Message ----- 
From: "Bill Darte" <BillD at cait.wustl.edu>
To: "Martin Hannigan" <hannigan at gmail.com>; "William Herrin" 
<bill at herrin.us>
Cc: "arin ppml" <ppml at arin.net>; "Robert E. Seastrom" <rs at seastrom.com>
Sent: Thursday, June 23, 2011 10:03 AM
Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR 
Transfers -Shepherd's Inquiry


> Well now, that's an interesting idea....
> Have to investigate the ramifications as you say...but, hmmmmm.
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
>> Sent: Thursday, June 23, 2011 8:58 AM
>> To: William Herrin
>> Cc: arin ppml; Robert E. Seastrom
>> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
>> Transfers - Shepherd's Inquiry
>>
>> On Wed, Jun 22, 2011 at 7:03 PM, William Herrin
>> <bill at herrin.us> wrote:
>>
>>
>> [ clip ]
>>
>>
>> >>> shall be revoked unless the recipient puts received
>> resources to use
>> >>> for a networking purpose within 3 months of receipt. Transferred
>> >>> resources become part of the resource holdings of the
>> recipient RIR
>> >>> unless otherwise agreed by both RIRs.
>>
>>
>> Why not allow "anyone" to come to ARIN and request resources
>> under the same conditions that the rest of us do?
>>
>> It potentially conflicts with "ICP 2", but that might be a
>> good problem to have all considered.
>>
>> Best,
>>
>> -M<
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues. 



From hannigan at gmail.com  Thu Jun 23 10:13:45 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 23 Jun 2011 10:13:45 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087CDA257@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
	<30D394EF-2F22-40AD-8C20-345D6B465D95@delong.com>
	<BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>
	<BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA257@ex1.cait.wustl.edu>
Message-ID: <BANLkTinq4xGgOsZU5Hc3YiOxgQe-DyuD+g@mail.gmail.com>

On Thu, Jun 23, 2011 at 10:03 AM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Well now, that's an interesting idea....
> Have to investigate the ramifications as you say...but, hmmmmm.
>


I would also not underestimate the political ramifications within the
RIR oligarchy. There are potential revenue and control implications at
play and I can envision significant angst related to how "whois" would
work resulting in it being held up as a primary roadblock. It would
potentially resolve the problem of technical if not in spirit "global
cooperation" and remove most if not all of the in-region roadblocks to
getting something done.

Mike Burns:

Such an idea would need to be developed. Try not to dismiss out of
hand without any detail or discussion. I agree with you with respect
to a drain on the pool. I would envision a secondary pool of non
regional requests operationally "TBD".


Best,

-M<


From mike at nationwideinc.com  Thu Jun 23 10:49:15 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 10:49:15 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com><30D394EF-2F22-40AD-8C20-345D6B465D95
	@delong.com><BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com><BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com><EACF8B735E
	9CBA4B8BAF9E4165D03087CDA257@ex1.cait.wustl.edu>
	<BANLkTinq4xGgOsZU5Hc3YiOxgQe-DyuD+g@mail.gmail.com>
Message-ID: <489159D9E8A3419E8DB3DE1E20108055@mike>


> 
> Mike Burns:
> 
> Such an idea would need to be developed. Try not to dismiss out of
> hand without any detail or discussion. I agree with you with respect
> to a drain on the pool. I would envision a secondary pool of non
> regional requests operationally "TBD".
> 
> 
> Best,
>

Maybe we could allow Inter-RIR transfers only through 8.3?

Regards,
Mike



From hannigan at gmail.com  Thu Jun 23 11:11:16 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 23 Jun 2011 11:11:16 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-Shepherd's Inquiry
In-Reply-To: <489159D9E8A3419E8DB3DE1E20108055@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<BANLkTinULBGG4Kvap61kjaVRRCnjE3BQTQ@mail.gmail.com>
	<BANLkTikR2JDXUKbf2AONhkfGQnjmUSEVzQ@mail.gmail.com>
	<BANLkTim9hGb2mOjERcKqBu+yyJ8x9y=W8A@mail.gmail.com>
	<BANLkTinq4xGgOsZU5Hc3YiOxgQe-DyuD+g@mail.gmail.com>
	<489159D9E8A3419E8DB3DE1E20108055@mike>
Message-ID: <BANLkTimmAcTM_GcTacdxBT5ERccUOyB3vg@mail.gmail.com>

On Thu, Jun 23, 2011 at 10:49 AM, Mike Burns <mike at nationwideinc.com> wrote:
>
>>
>> Mike Burns:
>>
>> Such an idea would need to be developed. Try not to dismiss out of
>> hand without any detail or discussion. I agree with you with respect
>> to a drain on the pool. I would envision a secondary pool of non
>> regional requests operationally "TBD".
>>
>>
>> Best,
>>
>
> Maybe we could allow Inter-RIR transfers only through 8.3?
>


This could be an ASCP suggestion since we're talking more about who
the recipients are vs. how something would operate or the policy
framework. There are some hairy issues other than RIR cooperation like
member rights, voting, etc. but I'd argue those would not be extended
to out of region transfers to keep it simple and low-cost.

Hope that helps.

Best,

-M<


From kkargel at polartel.com  Thu Jun 23 11:56:06 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 10:56:06 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers
	-	Shepherd's Inquiry
In-Reply-To: <A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D566@MAIL1.polartel.local>



 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Wednesday, June 22, 2011 3:57 PM
> To: Scott Leibrand
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
> Shepherd's Inquiry
> 
> > After Thursday, I also plan to float some other ideas (which we've
> > discussed here on the AC list) on PPML for inter-RIR transfer policy
> > that avoids the requirement for needs-based local transfer policy at
> > the receiving RIR. I think that will be necessary to actually allow
> > any inter-RIR transfers to APNIC. Since the current proposals are
> > no-ops unless APNIC changes their transfer policy in Busan, I'm ok
> > waiting to discuss them at Philly as well.
> >
> 
> First, the current proposals are not no-ops. They happen to exclude
> APNIC unless APNIC happens to change their policy. I see this as
> the right thing to do. I will strenuously oppose any policy that favors
> the
> elimination of needs basis and the abandonment of our stewardship in
> that direction.
> 
> Owen
> 
+1 ..  I believe needs basis is fundamental to ARIN philosophy and must not be abandoned.  

Kevin


From kkargel at polartel.com  Thu Jun 23 12:01:57 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 11:01:57 -0500
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR
	Transfers	-Shepherd's Inquiry
In-Reply-To: <0331D5C3EA74461286B111A482D85E4A@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<0331D5C3EA74461286B111A482D85E4A@mike>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>



 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Mike Burns
> Sent: Wednesday, June 22, 2011 4:49 PM
> To: Owen DeLong; Scott Leibrand
> Cc: arin ppml; Robert E. Seastrom
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
> Shepherd's Inquiry
> 
> >
> > First, the current proposals are not no-ops. They happen to exclude
> > APNIC unless APNIC happens to change their policy. I see this as
> > the right thing to do. I will strenuously oppose any policy that favors
> > the
> > elimination of needs basis and the abandonment of our stewardship in
> > that direction.
> >
> > Owen
> >
> 
> Owen,
> 
> You know there are Asian companies with justifiable need who will be
> prevented from accessing the mother lode of available address space in
> ARIN
> simply because you believe that your notion of stewardship is superior to
> the APNIC community's.

I know that too, and I also know that if my family needs food and another family needs food I am feeding mine first, then if I have any food left over I will share.  I don't see the other RIR's making great strides to prepare to share any IP space they have globally.

> 
> Basically you are holding those companies' justifiable need hostage to the
> fears you have about market speculators and the like.
> 
> Nevermind that there is no evidence of that speculation happening and
> nevermind that APNIC has a real, honest need, and nevermind that ARIN has
> the benefit of huge legacy allocations.

Good! Hurrah!  If there is going to be no speculation then we can abandon the whole IP market thing.  

> And nevermind that the stewards at APNIC debated and decided that their
> primary stewardship of Whois demanded changes to their needs policies for
> transfers.
> 
> The effect of your strenous opposition will be the prevention of unused
> addresses being put to use by those with a justifiable need, just so you
> can
> prevent anybody without a justifiable need from possibly getting space.
> 
> So you are standing between those with a need and those with unused space
> and preventing the transfer. Now that's stewardship.
> I mean, wouldn't you even consider dropping the needs language from the
> proposal and relying on ARIN staff to discern nefarious practices and not
> agree to the transfer?
> Do you really think there are wild horses worth of speculators just
> waiting
> for the door to open a crack, then rush in to drain all available space
> before the ARIN staff knew what was happening?
> I really think that's a stretch. Yet you are using that fear to
> effectively
> block all transfers to APNIC.
> 
> And to say the current proposals "happen to exclude" APNIC is disingenous.
> The language we are debating could just as easily say "No APNIC members
> need
> apply" and have the same effect.
> 
> And as usual, you ignore the threat to the registration function of
> standing
> between willing buyers and willing sellers, with willing network operators
> ready to carry the traffic waiting in the wings.
> 
> I know you will point the finger at the APNIC stewards and insist they
> revert to a needs test, but you are effectively using the justifiable but
> unmet need of the APNIC members as blackmail to force them to effect that
> change.
> 
> Regards,
> Mike
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mike at nationwideinc.com  Thu Jun 23 12:12:52 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 12:12:52 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
Message-ID: <6547DD7D4CD84631AD433C7127F2BDD2@mike>

Hi Kevin,

> I know that too, and I also know that if my family needs food and another 
> family needs food I am feeding mine first, then if I have any food left 
> over I will share.  I don't see the other RIR's making great strides to 
> prepare to share any IP space they have globally.

I understand the argument about using ARIN resources in ARIN territory. I 
think it may be a bit jingoistic, but I respect the argument.
It is a separate discussion though, from the needs test which was the issue 
I was raising with Owen.
I also believe that the free pool should be reserved for ARIN members and 
there should be protections against an end-run on the free pool through an 
Inter-RIR transfer policy.

>
>>
>> Basically you are holding those companies' justifiable need hostage to 
>> the
>> fears you have about market speculators and the like.
>>
>> Nevermind that there is no evidence of that speculation happening and
>> nevermind that APNIC has a real, honest need, and nevermind that ARIN has
>> the benefit of huge legacy allocations.
>
> Good! Hurrah!  If there is going to be no speculation then we can abandon 
> the whole IP market thing.
experience any issues.

My argument is that we cannot abandon the whole IP market thing. It is out 
of our control, because the limited power we have is in Whois and reverse 
naming.
We can't force network operators to route or not to route certain addresses, 
and I see no stomach at ARIN for challenging legacy transfers by revoking 
and reissuing their space.

So to think we have any significant power to prevent the rise of an IPv4 
market is naive. What we should do is acknowledge it and take the steps to 
transition ARIN from an arbiter of who gets addresses to a title-agency 
whose routing authority is respected enough to handle the challenges facing 
registration in the post-exhaust world.

Regards,
Mike



From kkargel at polartel.com  Thu Jun 23 12:31:21 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 11:31:21 -0500
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <6547DD7D4CD84631AD433C7127F2BDD2@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Mike Burns [mailto:mike at nationwideinc.com]
> Sent: Thursday, June 23, 2011 11:13 AM
> To: Kevin Kargel; arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers -
> Shepherd's Inquiry
> 
> Hi Kevin,
> 
> > I know that too, and I also know that if my family needs food and
> another
> > family needs food I am feeding mine first, then if I have any food left
> > over I will share.  I don't see the other RIR's making great strides to
> > prepare to share any IP space they have globally.
> 
> I understand the argument about using ARIN resources in ARIN territory. I
> think it may be a bit jingoistic, but I respect the argument.
> It is a separate discussion though, from the needs test which was the
> issue
> I was raising with Owen.
> I also believe that the free pool should be reserved for ARIN members and
> there should be protections against an end-run on the free pool through an
> Inter-RIR transfer policy.
> 
> >
> >>
> >> Basically you are holding those companies' justifiable need hostage to
> >> the
> >> fears you have about market speculators and the like.
> >>
> >> Nevermind that there is no evidence of that speculation happening and
> >> nevermind that APNIC has a real, honest need, and nevermind that ARIN
> has
> >> the benefit of huge legacy allocations.
> >
> > Good! Hurrah!  If there is going to be no speculation then we can
> abandon
> > the whole IP market thing.
> experience any issues.
> 
> My argument is that we cannot abandon the whole IP market thing. It is out
> of our control, because the limited power we have is in Whois and reverse
> naming.
> We can't force network operators to route or not to route certain
> addresses,
> and I see no stomach at ARIN for challenging legacy transfers by revoking
> and reissuing their space.
> 
> So to think we have any significant power to prevent the rise of an IPv4
> market is naive. What we should do is acknowledge it and take the steps to
> transition ARIN from an arbiter of who gets addresses to a title-agency
> whose routing authority is respected enough to handle the challenges
> facing
> registration in the post-exhaust world.

This falls back to the argument that illicit drug sales are going to happen anyway and we can't stop them so we should legislate and tax them.  I personally don't buy that argument and I refuse to believe that we should facilitate a bad practice just because it is inevitable.  

The majority of drivers break speed limit laws, yet I still feel speed limit laws are good and necessary.  Even if rules don't completely eradicate a problem the existence of the rules can ameliorate the problem.

> 
> Regards,
> Mike



From mike at nationwideinc.com  Thu Jun 23 13:12:41 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 13:12:41 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -Inter-RIRTransfers	-Shepherd's
	Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C52D567@MAIL1.
	polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>
Message-ID: <0580C5F74BE24B518691FBCC4AB0D734@mike>

>
> This falls back to the argument that illicit drug sales are going to 
> happen anyway and we can't stop them so we should legislate and tax them. 
> I personally don't buy that argument and I refuse to believe that we 
> should facilitate a bad practice just because it is inevitable.
>
> The majority of drivers break speed limit laws, yet I still feel speed 
> limit laws are good and necessary.  Even if rules don't completely 
> eradicate a problem the existence of the rules can ameliorate the problem.
>

Hi Kevin,

Perhaps a return to Prohibition is in order, as it may ameliorate problems 
associated with alcohol consumption.
Prohibition may indeed have reduced consumption, but its side effect was the 
growth of organized crime.

Our "needs-based prohibition" will have the side effect of corrupting Whois 
accuracy and driving transactions underground.
We dropped Prohibition when we learned of its costly side effect, I hope we 
can drop the needs test before we have to learn about "Whois bypass" or a 
duel involving a private registry and ARIN over contested address space, or 
between ARIN and APNIC for that matter.

Regards,
Mike





From kkargel at polartel.com  Thu Jun 23 13:30:20 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 12:30:20 -0500
Subject: [arin-ppml] Draft Policy 2011-1 -Inter-RIRTransfers	-Shepherd's
 Inquiry
In-Reply-To: <0580C5F74BE24B518691FBCC4AB0D734@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C52D567@MAIL1.
	polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>
	<0580C5F74BE24B518691FBCC4AB0D734@mike>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D56B@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Mike Burns [mailto:mike at nationwideinc.com]
> Sent: Thursday, June 23, 2011 12:13 PM
> To: Kevin Kargel; arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2011-1 -Inter-RIRTransfers -
> Shepherd's Inquiry
> 
> >
> > This falls back to the argument that illicit drug sales are going to
> > happen anyway and we can't stop them so we should legislate and tax
> them.
> > I personally don't buy that argument and I refuse to believe that we
> > should facilitate a bad practice just because it is inevitable.
> >
> > The majority of drivers break speed limit laws, yet I still feel speed
> > limit laws are good and necessary.  Even if rules don't completely
> > eradicate a problem the existence of the rules can ameliorate the
> problem.
> >
> 
> Hi Kevin,
> 
> Perhaps a return to Prohibition is in order, as it may ameliorate problems
> associated with alcohol consumption.
> Prohibition may indeed have reduced consumption, but its side effect was
> the
> growth of organized crime.

Here in the US we do still have a varied and confusing provisional prohibition in place.  There are many and sundry laws regarding alcohol sale, consumption, transportation, etc..  So yes, it appears the US government sees a valid reason for a limited prohibition.  Many public facilities including schools and publicly owned meeting places enforce either voluntary or mandated prohibition. Many municipalities and even counties still legislate complete prohibition within their borders.  Thank you for adding another point to my case.  

These laws do not eliminate alcohol related problems, but they do to some small extent control and regulate them.


> 
> Our "needs-based prohibition" will have the side effect of corrupting
> Whois
> accuracy and driving transactions underground.
> We dropped Prohibition when we learned of its costly side effect, I hope
> we
> can drop the needs test before we have to learn about "Whois bypass" or a
> duel involving a private registry and ARIN over contested address space,
> or
> between ARIN and APNIC for that matter.

If "Whois bypass" or "private registry" issues arise, this falls in line with how the internet has evolved over the decades.  If people don't like the way something works they do something else.  If the something else works better then networks adopt it, if not the networks don't use it and it atrophy's.  So far this has been eminently functional.  

This is one of my personal soap boxes.  The internet has operated successfully so far only because of the philosophy of cooperative anarchy.

Isn't (wasn't?) internet2 at it's core little more than a private registry with Whois bypass?  This is gross simplification but I think it applies.

Kevin


> 
> Regards,
> Mike
> 
> 



From mike at nationwideinc.com  Thu Jun 23 13:42:37 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 13:42:37 -0400
Subject: [arin-ppml] Draft Policy 2011-1
	-Inter-RIRTransfers	-Shepherd'sInquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C52D567@MAIL1.
	polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike><8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local><0580C5F
	74BE24B518691FBCC4AB0D734@mike>
	<8695009A81378E48879980039EEDAD28010C52D56B@MAIL1.polartel.local>
Message-ID: <C9D540BC8BF54544BFA607C42CCA966D@mike>

Hi Kevin,
>
> If "Whois bypass" or "private registry" issues arise, this falls in line 
> with how the internet has evolved over the decades.  If people don't like 
> the way something works they do something else.  If the something else 
> works better then networks adopt it, if not the networks don't use it and 
> it atrophy's.  So far this has been eminently functional.
>
> This is one of my personal soap boxes.  The internet has operated 
> successfully so far only because of the philosophy of cooperative anarchy.
>
> Isn't (wasn't?) internet2 at it's core little more than a private registry 
> with Whois bypass?  This is gross simplification but I think it applies.
>
> Kevin
>

I have to say I agree with everything you say, but to me cooperative anarchy 
dictates a minimal ruleset of which a needs-test designed for efficiency in 
an unpriced world would not be included.

Regards,
Mike



From kkargel at polartel.com  Thu Jun 23 13:51:17 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 12:51:17 -0500
Subject: [arin-ppml] Draft Policy 2011-1
	-Inter-RIRTransfers	-Shepherd'sInquiry
In-Reply-To: <C9D540BC8BF54544BFA607C42CCA966D@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C52D567@MAIL1.
	polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike><8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local><0580C5F
	74BE24B518691FBCC4AB0D734@mike>
	<8695009A81378E48879980039EEDAD28010C52D56B@MAIL1.polartel.local>
	<C9D540BC8BF54544BFA607C42CCA966D@mike>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D570@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Mike Burns [mailto:mike at nationwideinc.com]
> Sent: Thursday, June 23, 2011 12:43 PM
> To: Kevin Kargel; arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2011-1 -Inter-RIRTransfers -
> Shepherd'sInquiry
> 
> Hi Kevin,
> >
> > If "Whois bypass" or "private registry" issues arise, this falls in line
> > with how the internet has evolved over the decades.  If people don't
> like
> > the way something works they do something else.  If the something else
> > works better then networks adopt it, if not the networks don't use it
> and
> > it atrophy's.  So far this has been eminently functional.
> >
> > This is one of my personal soap boxes.  The internet has operated
> > successfully so far only because of the philosophy of cooperative
> anarchy.
> >
> > Isn't (wasn't?) internet2 at it's core little more than a private
> registry
> > with Whois bypass?  This is gross simplification but I think it applies.
> >
> > Kevin
> >
> 
> I have to say I agree with everything you say, but to me cooperative
> anarchy
> dictates a minimal ruleset of which a needs-test designed for efficiency
> in
> an unpriced world would not be included.

I also agree that a rule set is required, if for no other reason than for network operators to be able to research and design their networks to interoperate with the world.

While operating under cooperative anarchy algorithms, I doubt anyone will deny that the RFC base is a rather extensive rule set.  

Kevin

> 
> Regards,
> Mike



From farmer at umn.edu  Thu Jun 23 13:52:05 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 23 Jun 2011 12:52:05 -0500
Subject: [arin-ppml] Interet2 was: Draft Policy 2011-1
 -Inter-RIRTransfers-Shepherd's Inquiry
In-Reply-To: <8695009A81378E48879980039EEDAD28010C52D56B@MAIL1.polartel.local>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C52D567@MAIL1.	polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike>	<8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>	<0580C5F74BE24B518691FBCC4AB0D734@mike>
	<8695009A81378E48879980039EEDAD28010C52D56B@MAIL1.polartel.local>
Message-ID: <4E037D45.5060201@umn.edu>

On 6/23/11 12:30 CDT, Kevin Kargel wrote:
....
> Isn't (wasn't?) internet2 at it's core little more than a private registry with Whois bypass?  This is gross simplification but I think it applies.
>
> Kevin
>

No, Internet2 never had anything to do with Registry Services.  It is 
simply a private backbone.  Early on (2001ish) for ipv6 it kind of acted 
as an LIR because of the very early IPv6 policies, these days there is a 
push for participants to get their IPv6 assignments or allocations 
directly from ARIN.

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


From owen at delong.com  Thu Jun 23 15:39:54 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Jun 2011 12:39:54 -0700
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <6547DD7D4CD84631AD433C7127F2BDD2@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
Message-ID: <D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>

> 
> My argument is that we cannot abandon the whole IP market thing. It is out of our control, because the limited power we have is in Whois and reverse naming.
> We can't force network operators to route or not to route certain addresses, and I see no stomach at ARIN for challenging legacy transfers by revoking and reissuing their space.
> 
Like speculation, just because you don't see it does not mean that it is not there.

I believe that confronted with a legacy transfer that happened off the books ARIN will go through the following steps (John, feel free to correct me if I'm wrong):

	1.	Attempt to contact the original holder of the resources
			If they acknowledge the transfer, see if the recipient and original holder will work to
			complete the transaction under NRPM 8.

			If they do not acknowledge the transfer, let them know their space has been hijacked
			and encourage them to take appropriate action.

			If they are unreachable, work with the recipient to see if sufficient documentation
			exists to complete an 8.2 or 8.3 transfer and attempt to do so.

	2.	If the original resource holder is unreachable and a transfer cannot be completed
		as described above, I believe ARIN will reclaim the space as abandoned and take
		the appropriate steps to clean and reissue it.

	3.	If the original resource holder is unreachable or uncooperative and the "recipient" refuses to cooperate,
		I believe ARIN is also likely to proceed with reclamation under NRPM 12.


> So to think we have any significant power to prevent the rise of an IPv4 market is naive. What we should do is acknowledge it and take the steps to transition ARIN from an arbiter of who gets addresses to a title-agency whose routing authority is respected enough to handle the challenges facing registration in the post-exhaust world.
> 

Can we prevent the rise of a market? Probably not. Can we apply a needs-basis test to that market and regulate the redistribution of addresses through that market by applying reasonable stewardship policies governing the source and recipient conduct in the market? Yes.

There is a lot of room between the extremes of "ignore the market altogether" and "acknowledge the market and let it become a free-for-all with no rules".

I realize that you favor the latter extreme. I favor something towards the former, but much closer to the middle.

Owen



From hannigan at gmail.com  Thu Jun 23 15:43:58 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 23 Jun 2011 15:43:58 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers -
 Shepherd's Inquiry
In-Reply-To: <8695009A81378E48879980039EEDAD28010C52D566@MAIL1.polartel.local>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTimBHp9M8VvhfTtBYoXi-vmn025jmw@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<A6762C78-F913-4E78-A9BD-8D5F93BE4E95@delong.com>
	<8695009A81378E48879980039EEDAD28010C52D566@MAIL1.polartel.local>
Message-ID: <BANLkTimDjwnc2Bz2hphSd4MkZtR43aCgzQ@mail.gmail.com>

On Thu, Jun 23, 2011 at 11:56 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>

[ snip ]

> +1 .. ?I believe needs basis is fundamental to ARIN philosophy and must not be abandoned.


Kevin, if you don't mind me asking, what would you project the need of
a network your size to be over the next three years? I'll concede that
this isn't wholly scientific up front, but give me a ballpark if you
can.

Best,

-M<


From owen at delong.com  Thu Jun 23 15:44:31 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Jun 2011 12:44:31 -0700
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>
Message-ID: <4D6B2A98-1A8D-4363-B6A5-6FF338886589@delong.com>

>> 
>> So to think we have any significant power to prevent the rise of an IPv4
>> market is naive. What we should do is acknowledge it and take the steps to
>> transition ARIN from an arbiter of who gets addresses to a title-agency
>> whose routing authority is respected enough to handle the challenges
>> facing
>> registration in the post-exhaust world.
> 
> This falls back to the argument that illicit drug sales are going to happen anyway and we can't stop them so we should legislate and tax them.  I personally don't buy that argument and I refuse to believe that we should facilitate a bad practice just because it is inevitable.  
> 

Very poor choice of analogy.

Prohibition of vice is a very different thing from regulation of a market.

> The majority of drivers break speed limit laws, yet I still feel speed limit laws are good and necessary.  Even if rules don't completely eradicate a problem the existence of the rules can ameliorate the problem.
> 

I think there are places where speed limit laws make sense. I support what California calls the basic speed law and certain laws of presumption (known as prima facie speed limits). However, there are many speed limit laws that make no sense yet remain in place (70 MPH on I-5 is a good example).

Getting back to the subject however, Kevin is correct in that even if our efforts to regulate the market are not 100% successful it is still useful to attempt to do so.

Owen



From mike at nationwideinc.com  Thu Jun 23 15:48:37 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 15:48:37 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
Message-ID: <85C9F4B5D6844F6FBEB90DA9F656C172@mike>

Hi Owen,

I don't think ARIN will be confronted with anything, I think they will be 
ignored.
And I don't think ARIN has any rights to revoke or reclaim legacy space 
unless they have an agreement with the rights holder which gives them that 
right.
Clearly they have no additional rights under section 12 to reclaim legacy 
space, that's explicit in the NRPM.
So you would have to demonstrate some other source of that reclamation 
right.
It's not in any agreement between ARIN and the legacy holder, and it's not 
part of any agreement the legacy allocants had with ARIN's precursors.
Where does it come from?

Regards,
Mike




----- Original Message ----- 
From: "Owen DeLong" <owen at delong.com>
To: "Mike Burns" <mike at nationwideinc.com>
Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
Sent: Thursday, June 23, 2011 3:39 PM
Subject: Re: [arin-ppml] Draft Policy 2011-1 - 
Inter-RIRTransfers -Shepherd's Inquiry


>
> My argument is that we cannot abandon the whole IP market thing. It is out 
> of our control, because the limited power we have is in Whois and reverse 
> naming.
> We can't force network operators to route or not to route certain 
> addresses, and I see no stomach at ARIN for challenging legacy transfers 
> by revoking and reissuing their space.
>
Like speculation, just because you don't see it does not mean that it is not 
there.

I believe that confronted with a legacy transfer that happened off the books 
ARIN will go through the following steps (John, feel free to correct me if 
I'm wrong):

1. Attempt to contact the original holder of the resources
If they acknowledge the transfer, see if the recipient and original holder 
will work to
complete the transaction under NRPM 8.

If they do not acknowledge the transfer, let them know their space has been 
hijacked
and encourage them to take appropriate action.

If they are unreachable, work with the recipient to see if sufficient 
documentation
exists to complete an 8.2 or 8.3 transfer and attempt to do so.

2. If the original resource holder is unreachable and a transfer cannot be 
completed
as described above, I believe ARIN will reclaim the space as abandoned and 
take
the appropriate steps to clean and reissue it.

3. If the original resource holder is unreachable or uncooperative and the 
"recipient" refuses to cooperate,
I believe ARIN is also likely to proceed with reclamation under NRPM 12.


> So to think we have any significant power to prevent the rise of an IPv4 
> market is naive. What we should do is acknowledge it and take the steps to 
> transition ARIN from an arbiter of who gets addresses to a title-agency 
> whose routing authority is respected enough to handle the challenges 
> facing registration in the post-exhaust world.
>

Can we prevent the rise of a market? Probably not. Can we apply a 
needs-basis test to that market and regulate the redistribution of addresses 
through that market by applying reasonable stewardship policies governing 
the source and recipient conduct in the market? Yes.

There is a lot of room between the extremes of "ignore the market 
altogether" and "acknowledge the market and let it become a free-for-all 
with no rules".

I realize that you favor the latter extreme. I favor something towards the 
former, but much closer to the middle.

Owen



From kkargel at polartel.com  Thu Jun 23 15:53:22 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 23 Jun 2011 14:53:22 -0500
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <4D6B2A98-1A8D-4363-B6A5-6FF338886589@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<8695009A81378E48879980039EEDAD28010C52D568@MAIL1.polartel.local>
	<4D6B2A98-1A8D-4363-B6A5-6FF338886589@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD28010C52D57A@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Thursday, June 23, 2011 2:45 PM
> To: Kevin Kargel
> Cc: arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers -
> Shepherd's Inquiry
> 
> >>
> >> So to think we have any significant power to prevent the rise of an
> IPv4
> >> market is naive. What we should do is acknowledge it and take the steps
> to
> >> transition ARIN from an arbiter of who gets addresses to a title-agency
> >> whose routing authority is respected enough to handle the challenges
> >> facing
> >> registration in the post-exhaust world.
> >
> > This falls back to the argument that illicit drug sales are going to
> happen anyway and we can't stop them so we should legislate and tax them.
> I personally don't buy that argument and I refuse to believe that we
> should facilitate a bad practice just because it is inevitable.
> >
> 
> Very poor choice of analogy.
> 
> Prohibition of vice is a very different thing from regulation of a market.
> 
> > The majority of drivers break speed limit laws, yet I still feel speed
> limit laws are good and necessary.  Even if rules don't completely
> eradicate a problem the existence of the rules can ameliorate the problem.
> >
> 
> I think there are places where speed limit laws make sense. I support what
> California calls the basic speed law and certain laws of presumption
> (known as prima facie speed limits). However, there are many speed limit
> laws that make no sense yet remain in place (70 MPH on I-5 is a good
> example).
> 
> Getting back to the subject however, Kevin is correct in that even if our
> efforts to regulate the market are not 100% successful it is still useful
> to attempt to do so.
> 
> Owen
Thanks Owen. You are always more accurate in your verbiage than I.  I am jealous of your skill in that regard. My apologies to all if I made poor choices in illustrations.  
Kevin


From owen at delong.com  Thu Jun 23 15:57:08 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Jun 2011 12:57:08 -0700
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <85C9F4B5D6844F6FBEB90DA9F656C172@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
	<85C9F4B5D6844F6FBEB90DA9F656C172@mike>
Message-ID: <4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>


On Jun 23, 2011, at 12:48 PM, Mike Burns wrote:

> Hi Owen,
> 
> I don't think ARIN will be confronted with anything, I think they will be ignored.

When I say confronted, I mean becomes aware of. There are numerous ways in which it is very likely ARIN will become aware of such things.

> And I don't think ARIN has any rights to revoke or reclaim legacy space unless they have an agreement with the rights holder which gives them that right.

You are incorrect, sir. ARIN is the successor registry to the earlier registries for this region. Those registries ALL issued the address space on the
basis that it was issued to a particular organization for a particular purpose and should be returned when one or both of those criteria was no longer
valid.

> Clearly they have no additional rights under section 12 to reclaim legacy space, that's explicit in the NRPM.

The words in NRPM 12 were chosen very carefully. The word additional is just that. We added no ability to reclaim legacy space, but, the existing
abilities remain.

> So you would have to demonstrate some other source of that reclamation right.

Q.E.D. See above.

> It's not in any agreement between ARIN and the legacy holder, and it's not part of any agreement the legacy allocants had with ARIN's precursors.
> Where does it come from?
> 

It is actually part of policies documented in earlier RFCs and in the writings of Jon Postel as described above.

Owen

> Regards,
> Mike
> 
> 
> 
> 
> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
> To: "Mike Burns" <mike at nationwideinc.com>
> Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
> Sent: Thursday, June 23, 2011 3:39 PM
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers -Shepherd's Inquiry
> 
> 
>> 
>> My argument is that we cannot abandon the whole IP market thing. It is out of our control, because the limited power we have is in Whois and reverse naming.
>> We can't force network operators to route or not to route certain addresses, and I see no stomach at ARIN for challenging legacy transfers by revoking and reissuing their space.
>> 
> Like speculation, just because you don't see it does not mean that it is not there.
> 
> I believe that confronted with a legacy transfer that happened off the books ARIN will go through the following steps (John, feel free to correct me if I'm wrong):
> 
> 1. Attempt to contact the original holder of the resources
> If they acknowledge the transfer, see if the recipient and original holder will work to
> complete the transaction under NRPM 8.
> 
> If they do not acknowledge the transfer, let them know their space has been hijacked
> and encourage them to take appropriate action.
> 
> If they are unreachable, work with the recipient to see if sufficient documentation
> exists to complete an 8.2 or 8.3 transfer and attempt to do so.
> 
> 2. If the original resource holder is unreachable and a transfer cannot be completed
> as described above, I believe ARIN will reclaim the space as abandoned and take
> the appropriate steps to clean and reissue it.
> 
> 3. If the original resource holder is unreachable or uncooperative and the "recipient" refuses to cooperate,
> I believe ARIN is also likely to proceed with reclamation under NRPM 12.
> 
> 
>> So to think we have any significant power to prevent the rise of an IPv4 market is naive. What we should do is acknowledge it and take the steps to transition ARIN from an arbiter of who gets addresses to a title-agency whose routing authority is respected enough to handle the challenges facing registration in the post-exhaust world.
>> 
> 
> Can we prevent the rise of a market? Probably not. Can we apply a needs-basis test to that market and regulate the redistribution of addresses through that market by applying reasonable stewardship policies governing the source and recipient conduct in the market? Yes.
> 
> There is a lot of room between the extremes of "ignore the market altogether" and "acknowledge the market and let it become a free-for-all with no rules".
> 
> I realize that you favor the latter extreme. I favor something towards the former, but much closer to the middle.
> 
> Owen



From lar at mwtcorp.net  Thu Jun 23 16:31:06 2011
From: lar at mwtcorp.net (Larry Ash)
Date: Thu, 23 Jun 2011 14:31:06 -0600
Subject: [arin-ppml] Draft Policy 2011-1
	-	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <85C9F4B5D6844F6FBEB90DA9F656C172@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
Message-ID: <web-17578861@be2.mail.trib.com>

"Mike Burns" <mike at nationwideinc.com> wrote:
> Hi Owen,
> 
> I don't think ARIN will be confronted with anything, I think they will be 
>ignored.
> And I don't think ARIN has any rights to revoke or reclaim legacy space 
>unless they have an agreement with the rights holder which gives them that 
>right.

You can argue the reverse just as forcefully. What "right" does a legacy 
holder
have that a simple squatter doesn't. i.e It works now, it worked yesterday 
and
your threatening to make it not work tomorrow. That has weight but not a 
lot.

Any agreement that may have been in place is with a now defunct 
organization.
The fact that ARIN agreed to allow the legacy holders to continue when they
were formed is  the strongest argument that a legacy holder has but I'd 
wouldn't
want to try and take that to a court. I have never gotten IP from any entity 
that
said they were mine. There was always (at least by 1993) language that 
indicated
that they could be reclaimed under some condition.

> Clearly they have no additional rights under section 12 to reclaim legacy 
>space, that's explicit in the NRPM.
> So you would have to demonstrate some other source of that reclamation 
>right.
> It's not in any agreement between ARIN and the legacy holder, and it's not 
>part of any agreement the legacy allocants had with ARIN's precursors.
> Where does it come from?

Existing ARIN policy does not create "rights" for people that have
no formal relationship with ARIN. ARIN policy, up to now, is to
leave well enough alone, that's not exactly a contract.

ARIN could argue that every legacy holder has had ample time to formalize
a relationship and declare the legacy IP not under NRPM abandoned. I know 
that
would be a mistake as it would create an unnecessary war. But the belief 
that
not formalizing a relationship with ARIN, because someone believes that they
have superior "rights" without one is a mistake also.

aside: The IPV6 boys made a mistake by not clearly indicating that IPV6 is
a replacement for IPV4 with the IPV4 drop date to be announced. If we are 
ever
to get out of this swamp that is going to have to be done and a drop dead
date picked.


  

> 
> Regards,
> Mike
> 
> 
> 
> 
> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
> To: "Mike Burns" <mike at nationwideinc.com>
> Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
> Sent: Thursday, June 23, 2011 3:39 PM
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers 
>-Shepherd's Inquiry
> 
> 
>>
>> My argument is that we cannot abandon the whole IP market thing. It is out 
>>of our control, because the limited power we have is in Whois and reverse 
>>naming.
>> We can't force network operators to route or not to route certain 
>>addresses, and I see no stomach at ARIN for challenging legacy transfers by 
>>revoking and reissuing their space.
>>
> Like speculation, just because you don't see it does not mean that it is 
>not there.
> 
> I believe that confronted with a legacy transfer that happened off the 
>books ARIN will go through the following steps (John, feel free to correct 
>me if I'm wrong):
> 
> 1. Attempt to contact the original holder of the resources
> If they acknowledge the transfer, see if the recipient and original holder 
>will work to
> complete the transaction under NRPM 8.
> 
> If they do not acknowledge the transfer, let them know their space has 
>been hijacked
> and encourage them to take appropriate action.
> 
> If they are unreachable, work with the recipient to see if sufficient 
>documentation
> exists to complete an 8.2 or 8.3 transfer and attempt to do so.
> 
> 2. If the original resource holder is unreachable and a transfer cannot be 
>completed
> as described above, I believe ARIN will reclaim the space as abandoned and 
>take
> the appropriate steps to clean and reissue it.
> 
> 3. If the original resource holder is unreachable or uncooperative and the 
>"recipient" refuses to cooperate,
> I believe ARIN is also likely to proceed with reclamation under NRPM 12.
> 
> 
>> So to think we have any significant power to prevent the rise of an IPv4 
>>market is naive. What we should do is acknowledge it and take the steps to 
>>transition ARIN from an arbiter of who gets addresses to a title-agency 
>>whose routing authority is respected enough to handle the challenges facing 
>>registration in the post-exhaust world.
>>
> 
> Can we prevent the rise of a market? Probably not. Can we apply a 
>needs-basis test to that market and regulate the redistribution of 
>addresses through that market by applying reasonable stewardship policies 
>governing the source and recipient conduct in the market? Yes.
> 
> There is a lot of room between the extremes of "ignore the market 
>altogether" and "acknowledge the market and let it become a free-for-all 
>with no rules".
> 
> I realize that you favor the latter extreme. I favor something towards the 
>former, but much closer to the middle.
> 
> 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.

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387


From mike at nationwideinc.com  Thu Jun 23 16:45:20 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 16:45:20 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
	<85C9F4B5D6844F6FBEB90DA9F656C172@mike>
	<4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>
Message-ID: <A7D828E8C9154245BE467CC985F83294@mike>

Hi Owen,

You've been saying this stuff for years, but where is a section 12 
reclamation of legacy space you can point to where the reclamation took 
place due to the original registrant selling his addresses?

Where is any reclamation of legacy space which is not associated with actual 
hijacking, voluntary return, or dissolution? Spamming or child porn? Any 
examples?

The bankruptcy judge, need I remind you, found that Nortel had the exclusive 
right to transfer addresses which were allocated to other companies, and for 
which no ARIN transfer had ever taken place, and this was after all the 
companies involved were bankrupt. I find this much more convincing than 
allusions to RFCs and the writings of Jon Postel. Now if Mr. Postel had 
actually created an agreement which could be legally construed as a 
contract, you might have something. Absent that, you have only bluster which 
grows more outdated each month.

As a test example, I was back at my alma mater last June and I spoke with 
one of the campus computer engineers, who told me although he had 16 million 
ip addresses to work with, most of the campus is Natted. Do you think I 
should open up a ticket and inform ARIN that they should institute a section 
12 review of MIT? Would you like to confront ARIN with that knowledge and 
see if it nets the free pool a sizeable chunk of a /8?

ARIN controls Whois, I'm pretty sure that is what John Curran will say. ARIN 
is within its legal rights to change Whois data in whatever way it pleases.
If ARIN wants to make Whois even more irrelevant, they can take the course 
you prescribe, but since they have not done this, ever, the threat of 
reclamation of legacy space is a nonstarter.

John Curran referencing ex post facto transfer requests demonstrates that 
unreported transfers have occurred where the IP addresses worked fine after 
they were transferred to another party.
If ARIN has no control over routing, and no legal ability to stop ip address 
sales, their leverage is little. If the benefits of the transfers outweigh 
the little costs which ARIN can apply, the transfers will happen.

Regards,
Mike

:

> Hi Owen,
>
> I don't think ARIN will be confronted with anything, I think they will be 
> ignored.

When I say confronted, I mean becomes aware of. There are numerous ways in 
which it is very likely ARIN will become aware of such things.

> And I don't think ARIN has any rights to revoke or reclaim legacy space 
> unless they have an agreement with the rights holder which gives them that 
> right.

You are incorrect, sir. ARIN is the successor registry to the earlier 
registries for this region. Those registries ALL issued the address space on 
the
basis that it was issued to a particular organization for a particular 
purpose and should be returned when one or both of those criteria was no 
longer
valid.


> Clearly they have no additional rights under section 12 to reclaim legacy 
> space, that's explicit in the NRPM.

The words in NRPM 12 were chosen very carefully. The word additional is just 
that. We added no ability to reclaim legacy space, but, the existing
abilities remain.

> So you would have to demonstrate some other source of that reclamation 
> right.

Q.E.D. See above.

> It's not in any agreement between ARIN and the legacy holder, and it's not 
> part of any agreement the legacy allocants had with ARIN's precursors.
> Where does it come from?
>

It is actually part of policies documented in earlier RFCs and in the 
writings of Jon Postel as described above.

Owen

> Regards,
> Mike
>
>
>
>
> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
> To: "Mike Burns" <mike at nationwideinc.com>
> Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
> Sent: Thursday, June 23, 2011 3:39 PM
> Subject: Re: [arin-ppml] Draft Policy 2011-1 - 
> Inter-RIRTransfers -Shepherd's Inquiry
>
>
>>
>> My argument is that we cannot abandon the whole IP market thing. It is 
>> out of our control, because the limited power we have is in Whois and 
>> reverse naming.
>> We can't force network operators to route or not to route certain 
>> addresses, and I see no stomach at ARIN for challenging legacy transfers 
>> by revoking and reissuing their space.
>>
> Like speculation, just because you don't see it does not mean that it is 
> not there.
>
> I believe that confronted with a legacy transfer that happened off the 
> books ARIN will go through the following steps (John, feel free to correct 
> me if I'm wrong):
>
> 1. Attempt to contact the original holder of the resources
> If they acknowledge the transfer, see if the recipient and original holder 
> will work to
> complete the transaction under NRPM 8.
>
> If they do not acknowledge the transfer, let them know their space has 
> been hijacked
> and encourage them to take appropriate action.
>
> If they are unreachable, work with the recipient to see if sufficient 
> documentation
> exists to complete an 8.2 or 8.3 transfer and attempt to do so.
>
> 2. If the original resource holder is unreachable and a transfer cannot be 
> completed
> as described above, I believe ARIN will reclaim the space as abandoned and 
> take
> the appropriate steps to clean and reissue it.
>
> 3. If the original resource holder is unreachable or uncooperative and the 
> "recipient" refuses to cooperate,
> I believe ARIN is also likely to proceed with reclamation under NRPM 12.
>
>
>> So to think we have any significant power to prevent the rise of an IPv4 
>> market is naive. What we should do is acknowledge it and take the steps 
>> to transition ARIN from an arbiter of who gets addresses to a 
>> title-agency whose routing authority is respected enough to handle the 
>> challenges facing registration in the post-exhaust world.
>>
>
> Can we prevent the rise of a market? Probably not. Can we apply a 
> needs-basis test to that market and regulate the redistribution of 
> addresses through that market by applying reasonable stewardship policies 
> governing the source and recipient conduct in the market? Yes.
>
> There is a lot of room between the extremes of "ignore the market 
> altogether" and "acknowledge the market and let it become a free-for-all 
> with no rules".
>
> I realize that you favor the latter extreme. I favor something towards the 
> former, but much closer to the middle.
>
> Owen



From mike at nationwideinc.com  Thu Jun 23 16:52:17 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 23 Jun 2011 16:52:17 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -	Inter-RIRTransfers-Shepherd's
	Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<web-17578861@be2.mail.trib.com>
Message-ID: <D72CD7B25359406ABE57523E060FDBF6@mike>


Hi Larry,

What you can take into court is the fact that there was an original 
allocation made without formal agreements, that IP addresses have appeared 
on innumerable asset sales documents as transferred assets (impying 
ownership), that ARIN has failed to exercise its claimed reclamation rights, 
leaving the current holders in adverse possession, and that no other 
claimant has greater rights.

What ARIN can do is change Whois. ARIN has the rights to do this, I am not 
claiming otherwise. I am saying ARIN has no legal right to stop a legacy 
sale, and taking action via Whois runs the risk of increasing Whois 
irrelevance.  So far it seems like this is not a course that ARIN has 
chosen, wisely, I think.

On the other hand, ARIN seeks to bring legacy holders under agreement which 
will give ARIN some of these rights, particularly of note is the insistence 
on legacy holders signing away any ownership rights, which is curious 
considering they claim that legacy holders don't have those anyway.

And of course we have the declaration of Mr. Plzak in which he explicitly 
claims ARIN has no control over legacy addresses, and the fact that the 
bankruptcy judge in the Nortel case found that Nortel had the exclusive 
right to transfer addresses assigned to prior acquisitions, even after 
Nortel was bankrupt.

You are right that ARIN can make the claim that they have tried to contact 
legacy holders and they will begin re-allocating addresses for those who are 
not reachable. ARIN has the right to erase ALL legacy holders who have not 
signed an LRSA agreement from the records of Whois, and do it this afternoon 
without notifying anyone.

Regards,
Mike

----- Original Message ----- 
From: "Larry Ash" <lar at mwtcorp.net>
To: "Mike Burns" <mike at nationwideinc.com>; "Owen DeLong" <owen at delong.com>
Cc: "arin ppml" <ppml at arin.net>
Sent: Thursday, June 23, 2011 4:31 PM
Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers-Shepherd's 
Inquiry


> "Mike Burns" <mike at nationwideinc.com> wrote:
>> Hi Owen,
>>
>> I don't think ARIN will be confronted with anything, I think they will be 
>> ignored.
>> And I don't think ARIN has any rights to revoke or reclaim legacy space 
>> unless they have an agreement with the rights holder which gives them 
>> that right.
>
> You can argue the reverse just as forcefully. What "right" does a legacy 
> holder
> have that a simple squatter doesn't. i.e It works now, it worked yesterday 
> and
> your threatening to make it not work tomorrow. That has weight but not a 
> lot.
>
> Any agreement that may have been in place is with a now defunct 
> organization.
> The fact that ARIN agreed to allow the legacy holders to continue when 
> they
> were formed is  the strongest argument that a legacy holder has but I'd 
> wouldn't
> want to try and take that to a court. I have never gotten IP from any 
> entity that
> said they were mine. There was always (at least by 1993) language that 
> indicated
> that they could be reclaimed under some condition.
>
>> Clearly they have no additional rights under section 12 to reclaim legacy 
>> space, that's explicit in the NRPM.
>> So you would have to demonstrate some other source of that reclamation 
>> right.
>> It's not in any agreement between ARIN and the legacy holder, and it's 
>> not part of any agreement the legacy allocants had with ARIN's 
>> precursors.
>> Where does it come from?
>
> Existing ARIN policy does not create "rights" for people that have
> no formal relationship with ARIN. ARIN policy, up to now, is to
> leave well enough alone, that's not exactly a contract.
>
> ARIN could argue that every legacy holder has had ample time to formalize
> a relationship and declare the legacy IP not under NRPM abandoned. I know 
> that
> would be a mistake as it would create an unnecessary war. But the belief 
> that
> not formalizing a relationship with ARIN, because someone believes that 
> they
> have superior "rights" without one is a mistake also.
>
> aside: The IPV6 boys made a mistake by not clearly indicating that IPV6 is
> a replacement for IPV4 with the IPV4 drop date to be announced. If we are 
> ever
> to get out of this swamp that is going to have to be done and a drop dead
> date picked.
>
>
>
>>
>> Regards,
>> Mike
>>
>>
>>
>>
>> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
>> To: "Mike Burns" <mike at nationwideinc.com>
>> Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
>> Sent: Thursday, June 23, 2011 3:39 PM
>> Subject: Re: [arin-ppml] Draft Policy 2011-1 - 
>> Inter-RIRTransfers -Shepherd's Inquiry
>>
>>
>>>
>>> My argument is that we cannot abandon the whole IP market thing. It is 
>>> out of our control, because the limited power we have is in Whois and 
>>> reverse naming.
>>> We can't force network operators to route or not to route certain 
>>> addresses, and I see no stomach at ARIN for challenging legacy transfers 
>>> by revoking and reissuing their space.
>>>
>> Like speculation, just because you don't see it does not mean that it is 
>> not there.
>>
>> I believe that confronted with a legacy transfer that happened off the 
>> books ARIN will go through the following steps (John, feel free to 
>> correct me if I'm wrong):
>>
>> 1. Attempt to contact the original holder of the resources
>> If they acknowledge the transfer, see if the recipient and original 
>> holder will work to
>> complete the transaction under NRPM 8.
>>
>> If they do not acknowledge the transfer, let them know their space has 
>> been hijacked
>> and encourage them to take appropriate action.
>>
>> If they are unreachable, work with the recipient to see if sufficient 
>> documentation
>> exists to complete an 8.2 or 8.3 transfer and attempt to do so.
>>
>> 2. If the original resource holder is unreachable and a transfer cannot 
>> be completed
>> as described above, I believe ARIN will reclaim the space as abandoned 
>> and take
>> the appropriate steps to clean and reissue it.
>>
>> 3. If the original resource holder is unreachable or uncooperative and 
>> the "recipient" refuses to cooperate,
>> I believe ARIN is also likely to proceed with reclamation under NRPM 12.
>>
>>
>>> So to think we have any significant power to prevent the rise of an IPv4 
>>> market is naive. What we should do is acknowledge it and take the steps 
>>> to transition ARIN from an arbiter of who gets addresses to a 
>>> title-agency whose routing authority is respected enough to handle the 
>>> challenges facing registration in the post-exhaust world.
>>>
>>
>> Can we prevent the rise of a market? Probably not. Can we apply a 
>> needs-basis test to that market and regulate the redistribution of 
>> addresses through that market by applying reasonable stewardship policies 
>> governing the source and recipient conduct in the market? Yes.
>>
>> There is a lot of room between the extremes of "ignore the market 
>> altogether" and "acknowledge the market and let it become a free-for-all 
>> with no rules".
>>
>> I realize that you favor the latter extreme. I favor something towards 
>> the former, but much closer to the middle.
>>
>> 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.
>
> Larry Ash
> Network Administrator
> Mountain West Telephone
> 123 W 1st St.
> Casper, WY 82601
> Office 307 233-8387 



From owen at delong.com  Thu Jun 23 17:23:59 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Jun 2011 14:23:59 -0700
Subject: [arin-ppml] Draft Policy 2011-1 -
	Inter-RIRTransfers	-Shepherd's Inquiry
In-Reply-To: <A7D828E8C9154245BE467CC985F83294@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com><EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><BANLkTimBHp9M8VvhfTtB
	YoXi-vmn025jmw@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid><A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95@delong.com><0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
	<85C9F4B5D6844F6FBEB90DA9F656C172@mike>
	<4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>
	<A7D828E8C9154245BE467CC985F83294@mike>
Message-ID: <3220E875-6E40-4E87-8EC7-9D2D67E7F179@delong.com>


On Jun 23, 2011, at 1:45 PM, Mike Burns wrote:

> Hi Owen,
> 
> You've been saying this stuff for years, but where is a section 12 reclamation of legacy space you can point to where the reclamation took place due to the original registrant selling his addresses?
> 
I don't know whether such a reclamation has occurred yet or not. Frankly, even if it has not, that does not mean that it will not.

> Where is any reclamation of legacy space which is not associated with actual hijacking, voluntary return, or dissolution? Spamming or child porn? Any examples?
> 

Just as you have no examples of transfers that have occurred outside of policy, I have no examples of this. I am not privy to the information and those that are would be unable to disclose it.

> The bankruptcy judge, need I remind you, found that Nortel had the exclusive right to transfer addresses which were allocated to other companies, and for which no ARIN transfer had ever taken place, and this was after all the companies involved were bankrupt. I find this much more convincing than allusions to RFCs and the writings of Jon Postel. Now if Mr. Postel had actually created an agreement which could be legally construed as a contract, you might have something. Absent that, you have only bluster which grows more outdated each month.
> 

That's your right. It does not change my opinion.

> As a test example, I was back at my alma mater last June and I spoke with one of the campus computer engineers, who told me although he had 16 million ip addresses to work with, most of the campus is Natted. Do you think I should open up a ticket and inform ARIN that they should institute a section 12 review of MIT? Would you like to confront ARIN with that knowledge and see if it nets the free pool a sizeable chunk of a /8?
> 

No. MIT is still using the addresses for the purpose for which they were issued and the efficient utilization of those addresses is not part of the requirements that existed at the time of issue. However, if MIT were to abandon the /8 altogether and/or to transfer it to a third party outside of NRPM 8, that third party would have no rights to the space in ARIN's eyes and unless MIT chose to continue to assert their utilization, ARIN would, indeed, be able to if not obliged to reclaim it.

> ARIN controls Whois, I'm pretty sure that is what John Curran will say. ARIN is within its legal rights to change Whois data in whatever way it pleases.
> If ARIN wants to make Whois even more irrelevant, they can take the course you prescribe, but since they have not done this, ever, the threat of reclamation of legacy space is a nonstarter.
> 

I am not convinced that they have not done this ever and even less convinced that they would not do so ever. I believe that ARIN has reclaimed abandoned resources in the past which non-entitled entities have claimed they received through transfer or have claimed they are the successor organization. I believe that ARIN has also completed 8.2 transfers and possibly 8.3 transfers when they have found successor organizations that have some legitimacy under those policies making such transfers retroactive (as I believe happened with Nortel, actually).

> John Curran referencing ex post facto transfer requests demonstrates that unreported transfers have occurred where the IP addresses worked fine after they were transferred to another party.
> If ARIN has no control over routing, and no legal ability to stop ip address sales, their leverage is little. If the benefits of the transfers outweigh the little costs which ARIN can apply, the transfers will happen.
> 

And nothing I have said precludes this practice continuing. Yes, there are transfers that occur without ARIN being notified and nothing in policy will change that fact. In most of the cases that result in ex post facto transfer requests, it is the result of the organizations in question being unaware of ARIN or its role and choosing to cooperate in that role upon becoming aware of it.

Owen

> Regards,
> Mike
> 
> :
> 
>> Hi Owen,
>> 
>> I don't think ARIN will be confronted with anything, I think they will be ignored.
> 
> When I say confronted, I mean becomes aware of. There are numerous ways in which it is very likely ARIN will become aware of such things.
> 
>> And I don't think ARIN has any rights to revoke or reclaim legacy space unless they have an agreement with the rights holder which gives them that right.
> 
> You are incorrect, sir. ARIN is the successor registry to the earlier registries for this region. Those registries ALL issued the address space on the
> basis that it was issued to a particular organization for a particular purpose and should be returned when one or both of those criteria was no longer
> valid.
> 
> 
>> Clearly they have no additional rights under section 12 to reclaim legacy space, that's explicit in the NRPM.
> 
> The words in NRPM 12 were chosen very carefully. The word additional is just that. We added no ability to reclaim legacy space, but, the existing
> abilities remain.
> 
>> So you would have to demonstrate some other source of that reclamation right.
> 
> Q.E.D. See above.
> 
>> It's not in any agreement between ARIN and the legacy holder, and it's not part of any agreement the legacy allocants had with ARIN's precursors.
>> Where does it come from?
>> 
> 
> It is actually part of policies documented in earlier RFCs and in the writings of Jon Postel as described above.
> 
> Owen
> 
>> Regards,
>> Mike
>> 
>> 
>> 
>> 
>> ----- Original Message ----- From: "Owen DeLong" <owen at delong.com>
>> To: "Mike Burns" <mike at nationwideinc.com>
>> Cc: "Kevin Kargel" <kkargel at polartel.com>; "arin ppml" <ppml at arin.net>
>> Sent: Thursday, June 23, 2011 3:39 PM
>> Subject: Re: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers -Shepherd's Inquiry
>> 
>> 
>>> 
>>> My argument is that we cannot abandon the whole IP market thing. It is out of our control, because the limited power we have is in Whois and reverse naming.
>>> We can't force network operators to route or not to route certain addresses, and I see no stomach at ARIN for challenging legacy transfers by revoking and reissuing their space.
>>> 
>> Like speculation, just because you don't see it does not mean that it is not there.
>> 
>> I believe that confronted with a legacy transfer that happened off the books ARIN will go through the following steps (John, feel free to correct me if I'm wrong):
>> 
>> 1. Attempt to contact the original holder of the resources
>> If they acknowledge the transfer, see if the recipient and original holder will work to
>> complete the transaction under NRPM 8.
>> 
>> If they do not acknowledge the transfer, let them know their space has been hijacked
>> and encourage them to take appropriate action.
>> 
>> If they are unreachable, work with the recipient to see if sufficient documentation
>> exists to complete an 8.2 or 8.3 transfer and attempt to do so.
>> 
>> 2. If the original resource holder is unreachable and a transfer cannot be completed
>> as described above, I believe ARIN will reclaim the space as abandoned and take
>> the appropriate steps to clean and reissue it.
>> 
>> 3. If the original resource holder is unreachable or uncooperative and the "recipient" refuses to cooperate,
>> I believe ARIN is also likely to proceed with reclamation under NRPM 12.
>> 
>> 
>>> So to think we have any significant power to prevent the rise of an IPv4 market is naive. What we should do is acknowledge it and take the steps to transition ARIN from an arbiter of who gets addresses to a title-agency whose routing authority is respected enough to handle the challenges facing registration in the post-exhaust world.
>>> 
>> 
>> Can we prevent the rise of a market? Probably not. Can we apply a needs-basis test to that market and regulate the redistribution of addresses through that market by applying reasonable stewardship policies governing the source and recipient conduct in the market? Yes.
>> 
>> There is a lot of room between the extremes of "ignore the market altogether" and "acknowledge the market and let it become a free-for-all with no rules".
>> 
>> I realize that you favor the latter extreme. I favor something towards the former, but much closer to the middle.
>> 
>> Owen



From bill at herrin.us  Thu Jun 23 19:13:04 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 23 Jun 2011 19:13:04 -0400
Subject: [arin-ppml] Draft Policy 2011-1 - Inter-RIRTransfers
	-Shepherd's Inquiry
In-Reply-To: <4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid>
	<0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
	<85C9F4B5D6844F6FBEB90DA9F656C172@mike>
	<4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>
Message-ID: <BANLkTi=4UUigOeh8r6NJGChFjO+Zeub68Q@mail.gmail.com>

> On Jun 23, 2011, at 12:48 PM, Mike Burns wrote:
>> And I don't think ARIN has any rights to revoke or
>>reclaim legacy space unless they have an agreement
>>with the rights holder which gives them that right.

If they ever did, they surely gave it up under the doctrine of laches.


On Thu, Jun 23, 2011 at 3:57 PM, Owen DeLong <owen at delong.com> wrote:
> You are incorrect, sir. ARIN is the successor registry
> to the earlier registries for this region. Those registries
> ALL issued the address space on the basis that it
> was issued to a particular organization for a
> particular purpose and should be returned when
> one or both of those criteria was no longer valid.

Owen,

None of these claims is accurate.

No purpose was requested or required for a legacy address allocation. The
closest thing was, "If a
class C network number is not acceptable for your purposes state why." The
field could be left blank if a class C was requested.

You were asked to "Identify [...] the responsible organization establishing
the network" however that was not understood to be a legal entity as ARIN
defines it today and it was not generally checked. The registrant
organization name was, in actual fact, whatever the POC claimed it to be.

Although there were instructions for how to submit a DELETE template, the
registrant was not asked to do so for any particular criteria.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110623/70cc57e1/attachment.htm>

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

Total of 84 messages in the last 7 days.
 
script run at: Fri Jun 24 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.67% |   14 | 18.43% |   118601 | owen at delong.com
 15.48% |   13 | 14.16% |    91148 | hannigan at gmail.com
 14.29% |   12 | 15.33% |    98688 | mike at nationwideinc.com
 13.10% |   11 | 12.02% |    77343 | bill at herrin.us
  8.33% |    7 | 10.54% |    67831 | billd at cait.wustl.edu
  9.52% |    8 |  9.07% |    58357 | kkargel at polartel.com
  4.76% |    4 |  5.08% |    32674 | scottleibrand at gmail.com
  3.57% |    3 |  2.79% |    17957 | cgrundemann at gmail.com
  2.38% |    2 |  2.08% |    13379 | joe at oregon.uoregon.edu
  1.19% |    1 |  1.51% |     9714 | lar at mwtcorp.net
  1.19% |    1 |  1.42% |     9170 | info at arin.net
  1.19% |    1 |  1.33% |     8593 | jeffrey.lyon at blacklotus.net
  1.19% |    1 |  1.14% |     7357 | mysidia at gmail.com
  1.19% |    1 |  0.96% |     6169 | farmer at umn.edu
  1.19% |    1 |  0.92% |     5900 | frnkblk at iname.com
  1.19% |    1 |  0.87% |     5608 | gary.buhrmaster at gmail.com
  1.19% |    1 |  0.83% |     5355 | ikiris at gmail.com
  1.19% |    1 |  0.82% |     5268 | narten at us.ibm.com
  1.19% |    1 |  0.71% |     4564 | matthew at matthew.at
--------+------+--------+----------+------------------------
100.00% |   84 |100.00% |   643676 | Total


From jcurran at arin.net  Sat Jun 25 19:37:26 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 25 Jun 2011 23:37:26 +0000
Subject: [arin-ppml] Draft Policy 2011-1 -	Inter-RIR Transfers	 -
 Shepherd's Inquiry
In-Reply-To: <A7D828E8C9154245BE467CC985F83294@mike>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu>
	<BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com> <"EACF8
	B735E9CBA4B8BAF9E4165D03087CDA179"@ex1.cait.wustl.edu>
	<BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com>
	<"BANLkTimBHp9M8VvhfTtB YoXi-vmn025jmw"@mail.gmail.com>
	<BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com>
	<3616067634770048478@unknownmsgid> <"A6762C78-F
	913-4E78-A9BD-8D5F93BE4E95"@delong.com>
	<0331D5C3EA74461286B111A482D85E4A@mike>
	<8695009A81378E48879980039EEDAD28010C52D567@MAIL1.polartel.local>
	<6547DD7D4CD84631AD433C7127F2BDD2@mike>
	<D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com>
	<85C9F4B5D6844F6FBEB90DA9F656C172@mike>
	<4F542EEB-4A52-4230-A221-7D624E14F890@delong.com>
	<A7D828E8C9154245BE467CC985F83294@mike>
Message-ID: <A3710302-9D56-4849-9961-2E7C45B945A4@arin.net>

On Jun 24, 2011, at 4:45 AM, Mike Burns wrote:
> ...
> Where is any reclamation of legacy space which is not associated with actual hijacking, voluntary return, or dissolution? Spamming or child porn? Any examples?

Given that there is now the recognized ability to transfer one rights as a 
registrant of an address block to another party in accordance with policy, 
it is perfectly understandable that ARIN would prioritize pursuing number
reclamation in the cases you list above (hijacking, dissolution, etc.)

> The bankruptcy judge, need I remind you, found that Nortel had the exclusive right to transfer addresses which were allocated to other companies, and for which no ARIN transfer had ever taken place, and this was after all the companies involved were bankrupt.

The judge did indeed find that Nortel had that right, but approved a sale 
order which stated:

 "For the avoidance of doubt, this Order shall not affect the LRSA AND THE 
  PURCHASER?S RIGHTS IN THE INTERNET NUMBERS TRANSFERRED PURSUANT TO THIS 
  ORDER SHALL BE SUBJECT TO THE TERMS OF THE LRSA." (emphasis added)

Please keep this in mind when trying to consider this particular specified
transfer any form of precedent.

> As a test example, I was back at my alma mater last June and I spoke with one of the campus computer engineers, who told me although he had 16 million ip addresses to work with, most of the campus is Natted. Do you think I should open up a ticket and inform ARIN that they should institute a section 12 review of MIT? Would you like to confront ARIN with that knowledge and see if it nets the free pool a sizeable chunk of a /8?

It would be best if you encouraged them to return the unused resources 
or make them available via specified transfer.

> John Curran referencing ex post facto transfer requests demonstrates that unreported transfers have occurred where the IP addresses worked fine after they were transferred to another party.

Transfers occur when the request is approved and the Whois database is 
updated.  You're free to try and purchase anything that you like including
the number 3, the letter Q, the color blue, or a new york bridge, but if 
you'd like to transfer your rights as a registrant of an address block, 
then you should keep in mind the that transfer occurs when the registration
changes.  I'd definitely get a receipt from anyone who suggests otherwise...

> If ARIN has no control over routing, and no legal ability to stop ip address sales, their leverage is little. If the benefits of the transfers outweigh the little costs which ARIN can apply, the transfers will happen.

ARIN maintains the database accordingly to the community developed policies;
the community seems to value this and makes use of the database accordingly.

/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Sat Jun 25 20:45:41 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 26 Jun 2011 00:45:41 +0000
Subject: [arin-ppml] Completion of legal and parliamentarian review of the
 Standing Rule of AC Role in Petitions
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD4656937791409227A8B@PRVPEXVS03.corp.twcable.com>
References: <DCC302FAA9FE5F4BBA4DCAD4656937791409227A8B@PRVPEXVS03.corp.twcable.com>
Message-ID: <E8CCE439-42BD-4A04-A01D-712FEE9B67E1@arin.net>

On Apr 18, 2011, at 4:38 AM, Sweeting, John wrote:
> Sorry, I meant for the email below to go to PPML. Thanks.
> ________________________________________
> From: Sweeting, John
> Sent: Sunday, April 17, 2011 4:18 PM
> To: ARIN Advisory Council
> Subject: RE: [arin-ppml] [arin-council] AC Role in Petitions
> 
> Hello All,
> 
> A complete legal and parlimentarian review of this Standing Rule has been requested. Most definitions state that standing rules are regulations for the guidance of an organization usually adopted by majority vote without previous notice but we would rather be safe than sorry. We would like to thank everyone for their input and look forward to clearing this issue up.
> 
> Enjoy the rest of the weekend,
> 
> -john
> 
> ++

ARIN-PPML Community - 
 
   Please find the following results of the legal and parliamentarian 
   review of this Standing Rule as requested by the AC Chair.

FYI,
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

> From: John Curran <jcurran at arin.net>
> Date: June 24, 2011 10:49:24 AM GMT+08:00
> To: "Sweeting, John" <john.sweeting at twcable.com>
> Cc: ARIN Advisory Council
> Subject: Completion of legal and parliamentarian review of the Standing Rule of AC Role in Petitions
> 
> On Apr 18, 2011, at 4:18 AM, Sweeting, John wrote:
> 
>> Hello All,
>> 
>> A complete legal and parlimentarian review of this Standing Rule has been requested. Most definitions state that standing rules are regulations for the guidance of an organization usually adopted by majority vote without previous notice but we would rather be safe than sorry. We would like to thank everyone for their input and look forward to clearing this issue up.
> 
> ARIN Advisory Council
> Chairman Sweeting - 
> 
>  As requested, a legal and parliamentary review of the AC Standing 
>  Rule regarding AC members not participating in PDP Petitions has 
>  been completed.  No legal issue was identified with respect to 
>  establishment of this Standing Rule. 
> 
>  From a parliamentary perspective, adoption of the Standing Rule
>  creates an ambiguity with respect to the existing language in the 
>  Petition Process of ARIN Board adopted Policy Development Process 
>  (PDP).  Upon careful review, it was determined that the ARIN Advisory 
>  Council should not be establishing their own standing rules, as it
>  is unclear what precedence any such rule has with respect to Board 
>  adopted materials.  Roberts Rules of Order minimizes the potential 
>  for creation of such ambiguities by precluding subordinate bodies 
>  from establishing their own rules unless specifically directed to
>  do so:
> 
>  "Committee's may not adopt their own rules except as authorized in 
>   the bylaws or in instructions given to the committee by the society."
>   (Roberts Rules Newly Revised, 10th Edition, p. 483, l. 23 - 29)
> 
>  By having any Standing Rules adopted by the Board, the potential for
>  any conflict with established rules is greatly reduced.   At its 10 
>  June 2010 meeting, the ARIN Board of Trustees adopted the attached 
>  "AC Standing Rules and Special Rules of Order" document which contains 
>  the existing set of AC rules except the new rule prohibiting AC 
>  participation of petitions.  The AC is free to recommend any changes 
>  to these rules to the Board, and such suggestions will be considered 
>  in a timely manner.   Advisory Council member participation in petitions 
>  remains available and should only change if a revised Policy Development 
>  Process is adopted which contains such provisions.
> 
>  Thank you for raising this matter and do not hesitate to contact me 
>  if you have any questions.
> 
> Sincerely,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AC Standing Rules and Special Rules of Order.pdf
Type: application/pdf
Size: 58528 bytes
Desc: AC Standing Rules and Special Rules of Order.pdf
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110626/98384735/attachment.pdf>
-------------- next part --------------
> 
> 


From jcurran at arin.net  Sat Jun 25 23:11:57 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 26 Jun 2011 03:11:57 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
Message-ID: <503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>

On February 15th, the following update to staff assessment for Draft Policy 
2011-5 was made:

> 

> In keeping with the spirit of RFC 2860 with respect to the assignment
> of specialized address blocks, ARIN Staff will consult with the IANA and
> the IAB regarding implementation of this draft policy.

Please find attached correspondence regarding consultation with the IAB on 
Draft Policy 2011-5 "Shared Transition Space for IPv4 Address Extension". 
The ARIN Board will consider this response and the recommendation to adopt 
2011-5 at an upcoming meeting.  It is quite possible that this will result 
in the policy proposal being referred to the IETF for reconsideration, and 
any parties interested in this Draft Policy should note this possibility 
for purposes of planning their ongoing efforts in this area.

FYI,
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

> From: Bernard Aboba <bernard_aboba at hotmail.com>
> Date: June 23, 2011 4:37:36 AM GMT+08:00
> To: <jcurran at arin.net>
> Cc: <ndavis at arin.net>, Russ Housley <housley at vigilsec.com>
> Subject: IAB comment on ARIN 2011-05
> 
> Dear John,
> 
> The IAB has reviewed your request for IAB/IESG guidance regarding Draft
> Policy ARIN-2011-5. We would like to submit the following for the ARIN
> board's consideration.
> 
> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
> 
> The IAB honors and values the division of responsibilities as
> documented in RFC 2860 section 4.3. That section forms the basis for
> Unicast address allocation via ICANN through the RIR system.
> 
> The second paragraph of that section excludes 'assignments of
> specialised address blocks (such as multicast or anycast blocks)' from
> that IANA-> RIR model, leaving such blocks as the responsibility, and
> under the authority, of the IETF.
> 
> Policy proposal 2011-005 is not a regular proposal in the sense that
> it adheres to Unicast space. In contrast, it allows for an allocation
> of addresses for special and global use very similar to, and almost
> indistinguishable from, RFC1918 local addresses. Because of the impact
> beyond the ARIN region the management (i.e. creation
> and subsequent changes) of such reservation should be global and RFC2860
> puts the management responsibility with the IETF.
> 
> The IAB believes that the adoption by ARIN would be in conflict with the
> provisions in RFC2860 and would set a bad precedent: Setting aside
> special addresses should be done within the existing process, i.e. by
> the IETF.
> 
> It is our expectation that the IAB and the ARIN Board are in general
> agreement about this interpretation.
> 
> == Re-reviewing the Operational and Technical merits in the IETF ==
> 
> The IAB is aware that earlier variations of the proposal have been brought
> to the IETF. However, there was very little support and some strong
> opposition to them, consequently, the IETF never reached consensus to
> approve them.
> 
> If there is consensus for 2011-005 in the ARIN region we would be
> happy to work with you to resubmit the proposal to the IETF and, as
> usual, have the IESG judge consensus. This would include our reaching
> out to other RIRs to have members of their community provide input on
> this proposal. Clear support from the various RIR communities might
> bring new insights into to the IETF, producing a level of support that
> was not present with the earlier drafts.
> 
> Obviously the IAB cannot commit to the outcome of that process, but we
> can work with you to make sure the proposal gets maximum exposure
> within the IETF and the broader community.
> 
> [for the IAB],
> Bernard Aboba
> IAB Chair
> 
> From: jcurran at arin.net
> To: bernard_aboba at hotmail.com; housley at vigilsec.com
> CC: ndavis at arin.net
> Subject: Request for IAB/IESG guidance regarding Draft Policy ARIN-2011-5 (Shared Transition Space for IPv4 Address Extension) 
> Date: Tue, 14 Jun 2011 06:32:10 +0000
> 
> To:  IAB Chair Bernard Aboba & IETF/IESG Chair Russ Housley
> 
> As noted in the communication of 10 April 2011 ..., the ARIN community
> has been working on a Draft Policy (ARIN-2011-5, Shared Transition Space for 
> IPv4 Address Extension) which would result in the allocation of a /10 IPv4 address 
> block for facilitating transition technologies.  I am writing to provide an update on
> the status of this Draft Policy and to seek guidance from the IAB & IESG regarding
> appropriate next steps.
> 
> After significant deliberation both online and during the ARIN Public Policy meeting,
> the ARIN Advisory Council (which consists of 15 members elected by the ARIN
> community) met in late May and recommended adoption of the Draft Policy by the 
> ARIN Board.  I  have made to the ARIN AC as well as the community at large that 
> since the  proposed reservation is for shared use, it arguably could be considered 
> as a specialized address block in accordance section 4.3 of RFC 2860, and would 
> need to made under the guidance of IAB and IESG.
> 
> On June 10th 2011, the ARIN Board of Trustees took the recommendation to adopt 
> the Draft Policy under advisement, and directed me to consult with the IAB and IESG
> regarding any issues in adopting this Draft Policy.
> 
> I am hereby requesting that the IAB and IESG consider this matter, and provide any
> guidance regarding recommendations for moving forward as deemed appropriate.
> I am available to discuss the matter by phone at the IAB and IESG's convenience;
> please let me know via email if this is desirable at any time.
> 
> Best wishes and thank you for your consideration,
> /John
> 
> John Curran
> President and CEO
> ARIN
> ...


From mike at nationwideinc.com  Sat Jun 25 23:39:02 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Sat, 25 Jun 2011 23:39:02 -0400
Subject: [arin-ppml] Draft Policy 2011-1 -	Inter-RIR Transfers	
	-Shepherd's Inquiry
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<"EACF8B735E9CBA4B8BAF9E4165D03087CDA179"@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><"BANLkTimBHp9
	M8VvhfTtB
	YoXi-vmn025jmw"@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid>
	<"A6762C78-F913-4E78-A9BD-8D5F93BE4E95"@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C
	52D567@MAIL1.polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike><D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com><85C9F4B5D6
	844F6FBEB90DA9F656C172@mike><4F542EEB-4A52-4230-A221-7D624E14F890@delong.com><A7D828E8C9154245BE467CC985F83294@mike>
	<A3710302-9D56-4849-9961-2E7C45B945A4@arin.net>
Message-ID: <2957F65DFC0B4FB5ABC6D50D885ED664@video>

Hi John,

>> Where is any reclamation of legacy space which is not associated with 
>> actual hijacking, voluntary return, or dissolution?
>>Spamming or child porn? Any examples?

>Given that there is now the recognized ability to transfer one rights as a
>registrant of an address block to another party in accordance with policy,
>it is perfectly understandable that ARIN would prioritize pursuing number
>reclamation in the cases you list above (hijacking, dissolution, etc.)

With respect, I take this answer to mean that there has been no reclamation 
of legacy space which was not voluntarily returned, the subject of hijacking 
or fraud, or of corporate dissolution. If I am wong, let me know.


>> The bankruptcy judge, need I remind you, found that Nortel had the 
>> exclusive right to transfer addresses which were
>>allocated to other companies, and for which no ARIN transfer had ever 
>>taken place, and this was after all the companies
>>involved were bankrupt.

>The judge did indeed find that Nortel had that right, but approved a sale
>order which stated:

 "For the avoidance of doubt, this Order shall not affect the LRSA AND THE
  PURCHASER?S RIGHTS IN THE INTERNET NUMBERS TRANSFERRED PURSUANT TO THIS
  ORDER SHALL BE SUBJECT TO THE TERMS OF THE LRSA." (emphasis added)

>Please keep this in mind when trying to consider this particular specified
>transfer any form of precedent.

John, I have the whole asset sale agreement not only in my mind, but on my 
screen, and I have read the original asset sale agreement and compared it 
closely to the one the judge approved after ARIN negotiated with Microsoft. 
And I find absent from the approved motion any language which says that the 
seller's exclusive rights to transfer are subject to ARIN policy. Instead I 
read that the *purchaser* has agreed to enter the modified LRSA with ARIN 
and merely represents to the court that they have done so, and are willing 
to abide by this modified LRSA, which is of course invisible to our 
community eyes.  My reading of the event is that ARIN negotiated with 
Microsoft and convinced them that signing a modified LRSA and undergoing a 
needs test wouldn't cost much, if anything, to Microsoft, but that working 
with ARIN just enough to make it plausible for ARIN to claim that policy was 
followed would inure to Microsoft's benefit, publicity-wise. And so 
Microsoft *consented* to the change in the final document, rather than due 
to any decision by the judge. There was nothing to indicate that ARIN had 
any control over Nortel's right to sell addresses, nothing saying that as a 
condition of sale that Nortel had to sign an LRSA with ARIN, which was an 
ARIN requirement prior to this sale. Nothing to say Nortel had to process 
8.2 transfers from the prior acquistions who were the original allocants of 
the legacy space before Nortel had the right to sell them. So the lessons I 
draw from the document come not from the deal Microsoft struck with ARIN but 
from the lack of a deal ARIN struck with Nortel. If ARIN could have made any 
legal claim that they controlled Nortel's transfer rights, I believe ARIN 
would have made that claim to the judge in the form of an objection to the 
motion.
Instead it punted and struck a deal with the Microsoft to consent to signing 
a secret agreement, and to have Miicrosoft represent to the judge that they 
had agreed to be bound by that document, the ":modified LRSA."

Because ARIN did not attempt any revokation action against a bankrupt entity 
very publicly selling IP addresses allocated to other, also defunct 
entities, I believe Owen is wrong in his belief that ARIN has the right to 
revoke legacy space for bankruptcy or dissolution. Here we have a public 
example of prior unbooked transfers, public declaration of bankruptcy 
liquidation, and ARIN engaged in the deal prior to judicial approval. But 
where was any attempt at review or revokation? I know that NRPM section 12 
states that it give no "additional" rights to reclaim legacy space, but Owen 
claims the rights are there anyway. If he is right, why did ARIN not review 
and reclaim the 660,000 IP addresses that Nortel sold? Why not take the 
opportunity afforded by the public nature of this deal to clearly establish 
ARIN's (heretofore unutilized?) right to revoke legacy space when the 
allocant goes out of business?


>> John Curran referencing ex post facto transfer requests demonstrates that 
>> unreported transfers have occurred where the IP addresses worked fine 
>> after they were transferred to another party.

>Transfers occur when the request is approved and the Whois database is
>updated.  You're free to try and purchase anything that you like including
>the number 3, the letter Q, the color blue, or a new york bridge, but if
>you'd like to transfer your rights as a registrant of an address block,
>then you should keep in mind the that transfer occurs when the registration
>changes.  I'd definitely get a receipt from anyone who suggests 
>otherwise...

I know the last comment was flip, but in reality, that is all that is 
required. A receipt that you can show a network operator.
ARIN does not control routing. ARIN controls a database which is used by 
network operators, but which network operators also are free to ignore.
That has been my point all along. If ARIN wants to increase the 
"ignorability" of Whois by maintaing policies which do not align with legal 
realities, then ARIN is not acting as a responsible steward of Whois.


> >If ARIN has no control over routing, and no legal ability to stop ip 
> >address sales, their leverage is little. If the benefits
>>of the transfers outweigh the little costs which ARIN can apply, the 
>>transfers will happen.

>ARIN maintains the database accordingly to the community developed 
>policies;
>the community seems to value this and makes use of the database 
>accordingly.

The database is as valuable as a database can be that has been in the 
control of an organization that  for years allowed email templates to 
manipulate data. That has no agreement with  holders of the rights to huge 
swaths of address space. That suffers from stale, missing, or incorrect POC 
data. Whose policies were developed in an age where addresses had no 
monetary value. And that has not yet been tested by the stresses of a 
post-exhaust world where address conflict will increase. My personal 
experience is that network operators have come to realize that, especially 
for legacy space, what is important is not so much what Whois says, but 
whether anybody else is routing addresses they are being asked to route and 
whether the asker has documentary proof of his rights to the space and is 
willing to attest to those rights, covering the butt of the network operator 
and allowing him to realize the revenues derived from the rights-holder.

Regards,
Mike



From jcurran at arin.net  Sat Jun 25 23:57:09 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 26 Jun 2011 03:57:09 +0000
Subject: [arin-ppml] Draft Policy 2011-1 -	Inter-RIR Transfers	
	-Shepherd's Inquiry
In-Reply-To: <2957F65DFC0B4FB5ABC6D50D885ED664@video>
References: <EACF8B735E9CBA4B8BAF9E4165D03087CDA134@ex1.cait.wustl.edu><BANLkTina9wjLJnaVHE7XXkjaE=b11=T3UA@mail.gmail.com>
	<"EACF8B735E9CBA4B8BAF9E4165D03087CDA179"@ex1.cait.wustl.edu><BANLkTim68RN8wAV2Xhf4v9HavRo+RpWwow@mail.gmail.com><"BANLkTimBHp9
	M8VvhfTtB
	YoXi-vmn025jmw"@mail.gmail.com><BANLkTikeAVk2A+MF1uMOtq1f3QStLi6T0w@mail.gmail.com><3616067634770048478@unknownmsgid>
	<"A6762C78-F913-4E78-A9BD-8D5F93BE4E95"@delong.com><0331D5C3EA74461286B111A482D85E4A@mike><8695009A81378E48879980039EEDAD28010C
	52D567@MAIL1.polartel.local><6547DD7D4CD84631AD433C7127F2BDD2@mike><D440DC7A-4D53-4211-9DDD-40C2FE4EF60F@delong.com><85C9F4B5D6
	844F6FBEB90DA9F656C172@mike><4F542EEB-4A52-4230-A221-7D624E14F890@delong.com><A7D828E8C9154245BE467CC985F83294@mike>
	<A3710302-9D56-4849-9961-2E7C45B945A4@arin.net>
	<2957F65DFC0B4FB5ABC6D50D885ED664@video>
Message-ID: <DADE7C10-C5D4-4F8F-945E-0A68C78DF96C@arin.net>

On Jun 26, 2011, at 11:39 AM, Mike Burns wrote:

>> Given that there is now the recognized ability to transfer one rights as a
>> registrant of an address block to another party in accordance with policy,
>> it is perfectly understandable that ARIN would prioritize pursuing number
>> reclamation in the cases you list above (hijacking, dissolution, etc.)
> 
> With respect, I take this answer to mean that there has been no reclamation of legacy space which was not voluntarily returned, the subject of hijacking or fraud, or of corporate dissolution. If I am wong, let me know.

I'm not aware of any recent reclamation activities purely for lack of 
utilization, but would need to confirm with the staff to be certain.

> So the lessons I draw from the document come not from the deal Microsoft struck with ARIN but from the lack of a deal ARIN struck with Nortel. If ARIN could have made any legal claim that they controlled Nortel's transfer rights, I believe ARIN would have made that claim to the judge in the form of an objection to the motion.

It was not necessary to do so since the policy constraints
were being adhered to, including needs-based assessment of 
the recipient and number resources ending up under agreement.

> I know that NRPM section 12 states that it give no "additional" rights to reclaim legacy space, but Owen claims the rights are there anyway. If he is right, why did ARIN not review and reclaim the 660,000 IP addresses that Nortel sold? Why not take the opportunity afforded by the public nature of this deal to clearly establish ARIN's (heretofore unutilized?) right to revoke legacy space when the allocant goes out of business?

See above - it was not necessary to do so, and would have actually 
been contrary to the purpose of the specified transfer policy. 

>> Transfers occur when the request is approved and the Whois database is
>> updated.  You're free to try and purchase anything that you like including
>> the number 3, the letter Q, the color blue, or a new york bridge, but if
>> you'd like to transfer your rights as a registrant of an address block,
>> then you should keep in mind the that transfer occurs when the registration
>> changes.  I'd definitely get a receipt from anyone who suggests otherwise...
> 
> I know the last comment was flip, but in reality, that is all that is required.
> A receipt that you can show a network operator.

That's certainly possible.  It certainly will get interesting if
the resources are reissued to another provider in accordance with 
the community-developed policy.

> ARIN does not control routing. ARIN controls a database which is used by network operators, but which network operators also are free to ignore.
> That has been my point all along. If ARIN wants to increase the "ignorability" of Whois by maintaing policies which do not align with legal realities, then ARIN is not acting as a responsible steward of Whois.

ARIN complies with all applicable laws in the regions in which it operates.
We may not operate in alignment with your particular legal theories, however, 
and that appears to be the issue here.

FYI,
/John

John Curran
President and CEO
ARIN

From jmaimon at chl.com  Sun Jun 26 21:24:50 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Sun, 26 Jun 2011 21:24:50 -0400
Subject: [arin-ppml] Completion of legal and parliamentarian review of
 the Standing Rule of AC Role in Petitions
In-Reply-To: <E8CCE439-42BD-4A04-A01D-712FEE9B67E1@arin.net>
References: <DCC302FAA9FE5F4BBA4DCAD4656937791409227A8B@PRVPEXVS03.corp.twcable.com>
	<E8CCE439-42BD-4A04-A01D-712FEE9B67E1@arin.net>
Message-ID: <4E07DBE2.4040607@chl.com>



John Curran wrote:

>>   Advisory Council member participation in petitions
>>   remains available and should only change if a revised Policy Development
>>   Process is adopted which contains such provisions.
>>
>>   Thank you for raising this matter and do not hesitate to contact me
>>   if you have any questions.
>>
>> Sincerely,
>> /John
>>
>> John Curran
>> President and CEO
>> ARIN
>>

Excellent.

Thank you to all involved.

Joe


From mysidia at gmail.com  Sun Jun 26 22:55:39 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 26 Jun 2011 21:55:39 -0500
Subject: [arin-ppml] Completion of legal and parliamentarian review of
 the Standing Rule of AC Role in Petitions
In-Reply-To: <4E07DBE2.4040607@chl.com>
References: <DCC302FAA9FE5F4BBA4DCAD4656937791409227A8B@PRVPEXVS03.corp.twcable.com>
	<E8CCE439-42BD-4A04-A01D-712FEE9B67E1@arin.net>
	<4E07DBE2.4040607@chl.com>
Message-ID: <BANLkTiknu+CJT1bVR5Xjv4u0NoEejt+VhQ@mail.gmail.com>

On Sun, Jun 26, 2011 at 8:24 PM, Joe Maimon <jmaimon at chl.com> wrote:
> John Curran wrote:
>>> ?Advisory Council member participation in petitions
>>> ?remains available and should only change if a revised Policy Development
>>> ?Process is adopted which contains such provisions.
>>>
>>> ?Thank you for raising this matter and do not hesitate to contact me
>>> ?if you have any questions.
>>> Sincerely,
>>> /John

> Excellent.
> Thank you to all involved.
+1.

I am pleased with this result of Advisory Council member participation
in petitions
remaining available.


Regards,

--
-JH


From bill at herrin.us  Mon Jun 27 13:43:29 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Jun 2011 13:43:29 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
Message-ID: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>

On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
> > In keeping with the spirit of RFC 2860 with respect to the assignment
> > of specialized address blocks, ARIN Staff will consult with the IANA and
> > the IAB regarding implementation of this draft policy.
>
> > == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
> >
> > The IAB honors and values the division of responsibilities as
> > documented in RFC 2860 section 4.3. That section forms the basis for
> > Unicast address allocation via ICANN through the RIR system.
> >
> > Policy proposal 2011-005 is not a regular proposal in the sense that
> > it adheres to Unicast space. In contrast, it allows for an allocation
> > of addresses for special and global use very similar to, and almost
> > indistinguishable from, RFC1918 local addresses. Because of the impact
> > beyond the ARIN region the management (i.e. creation
> > and subsequent changes) of such reservation should be global and RFC2860
> > puts the management responsibility with the IETF.
> >
> > The IAB believes that the adoption by ARIN would be in conflict with the
> > provisions in RFC2860 and would set a bad precedent: Setting aside
> > special addresses should be done within the existing process, i.e. by
> > the IETF.
> >
> > If there is consensus for 2011-005 in the ARIN region we would be
> > happy to work with you to resubmit the proposal to the IETF and, as
> > usual, have the IESG judge consensus. This would include our reaching
> > out to other RIRs to have members of their community provide input on
> > this proposal. Clear support from the various RIR communities might
> > bring new insights into to the IETF, producing a level of support that
> > was not present with the earlier drafts.

Hi Folks,

In light of the IAB's objection, it seems to me that the ARIN board
has four options to consider:

1. Submit an internet draft as the IAB requests, along with the
implications of doing so.

2. Implement 2011-5  as recommended by the AC and community, and over
the IAB's objection.

3. Abandon 2011-5. Proponents may make their case to the IETF.

4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.



1. The case for complying with the IAB's request:

The Internet standards process works because of the cordial and
cooperative atmosphere between the various NGOs and individual
participants. The IETF is indeed the appropriate venue for global
assignment of IP addresses to specific purposes as opposed to specific
end users. However, we must observe that the IANA has insufficient
unicast (class A, B or C) addresses available to award the IETF for
the implementation of 2011-5's intended use.

Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
hold it unused while championing an RFC through the IETF's standards
process that uses the /10 as contemplated in 2011-5. Upon publication
of such an RFC, the /10 would be ceded to IANA for use with the RFC.
Upon a failure to reach consensus within the IETF process, the /10
would be returned to the ARIN free pool for general use.


2. The case for implementing 2011-5 over the IAB's objection.

a. ARIN's constituents have expressed a well defined, well supported
and consensus need for addresses to be used similar like RFC1918 space
but with the expectation that such space crosses the administrative
boundary between ISP and end-user and should, thus, not be used by the
end-user.

b. The IETF had the opportunity to act on these constituents' concerns
but failed to take leadership citing, among other reasons, that it
would deplete the pool of addresses available to the RIRs from IANA.

c. The ARIN region is satisfied with depleting its own address pool
for this purpose.

d. The IAB's suggestion that the proposal be brought back to the IETF
is rendered disingenuous by the fact that no addresses remain at the
IANA for implementation.

e. Precedent exists for RIRs to unilaterally act on regional
imperatives despite potentially global impact. Witness APNIC's
abandonment of needs-based allocation.

Because of these points, ARIN has a moral duty to act on behalf of its
constituents. Should the IETF desire to reclaim leadership in this
matter, ARIN's open public policy process is available to all comers
who may request that the addresses be reassigned to any RFC that is
produced.


3. The case for abandoning 2011-5:

The IETF is the proper venue for a proposal like 2011-5. Such
proposals were considered and rejected. 2011-5 is an end-run around
around the proper process.


4. The case for 2011-5 as a stopgap pending IETF action:

ARIN constituents within the ARIN region have an immediate and
pressing need for IP addresses to be used for the interior of multiple
NAT translators. This need is not adequately served by the delay
inherent in initiating a fresh proposal in the IETF's standards
process, it is not adequately served by RFC1918 and it is poorly
served by having every ISP use its own unique space allocated by ARIN.
Due to the IETF's failure to act in a timely manner while addresses
were still available to them from IANA, ARIN has a duty to act on its
constituents' imperative.

Nevertheless, global assignment of addresses to purposes rather than
registrants properly belongs with the IETF. ARIN should facilitate the
IETF retaking the leadership on the matter by ending the ARIN-region
policy and ceding the /10 address block back to IANA after the IETF
debates, drafts and publishes an RFC that the board of trustees
believes meets or exceeds ARIN constituents' expectations for these
addresses.


For your consideration,
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 matthew at matthew.at  Mon Jun 27 13:51:51 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 27 Jun 2011 10:51:51 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <7C612F05-8637-4E1D-A130-5C2EABA5F0E6@matthew.at>

Why cannot an existing (or new) organization make the case for allocation of the /10 to them, with the "justified need" being that they will be sharing it with themselves and everyone else who needs this type of space? As long as *any* organization is actually using the space in this way, it won't be reclaimed due to lack of need. Done.

At least as long as we don't pass something that requires an actual layer 2 connection between the holder of the space and its user, of course.

Matthew Kaufman

From hannigan at gmail.com  Mon Jun 27 14:16:01 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 27 Jun 2011 14:16:01 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <BANLkTimXE8==2aR5Xg7aamzcQ6RcEmkmMg@mail.gmail.com>

On Mon, Jun 27, 2011 at 1:43 PM, William Herrin <bill at herrin.us> wrote:
> On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
>> > In keeping with the spirit of RFC 2860 with respect to the assignment
>> > of specialized address blocks, ARIN Staff will consult with the IANA and
>> > the IAB regarding implementation of this draft policy.
>>

[ snip ]

> Nevertheless, global assignment of addresses to purposes rather than
> registrants properly belongs with the IETF. ARIN should facilitate the
> IETF retaking the leadership on the matter by ending the ARIN-region
> policy and ceding the /10 address block back to IANA after the IETF
> debates, drafts and publishes an RFC that the board of trustees
> believes meets or exceeds ARIN constituents' expectations for these
> addresses.
>
>


Nice write-up, Bill.

I support that, but with a caveat. Since the various registries issue
mayt not be completely resolved yet, why not strip the /10 out of the
VR addresses instead?

Best,

-M<


From jcurran at arin.net  Mon Jun 27 14:28:51 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 27 Jun 2011 18:28:51 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	for	IPv4 Address Extension - IAB comment
In-Reply-To: <7C612F05-8637-4E1D-A130-5C2EABA5F0E6@matthew.at>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<7C612F05-8637-4E1D-A130-5C2EABA5F0E6@matthew.at>
Message-ID: <D4AAB76E-8F74-4216-9E89-2F4DE7E56D1F@arin.net>

On Jun 28, 2011, at 1:51 AM, Matthew Kaufman wrote:

> Why cannot an existing (or new) organization make the case for allocation of the /10 to them, with the "justified need" being that they will be sharing it with themselves and everyone else who needs this type of space? As long as *any* organization is actually using the space in this way, it won't be reclaimed due to lack of need. Done.
> 
> At least as long as we don't pass something that requires an actual layer 2 connection between the holder of the space and its user, of course.

There are several organizations which have sufficient need on their own to 
justify such allocations, and to my knowledge nothing precludes them sharing 
the use of such an allocation.  

The advantages of an IANA-assigned reservation for this purpose is clarity
and elimination of risk from a business perspective for any organization 
which builds plans dependent on this address block.  While it is possible 
that such clarity could be be obtained by agreement (explicit or otherwise)
with an organizational registrant of an appropriately-sized allocation, that 
also would would take some degree of effort and coordination.

This is not to recommend such an approach, only to note that it appears to be 
a possibility if the available mechanisms to obtain an IANA reservation are too 
onerous to undertake or are ultimately unsuccessful.  There would be some irony 
to such a result, but if it is the will of the community to have this outcome 
then it is very likely to be satisfied in the end in some manner or another.

FYI,
/John

John Curran
President and CEO
ARIN







From joelja at bogus.com  Mon Jun 27 14:00:52 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 27 Jun 2011 11:00:52 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <207CE2A9-5611-4BAB-BAAF-1E6CE26E637C@bogus.com>


On Jun 27, 2011, at 10:43 AM, William Herrin wrote:

> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
> 
> 1. Submit an internet draft as the IAB requests, along with the
> implications of doing so.
> 
> 2. Implement 2011-5  as recommended by the AC and community, and over
> the IAB's objection.
> 
> 3. Abandon 2011-5. Proponents may make their case to the IETF.


The proponents have made their case in the IETF. the outcome of that discussion is a matter of record.


> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> 
> 
> 
> 1. The case for complying with the IAB's request:
> 
> The Internet standards process works because of the cordial and
> cooperative atmosphere between the various NGOs and individual
> participants. The IETF is indeed the appropriate venue for global
> assignment of IP addresses to specific purposes as opposed to specific
> end users. However, we must observe that the IANA has insufficient
> unicast (class A, B or C) addresses available to award the IETF for
> the implementation of 2011-5's intended use.
> 
> Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> hold it unused while championing an RFC through the IETF's standards
> process that uses the /10 as contemplated in 2011-5. Upon publication
> of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> Upon a failure to reach consensus within the IETF process, the /10
> would be returned to the ARIN free pool for general use.
> 
> 
> 2. The case for implementing 2011-5 over the IAB's objection.
> 
> a. ARIN's constituents have expressed a well defined, well supported
> and consensus need for addresses to be used similar like RFC1918 space
> but with the expectation that such space crosses the administrative
> boundary between ISP and end-user and should, thus, not be used by the
> end-user.
> 
> b. The IETF had the opportunity to act on these constituents' concerns
> but failed to take leadership citing, among other reasons, that it
> would deplete the pool of addresses available to the RIRs from IANA.
> 
> c. The ARIN region is satisfied with depleting its own address pool
> for this purpose.
> 
> d. The IAB's suggestion that the proposal be brought back to the IETF
> is rendered disingenuous by the fact that no addresses remain at the
> IANA for implementation.
> 
> e. Precedent exists for RIRs to unilaterally act on regional
> imperatives despite potentially global impact. Witness APNIC's
> abandonment of needs-based allocation.
> 
> Because of these points, ARIN has a moral duty to act on behalf of its
> constituents. Should the IETF desire to reclaim leadership in this
> matter, ARIN's open public policy process is available to all comers
> who may request that the addresses be reassigned to any RFC that is
> produced.
> 
> 
> 3. The case for abandoning 2011-5:
> 
> The IETF is the proper venue for a proposal like 2011-5. Such
> proposals were considered and rejected. 2011-5 is an end-run around
> around the proper process.
> 
> 
> 4. The case for 2011-5 as a stopgap pending IETF action:
> 
> ARIN constituents within the ARIN region have an immediate and
> pressing need for IP addresses to be used for the interior of multiple
> NAT translators. This need is not adequately served by the delay
> inherent in initiating a fresh proposal in the IETF's standards
> process, it is not adequately served by RFC1918 and it is poorly
> served by having every ISP use its own unique space allocated by ARIN.
> Due to the IETF's failure to act in a timely manner while addresses
> were still available to them from IANA, ARIN has a duty to act on its
> constituents' imperative.
> 
> Nevertheless, global assignment of addresses to purposes rather than
> registrants properly belongs with the IETF. ARIN should facilitate the
> IETF retaking the leadership on the matter by ending the ARIN-region
> policy and ceding the /10 address block back to IANA after the IETF
> debates, drafts and publishes an RFC that the board of trustees
> believes meets or exceeds ARIN constituents' expectations for these
> addresses.
> 
> 
> For your consideration,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From owen at delong.com  Mon Jun 27 16:35:26 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jun 2011 13:35:26 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>

I believe there may be a fifth option.

I believe that the ISPs who need this space might be able to  form a consortium and
use this as a standard justification to have the IPs registered to the consortium
as an organization. It would be up to the consortium after that whether they
expressed a willingness for non-members to make duplicate use of their
address space for this purpose or not.

John Curran, could you please comment on whether such a request from
a consortium for an allocation or assignment could be processed within
staff interpretation of existing policy?

Thoughts?

Owen

On Jun 27, 2011, at 10:43 AM, William Herrin wrote:

> On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
>>> In keeping with the spirit of RFC 2860 with respect to the assignment
>>> of specialized address blocks, ARIN Staff will consult with the IANA and
>>> the IAB regarding implementation of this draft policy.
>> 
>>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
>>> 
>>> The IAB honors and values the division of responsibilities as
>>> documented in RFC 2860 section 4.3. That section forms the basis for
>>> Unicast address allocation via ICANN through the RIR system.
>>> 
>>> Policy proposal 2011-005 is not a regular proposal in the sense that
>>> it adheres to Unicast space. In contrast, it allows for an allocation
>>> of addresses for special and global use very similar to, and almost
>>> indistinguishable from, RFC1918 local addresses. Because of the impact
>>> beyond the ARIN region the management (i.e. creation
>>> and subsequent changes) of such reservation should be global and RFC2860
>>> puts the management responsibility with the IETF.
>>> 
>>> The IAB believes that the adoption by ARIN would be in conflict with the
>>> provisions in RFC2860 and would set a bad precedent: Setting aside
>>> special addresses should be done within the existing process, i.e. by
>>> the IETF.
>>> 
>>> If there is consensus for 2011-005 in the ARIN region we would be
>>> happy to work with you to resubmit the proposal to the IETF and, as
>>> usual, have the IESG judge consensus. This would include our reaching
>>> out to other RIRs to have members of their community provide input on
>>> this proposal. Clear support from the various RIR communities might
>>> bring new insights into to the IETF, producing a level of support that
>>> was not present with the earlier drafts.
> 
> Hi Folks,
> 
> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
> 
> 1. Submit an internet draft as the IAB requests, along with the
> implications of doing so.
> 
> 2. Implement 2011-5  as recommended by the AC and community, and over
> the IAB's objection.
> 
> 3. Abandon 2011-5. Proponents may make their case to the IETF.
> 
> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> 
> 
> 
> 1. The case for complying with the IAB's request:
> 
> The Internet standards process works because of the cordial and
> cooperative atmosphere between the various NGOs and individual
> participants. The IETF is indeed the appropriate venue for global
> assignment of IP addresses to specific purposes as opposed to specific
> end users. However, we must observe that the IANA has insufficient
> unicast (class A, B or C) addresses available to award the IETF for
> the implementation of 2011-5's intended use.
> 
> Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> hold it unused while championing an RFC through the IETF's standards
> process that uses the /10 as contemplated in 2011-5. Upon publication
> of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> Upon a failure to reach consensus within the IETF process, the /10
> would be returned to the ARIN free pool for general use.
> 
> 
> 2. The case for implementing 2011-5 over the IAB's objection.
> 
> a. ARIN's constituents have expressed a well defined, well supported
> and consensus need for addresses to be used similar like RFC1918 space
> but with the expectation that such space crosses the administrative
> boundary between ISP and end-user and should, thus, not be used by the
> end-user.
> 
> b. The IETF had the opportunity to act on these constituents' concerns
> but failed to take leadership citing, among other reasons, that it
> would deplete the pool of addresses available to the RIRs from IANA.
> 
> c. The ARIN region is satisfied with depleting its own address pool
> for this purpose.
> 
> d. The IAB's suggestion that the proposal be brought back to the IETF
> is rendered disingenuous by the fact that no addresses remain at the
> IANA for implementation.
> 
> e. Precedent exists for RIRs to unilaterally act on regional
> imperatives despite potentially global impact. Witness APNIC's
> abandonment of needs-based allocation.
> 
> Because of these points, ARIN has a moral duty to act on behalf of its
> constituents. Should the IETF desire to reclaim leadership in this
> matter, ARIN's open public policy process is available to all comers
> who may request that the addresses be reassigned to any RFC that is
> produced.
> 
> 
> 3. The case for abandoning 2011-5:
> 
> The IETF is the proper venue for a proposal like 2011-5. Such
> proposals were considered and rejected. 2011-5 is an end-run around
> around the proper process.
> 
> 
> 4. The case for 2011-5 as a stopgap pending IETF action:
> 
> ARIN constituents within the ARIN region have an immediate and
> pressing need for IP addresses to be used for the interior of multiple
> NAT translators. This need is not adequately served by the delay
> inherent in initiating a fresh proposal in the IETF's standards
> process, it is not adequately served by RFC1918 and it is poorly
> served by having every ISP use its own unique space allocated by ARIN.
> Due to the IETF's failure to act in a timely manner while addresses
> were still available to them from IANA, ARIN has a duty to act on its
> constituents' imperative.
> 
> Nevertheless, global assignment of addresses to purposes rather than
> registrants properly belongs with the IETF. ARIN should facilitate the
> IETF retaking the leadership on the matter by ending the ARIN-region
> policy and ceding the /10 address block back to IANA after the IETF
> debates, drafts and publishes an RFC that the board of trustees
> believes meets or exceeds ARIN constituents' expectations for these
> addresses.
> 
> 
> For your consideration,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Mon Jun 27 16:46:29 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jun 2011 13:46:29 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <207CE2A9-5611-4BAB-BAAF-1E6CE26E637C@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<207CE2A9-5611-4BAB-BAAF-1E6CE26E637C@bogus.com>
Message-ID: <C41100AE-4EE6-4D9E-ADC9-349EC85236F8@delong.com>


On Jun 27, 2011, at 11:00 AM, Joel Jaeggli wrote:

> 
> On Jun 27, 2011, at 10:43 AM, William Herrin wrote:
> 
>> In light of the IAB's objection, it seems to me that the ARIN board
>> has four options to consider:
>> 
>> 1. Submit an internet draft as the IAB requests, along with the
>> implications of doing so.
>> 
>> 2. Implement 2011-5  as recommended by the AC and community, and over
>> the IAB's objection.
>> 
>> 3. Abandon 2011-5. Proponents may make their case to the IETF.
> 
> 
> The proponents have made their case in the IETF. the outcome of that discussion is a matter of record.
> 

When this was being discussed at IETF, I, for one, opposed it because I did not fully understand
the issue or the implications. I now believe that this should be adopted.

I support IETF/IAB reconsideration of the proposal, though, in the interim, I think it would
be wise for the group that needs these addresses to form a consortium and make an
application to ARIN under existing policies for a standard assignment to then use for
this same purpose.

Owen

> 
>> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
>> 
>> 
>> 
>> 1. The case for complying with the IAB's request:
>> 
>> The Internet standards process works because of the cordial and
>> cooperative atmosphere between the various NGOs and individual
>> participants. The IETF is indeed the appropriate venue for global
>> assignment of IP addresses to specific purposes as opposed to specific
>> end users. However, we must observe that the IANA has insufficient
>> unicast (class A, B or C) addresses available to award the IETF for
>> the implementation of 2011-5's intended use.
>> 
>> Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
>> hold it unused while championing an RFC through the IETF's standards
>> process that uses the /10 as contemplated in 2011-5. Upon publication
>> of such an RFC, the /10 would be ceded to IANA for use with the RFC.
>> Upon a failure to reach consensus within the IETF process, the /10
>> would be returned to the ARIN free pool for general use.
>> 
>> 
>> 2. The case for implementing 2011-5 over the IAB's objection.
>> 
>> a. ARIN's constituents have expressed a well defined, well supported
>> and consensus need for addresses to be used similar like RFC1918 space
>> but with the expectation that such space crosses the administrative
>> boundary between ISP and end-user and should, thus, not be used by the
>> end-user.
>> 
>> b. The IETF had the opportunity to act on these constituents' concerns
>> but failed to take leadership citing, among other reasons, that it
>> would deplete the pool of addresses available to the RIRs from IANA.
>> 
>> c. The ARIN region is satisfied with depleting its own address pool
>> for this purpose.
>> 
>> d. The IAB's suggestion that the proposal be brought back to the IETF
>> is rendered disingenuous by the fact that no addresses remain at the
>> IANA for implementation.
>> 
>> e. Precedent exists for RIRs to unilaterally act on regional
>> imperatives despite potentially global impact. Witness APNIC's
>> abandonment of needs-based allocation.
>> 
>> Because of these points, ARIN has a moral duty to act on behalf of its
>> constituents. Should the IETF desire to reclaim leadership in this
>> matter, ARIN's open public policy process is available to all comers
>> who may request that the addresses be reassigned to any RFC that is
>> produced.
>> 
>> 
>> 3. The case for abandoning 2011-5:
>> 
>> The IETF is the proper venue for a proposal like 2011-5. Such
>> proposals were considered and rejected. 2011-5 is an end-run around
>> around the proper process.
>> 
>> 
>> 4. The case for 2011-5 as a stopgap pending IETF action:
>> 
>> ARIN constituents within the ARIN region have an immediate and
>> pressing need for IP addresses to be used for the interior of multiple
>> NAT translators. This need is not adequately served by the delay
>> inherent in initiating a fresh proposal in the IETF's standards
>> process, it is not adequately served by RFC1918 and it is poorly
>> served by having every ISP use its own unique space allocated by ARIN.
>> Due to the IETF's failure to act in a timely manner while addresses
>> were still available to them from IANA, ARIN has a duty to act on its
>> constituents' imperative.
>> 
>> Nevertheless, global assignment of addresses to purposes rather than
>> registrants properly belongs with the IETF. ARIN should facilitate the
>> IETF retaking the leadership on the matter by ending the ARIN-region
>> policy and ceding the /10 address block back to IANA after the IETF
>> debates, drafts and publishes an RFC that the board of trustees
>> believes meets or exceeds ARIN constituents' expectations for these
>> addresses.
>> 
>> 
>> For your consideration,
>> Bill Herrin
>> 
>> 
>> 
>> --
>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mike at nationwideinc.com  Mon Jun 27 16:54:05 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 27 Jun 2011 16:54:05 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
Message-ID: <A573D3C182714982B8395BC0FDC2ABFE@mike>

I support either option 2/4 of Bill's option list or this idea of an 
allocation to an entity who publicly allows for them to be shared for 
internal use only.
Either way it's insane to dole out addresses to multiple ISPs for this same 
internal use purpose.
I guess my preference would be to do it in policy, otherwise if this 
justification is used for the new entity, couldn't it be used subsequently 
(and wastefully) by another entity?

Mike

----- Original Message ----- 
From: "Owen DeLong" <owen at delong.com>
To: "William Herrin" <bill at herrin.us>
Cc: "John Curran" <jcurran at arin.net>; <arin-ppml at arin.net>
Sent: Monday, June 27, 2011 4:35 PM
Subject: Re: [arin-ppml] Draft Policy 2011-5: Shared Transition Space 
forIPv4 Address Extension - IAB comment


>I believe there may be a fifth option.
>
> I believe that the ISPs who need this space might be able to  form a 
> consortium and
> use this as a standard justification to have the IPs registered to the 
> consortium
> as an organization. It would be up to the consortium after that whether 
> they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.
>
> John Curran, could you please comment on whether such a request from
> a consortium for an allocation or assignment could be processed within
> staff interpretation of existing policy?
>
> Thoughts?
>
> Owen
>
> On Jun 27, 2011, at 10:43 AM, William Herrin wrote:
>
>> On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
>>>> In keeping with the spirit of RFC 2860 with respect to the assignment
>>>> of specialized address blocks, ARIN Staff will consult with the IANA 
>>>> and
>>>> the IAB regarding implementation of this draft policy.
>>>
>>>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
>>>>
>>>> The IAB honors and values the division of responsibilities as
>>>> documented in RFC 2860 section 4.3. That section forms the basis for
>>>> Unicast address allocation via ICANN through the RIR system.
>>>>
>>>> Policy proposal 2011-005 is not a regular proposal in the sense that
>>>> it adheres to Unicast space. In contrast, it allows for an allocation
>>>> of addresses for special and global use very similar to, and almost
>>>> indistinguishable from, RFC1918 local addresses. Because of the impact
>>>> beyond the ARIN region the management (i.e. creation
>>>> and subsequent changes) of such reservation should be global and 
>>>> RFC2860
>>>> puts the management responsibility with the IETF.
>>>>
>>>> The IAB believes that the adoption by ARIN would be in conflict with 
>>>> the
>>>> provisions in RFC2860 and would set a bad precedent: Setting aside
>>>> special addresses should be done within the existing process, i.e. by
>>>> the IETF.
>>>>
>>>> If there is consensus for 2011-005 in the ARIN region we would be
>>>> happy to work with you to resubmit the proposal to the IETF and, as
>>>> usual, have the IESG judge consensus. This would include our reaching
>>>> out to other RIRs to have members of their community provide input on
>>>> this proposal. Clear support from the various RIR communities might
>>>> bring new insights into to the IETF, producing a level of support that
>>>> was not present with the earlier drafts.
>>
>> Hi Folks,
>>
>> In light of the IAB's objection, it seems to me that the ARIN board
>> has four options to consider:
>>
>> 1. Submit an internet draft as the IAB requests, along with the
>> implications of doing so.
>>
>> 2. Implement 2011-5  as recommended by the AC and community, and over
>> the IAB's objection.
>>
>> 3. Abandon 2011-5. Proponents may make their case to the IETF.
>>
>> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF 
>> action.
>>
>>
>>
>> 1. The case for complying with the IAB's request:
>>
>> The Internet standards process works because of the cordial and
>> cooperative atmosphere between the various NGOs and individual
>> participants. The IETF is indeed the appropriate venue for global
>> assignment of IP addresses to specific purposes as opposed to specific
>> end users. However, we must observe that the IANA has insufficient
>> unicast (class A, B or C) addresses available to award the IETF for
>> the implementation of 2011-5's intended use.
>>
>> Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
>> hold it unused while championing an RFC through the IETF's standards
>> process that uses the /10 as contemplated in 2011-5. Upon publication
>> of such an RFC, the /10 would be ceded to IANA for use with the RFC.
>> Upon a failure to reach consensus within the IETF process, the /10
>> would be returned to the ARIN free pool for general use.
>>
>>
>> 2. The case for implementing 2011-5 over the IAB's objection.
>>
>> a. ARIN's constituents have expressed a well defined, well supported
>> and consensus need for addresses to be used similar like RFC1918 space
>> but with the expectation that such space crosses the administrative
>> boundary between ISP and end-user and should, thus, not be used by the
>> end-user.
>>
>> b. The IETF had the opportunity to act on these constituents' concerns
>> but failed to take leadership citing, among other reasons, that it
>> would deplete the pool of addresses available to the RIRs from IANA.
>>
>> c. The ARIN region is satisfied with depleting its own address pool
>> for this purpose.
>>
>> d. The IAB's suggestion that the proposal be brought back to the IETF
>> is rendered disingenuous by the fact that no addresses remain at the
>> IANA for implementation.
>>
>> e. Precedent exists for RIRs to unilaterally act on regional
>> imperatives despite potentially global impact. Witness APNIC's
>> abandonment of needs-based allocation.
>>
>> Because of these points, ARIN has a moral duty to act on behalf of its
>> constituents. Should the IETF desire to reclaim leadership in this
>> matter, ARIN's open public policy process is available to all comers
>> who may request that the addresses be reassigned to any RFC that is
>> produced.
>>
>>
>> 3. The case for abandoning 2011-5:
>>
>> The IETF is the proper venue for a proposal like 2011-5. Such
>> proposals were considered and rejected. 2011-5 is an end-run around
>> around the proper process.
>>
>>
>> 4. The case for 2011-5 as a stopgap pending IETF action:
>>
>> ARIN constituents within the ARIN region have an immediate and
>> pressing need for IP addresses to be used for the interior of multiple
>> NAT translators. This need is not adequately served by the delay
>> inherent in initiating a fresh proposal in the IETF's standards
>> process, it is not adequately served by RFC1918 and it is poorly
>> served by having every ISP use its own unique space allocated by ARIN.
>> Due to the IETF's failure to act in a timely manner while addresses
>> were still available to them from IANA, ARIN has a duty to act on its
>> constituents' imperative.
>>
>> Nevertheless, global assignment of addresses to purposes rather than
>> registrants properly belongs with the IETF. ARIN should facilitate the
>> IETF retaking the leadership on the matter by ending the ARIN-region
>> policy and ceding the /10 address block back to IANA after the IETF
>> debates, drafts and publishes an RFC that the board of trustees
>> believes meets or exceeds ARIN constituents' expectations for these
>> addresses.
>>
>>
>> For your consideration,
>> Bill Herrin
>>
>>
>>
>> --
>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues. 



From owen at delong.com  Mon Jun 27 16:58:30 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jun 2011 13:58:30 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
In-Reply-To: <A573D3C182714982B8395BC0FDC2ABFE@mike>
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<A573D3C182714982B8395BC0FDC2ABFE@mike>
Message-ID: <BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>


On Jun 27, 2011, at 1:54 PM, Mike Burns wrote:

> I support either option 2/4 of Bill's option list or this idea of an allocation to an entity who publicly allows for them to be shared for internal use only.
> Either way it's insane to dole out addresses to multiple ISPs for this same internal use purpose.
> I guess my preference would be to do it in policy, otherwise if this justification is used for the new entity, couldn't it be used subsequently (and wastefully) by another entity?
> 
> Mike
> 

I would prefer to do it in policy as well and for exactly that reason. However, that door just got slammed in our face by the IAB, so, pragmatically, I think the best we can do is encourage the formation of a coalition and hope that exactly one coalition forms and is able to convince people to do the right thing and use the one unit of space rather than filing duplicate requests from multiple organizations.

Given the outcome of ARIN's correspondence with IAB, I'm not sure how else we can meet the needs of these ISPs.

Owen


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

From lsawyer at gci.com  Mon Jun 27 17:03:47 2011
From: lsawyer at gci.com (Leif Sawyer)
Date: Mon, 27 Jun 2011 13:03:47 -0800
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition
	Space	forIPv4 Address Extension - IAB comment
In-Reply-To: <BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<A573D3C182714982B8395BC0FDC2ABFE@mike>
	<BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC51F46E9D12@fnb1mbx01.gci.com>

I think CableLabs would be an ideal consortium to approach with this concept.

I'll bring it up tomorrow morning during our conference call.


________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Monday, June 27, 2011 12:59 PM
To: Mike Burns
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2011-5: Shared Transition Space forIPv4 Address Extension - IAB comment


On Jun 27, 2011, at 1:54 PM, Mike Burns wrote:

I support either option 2/4 of Bill's option list or this idea of an allocation to an entity who publicly allows for them to be shared for internal use only.
Either way it's insane to dole out addresses to multiple ISPs for this same internal use purpose.
I guess my preference would be to do it in policy, otherwise if this justification is used for the new entity, couldn't it be used subsequently (and wastefully) by another entity?

Mike


I would prefer to do it in policy as well and for exactly that reason. However, that door just got slammed in our face by the IAB, so, pragmatically, I think the best we can do is encourage the formation of a coalition and hope that exactly one coalition forms and is able to convince people to do the right thing and use the one unit of space rather than filing duplicate requests from multiple organizations.

Given the outcome of ARIN's correspondence with IAB, I'm not sure how else we can meet the needs of these ISPs.

Owen


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

From bensons at queuefull.net  Mon Jun 27 17:32:43 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Mon, 27 Jun 2011 16:32:43 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>


On Jun 27, 2011, at 12:43 PM, William Herrin wrote:
> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
> 
> 1. Submit an internet draft as the IAB requests, along with the
> implications of doing so.
> 
> 2. Implement 2011-5  as recommended by the AC and community, and over
> the IAB's objection.
> 
> 3. Abandon 2011-5. Proponents may make their case to the IETF.
> 
> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> 

Thanks for your analysis, Bill - I think this was a good write-up.

While I do agree with some of your conclusions in 2, in my opinion ARIN should first pursue option 1.  If we can collaboratively agree on the reservation of Shared Transition Space, that would be preferred over ARIN acting alone.  And if in the end the IETF and ARIN do not agree on this matter, we can consider choosing one of the other options at that time.

Given how drawn-out these things can become, I would also recommend ARIN hold back a /10 in reserve, until the IETF process concludes.  In pursuing the IETF process, we should write a draft that indicates ARIN is willing to "donate" a /10 for this purpose.  It would also be great to get co-authors from each RIR region, to act as local points of contact (although, probably not representatives).

Cheers,
-Benson



From matthew at matthew.at  Mon Jun 27 17:39:15 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 27 Jun 2011 14:39:15 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
Message-ID: <FD538491-7EAE-470F-9546-BA0CAEE3A914@matthew.at>


On Jun 27, 2011, at 1:35 PM, Owen DeLong wrote:

> I believe there may be a fifth option.
> 
> I believe that the ISPs who need this space might be able to  form a consortium and
> use this as a standard justification to have the IPs registered to the consortium
> as an organization. It would be up to the consortium after that whether they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.
> 
> John Curran, could you please comment on whether such a request from
> a consortium for an allocation or assignment could be processed within
> staff interpretation of existing policy?
> 
> Thoughts?

I think that's exactly what I suggested ("(or new) organization")

Matthew Kaufman

From jcurran at arin.net  Mon Jun 27 18:01:43 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 27 Jun 2011 22:01:43 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
 forIPv4 Address Extension - IAB comment
In-Reply-To: <BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<A573D3C182714982B8395BC0FDC2ABFE@mike>,
	<BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>
Message-ID: <00E3E3DF-705B-4728-851A-6F7D0FAF3A10@arin.net>

Owen -

    I completely disagree with your characterization of
the IAB correspondence.   The IAB went out of its way
to open the door to reconsideration of this matter within
the IETF process.  If the community wishes to raise this
matter there, it will be heard.

/John

John Curran
President and CEO
ARIN

On Jun 28, 2011, at 5:01 AM, "Owen DeLong" <owen at delong.com<mailto:owen at delong.com>> wrote:


On Jun 27, 2011, at 1:54 PM, Mike Burns wrote:

I support either option 2/4 of Bill's option list or this idea of an allocation to an entity who publicly allows for them to be shared for internal use only.
Either way it's insane to dole out addresses to multiple ISPs for this same internal use purpose.
I guess my preference would be to do it in policy, otherwise if this justification is used for the new entity, couldn't it be used subsequently (and wastefully) by another entity?

Mike


I would prefer to do it in policy as well and for exactly that reason. However, that door just got slammed in our face by the IAB, so, pragmatically, I think the best we can do is encourage the formation of a coalition and hope that exactly one coalition forms and is able to convince people to do the right thing and use the one unit of space rather than filing duplicate requests from multiple organizations.

Given the outcome of ARIN's correspondence with IAB, I'm not sure how else we can meet the needs of these ISPs.

Owen


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

From owen at delong.com  Mon Jun 27 18:12:15 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jun 2011 15:12:15 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
In-Reply-To: <00E3E3DF-705B-4728-851A-6F7D0FAF3A10@arin.net>
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<A573D3C182714982B8395BC0FDC2ABFE@mike>,
	<BEEDCA3B-2D82-47FE-9203-D229DF0B4652@delong.com>
	<00E3E3DF-705B-4728-851A-6F7D0FAF3A10@arin.net>
Message-ID: <2A474E65-87BE-4184-BF95-7F261A7C38A3@delong.com>

Yes, they opened the door to having the IETF reconsider it, but, they slammed the door on ARIN doing it through the ARIN policy process.

That is what I said and I think it is an accurate statement.

Owen

On Jun 27, 2011, at 3:01 PM, John Curran wrote:

> Owen -
> 
>     I completely disagree with your characterization of 
> the IAB correspondence.   The IAB went out of its way 
> to open the door to reconsideration of this matter within
> the IETF process.  If the community wishes to raise this 
> matter there, it will be heard.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> On Jun 28, 2011, at 5:01 AM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Jun 27, 2011, at 1:54 PM, Mike Burns wrote:
>> 
>>> I support either option 2/4 of Bill's option list or this idea of an allocation to an entity who publicly allows for them to be shared for internal use only.
>>> Either way it's insane to dole out addresses to multiple ISPs for this same internal use purpose.
>>> I guess my preference would be to do it in policy, otherwise if this justification is used for the new entity, couldn't it be used subsequently (and wastefully) by another entity?
>>> 
>>> Mike
>>> 
>> 
>> I would prefer to do it in policy as well and for exactly that reason. However, that door just got slammed in our face by the IAB, so, pragmatically, I think the best we can do is encourage the formation of a coalition and hope that exactly one coalition forms and is able to convince people to do the right thing and use the one unit of space rather than filing duplicate requests from multiple organizations.
>> 
>> Given the outcome of ARIN's correspondence with IAB, I'm not sure how else we can meet the needs of these ISPs.
>> 
>> Owen
>> 
>> 

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

From adurand at juniper.net  Mon Jun 27 18:03:58 2011
From: adurand at juniper.net (Alain Durand)
Date: Mon, 27 Jun 2011 15:03:58 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <FF8DB154-DB96-404F-B096-31E1A8DAD713@juniper.net>

>>> 
>>> The IAB believes that the adoption by ARIN would be in conflict with the
>>> provisions in RFC2860 and would set a bad precedent: Setting aside
>>> special addresses should be done within the existing process, i.e. by
>>> the IETF.
> 

> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
> 
> 1. Submit an internet draft as the IAB requests, along with the
> implications of doing so.
> 
> 2. Implement 2011-5  as recommended by the AC and community, and over
> the IAB's objection.
> 
> 3. Abandon 2011-5. Proponents may make their case to the IETF.
> 
> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> 


In their response, the IAB clearly states that 2011-5 creates address space that modifies the IP addressing architecture. This should not be done by RIRs. Period.
As such, I believe ARIN should abandon 2011-5 all together. Trying to stick it under the rug is a bad idea. If some wants to do that in the privacy of their networks, this is one thing,
ARIN doing it is another. That would set a very bad precedent that other SDO could follow to claim they can update IETF protocols on their own. Note: this is already happening with MPLS-TP,
for those who follow that discussion.

   - Alain.

From george.herbert at gmail.com  Mon Jun 27 18:25:30 2011
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 27 Jun 2011 15:25:30 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <FF8DB154-DB96-404F-B096-31E1A8DAD713@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<FF8DB154-DB96-404F-B096-31E1A8DAD713@juniper.net>
Message-ID: <BANLkTimLTYV4GRXinkCBotg+eKNrf+cT2w@mail.gmail.com>

On Mon, Jun 27, 2011 at 3:03 PM, Alain Durand <adurand at juniper.net> wrote:
>>>>
>>>> The IAB believes that the adoption by ARIN would be in conflict with the
>>>> provisions in RFC2860 and would set a bad precedent: Setting aside
>>>> special addresses should be done within the existing process, i.e. by
>>>> the IETF.
>>
>
>> In light of the IAB's objection, it seems to me that the ARIN board
>> has four options to consider:
>>
>> 1. Submit an internet draft as the IAB requests, along with the
>> implications of doing so.
>>
>> 2. Implement 2011-5 ?as recommended by the AC and community, and over
>> the IAB's objection.
>>
>> 3. Abandon 2011-5. Proponents may make their case to the IETF.
>>
>> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
>>
>
>
> In their response, the IAB clearly states that 2011-5 creates address space that modifies the IP addressing architecture. This should not be done by RIRs. Period.
> As such, I believe ARIN should abandon 2011-5 all together. Trying to stick it under the rug is a bad idea. If some wants to do that in the privacy of their networks, this is one thing,
> ARIN doing it is another. That would set a very bad precedent that other SDO could follow to claim they can update IETF protocols on their own. Note: this is already happening with MPLS-TP,
> for those who follow that discussion.


If the need is urgent enough, the operators may be forced to override
the policy cries of "Unclean!  Unclean!" and simply do it.

If the easiest way to do that is for ARIN to allocate the block to a
consortium with a wink wink nudge nudge, and simultaneously for
someone to go to IETF to legitimize the consortium's action, then that
seems reasonably harmless...


-- 
-george william herbert
george.herbert at gmail.com


From owen at delong.com  Mon Jun 27 18:31:11 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jun 2011 15:31:11 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTimLTYV4GRXinkCBotg+eKNrf+cT2w@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<FF8DB154-DB96-404F-B096-31E1A8DAD713@juniper.net>
	<BANLkTimLTYV4GRXinkCBotg+eKNrf+cT2w@mail.gmail.com>
Message-ID: <4AFE0D94-22AF-408A-91B6-F9ABD1F43DFE@delong.com>

> 
> 
> If the need is urgent enough, the operators may be forced to override
> the policy cries of "Unclean!  Unclean!" and simply do it.
> 
> If the easiest way to do that is for ARIN to allocate the block to a
> consortium with a wink wink nudge nudge, and simultaneously for
> someone to go to IETF to legitimize the consortium's action, then that
> seems reasonably harmless...
> 

+1

Owen



From bill at herrin.us  Mon Jun 27 19:14:26 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Jun 2011 19:14:26 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <BANLkTikOYnPmuZTJ80xH9t=rgSLrfh7wpA@mail.gmail.com>

On Mon, Jun 27, 2011 at 1:43 PM, William Herrin <bill at herrin.us> wrote:
> 4. The case for 2011-5 as a stopgap pending IETF action:
>
> ARIN constituents within the ARIN region have an immediate and
> pressing need for IP addresses to be used for the interior of multiple
> NAT translators. This need is not adequately served by the delay
> inherent in initiating a fresh proposal in the IETF's standards
> process, it is not adequately served by RFC1918 and it is poorly
> served by having every ISP use its own unique space allocated by ARIN.
> Due to the IETF's failure to act in a timely manner while addresses
> were still available to them from IANA, ARIN has a duty to act on its
> constituents' imperative.
>
> Nevertheless, global assignment of addresses to purposes rather than
> registrants properly belongs with the IETF. ARIN should facilitate the
> IETF retaking the leadership on the matter by ending the ARIN-region
> policy and ceding the /10 address block back to IANA after the IETF
> debates, drafts and publishes an RFC that the board of trustees
> believes meets or exceeds ARIN constituents' expectations for these
> addresses.


Personally, I'd like to see the board chart a course similar to option
4. Our ISPs need this address space NOW, not 3 years from now when
their multilevel NAT deployments are done. However, ARIN does not
provide the proper forum nor is the NRPM the proper mechanism to work
through and document the technical details which are not, as
previously mentioned, the same as RFC 1918. That forum will be found
within the IETF.



On Mon, Jun 27, 2011 at 4:35 PM, Owen DeLong <owen at delong.com> wrote:
> I believe there may be a fifth option.
>
> I believe that the ISPs who need this space might be able to  form a consortium and
> use this as a standard justification to have the IPs registered to the consortium
> as an organization. It would be up to the consortium after that whether they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.

Hi Owen,

Let's call that the nuclear option. If the IETF won't be reasonable
and the ARIN BoT won't stand up and say, "hey, we're doin' it," we
could drag the shared transition space out of the established TCP/IP
standards process altogether. I'm not sure it's wise to create
precedent that gives other entities like the ITU a back door to come
after us for their clever ideas.

Regards,
Bill Herrin

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


From jcurran at arin.net  Mon Jun 27 19:34:41 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 27 Jun 2011 23:34:41 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition
	Space	for	IPv4 Address Extension - IAB comment
In-Reply-To: <D4AAB76E-8F74-4216-9E89-2F4DE7E56D1F@arin.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<7C612F05-8637-4E1D-A130-5C2EABA5F0E6@matthew.at>
	<D4AAB76E-8F74-4216-9E89-2F4DE7E56D1F@arin.net>
Message-ID: <7F442D09-D4B8-4042-936D-EF6BEAB3DF5C@arin.net>

On Jun 28, 2011, at 2:28 AM, John Curran wrote:
> 
> There are several organizations which have sufficient need on their own to 
> justify such allocations, and to my knowledge nothing precludes them sharing 
> the use of such an allocation.  

In doing some exploring of this option, it turns out to now be much 
more difficult to qualify for such an allocation due to the change 
in allocation window that occurred with the issuance of the final /8,
i.e.  there may not be any organization today that qualifies for a
/10 allocation based on their allocation history and three months of
demand.  

I wanted to make sure the community was aware of this, since my 
characterization above was incorrect.

FYI,
/John

John Curran
President and CEO
ARIN



From joelja at bogus.com  Mon Jun 27 19:49:58 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 27 Jun 2011 16:49:58 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikOYnPmuZTJ80xH9t=rgSLrfh7wpA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<BANLkTikOYnPmuZTJ80xH9t=rgSLrfh7wpA@mail.gmail.com>
Message-ID: <B3E16454-3DD0-42A4-A749-2F1E4739239F@bogus.com>


On Jun 27, 2011, at 4:14 PM, William Herrin wrote:

> 
> Let's call that the nuclear option. If the IETF won't be reasonable
> and the ARIN BoT won't stand up and say, "hey, we're doin' it," we
> could drag the shared transition space out of the established TCP/IP
> standards process altogether.

It is possible for reasonable people to come to different conclusions on this issue. 

http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-02

was not discarded out of hand, nor lightly considered.

> I'm not sure it's wise to create
> precedent that gives other entities like the ITU a back door to come
> after us for their clever ideas.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From jcurran at arin.net  Mon Jun 27 20:04:31 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 28 Jun 2011 00:04:31 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	for	IPv4 Address Extension - IAB comment
In-Reply-To: <02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
Message-ID: <51190B99-56C8-4D12-8DD4-A6968D2F9E60@arin.net>

On Jun 28, 2011, at 4:35 AM, Owen DeLong wrote:

> I believe there may be a fifth option.
> 
> I believe that the ISPs who need this space might be able to  form a consortium and
> use this as a standard justification to have the IPs registered to the consortium
> as an organization. It would be up to the consortium after that whether they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.
> 
> John Curran, could you please comment on whether such a request from
> a consortium for an allocation or assignment could be processed within
> staff interpretation of existing policy?

There is unlikely to be a consortium with the necessary allocation
history to warrant a /10 allocation per NRPM 4.2.4.  With respect 
to an end-user assignment, it is a difficult question.  First, 
one must determine whether this application is an "internal use" 
to see if the end-user policy in NRPM 4.3 is applicable.  If so,
and absent any utilization history, ARIN would assign the minimum
sized block (/20) and encourage the organization to come back for
more when utilization of the initial assignment has reached 80%.
There is some discretion within the end-user policy to provide a
larger initial allocation if clearly warranted, but this needs to 
be balanced against the conservation principle in RFC 2050 and the 
assignment of a /10 would obviously be completely unprecedented.
I will need to research the end-user option in more detail to see
if (and/or how) it applies; at this time I cannot be certain that 
it could be used for this purpose and still be true to existing
application of policy.

FYI,
/John

John Curran 
President and CEO
ARIN



From ipng at 69706e6720323030352d30312d31340a.nosense.org  Mon Jun 27 18:16:21 2011
From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith)
Date: Tue, 28 Jun 2011 07:46:21 +0930
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
Message-ID: <20110628074621.3a081659@opy.nosense.org>

On Mon, 27 Jun 2011 13:35:26 -0700
Owen DeLong <owen at delong.com> wrote:

> I believe there may be a fifth option.
> 
> I believe that the ISPs who need this space might be able to  form a consortium and
> use this as a standard justification to have the IPs registered to the consortium
> as an organization. It would be up to the consortium after that whether they
> expressed a willingness for non-members to make duplicate use of their
> address space for this purpose or not.
> 

This is the best way to solve this problem. It does not externalise the
costs of this allocation to those who don't need the space i.e. the
rest of the Internet community who don't have the particular problem
that the proponents of this proposal want to solve.

> John Curran, could you please comment on whether such a request from
> a consortium for an allocation or assignment could be processed within
> staff interpretation of existing policy?
> 
> Thoughts?
> 
> Owen
> 
> On Jun 27, 2011, at 10:43 AM, William Herrin wrote:
> 
> > On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net> wrote:
> >>> In keeping with the spirit of RFC 2860 with respect to the assignment
> >>> of specialized address blocks, ARIN Staff will consult with the IANA and
> >>> the IAB regarding implementation of this draft policy.
> >> 
> >>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
> >>> 
> >>> The IAB honors and values the division of responsibilities as
> >>> documented in RFC 2860 section 4.3. That section forms the basis for
> >>> Unicast address allocation via ICANN through the RIR system.
> >>> 
> >>> Policy proposal 2011-005 is not a regular proposal in the sense that
> >>> it adheres to Unicast space. In contrast, it allows for an allocation
> >>> of addresses for special and global use very similar to, and almost
> >>> indistinguishable from, RFC1918 local addresses. Because of the impact
> >>> beyond the ARIN region the management (i.e. creation
> >>> and subsequent changes) of such reservation should be global and RFC2860
> >>> puts the management responsibility with the IETF.
> >>> 
> >>> The IAB believes that the adoption by ARIN would be in conflict with the
> >>> provisions in RFC2860 and would set a bad precedent: Setting aside
> >>> special addresses should be done within the existing process, i.e. by
> >>> the IETF.
> >>> 
> >>> If there is consensus for 2011-005 in the ARIN region we would be
> >>> happy to work with you to resubmit the proposal to the IETF and, as
> >>> usual, have the IESG judge consensus. This would include our reaching
> >>> out to other RIRs to have members of their community provide input on
> >>> this proposal. Clear support from the various RIR communities might
> >>> bring new insights into to the IETF, producing a level of support that
> >>> was not present with the earlier drafts.
> > 
> > Hi Folks,
> > 
> > In light of the IAB's objection, it seems to me that the ARIN board
> > has four options to consider:
> > 
> > 1. Submit an internet draft as the IAB requests, along with the
> > implications of doing so.
> > 
> > 2. Implement 2011-5  as recommended by the AC and community, and over
> > the IAB's objection.
> > 
> > 3. Abandon 2011-5. Proponents may make their case to the IETF.
> > 
> > 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
> > 
> > 
> > 
> > 1. The case for complying with the IAB's request:
> > 
> > The Internet standards process works because of the cordial and
> > cooperative atmosphere between the various NGOs and individual
> > participants. The IETF is indeed the appropriate venue for global
> > assignment of IP addresses to specific purposes as opposed to specific
> > end users. However, we must observe that the IANA has insufficient
> > unicast (class A, B or C) addresses available to award the IETF for
> > the implementation of 2011-5's intended use.
> > 
> > Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> > hold it unused while championing an RFC through the IETF's standards
> > process that uses the /10 as contemplated in 2011-5. Upon publication
> > of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> > Upon a failure to reach consensus within the IETF process, the /10
> > would be returned to the ARIN free pool for general use.
> > 
> > 
> > 2. The case for implementing 2011-5 over the IAB's objection.
> > 
> > a. ARIN's constituents have expressed a well defined, well supported
> > and consensus need for addresses to be used similar like RFC1918 space
> > but with the expectation that such space crosses the administrative
> > boundary between ISP and end-user and should, thus, not be used by the
> > end-user.
> > 
> > b. The IETF had the opportunity to act on these constituents' concerns
> > but failed to take leadership citing, among other reasons, that it
> > would deplete the pool of addresses available to the RIRs from IANA.
> > 
> > c. The ARIN region is satisfied with depleting its own address pool
> > for this purpose.
> > 
> > d. The IAB's suggestion that the proposal be brought back to the IETF
> > is rendered disingenuous by the fact that no addresses remain at the
> > IANA for implementation.
> > 
> > e. Precedent exists for RIRs to unilaterally act on regional
> > imperatives despite potentially global impact. Witness APNIC's
> > abandonment of needs-based allocation.
> > 
> > Because of these points, ARIN has a moral duty to act on behalf of its
> > constituents. Should the IETF desire to reclaim leadership in this
> > matter, ARIN's open public policy process is available to all comers
> > who may request that the addresses be reassigned to any RFC that is
> > produced.
> > 
> > 
> > 3. The case for abandoning 2011-5:
> > 
> > The IETF is the proper venue for a proposal like 2011-5. Such
> > proposals were considered and rejected. 2011-5 is an end-run around
> > around the proper process.
> > 
> > 
> > 4. The case for 2011-5 as a stopgap pending IETF action:
> > 
> > ARIN constituents within the ARIN region have an immediate and
> > pressing need for IP addresses to be used for the interior of multiple
> > NAT translators. This need is not adequately served by the delay
> > inherent in initiating a fresh proposal in the IETF's standards
> > process, it is not adequately served by RFC1918 and it is poorly
> > served by having every ISP use its own unique space allocated by ARIN.
> > Due to the IETF's failure to act in a timely manner while addresses
> > were still available to them from IANA, ARIN has a duty to act on its
> > constituents' imperative.
> > 
> > Nevertheless, global assignment of addresses to purposes rather than
> > registrants properly belongs with the IETF. ARIN should facilitate the
> > IETF retaking the leadership on the matter by ending the ARIN-region
> > policy and ceding the /10 address block back to IANA after the IETF
> > debates, drafts and publishes an RFC that the board of trustees
> > believes meets or exceeds ARIN constituents' expectations for these
> > addresses.
> > 
> > 
> > For your consideration,
> > Bill Herrin
> > 
> > 
> > 
> > --
> > William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > Falls Church, VA 22042-3004
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Mon Jun 27 21:05:51 2011
From: farmer at umn.edu (David Farmer)
Date: Mon, 27 Jun 2011 20:05:51 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
Message-ID: <4E0928EF.8030702@umn.edu>

On 6/27/11 16:32 CDT, Benson Schliesser wrote:
>
> On Jun 27, 2011, at 12:43 PM, William Herrin wrote:
>> In light of the IAB's objection, it seems to me that the ARIN board
>> has four options to consider:
>>
>> 1. Submit an internet draft as the IAB requests, along with the
>> implications of doing so.
>>
>> 2. Implement 2011-5  as recommended by the AC and community, and over
>> the IAB's objection.
>>
>> 3. Abandon 2011-5. Proponents may make their case to the IETF.
>>
>> 4. Implement 2011-5 as a temporary stopgap policy pending further IETF action.
>>
>
> Thanks for your analysis, Bill - I think this was a good write-up.
>
> While I do agree with some of your conclusions in 2, in my opinion ARIN should first pursue option 1.  If we can collaboratively agree on the reservation of Shared Transition Space, that would be preferred over ARIN acting alone.  And if in the end the IETF and ARIN do not agree on this matter, we can consider choosing one of the other options at that time.
>
> Given how drawn-out these things can become, I would also recommend ARIN hold back a /10 in reserve, until the IETF process concludes.  In pursuing the IETF process, we should write a draft that indicates ARIN is willing to "donate" a /10 for this purpose.  It would also be great to get co-authors from each RIR region, to act as local points of contact (although, probably not representatives).
>
> Cheers,
> -Benson

I believe we should do a combination of #1 and #2.  Let me explain further;

I would like to request John and ARIN staff to investigate possible 
precedent documented in RFC 3849[1] by the allocation of 2001:DB8::/32 
by APNIC.  My interpretation of the text in the RFC is that APNIC passed 
a policy allocating a prefix for documentation purposes and then members 
of the APNIC community authored an Informational RFC documenting the 
allocation and the technical justifications to the IETF.

The second paragraph of section 2 of RFC 3849;

    Following acceptance within the Asia Pacific regional addressing
    community of a proposal for a block of IPv6 address space to be
    reserved for documentation purposes, the Asia Pacific Network
    Information Centre (APNIC) allocated a unicast address prefix for
    documentation purposes.  The address block is within the range of a
    conventional allocation size, so that documentation can accurately
    match deployment scenarios.

I believe my interpretation is supported by minutes of the address 
policy sig from APNIC14[2] and the original draft submitted 
"draft-huston-ipv6-documentation-prefix-00"[3].

Therefore, I would like to suggest representatives from the ARIN 
Community, and the ARIN AC, author and submit and Informational RFC 
documenting the allocation of the /10 per ARIN policy development 
process, including the technical details and justification surrounding 
it.  And, once the Draft is submitted, the board move forward with 
implementing 2011-5 based on the precedence of the allocation of 
2001:DB8::/32 by APNIC, as documented in RFC3849.  I believe RFC2860 is 
clear that the IETF has a role, and it is desirable and necessary that 
such an allocation should be documented in RFCs, but it is not clear to 
me that ARIN cannot and MUST not make such an allocation base on the 
clear policy will of its community, especially based on the precedent of 
RFC 3849.

References;

1. http://tools.ietf.org/html/rfc3849
2. http://archive.apnic.net/meetings/14/sigs/policy/minutes.html#7
3. http://tools.ietf.org/html/draft-huston-ipv6-documentation-prefix-00


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


From mysidia at gmail.com  Mon Jun 27 21:53:18 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 27 Jun 2011 20:53:18 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikOYnPmuZTJ80xH9t=rgSLrfh7wpA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<BANLkTikOYnPmuZTJ80xH9t=rgSLrfh7wpA@mail.gmail.com>
Message-ID: <BANLkTin1O1y_vcRYMKDByhnqk+2fu+9BaA@mail.gmail.com>

On Mon, Jun 27, 2011 at 6:14 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Jun 27, 2011 at 1:43 PM, William Herrin <bill at herrin.us> wrote:
> Personally, I'd like to see the board chart a course similar to option
> 4. Our ISPs need this address space NOW, not 3 years from now when
> their multilevel NAT deployments are done. However, ARIN does not
> provide the proper forum nor is the NRPM the proper mechanism to work
> through and document the technical details which are not, as
> previously mentioned, the same as RFC 1918. That forum will be found
> within the IETF.

I agree....  expeditious action is required, and IETFs' process is not
sufficiently
expeditious.

The most expedient thing to do is for ARIN to pass 2011-05 and handle
the allocation
of the shared network;  after all, ARIN itself is a consortium (of
resource holders)
anyways (sort of).

If a third party consortium were used,  ARIN could make a policy to
allow allocation of
a single /10 to a consortium meeting certain criteria -- but it's
simpler to just allocate the
block,  and then defer to the IETF to fully flesh out the usage of the
block / rules / standards
about when / where / why  addreses from the block should be used.

Another possibility would be to find a legacy holder willing to stand
up and publicly
promise a /10 for that purpose.

Anyways,  all methods of allocating a 'shared block' from ARIN non-legacy space
that require a consortium have
a problem  -- the consortium has to pay maintenance fees, and maintain contacts
for WHOIS, under current policy.    If the consortium falls apart, or
the money for
maintenance fees runs out,  then under policy, the address space could
be subject
to revokation.

This could be a stability risk, for users of shared space, or for
possible future
assignees.    It would seem to make  'have a consortium apply as an end user'
unacceptable.

'Shared use of a block' is not a standard utilization of IP address space;
end users cannot re-assign or allocate IPs for other users, and ISPs are
required to obtain a criterion of justification;  none of the policies
in the NRPM
address an LIR "Assigning addresses to _everyone_  for shared use"


The community needs are met more clearly, if it is at least be
official policy that the
assignment is permanent  and listed as shared in WHOIS  and other places.


Therefore, my suggestion is that ARIN pass 2011-05.   Reserve a /10
for shared use.
Inform members of the region of a block currently available and
permanently reserved
for shared use,  what that block is,  BUT  discourage actual
production use of the
block,  until the IETF has had an opportunity to review ARIN's draft
proposal for
the designation of the block & its intended purposes.

And list in WHOIS as such, but don't declare it a "special block" or
"reserved block"
officially.

After the block is fully reserved within the region,   submit a draft
under IETF standards
process, to request permanent official global recognition of the block, and IETF
management of it.

--
-JH


From david.kessens at nsn.com  Tue Jun 28 01:25:28 2011
From: david.kessens at nsn.com (David Kessens)
Date: Mon, 27 Jun 2011 22:25:28 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <4E0928EF.8030702@umn.edu>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
Message-ID: <20110628052528.GB23316@nsn.com>


David,

On Mon, Jun 27, 2011 at 08:05:51PM -0500, David Farmer wrote:
> 
> Therefore, I would like to suggest representatives from the ARIN
> Community, and the ARIN AC, author and submit and Informational RFC
> documenting the allocation of the /10 per ARIN policy development
> process, including the technical details and justification
> surrounding it.  And, once the Draft is submitted, the board move
> forward with implementing 2011-5 based on the precedence of the
> allocation of 2001:DB8::/32 by APNIC, as documented in RFC3849.  I
> believe RFC2860 is clear that the IETF has a role, and it is

I believe there is a rather significant difference between your reading of
the MoU between the IETF and ICANN and what it actually says:

It doesn't say that the IETF has 'a' role in this matter, it says the IETF
is responsible for 'assignment of specialised address blocks'.

David Kessens
---

> desirable and necessary that such an allocation should be documented
> in RFCs, but it is not clear to me that ARIN cannot and MUST not
> make such an allocation base on the clear policy will of its
> community, especially based on the precedent of RFC 3849.
> 
> References;
> 
> 1. http://tools.ietf.org/html/rfc3849
> 2. http://archive.apnic.net/meetings/14/sigs/policy/minutes.html#7
> 3. http://tools.ietf.org/html/draft-huston-ipv6-documentation-prefix-00
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota	
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bensons at queuefull.net  Tue Jun 28 02:24:04 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Tue, 28 Jun 2011 01:24:04 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <20110628052528.GB23316@nsn.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
Message-ID: <688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>


On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:

> I believe there is a rather significant difference between your reading of
> the MoU between the IETF and ICANN and what it actually says:
> 
> It doesn't say that the IETF has 'a' role in this matter, it says the IETF
> is responsible for 'assignment of specialised address blocks'.

One might argue that the Shared Transition Space isn't "specialized", in that it requires no protocol changes etc; it is merely an unusual administrative assignment. And if there is any purpose for ICANN and the RIRs, it is the administration of community resources. Thus I don't think it's unreasonable for an RIR to exercise mandate in this case. 

On the other hand, this would be a new / unique administrative category, and it would be ideal if the greater community was in consensus. Thus my previous recommendation that we (re)try the IETF, certainly before acting alone.

Cheers,
-Benson

>> 
>> 
>> 
>> 


From joelja at bogus.com  Tue Jun 28 02:43:05 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 27 Jun 2011 23:43:05 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
Message-ID: <CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>


On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:

> 
> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
> 
>> I believe there is a rather significant difference between your reading of
>> the MoU between the IETF and ICANN and what it actually says:
>> 
>> It doesn't say that the IETF has 'a' role in this matter, it says the IETF
>> is responsible for 'assignment of specialised address blocks'.
> 
> One might argue that the Shared Transition Space isn't "specialized", in that it requires no protocol changes etc; it is merely an unusual administrative assignment. And if there is any purpose for ICANN and the RIRs, it is the administration of community resources. Thus I don't think it's unreasonable for an RIR to exercise mandate in this case. 

It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.

> On the other hand, this would be a new / unique administrative category, and it would be ideal if the greater community was in consensus. Thus my previous recommendation that we (re)try the IETF, certainly before acting alone.
> 
> Cheers,
> -Benson
> 
>>> 
>>> 
>>> 
>>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From mysidia at gmail.com  Tue Jun 28 08:50:26 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 28 Jun 2011 07:50:26 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
Message-ID: <BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>

On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>
[snip]

What assumptions would those be?
The word 'private scope'  doesn't appear anywhere in the proposal.
If allocated it's shared use address space for service providers,
for their internal use,  by defintion that means any organization
meeting the criteria of Internet Service Provider could use space
in the /10 for non-conflicting uses inside their SP network.

That also means IP addresses in the shared range could be exposed
and visible to the service provider's end users. Their visibility
makes the addresses non-private;  specifically, they may appear in
traceroute output,  or  the user's  router might utilize a P2P link over this
"shared" address space, depending on how SPs choose to use the
addresses;  SP customers might be assigned IPs in this range and NAT'ed.

It's not just more special address space for private use.

Actually... the whole original reason for the proposal is it's  not
"special private address space",  to provide that the end user
is not already using it.    Some of the needed uses resemble RFC1918
address space usages,  but it is not a requirement served by private scope
address space.

It's that service providers really need a non-private address space available
that will not conflict with private networks using special address space.

Service providers'  intended use does not require uniqueness,  therefore
many IP addresses in the region will be conserved if one shared
allocation is issued, instead of each service provider needing to come in
and request global address space,  when shared address space would
be adequate.



--
-JH


From joelja at bogus.com  Tue Jun 28 10:50:58 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jun 2011 07:50:58 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
Message-ID: <047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>


On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:

> On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
>> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>> 
> [snip]
> 
> What assumptions would those be?

That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)

That an ipv4 unicast address can be used as source or destination for an auto-tunneling mechanism. 

Aa specific example of the later with an rfc-1918 address assignment an existing implmentation of 6to4 will simply fail, which is the desired behavior, in the case of a private scope address carved out of a new range it will assign itself a /64 and proceed to fire ipv6 traffic into a blackhole. existing 6to4 cpe cause enough breakage as it is without compounding it.

> The word 'private scope'  doesn't appear anywhere in the proposal.

If you can't advertise it into the dfz what other scope does it have?

you can see all this of course in the minutes when the proposal was discussed in v6ops.

http://www.ietf.org/proceedings/79/minutes/v6ops.txt




From kkargel at polartel.com  Tue Jun 28 11:45:19 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jun 2011 10:45:19 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <20110628074621.3a081659@opy.nosense.org>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<20110628074621.3a081659@opy.nosense.org>
Message-ID: <8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>



 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Mark Smith
> Sent: Monday, June 27, 2011 5:16 PM
> To: Owen DeLong
> Cc: John Curran; arin-ppml at arin.net List
> Subject: Re: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
> IPv4 Address Extension - IAB comment
> 
> On Mon, 27 Jun 2011 13:35:26 -0700
> Owen DeLong <owen at delong.com> wrote:
> 
> > I believe there may be a fifth option.
> >
> > I believe that the ISPs who need this space might be able to  form a
> consortium and
> > use this as a standard justification to have the IPs registered to the
> consortium
> > as an organization. It would be up to the consortium after that whether
> they
> > expressed a willingness for non-members to make duplicate use of their
> > address space for this purpose or not.
> >

Maybe if we asked nicely Microsoft would set aside a /10 of their new IP's for five years to allow the community to use it for this purpose.  ;)  OK, that was more than a little tongue in cheek, but it would be a good PR effort for them.


> 
> This is the best way to solve this problem. It does not externalise the
> costs of this allocation to those who don't need the space i.e. the
> rest of the Internet community who don't have the particular problem
> that the proponents of this proposal want to solve.
> 
> > John Curran, could you please comment on whether such a request from
> > a consortium for an allocation or assignment could be processed within
> > staff interpretation of existing policy?
> >
> > Thoughts?
> >
> > Owen
> >
> > On Jun 27, 2011, at 10:43 AM, William Herrin wrote:
> >
> > > On Sat, Jun 25, 2011 at 11:11 PM, John Curran <jcurran at arin.net>
> wrote:
> > >>> In keeping with the spirit of RFC 2860 with respect to the
> assignment
> > >>> of specialized address blocks, ARIN Staff will consult with the IANA
> and
> > >>> the IAB regarding implementation of this draft policy.
> > >>
> > >>> == A Procedural Issue: ARINA 2011-005 and RFC2860 section 4.3 ==
> > >>>
> > >>> The IAB honors and values the division of responsibilities as
> > >>> documented in RFC 2860 section 4.3. That section forms the basis for
> > >>> Unicast address allocation via ICANN through the RIR system.
> > >>>
> > >>> Policy proposal 2011-005 is not a regular proposal in the sense that
> > >>> it adheres to Unicast space. In contrast, it allows for an
> allocation
> > >>> of addresses for special and global use very similar to, and almost
> > >>> indistinguishable from, RFC1918 local addresses. Because of the
> impact
> > >>> beyond the ARIN region the management (i.e. creation
> > >>> and subsequent changes) of such reservation should be global and
> RFC2860
> > >>> puts the management responsibility with the IETF.
> > >>>
> > >>> The IAB believes that the adoption by ARIN would be in conflict with
> the
> > >>> provisions in RFC2860 and would set a bad precedent: Setting aside
> > >>> special addresses should be done within the existing process, i.e.
> by
> > >>> the IETF.
> > >>>
> > >>> If there is consensus for 2011-005 in the ARIN region we would be
> > >>> happy to work with you to resubmit the proposal to the IETF and, as
> > >>> usual, have the IESG judge consensus. This would include our
> reaching
> > >>> out to other RIRs to have members of their community provide input
> on
> > >>> this proposal. Clear support from the various RIR communities might
> > >>> bring new insights into to the IETF, producing a level of support
> that
> > >>> was not present with the earlier drafts.
> > >
> > > Hi Folks,
> > >
> > > In light of the IAB's objection, it seems to me that the ARIN board
> > > has four options to consider:
> > >
> > > 1. Submit an internet draft as the IAB requests, along with the
> > > implications of doing so.
> > >
> > > 2. Implement 2011-5  as recommended by the AC and community, and over
> > > the IAB's objection.
> > >
> > > 3. Abandon 2011-5. Proponents may make their case to the IETF.
> > >
> > > 4. Implement 2011-5 as a temporary stopgap policy pending further IETF
> action.
> > >
> > >
> > >
> > > 1. The case for complying with the IAB's request:
> > >
> > > The Internet standards process works because of the cordial and
> > > cooperative atmosphere between the various NGOs and individual
> > > participants. The IETF is indeed the appropriate venue for global
> > > assignment of IP addresses to specific purposes as opposed to specific
> > > end users. However, we must observe that the IANA has insufficient
> > > unicast (class A, B or C) addresses available to award the IETF for
> > > the implementation of 2011-5's intended use.
> > >
> > > Accordingly, ARIN should reserve the /10 that 2011-5 calls for and
> > > hold it unused while championing an RFC through the IETF's standards
> > > process that uses the /10 as contemplated in 2011-5. Upon publication
> > > of such an RFC, the /10 would be ceded to IANA for use with the RFC.
> > > Upon a failure to reach consensus within the IETF process, the /10
> > > would be returned to the ARIN free pool for general use.
> > >
> > >
> > > 2. The case for implementing 2011-5 over the IAB's objection.
> > >
> > > a. ARIN's constituents have expressed a well defined, well supported
> > > and consensus need for addresses to be used similar like RFC1918 space
> > > but with the expectation that such space crosses the administrative
> > > boundary between ISP and end-user and should, thus, not be used by the
> > > end-user.
> > >
> > > b. The IETF had the opportunity to act on these constituents' concerns
> > > but failed to take leadership citing, among other reasons, that it
> > > would deplete the pool of addresses available to the RIRs from IANA.
> > >
> > > c. The ARIN region is satisfied with depleting its own address pool
> > > for this purpose.
> > >
> > > d. The IAB's suggestion that the proposal be brought back to the IETF
> > > is rendered disingenuous by the fact that no addresses remain at the
> > > IANA for implementation.
> > >
> > > e. Precedent exists for RIRs to unilaterally act on regional
> > > imperatives despite potentially global impact. Witness APNIC's
> > > abandonment of needs-based allocation.
> > >
> > > Because of these points, ARIN has a moral duty to act on behalf of its
> > > constituents. Should the IETF desire to reclaim leadership in this
> > > matter, ARIN's open public policy process is available to all comers
> > > who may request that the addresses be reassigned to any RFC that is
> > > produced.
> > >
> > >
> > > 3. The case for abandoning 2011-5:
> > >
> > > The IETF is the proper venue for a proposal like 2011-5. Such
> > > proposals were considered and rejected. 2011-5 is an end-run around
> > > around the proper process.
> > >
> > >
> > > 4. The case for 2011-5 as a stopgap pending IETF action:
> > >
> > > ARIN constituents within the ARIN region have an immediate and
> > > pressing need for IP addresses to be used for the interior of multiple
> > > NAT translators. This need is not adequately served by the delay
> > > inherent in initiating a fresh proposal in the IETF's standards
> > > process, it is not adequately served by RFC1918 and it is poorly
> > > served by having every ISP use its own unique space allocated by ARIN.
> > > Due to the IETF's failure to act in a timely manner while addresses
> > > were still available to them from IANA, ARIN has a duty to act on its
> > > constituents' imperative.
> > >
> > > Nevertheless, global assignment of addresses to purposes rather than
> > > registrants properly belongs with the IETF. ARIN should facilitate the
> > > IETF retaking the leadership on the matter by ending the ARIN-region
> > > policy and ceding the /10 address block back to IANA after the IETF
> > > debates, drafts and publishes an RFC that the board of trustees
> > > believes meets or exceeds ARIN constituents' expectations for these
> > > addresses.
> > >
> > >
> > > For your consideration,
> > > Bill Herrin
> > >
> > >
> > >
> > > --
> > > William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> > > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > > Falls Church, VA 22042-3004
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bill at herrin.us  Tue Jun 28 11:48:42 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jun 2011 11:48:42 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
Message-ID: <BANLkTi=snEc-gbF0aCtFvTKBWdbO3kV3ZQ@mail.gmail.com>

On Tue, Jun 28, 2011 at 10:50 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
>> On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>>>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
>>> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>>>
>> [snip]
>>
>> What assumptions would those be?
>
> That a port mapped to a the outside of a cpe which does not
> have an rfc 1918 address will in fact be reachable (example
> by upnp or nat pmp)

That's ASS-U-ME assumption. Lots of places uses non-RFC1918 addresses
inside their NATs and those which don't often have other forms of
filtering and firewalling which obstruct global reachability inbound.

You can only assume the opposite - that a port mapped on an RFC1918
address won't be globally reachable. Nothing in proposal 2011-5 breaks
that assumption.

> That an ipv4 unicast address can be used as source or
> destination for an auto-tunneling mechanism.

And again.


> Aa specific example of the later with an rfc-1918 address
>assignment an existing implmentation of 6to4 will simply
>fail, which is the desired behavior

No, actually, it is not the desired behavior, at least not by me. In
fact, it obstructs the use of 6to4 on private networks where it could
otherwise facilitate a staged IPv6 rollout. I ran in to this, much to
my frustration, back when I was tinkering with 6to4.

If there's a case where a device or protocol should make positive
assumptions about global reachability based on its assigned IP
address, I haven't heard it yet.

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  Tue Jun 28 11:51:38 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 28 Jun 2011 11:51:38 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<20110628074621.3a081659@opy.nosense.org>
	<8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>
Message-ID: <BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>

On Tue, Jun 28, 2011 at 11:45 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>
>

[ snip ]

>> > I believe that the ISPs who need this space might be able to ?form a
>> consortium and
>> > use this as a standard justification to have the IPs registered to the
>> consortium
>> > as an organization. It would be up to the consortium after that whether
>> they
>> > expressed a willingness for non-members to make duplicate use of their
>> > address space for this purpose or not.
>> >
>
> Maybe if we asked nicely Microsoft would set aside a /10 of their new IP's for five years to allow the community to use it for this purpose. ?;) ?OK, that was more than a little tongue in cheek, but it would be a good PR effort for them.
>


I would think that either ARIN can move forward with the policy
"as-is" or it can't. If it can't, there's no mechanism that I can see
that allows a 'donation' of the address space to such an activity. I'm
not disagreeing that this should move forward _in the IETF_, but
shouldn't the IETF find the addresses for this from what's available,
including striking a deal with the RIR's? Hence, my comment regarding
"various registries" as the source of the addresses seemed like a
reasonable candidate.

Best,

-M<


From joelja at bogus.com  Tue Jun 28 12:04:21 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jun 2011 09:04:21 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTi=snEc-gbF0aCtFvTKBWdbO3kV3ZQ@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTi=snEc-gbF0aCtFvTKBWdbO3kV3ZQ@mail.gmail.com>
Message-ID: <E110C4CF-2B36-4667-99FB-2ABCB6AE3567@bogus.com>


On Jun 28, 2011, at 8:48 AM, William Herrin wrote:

> On Tue, Jun 28, 2011 at 10:50 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
>>> On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>>> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>>>>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
>>>> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>>>> 
>>> [snip]
>>> 
>>> What assumptions would those be?
>> 
>> That a port mapped to a the outside of a cpe which does not
>> have an rfc 1918 address will in fact be reachable (example
>> by upnp or nat pmp)
> 
> That's ASS-U-ME assumption. Lots of places uses non-RFC1918 addresses
> inside their NATs and those which don't often have other forms of
> filtering and firewalling which obstruct global reachability inbound.

we're not talking about lots of places. we're talking specifically about the behavior of residential CPE, which this prefix assignment is proposed to address.

> You can only assume the opposite - that a port mapped on an RFC1918
> address won't be globally reachable. Nothing in proposal 2011-5 breaks
> that assumption.

it creates an new address range which is not addressed in existing CPE and fundamentally this prefix is about not colliding with the behavior of existing cpe.

>> That an ipv4 unicast address can be used as source or
>> destination for an auto-tunneling mechanism.
> 
> And again.
> 
> 
>> Aa specific example of the later with an rfc-1918 address
>> assignment an existing implmentation of 6to4 will simply
>> fail, which is the desired behavior
> 
> No, actually, it is not the desired behavior, at least not by me. In
> fact, it obstructs the use of 6to4 on private networks where it could
> otherwise facilitate a staged IPv6 rollout.

It is the behavior defined in rfc 3056/3068 more to the point existing cpe that implement 6to4 generally honor this.


> I ran in to this, much to
> my frustration, back when I was tinkering with 6to4.

> If there's a case where a device or protocol should make positive
> assumptions about global reachability based on its assigned IP
> address, I haven't heard it yet.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> 



From mike at nationwideinc.com  Tue Jun 28 12:17:53 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 28 Jun 2011 12:17:53 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com><02E
	AF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com><20110628074621.3a081659@opy.nosense.org><8695009A81378E48879980039EEDAD28010E9EC9
	77@MAIL1.polartel.local>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
Message-ID: <7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>


>> >
>
> Maybe if we asked nicely Microsoft would set aside a /10 of their new IP's 
> for five years to allow the community to use it for this purpose. ;) OK, 
> that was more than a little tongue in cheek, but it would be a good PR 
> effort for them.
>

A /10 is 4 million addresses, 10 times more than MS received from the 
initial transfer.
Does it really need to be this big?






From bill at herrin.us  Tue Jun 28 12:38:35 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jun 2011 12:38:35 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
 forIPv4 Address Extension - IAB comment
In-Reply-To: <7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20110628074621.3a081659@opy.nosense.org>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
	<7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>
Message-ID: <BANLkTimMywAMfnXuYNUK=cW+04BOX1qCXA@mail.gmail.com>

On Tue, Jun 28, 2011 at 12:17 PM, Mike Burns <mike at nationwideinc.com> wrote:
> A /10 is 4 million addresses, 10 times more than MS received from the
> initial transfer.
> Does it really need to be this big?

Hi Mike,

Even at that size its use will require some partitioned routing at the
larger service providers so that they can employ the same addresses in
multiple locations within their network. /10 is a compromise value;
the original request was for a /8.

At any rate, the size is no longer at issue. The IAB's objection does
not change based on the size of the address block and we reached
consensus on carving out a /10 from ARIN's address pool.

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 cgrundemann at gmail.com  Tue Jun 28 12:39:23 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jun 2011 10:39:23 -0600
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
 forIPv4 Address Extension - IAB comment
In-Reply-To: <7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20110628074621.3a081659@opy.nosense.org>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
	<7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>
Message-ID: <BANLkTinFz3FRKFMkVFG64Me4pitw0cS5NQ@mail.gmail.com>

On Tue, Jun 28, 2011 at 10:17, Mike Burns <mike at nationwideinc.com> wrote:
>
>
> A /10 is 4 million addresses, 10 times more than MS received from the
> initial transfer.
> Does it really need to be this big?

To be most effective, a network operator needs one address per
subscriber. For many operators a /10 is not nearly big enough to
accomplish this - it is big enough for most however, thus striking a
fairly reasonable balance, IMHO.

~Chris


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



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


From joelja at bogus.com  Tue Jun 28 12:44:09 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jun 2011 09:44:09 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinFz3FRKFMkVFG64Me4pitw0cS5NQ@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20110628074621.3a081659@opy.nosense.org>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
	<7EDD7C0D834C47D2B0D3ED3FFB9C6EEC@mike>
	<BANLkTinFz3FRKFMkVFG64Me4pitw0cS5NQ@mail.gmail.com>
Message-ID: <36395AA9-2DF2-41C4-A3E4-242EB0578F9F@bogus.com>


On Jun 28, 2011, at 9:39 AM, Chris Grundemann wrote:

> On Tue, Jun 28, 2011 at 10:17, Mike Burns <mike at nationwideinc.com> wrote:
>> 
>> 
>> A /10 is 4 million addresses, 10 times more than MS received from the
>> initial transfer.
>> Does it really need to be this big?
> 
> To be most effective, a network operator needs one address per
> subscriber. For many operators a /10 is not nearly big enough to
> accomplish this - it is big enough for most however, thus striking a
> fairly reasonable balance, IMHO

http://archive.apnic.net/meetings/25/program/policy/ashisa-prop58-share.pdf

> ~Chris
> 
> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> 
> 
> 
> -- 
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.theIPv6experts.net
> www.coisoc.org
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From owen at delong.com  Tue Jun 28 12:47:23 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Jun 2011 09:47:23 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
Message-ID: <503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>


On Jun 28, 2011, at 7:50 AM, Joel Jaeggli wrote:

> 
> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
> 
>> On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>>>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
>>> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>>> 
>> [snip]
>> 
>> What assumptions would those be?
> 
> That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)
> 
That assumption is going to break under LSN no matter what. Providers aren't going to use 1918 space for this, so, it's fail regardless. The question with this policy isn't this space or RFC-1918, it's whether we set aside one block of space for this purpose or force each provider to use their own block of GUA for this purpose.

IMNSHO, it's much more efficient for multiple providers to share a single block than it is for each provider to get their own block.

> That an ipv4 unicast address can be used as source or destination for an auto-tunneling mechanism. 
> 

That assumption will also fail under LSN for the reasons mentioned above.

> Aa specific example of the later with an rfc-1918 address assignment an existing implmentation of 6to4 will simply fail, which is the desired behavior, in the case of a private scope address carved out of a new range it will assign itself a /64 and proceed to fire ipv6 traffic into a blackhole. existing 6to4 cpe cause enough breakage as it is without compounding it.
> 

This is going to suck in the LSN world. There's no way around that. At least if we have a specific block set aside for it, it MIGHT get added to CPE firmware updates.
If we force ISPs to each use their own block, not only do we waste vastly more addresses, but, we also make it impossible for firmware updates to address these issues.

>> The word 'private scope'  doesn't appear anywhere in the proposal.
> 
> If you can't advertise it into the dfz what other scope does it have?
> 
There are multiple possible administrative boundaries between private and global. The fact that IETF doesn't recognize this reality does not prevent the reality from existing.

> you can see all this of course in the minutes when the proposal was discussed in v6ops.
> 
> http://www.ietf.org/proceedings/79/minutes/v6ops.txt
> 

Why was an IPv4 address space proposal given to v6ops?

Owen



From owen at delong.com  Tue Jun 28 12:52:49 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Jun 2011 09:52:49 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<20110628074621.3a081659@opy.nosense.org>
	<8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
Message-ID: <04E0055C-9662-4E9F-BA13-F667557ED2D3@delong.com>


On Jun 28, 2011, at 8:51 AM, Martin Hannigan wrote:

> On Tue, Jun 28, 2011 at 11:45 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>> 
>> 
> 
> [ snip ]
> 
>>>> I believe that the ISPs who need this space might be able to  form a
>>> consortium and
>>>> use this as a standard justification to have the IPs registered to the
>>> consortium
>>>> as an organization. It would be up to the consortium after that whether
>>> they
>>>> expressed a willingness for non-members to make duplicate use of their
>>>> address space for this purpose or not.
>>>> 
>> 
>> Maybe if we asked nicely Microsoft would set aside a /10 of their new IP's for five years to allow the community to use it for this purpose.  ;)  OK, that was more than a little tongue in cheek, but it would be a good PR effort for them.
>> 
> 
> 
> I would think that either ARIN can move forward with the policy
> "as-is" or it can't. If it can't, there's no mechanism that I can see
> that allows a 'donation' of the address space to such an activity. I'm
> not disagreeing that this should move forward _in the IETF_, but
> shouldn't the IETF find the addresses for this from what's available,
> including striking a deal with the RIR's? Hence, my comment regarding
> "various registries" as the source of the addresses seemed like a
> reasonable candidate.
> 

Actually, if I had a /10 laying around and made a public announcemnet
of:

	1.	I promise not to use these addresses in a manner that will
		conflict with people using it for this purpose.

	2.	I will inform the community with as much notice as possible
		before giving up the address space.

It would pretty much work as a donation. I don't have a /10 laying around
I could do that with, but, yes, whether as a matter of strict policy or not,
such a donation would be possible from a purely pragmatic perspective.

The willingness of others to depend on such a donation would, of course,
be somewhat variable.

Owen




From bill at herrin.us  Tue Jun 28 13:08:12 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jun 2011 13:08:12 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
Message-ID: <BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>

On Tue, Jun 28, 2011 at 12:47 PM, Owen DeLong <owen at delong.com> wrote:
> On Jun 28, 2011, at 7:50 AM, Joel Jaeggli wrote:
>> you can see all this of course in the minutes when the proposal was discussed in v6ops.
>> http://www.ietf.org/proceedings/79/minutes/v6ops.txt
>
> Why was an IPv4 address space proposal given to v6ops?

IETF v6ops could also use some help on the web side. This is a UTF-8
document with unix end of lines being sent as text/plain with no
charset. Unless the browser violates standards and makes a guess about
what sort of document was sent, it comes up unreadable.

Which is ironic since we're talking about protocols making (poor)
guesses about what they can do depending on the assigned IP address.

Regards,
Bill Herrin


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


From jcurran at arin.net  Tue Jun 28 13:23:09 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 28 Jun 2011 17:23:09 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<20110628074621.3a081659@opy.nosense.org>
	<8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
Message-ID: <92019E0E-1B21-4E19-84CB-3896D5411114@corp.arin.net>

On Jun 28, 2011, at 4:51 PM, Martin Hannigan wrote:
> I would think that either ARIN can move forward with the policy
> "as-is" or it can't. If it can't, there's no mechanism that I can see
> that allows a 'donation' of the address space to such an activity. I'm
> not disagreeing that this should move forward _in the IETF_, but
> shouldn't the IETF find the addresses for this from what's available,
> including striking a deal with the RIR's? Hence, my comment regarding
> "various registries" as the source of the addresses seemed like a
> reasonable candidate.

Martin -

In light of the existing support already expressed by the ARIN 
community for this reservation, it is quite possible that the 
ARIN Board could direct a /10 block by reserved for this purpose, 
if the discussions appear to be making progress within the IETF 
process.

The main point is to make sure that that we have rough consensus 
within the greater community (i.e. both IETF and ARIN) so that 
this reservation can proceed at all.  The mechanics do need to 
be worked out, but there's quite a few ways for that to occur if
there is overall agreement on the outcome.

FYI,
/John

John Curran
President and CEO
ARIN



From joelja at bogus.com  Tue Jun 28 13:24:28 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jun 2011 10:24:28 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
	<BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
Message-ID: <E2F63A4C-4DDB-4376-A39D-251ACAE96DF7@bogus.com>


On Jun 28, 2011, at 10:08 AM, William Herrin wrote:

> On Tue, Jun 28, 2011 at 12:47 PM, Owen DeLong <owen at delong.com> wrote:
>> On Jun 28, 2011, at 7:50 AM, Joel Jaeggli wrote:
>>> you can see all this of course in the minutes when the proposal was discussed in v6ops.
>>> http://www.ietf.org/proceedings/79/minutes/v6ops.txt
>> 
>> Why was an IPv4 address space proposal given to v6ops?

it was given time early in the week at opsawg, and subsequently in the last meeting of v6ops.

http://www.ietf.org/proceedings/79/minutes/opsawg.txt

> IETF v6ops could also use some help on the web side. This is a UTF-8
> document with unix end of lines being sent as text/plain with no
> charset. Unless the browser violates standards and makes a guess about
> what sort of document was sent, it comes up unreadable.
> 
> Which is ironic since we're talking about protocols making (poor)
> guesses about what they can do depending on the assigned IP address.

you can google a better copy, or listen to the recording or you can complain that someone bothered to record the discussion for the purpose of producing a record.

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



From tedm at ipinc.net  Tue Jun 28 13:29:17 2011
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jun 2011 10:29:17 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
	<BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
Message-ID: <4E0A0F6D.7000309@ipinc.net>

On 6/28/2011 10:08 AM, William Herrin wrote:
> On Tue, Jun 28, 2011 at 12:47 PM, Owen DeLong<owen at delong.com>  wrote:
>> On Jun 28, 2011, at 7:50 AM, Joel Jaeggli wrote:
>>> you can see all this of course in the minutes when the proposal was discussed in v6ops.
>>> http://www.ietf.org/proceedings/79/minutes/v6ops.txt
>>
>> Why was an IPv4 address space proposal given to v6ops?
>
> IETF v6ops could also use some help on the web side. This is a UTF-8
> document with unix end of lines being sent as text/plain with no
> charset. Unless the browser violates standards and makes a guess about
> what sort of document was sent, it comes up unreadable.
>

It displays fine in Internet Explorer.  You can also right-click and
save it to a directory and use vi to read it.

> Which is ironic since we're talking about protocols making (poor)
> guesses about what they can do depending on the assigned IP address.
>

Ironic but not surprising.  I used to admin at a software development 
company that wrote networking software that ran on UNIX but the 
programmers had absolutely no understanding of how a UNIX system was 
administered.

Everyone has their specialties.  Few ever raise their eyes to look
beyond them.  Have you ever replaced the fuel filter in your car?
Do you know if it is due for it?

Ted

> Regards,
> Bill Herrin
>
>



From jmaimon at chl.com  Tue Jun 28 13:47:39 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 28 Jun 2011 13:47:39 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <92019E0E-1B21-4E19-84CB-3896D5411114@corp.arin.net>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>	<20110628074621.3a081659@opy.nosense.org>	<8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
	<92019E0E-1B21-4E19-84CB-3896D5411114@corp.arin.net>
Message-ID: <4E0A13BB.3070603@chl.com>



John Curran wrote:
> On Jun 28, 2011, at 4:51 PM, Martin Hannigan wrote:
>> I would think that either ARIN can move forward with the policy
>> "as-is" or it can't. If it can't, there's no mechanism that I can see
>> that allows a 'donation' of the address space to such an activity. I'm
>> not disagreeing that this should move forward _in the IETF_, but
>> shouldn't the IETF find the addresses for this from what's available,
>> including striking a deal with the RIR's? Hence, my comment regarding
>> "various registries" as the source of the addresses seemed like a
>> reasonable candidate.
>
> Martin -
>
> In light of the existing support already expressed by the ARIN
> community for this reservation, it is quite possible that the
> ARIN Board could direct a /10 block by reserved for this purpose,
> if the discussions appear to be making progress within the IETF
> process.
>
> The main point is to make sure that that we have rough consensus
> within the greater community (i.e. both IETF and ARIN) so that
> this reservation can proceed at all.  The mechanics do need to
> be worked out, but there's quite a few ways for that to occur if
> there is overall agreement on the outcome.
>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN


I am all in favor of reserving space. I am not in favor of attaching 
specific purpose to the reservation, since that risks creating a facts 
on the ground scenario that in essence dictates the nature of the space.

Joe


From info at arin.net  Tue Jun 28 13:48:38 2011
From: info at arin.net (ARIN)
Date: Tue, 28 Jun 2011 13:48:38 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - June 2011
Message-ID: <4E0A13F6.9020605@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 16 June 2011 and made decisions about
several proposals.

The following proposals have been added to the AC's docket for
development and evaluation:

   ARIN-prop-149 Improved Transparency for Directed Transfers
   ARIN-prop-151 Limiting needs requirements for IPv4 Transfers
   ARIN-prop-152 RSA Modification Limits
   ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

The AC abandoned the following proposals:

   ARIN-prop-148 LRSA resources must not be transferred to LRSA
   ARIN-prop-150 Reclamation Hold

Proposal 148 was abandoned because the majority of the AC members feel 
that which legal agreement ARIN uses with a resource requester is a 
business matter. It is indeed the case, however, that if the community 
feels there should be certain policy requirements for what is in an RSA, 
LRSA or similar document that those could be specified in policy. This 
would require ARIN to put those items in any agreement where applicable 
and allowed by law.  The AC felt that ARIN-prop-152 was an example of 
such a policy proposal, and voted to accept it onto the AC's docket for 
further development.

The Advisory Council has abandoned Proposal 150 based on the merits of 
the proposal and the author's stated desired to have it withdrawn.

The AC thanks the authors and the community for their continuing effort
and contributions to these and all other policy considerations.

The AC abandoned proposals 148 and 150. Anyone dissatisfied with these 
decisions may initiate a petition. The petition to advance these 
proposals would be the "Discussion Petition." The deadline to begin a 
petition will be five business days after the AC's draft meeting minutes 
are published. For more information on starting and participating in 
petitions, see PDP Petitions at:
https://www.arin.net/policy/pdp_petitions.html

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

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

Regards,

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





From jmaimon at chl.com  Tue Jun 28 13:55:15 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 28 Jun 2011 13:55:15 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
Message-ID: <4E0A1583.3020801@chl.com>



William Herrin wrote:


> Hi Folks,
>
> In light of the IAB's objection, it seems to me that the ARIN board
> has four options to consider:
>


Hey Folks,

In light of the IAB's objections, I invite the parties in favor of this 
policy and desirous of utilizing the approach advocated by this policy 
to consider moving forward as a group to implement this solution with 
purpose tailored constructs and resources.

Form a consortium. Use 8.3 space to "fund it" or just simply assign the 
space to the consortium. Build your running code and then gain your 
rough consensus.

Since responsibility to number the users of its members then rests with 
the consortium, I cannot fathom it not meeting needs-based justification 
requirements.

In fact this option could prove to be superior to the consortium 
members, since authority to utilize the numbers would come from the 
consortium and as such does not become rfc1918 equivalent. Documentation 
and accountability remains possible.

Nobody needs rfc permission to number multiple hosts under their 
authority with the same numbers.

Structuring membership in the consortium as returning access to more 
resources than you kicked in should provide plenty of self sufficiency.

Except of course, if potential members discover that they prefer to keep 
their global unicast space globally unicastable and instead utilize 
portions of rfc1918 or otherwise non globally unicasted space for the 
purpose.


Joe



From bill at herrin.us  Tue Jun 28 14:25:26 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jun 2011 14:25:26 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <4E0A0F6D.7000309@ipinc.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
	<BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
	<4E0A0F6D.7000309@ipinc.net>
Message-ID: <BANLkTinCbBePAfZ5w7AYQt3wYpKoojgRhg@mail.gmail.com>

On Tue, Jun 28, 2011 at 1:29 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 6/28/2011 10:08 AM, William Herrin wrote:
>> IETF v6ops could also use some help on the web side. This is a UTF-8
>> document with unix end of lines being sent as text/plain with no
>> charset. Unless the browser violates standards and makes a guess about
>> what sort of document was sent, it comes up unreadable.
>
> It displays fine in Internet Explorer. ?You can also right-click and
> save it to a directory and use vi to read it.

And it doesn't in Firefox. If nobody tried to guess, if everybody
rendered it as instructed, then the person who posted the document
would have immediately realized the mistake -- and fixed it. Instead
we have random brokenness.

Just like with Joel's assumption that a non-RFC1918 IP address means
global reachability.


>> Which is ironic since we're talking about protocols making (poor)
>> guesses about what they can do depending on the assigned IP address.
>
> Ironic but not surprising. ?I used to admin at a software development
> company that wrote networking software that ran on UNIX but the programmers
> had absolutely no understanding of how a UNIX system was administered.
>
> Everyone has their specialties. ?Few ever raise their eyes to look
> beyond them. ?Have you ever replaced the fuel filter in your car?

No, but I've changed a power steering pump. Mostly, I take the car in
for service and ask the technician to explain his recommendations.
Unless something raises a red flag for me, I then follow the
recommendation because those are the guys who know.

Which is also relevant here - RIRs like ARIN are the centers of
knowledge for operational addressing needs. While the IETF is
certainly the right organization to work out the technical details of
a shared address space, the protocol level musts and must nots,
they're a poor choice of organization to determine -whether- there's
an operational need for an address space with 2011-5's parameters or
-how much- address space should be dedicated to it. They don't draw
those experts. We do.

Regards,
Bill Herrin



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


From kkargel at polartel.com  Tue Jun 28 14:29:22 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jun 2011 13:29:22 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <04E0055C-9662-4E9F-BA13-F667557ED2D3@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<02EAF6A3-54FE-45FA-A83D-A10662C1A41F@delong.com>
	<20110628074621.3a081659@opy.nosense.org>
	<8695009A81378E48879980039EEDAD28010E9EC977@MAIL1.polartel.local>
	<BANLkTikA09SzCHgvcFgCm6+cmnEjSiZ_jg@mail.gmail.com>
	<04E0055C-9662-4E9F-BA13-F667557ED2D3@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD28010E9EC97B@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Tuesday, June 28, 2011 11:53 AM
> To: Martin Hannigan
> Cc: Kevin Kargel; arin-ppml at arin.net List
> Subject: Re: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
> IPv4 Address Extension - IAB comment
> 
> 
> On Jun 28, 2011, at 8:51 AM, Martin Hannigan wrote:
> 
> > On Tue, Jun 28, 2011 at 11:45 AM, Kevin Kargel <kkargel at polartel.com>
> wrote:
> >>
> >>
> >
> > [ snip ]
> >
> >>>> I believe that the ISPs who need this space might be able to  form a
> >>> consortium and
> >>>> use this as a standard justification to have the IPs registered to
> the
> >>> consortium
> >>>> as an organization. It would be up to the consortium after that
> whether
> >>> they
> >>>> expressed a willingness for non-members to make duplicate use of
> their
> >>>> address space for this purpose or not.
> >>>>
> >>
> >> Maybe if we asked nicely Microsoft would set aside a /10 of their new
> IP's for five years to allow the community to use it for this purpose.  ;)
> OK, that was more than a little tongue in cheek, but it would be a good PR
> effort for them.
> >>
> >
> >
> > I would think that either ARIN can move forward with the policy
> > "as-is" or it can't. If it can't, there's no mechanism that I can see
> > that allows a 'donation' of the address space to such an activity. I'm
> > not disagreeing that this should move forward _in the IETF_, but
> > shouldn't the IETF find the addresses for this from what's available,
> > including striking a deal with the RIR's? Hence, my comment regarding
> > "various registries" as the source of the addresses seemed like a
> > reasonable candidate.
> >
> 
> Actually, if I had a /10 laying around and made a public announcemnet
> of:
> 
> 	1.	I promise not to use these addresses in a manner that will
> 		conflict with people using it for this purpose.
> 
> 	2.	I will inform the community with as much notice as possible
> 		before giving up the address space.
> 
> It would pretty much work as a donation. I don't have a /10 laying around
> I could do that with, but, yes, whether as a matter of strict policy or
> not,
> such a donation would be possible from a purely pragmatic perspective.
> 
> The willingness of others to depend on such a donation would, of course,
> be somewhat variable.
> 
> Owen
> 
Putting out a public call for assistance might actually not be the dumbest idea we ever had.  According to tribal lore on the list there are at least a few orgs sitting on /8's that are not being efficiently (or even minimally) used.  If one of those orgs volunteered a /10 of that space for a calendar period it would certainly lock in their "ownership" (or at least garner some community gratitude) and keep the space from being considered for reclamation when the vultures start circling in the ends of days.  

All it would take would be a public commitment from the blockholder that they would not publically route the netblock for X years.

OK legacy holders, who wants to step up and save the world?  :D

Kevin





From wesley.george at twcable.com  Tue Jun 28 16:31:01 2011
From: wesley.george at twcable.com (George, Wesley)
Date: Tue, 28 Jun 2011 16:31:01 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	for	IPv4 Address Extension - IAB comment
In-Reply-To: <E2F63A4C-4DDB-4376-A39D-251ACAE96DF7@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<503C8329-64CC-4917-9EB7-9FC7522F307D@delong.com>
	<BANLkTin-XS98rCF1n6ZF=n8tKjdEmKJ+XA@mail.gmail.com>
	<E2F63A4C-4DDB-4376-A39D-251ACAE96DF7@bogus.com>
Message-ID: <34E4F50CAFA10349A41E0756550084FB0A7F87B0@PRVPEXVS04.corp.twcable.com>



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joel Jaeggli
Sent: Tuesday, June 28, 2011 1:24 PM
To: William Herrin
Cc: arin-ppml at arin.net List
Subject: Re: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

>> Why was an IPv4 address space proposal given to v6ops?

> it was given time early in the week at opsawg, and subsequently in the last meeting of v6ops.

> http://www.ietf.org/proceedings/79/minutes/opsawg.txt


Does it really matter why?
We can certainly armchair quarterback the previous discussion in IETF, and rehash the debate about whether 2011-5 is a good idea on PPML (as we're starting to do)...
However, if the ARIN community wants to make this happen *with* the IETF instead of in spite of it, it'd be far more productive for those who supported 2011-5 to assist in writing/reviewing/supporting the draft(s) that must be written to get this back into the machinery at IETF. The cutoff for new -00 drafts to be discussed in Quebec City (week of July 25) is July 4, and updates to existing drafts (like one of the two variants of draft-weil*, which I believe is already being updated) is July 11. This can happen in parallel to any other recommendations that have come forward on this thread.

This is a divisive issue. For the sake of expediting any discussion and consensus building within IETF, I would strongly recommend that any draft addresses the most common objections and concerns that have come up pretty much every single time this has been discussed, rather than avoiding discussing them in the hopes that this time they won't come up. Otherwise we can look forward to another triple-digit length email discussion thread about it every time it gets to a wider audience at IETF. Therefore there is a good bit of work to be done in a short time.

If you're convinced that the IETF doesn't like real solutions for real operational problems, or that they missed the boat on this specific issue for some other reason, now is as good a time as any to get involved in IETF and insert the clue that you believe to be missing. Operator input is extremely important and often lacking.
Like ARIN, IETF does not require physical meeting attendance to participate, only an investment of time. Consider this a call to arms to get involved, especially if this shared transition space is critically important to your employer.

It's quite likely this will hit OPSAWG again. Here's the email list for that group - https://www.ietf.org/mailman/listinfo/opsawg so that those who are interested can be watching for the draft and voice support or opposition as they deem appropriate.

Wes George

* http://tools.ietf.org/html/draft-weil-shared-transition-space-request-01 and http://tools.ietf.org/html/draft-weil-opsawg-provider-address-space-02


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From scottleibrand at gmail.com  Tue Jun 28 16:40:10 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 28 Jun 2011 16:40:10 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - June 2011
In-Reply-To: <4E0A13F6.9020605@arin.net>
References: <4E0A13F6.9020605@arin.net>
Message-ID: <BANLkTimRy7E_oLD29jWUrvRXU7OVxjeETg@mail.gmail.com>

A few personal opinions on the items the AC considered inline below...

On Tue, Jun 28, 2011 at 1:48 PM, ARIN <info at arin.net> wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 16 June 2011 and made decisions about
> several proposals.
>
> The following proposals have been added to the AC's docket for
> development and evaluation:
>
> ?ARIN-prop-149 Improved Transparency for Directed Transfers

Transfer market transparency is good.  :-)

> ?ARIN-prop-151 Limiting needs requirements for IPv4 Transfers

I'm not sure about this text, but I think it needs to be discussed in
Philadelphia.

> ?ARIN-prop-152 RSA Modification Limits

I'm not sure about this text either, but I think it's reasonable for
the community to express our collective opinion on how far ARIN should
go in modifying the RSA, and I think this is the right vehicle for
discussing that in Philly.

> ?ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

I don't support this proposal, but I think it's good to have this on
the agenda in Philly as a counterpoint to the "remove single
aggregate" proposal.

> The AC abandoned the following proposals:
>
> ?ARIN-prop-148 LRSA resources must not be transferred to LRSA
> ?ARIN-prop-150 Reclamation Hold
>
> Proposal 148 was abandoned because the majority of the AC members feel that
> which legal agreement ARIN uses with a resource requester is a business
> matter. It is indeed the case, however, that if the community feels there
> should be certain policy requirements for what is in an RSA, LRSA or similar
> document that those could be specified in policy. This would require ARIN to
> put those items in any agreement where applicable and allowed by law. ?The
> AC felt that ARIN-prop-152 was an example of such a policy proposal, and
> voted to accept it onto the AC's docket for further development.
>
> The Advisory Council has abandoned Proposal 150 based on the merits of the
> proposal and the author's stated desired to have it withdrawn.

I agree with both those explanations.

> The AC thanks the authors and the community for their continuing effort
> and contributions to these and all other policy considerations.

And wholeheartedly agree with this.  :-)

-Scott


From mysidia at gmail.com  Tue Jun 28 20:38:36 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 28 Jun 2011 19:38:36 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
Message-ID: <BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>

On Tue, Jun 28, 2011 at 9:50 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
>> [snip]
>> What assumptions would those be?
> That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)

We don't need to address all the issues with NAT and NAT444 over again
in this discussion;  there are multiple RFCs and drafts discussing NAT
and its issues,  let's concentrate on any _additional_ assumptions
that are violated by ARIN allocating a shared address space
that are not violated by the mere use of NAT444.

This is basically an argument against the use of NAT444 ever,  but if
ISPs want to utilize NAT444, this assumption is violated whether a
special shared range is allocated or not;  violation of that
assumption should not be a hurdle against 2011-05 adoption by ARIN.
The choice to deploy NAT444 or not is the choice of the ISPs  in
deciding how they will deal with IPv4 exhaustion,  in the interim,
assuming IPv6 will be deployed.

ISPs can study the impacts to their particular CPE model(s) and choose
to deploy (or not deploy), based on their requirements.
Whether to use NAT444 or not,  and whether to provide a single
dedicated allocation for all the large ISPs that are going to deploy
NAT444  (instead of each large ISP needing to carve out their own
shared range),  is a separate question.


As multiple service providers want to use NAT444,  ARIN should
acknowledge that,  and provide shared resources  _one time_ if it
makes sense to do so, from a standpoint of overall  conservation and
efficient utilization of IPv4 address space.


The benefit to the community, is a reduction in the amount of IPv4
resources that can be justified by ISPs utilizing NAT444 on their
networks, and therefore  (hopefully)  an  easing of  demand for IPv4
address space  after exhaustion.



The "reachable outside IP" is an assumption that is violated by
NAT444,  whether the CPE's outside address is in RFC1918 space or not,
 this is violated,  regardless of whether the range used is a range
shared by other providers or not.
In any Large Scale NAT implementation,  this assumption cannot be
preserved and is unsalvageable.

After the CPE's outside address is translated using LSN or  NAP,   the
port will not be reachable from outside the Large Scale NAT device,
even if a globally routable IP address is utilized.


> That an ipv4 unicast address can be used as source or destination for an auto-tunneling mechanism.

Ditto.


---
-JH


From joelja at bogus.com  Wed Jun 29 01:35:21 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jun 2011 22:35:21 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
Message-ID: <707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>


On Jun 28, 2011, at 5:38 PM, Jimmy Hess wrote:

> On Tue, Jun 28, 2011 at 9:50 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
>>> [snip]
>>> What assumptions would those be?
>> That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)
> 
> We don't need to address all the issues with NAT and NAT444 over again
> in this discussion;  there are multiple RFCs and drafts discussing NAT
> and its issues,  let's concentrate on any _additional_ assumptions
> that are violated by ARIN allocating a shared address space
> that are not violated by the mere use of NAT444.
> 
> This is basically an argument against the use of NAT444 ever,  but if
> ISPs want to utilize NAT444, this assumption is violated whether a
> special shared range is allocated or not;

no it isn't. there is a tangible difference between a scenario where something will not be configured and therefore will never fail and a, something which fires packets into the ether becuase it doesn't know any better. LSN is here, allocating a new prefix or squatting on public scope prefixes will break some fraction of old cpe (it does today) in worse way then allocating them out of private scope prefixes (for which they already have logic) until they age out of the network.





From jcurran at arin.net  Wed Jun 29 02:40:53 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 29 Jun 2011 06:40:53 +0000
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <4E0928EF.8030702@umn.edu>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
Message-ID: <78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>

On Jun 28, 2011, at 3:05 AM, David Farmer wrote:

> I would like to request John and ARIN staff to investigate possible precedent documented in RFC 3849[1] by the allocation of 2001:DB8::/32 by APNIC.  My interpretation of the text in the RFC is that APNIC passed a policy allocating a prefix for documentation purposes and then members of the APNIC community authored an Informational RFC documenting the allocation and the technical justifications to the IETF.

David - I'm quite familiar with the RFC 3849 document, but that does not 
automatically alter the existing agreements which outline the roles of the 
IANA and the RIRs (and one might readily argue that there is far more at 
issue with shared transition reservation versus a documentation prefix...)

Note - this doesn't mean that your suggestion regarding the next step isn't 
perfectly reasonable, as follows:

> Therefore, I would like to suggest representatives from the ARIN Community, and the ARIN AC, author and submit and Informational RFC documenting the allocation of the /10 per ARIN policy development process, including the technical details and justification surrounding it.

I believe that there are folks working on exactly that: I know that Chris 
Grundemann and Benson Schliesser both expressed interest to me to working 
on this effort, and I encourage anyone else interested in helping out to 
reach out to them accordingly.

> And, once the Draft is submitted, the board move forward with implementing 2011-5 based on the precedence of the allocation of 2001:DB8::/32 by APNIC, as documented in RFC3849.  I believe RFC2860 is clear that the IETF has a role, and it is desirable and necessary that such an allocation should be documented in RFCs, but it is not clear to me that ARIN cannot and MUST not make such an allocation base on the clear policy will of its community, especially based on the precedent of RFC 3849.

I will convey this to the ARIN Board as one possible course of action 
when it considers the IAB response. Making the reservation for this 
purpose without conferring with IAB would not have respected the nature
of the ARIN/IANA relationship, and the exact degree of engagement with 
the IETF community which is most appropriate is a matter of judgement.
To the extent that we have a clear document in the IETF which explains
why the reservation is needed, along with a strong show of support in
that community, the path forward will not be difficult.

Thanks!
/John

John Curran
President and CEO
ARIN




From ipng at 69706e6720323030352d30312d31340a.nosense.org  Wed Jun 29 05:24:16 2011
From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith)
Date: Wed, 29 Jun 2011 18:54:16 +0930
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
Message-ID: <20110629185416.018450e2@opy.nosense.org>

On Wed, 29 Jun 2011 06:40:53 +0000
John Curran <jcurran at arin.net> wrote:

> On Jun 28, 2011, at 3:05 AM, David Farmer wrote:
> 
<snip>
> 
> I will convey this to the ARIN Board as one possible course of action 
> when it considers the IAB response. Making the reservation for this 
> purpose without conferring with IAB would not have respected the nature
> of the ARIN/IANA relationship, and the exact degree of engagement with 
> the IETF community which is most appropriate is a matter of judgement.
> To the extent that we have a clear document in the IETF which explains
> why the reservation is needed, along with a strong show of support in
> that community, the path forward will not be difficult.
> 

It also needs to describe what the problem is with ISPs
reusing/recycling parts of their existing public address space for
this purpose i.e.

1. move 1/16, 1/8, 1/4 etc. of customers behind 1st LSN box.
2. duplicate the use of the ISP's existing public address space being
used by that first "LSN domain" group of customers on subsequent LSN
domains for the rest of the customer base.

For example, if an ISP has 8 LSN domains, once they're deployed, the
ISP has recovered 7/8ths of their existing public allocation through
duplicating 1/8th of it 8 times. They could give most of that 7/8ths
back to their RIR, which will increase the available IPv4 address pool,
extending it's life. On the scale of the ISPs proposing 2011-5, the
return of IPv4 addresses should be significant, even if they only
deployed 2 LSN domains (i.e. recover 1/2 their IPv4 addresses) across
their customer base. An ISP would have a financial incentive to return
these addresses, to reduce their RIR fees.

This method won't provide a unique and individual IP address per
customer within the ISP, however that is not a requirement stated in
2011-5, and nor will the /10 provide that for some of the ISPs behind
this proposal.


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


From owen at delong.com  Wed Jun 29 05:21:42 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 02:21:42 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
Message-ID: <5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>


On Jun 28, 2011, at 10:35 PM, Joel Jaeggli wrote:

> 
> On Jun 28, 2011, at 5:38 PM, Jimmy Hess wrote:
> 
>> On Tue, Jun 28, 2011 at 9:50 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
>>>> [snip]
>>>> What assumptions would those be?
>>> That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)
>> 
>> We don't need to address all the issues with NAT and NAT444 over again
>> in this discussion;  there are multiple RFCs and drafts discussing NAT
>> and its issues,  let's concentrate on any _additional_ assumptions
>> that are violated by ARIN allocating a shared address space
>> that are not violated by the mere use of NAT444.
>> 
>> This is basically an argument against the use of NAT444 ever,  but if
>> ISPs want to utilize NAT444, this assumption is violated whether a
>> special shared range is allocated or not;
> 
> no it isn't. there is a tangible difference between a scenario where something will not be configured and therefore will never fail and a, something which fires packets into the ether becuase it doesn't know any better. LSN is here, allocating a new prefix or squatting on public scope prefixes will break some fraction of old cpe (it does today) in worse way then allocating them out of private scope prefixes (for which they already have logic) until they age out of the network.


Due to the support issues, no provider in their right mind is going to use 1918 space for the middle-layer in a NAT444 scenario.

As such, the question remains the same...

Do we allocate a single /10 so that everyone can use the same address space, or, do we force each provider to build their own collection of GUA addresses allocated to this same purpose?

Owen



From owen at delong.com  Wed Jun 29 05:30:00 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 02:30:00 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <20110629185416.018450e2@opy.nosense.org>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<20110629185416.018450e2@opy.nosense.org>
Message-ID: <CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>

The problems are multiple:

	1.	It will increase the number of customers that must be moved from
		current access technologies to NAT444.

	2.	It will not allow the larger ISPs to approach this on a regional basis
		(which 2001-5 would). By using 2011-5, the ISP can set up a defined
		address space per region and start allocating to NAT boxes and
		customers. While it won't provide one globally unique IP per customer,
		it will allow each customer to have a regionally unique IP.

	3.	The approach you recommend below requires a lot of moving pieces
		to all fall into place at the same time or nearly the same time and is a
		much more complex and perilous migration scheme.

	4.	See 1 above... it bears repeating.

Owen

On Jun 29, 2011, at 2:24 AM, Mark Smith wrote:

> On Wed, 29 Jun 2011 06:40:53 +0000
> John Curran <jcurran at arin.net> wrote:
> 
>> On Jun 28, 2011, at 3:05 AM, David Farmer wrote:
>> 
> <snip>
>> 
>> I will convey this to the ARIN Board as one possible course of action 
>> when it considers the IAB response. Making the reservation for this 
>> purpose without conferring with IAB would not have respected the nature
>> of the ARIN/IANA relationship, and the exact degree of engagement with 
>> the IETF community which is most appropriate is a matter of judgement.
>> To the extent that we have a clear document in the IETF which explains
>> why the reservation is needed, along with a strong show of support in
>> that community, the path forward will not be difficult.
>> 
> 
> It also needs to describe what the problem is with ISPs
> reusing/recycling parts of their existing public address space for
> this purpose i.e.
> 
> 1. move 1/16, 1/8, 1/4 etc. of customers behind 1st LSN box.
> 2. duplicate the use of the ISP's existing public address space being
> used by that first "LSN domain" group of customers on subsequent LSN
> domains for the rest of the customer base.
> 
> For example, if an ISP has 8 LSN domains, once they're deployed, the
> ISP has recovered 7/8ths of their existing public allocation through
> duplicating 1/8th of it 8 times. They could give most of that 7/8ths
> back to their RIR, which will increase the available IPv4 address pool,
> extending it's life. On the scale of the ISPs proposing 2011-5, the
> return of IPv4 addresses should be significant, even if they only
> deployed 2 LSN domains (i.e. recover 1/2 their IPv4 addresses) across
> their customer base. An ISP would have a financial incentive to return
> these addresses, to reduce their RIR fees.
> 
> This method won't provide a unique and individual IP address per
> customer within the ISP, however that is not a requirement stated in
> 2011-5, and nor will the /10 provide that for some of the ISPs behind
> this proposal.
> 
> 
>> Thanks!
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ipng at 69706e6720323030352d30312d31340a.nosense.org  Wed Jun 29 06:33:58 2011
From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith)
Date: Wed, 29 Jun 2011 20:03:58 +0930
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<20110629185416.018450e2@opy.nosense.org>
	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
Message-ID: <20110629200358.4e70541b@opy.nosense.org>



On Wed, 29 Jun 2011 02:30:00 -0700
Owen DeLong <owen at delong.com> wrote:

> The problems are multiple:
> 
> 	1.	It will increase the number of customers that must be moved from
> 		current access technologies to NAT444.
> 

So? IPv4 address sharing is inevitable. The only way to be fair about
it to customers is to provide two product offerings - a shared and
non-shared IPv4 address service, and make the latter pay more for it if
they value it.

Regardless, 2011-5 does not say minimising NAT444 use is one
of it's goals. Being a /10, I think it is implying that NAT444 is going
to be the default for normal residential customers.


> 	2.	It will not allow the larger ISPs to approach this on a regional basis
> 		(which 2001-5 would). By using 2011-5, the ISP can set up a defined
> 		address space per region and start allocating to NAT boxes and
> 		customers. While it won't provide one globally unique IP per customer,
> 		it will allow each customer to have a regionally unique IP.
> 

I don't agree. The 1/16th, 1/4, 1/8th etc. I used as examples are likely
to be regions, as an ISP's network's topology tends to map to
geographical regions. Regions might vary in size, however that is easy
enough to deal with by setting your shared IPv4 address "unit of
allocation" to the smallest of either that or the maximum number of
customers the LSN box can handle. IIRC, based on a presentation on
Cisco's CRS1 LSN blade, the latter is around 128K customers. Managing
varying sizes of regional shared addresses is pretty much the same
problem as managing variable length subnetting. 

> 	3.	The approach you recommend below requires a lot of moving pieces
> 		to all fall into place at the same time or nearly the same time and is a
> 		much more complex and perilous migration scheme.
> 

I know a number of networking people at ISPs who are not afraid of this
"perilous migration", as it isn't any different to moving existing
dynamic IP addressing pools around between BRASes/LNSes. Here's the
process of deploying what I suggested -

1. Install first LSN and switch it on, leaving this group of customer's
public addressing as it is.
2. Install second LSN and switch it on. Move this group of customers to
the address space being used by the group in step 1 when the LSN is put
into production.
3. Repeat 2 until finished, likely over a time period of months.

I can think of and have done much more "complex and perilous
migration[s]". 

That being said, I didn't think RIRs were concerned with any of the
issues related to how ISPs deploy the address space, and whether that
deployment was "complex" or "perilous", just how much and what they
wanted to use it for.


> 	4.	See 1 above... it bears repeating.

So I'll repeat, IPv4 address sharing is inevitable. Giving away a /10
implies that it is going to be the default. Giving away a /10 will only
encourage NAT444's deployment, not reduce it. Only more IPv4 address
space can reduce the need for it's deployment, and there's none left.

Regards,
Mark.

> Owen
> 
> On Jun 29, 2011, at 2:24 AM, Mark Smith wrote:
> 
> > On Wed, 29 Jun 2011 06:40:53 +0000
> > John Curran <jcurran at arin.net> wrote:
> > 
> >> On Jun 28, 2011, at 3:05 AM, David Farmer wrote:
> >> 
> > <snip>
> >> 
> >> I will convey this to the ARIN Board as one possible course of action 
> >> when it considers the IAB response. Making the reservation for this 
> >> purpose without conferring with IAB would not have respected the nature
> >> of the ARIN/IANA relationship, and the exact degree of engagement with 
> >> the IETF community which is most appropriate is a matter of judgement.
> >> To the extent that we have a clear document in the IETF which explains
> >> why the reservation is needed, along with a strong show of support in
> >> that community, the path forward will not be difficult.
> >> 
> > 
> > It also needs to describe what the problem is with ISPs
> > reusing/recycling parts of their existing public address space for
> > this purpose i.e.
> > 
> > 1. move 1/16, 1/8, 1/4 etc. of customers behind 1st LSN box.
> > 2. duplicate the use of the ISP's existing public address space being
> > used by that first "LSN domain" group of customers on subsequent LSN
> > domains for the rest of the customer base.
> > 
> > For example, if an ISP has 8 LSN domains, once they're deployed, the
> > ISP has recovered 7/8ths of their existing public allocation through
> > duplicating 1/8th of it 8 times. They could give most of that 7/8ths
> > back to their RIR, which will increase the available IPv4 address pool,
> > extending it's life. On the scale of the ISPs proposing 2011-5, the
> > return of IPv4 addresses should be significant, even if they only
> > deployed 2 LSN domains (i.e. recover 1/2 their IPv4 addresses) across
> > their customer base. An ISP would have a financial incentive to return
> > these addresses, to reduce their RIR fees.
> > 
> > This method won't provide a unique and individual IP address per
> > customer within the ISP, however that is not a requirement stated in
> > 2011-5, and nor will the /10 provide that for some of the ISPs behind
> > this proposal.
> > 
> > 
> >> Thanks!
> >> /John
> >> 
> >> John Curran
> >> President and CEO
> >> ARIN
> >> 
> >> 
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 


From jmaimon at chl.com  Wed Jun 29 08:53:53 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 29 Jun 2011 08:53:53 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <20110629200358.4e70541b@opy.nosense.org>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>	<20110629185416.018450e2@opy.nosense.org>	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
Message-ID: <4E0B2061.3090000@chl.com>



Mark Smith wrote:
>
>
> On Wed, 29 Jun 2011 02:30:00 -0700
> Owen DeLong<owen at delong.com>  wrote:
>
>> The problems are multiple:
>>
>> 	1.	It will increase the number of customers that must be moved from
>> 		current access technologies to NAT444.
>>
>
> So? IPv4 address sharing is inevitable. The only way to be fair about
> it to customers is to provide two product offerings - a shared and
> non-shared IPv4 address service, and make the latter pay more for it if
> they value it.
>
> Regardless, 2011-5 does not say minimising NAT444 use is one
> of it's goals. Being a /10, I think it is implying that NAT444 is going
> to be the default for normal residential customers.
>

Precisely. Expect organizations who have had sufficient positive results 
with their NAT444 deployments to not limit it to new users only, for 
many reasons, some of which they cannot be faulted for.

Some of these organizations will as a result have more available 
resources then anybody else put together.

So either NAT444 is so horrible that only new users can be put into it, 
or there is a new sheriff in town, along the lines of the golden rule.


Joe



From jmaimon at chl.com  Wed Jun 29 09:09:01 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 29 Jun 2011 09:09:01 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
Message-ID: <4E0B23ED.5040504@chl.com>



Owen DeLong wrote:
>

>
> Due to the support issues, no provider in their right mind is going to use 1918 space for the middle-layer in a NAT444 scenario.

Due to the support issue, no provider in their right mind is going to 
share addresses across multiple customers.

Apparently, when it comes to support issue, the question remains one of 
degree. And I disagree sharply with you as to the effect on the equation 
the use of 1918 brings.

>
> As such, the question remains the same...
>
> Do we allocate a single /10 so that everyone can use the same address space, or, do we force each provider to build their own collection of GUA addresses allocated to this same purpose?
>
> Owen
>

False dichotomy.

Or providers will use GUA regardless of the /10. Or providers will pool 
a collection together. Or providers will go ahead and use space that 
already exists, either their own or rfc1918 or even 240/4.

Even if they do not find those options as attractive as this /10.


Joe


From adurand at juniper.net  Wed Jun 29 09:43:02 2011
From: adurand at juniper.net (Alain Durand)
Date: Wed, 29 Jun 2011 06:43:02 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	for	IPv4 Address Extension - IAB comment
In-Reply-To: <707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
Message-ID: <B52133D0-92DD-4202-A357-41F9A3E5A07B@juniper.net>


On Jun 29, 2011, at 1:35 AM, Joel Jaeggli wrote:
> 
> no it isn't. there is a tangible difference between a scenario where something will not be configured and therefore will never fail and a, something which fires packets into the ether becuase it doesn't know any better. LSN is here, allocating a new prefix or squatting on public scope prefixes will break some fraction of old cpe (it does today) in worse way then allocating them out of private scope prefixes (for which they already have logic) until they age out of the network.

This is exactly the point. There is logic coded in many, many devices that understand what a private address [rfc1918] is and do different things accordingly.
Feeding those devices with what looks like a perfectly good global unicast address will inevitably creates breakage. The first that comes to mind is 6to4, another
one is SIP where there is some logic to do NAT traversal put in place, etc...

This breakage has to be compared to the level of breakage of the same CPEs that would be fed RFC1918 addresses, especially 172.16/12 and that might get
confused with what they have allocated internally.

   - Alain.

From bill at herrin.us  Wed Jun 29 09:53:11 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jun 2011 09:53:11 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
Message-ID: <BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>

On Wed, Jun 29, 2011 at 5:21 AM, Owen DeLong <owen at delong.com> wrote:
> On Jun 28, 2011, at 10:35 PM, Joel Jaeggli wrote:
>> no it isn't. there is a tangible difference between a
>>scenario where something will not be configured and
>>therefore will never fail and a, something which fires
>>packets into the ether becuase it doesn't know any
>>better. LSN is here, allocating a new prefix or squatting
>>on public scope prefixes will break some fraction of old
>>cpe (it does today) in worse way then allocating them
>>out of private scope prefixes (for which they already
>>have logic) until they age out of the network.
>
> Due to the support issues, no provider in their right
> mind is going to use 1918 space for the middle-layer
> in a NAT444 scenario.

Hi Owen,

I wouldn't say -no- ISPs will use RFC1918 space for their NAT444
deployments. ISPs are a diverse bunch of folks. What's certain is:

1. Many if not most ISPs will use public scope prefixes inside the
NATted part of their deployments whether we provide a shared space for
it or not, and

2. Regardless of the disposition of 2011-5, the vendors and protocol
authors who made assumptions about NAT based on the assigned IP
address are about to get an object lesson in respecting the corner
case.

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 adurand at juniper.net  Wed Jun 29 10:02:33 2011
From: adurand at juniper.net (Alain Durand)
Date: Wed, 29 Jun 2011 07:02:33 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
Message-ID: <1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>


On Jun 29, 2011, at 9:53 AM, William Herrin wrote:

> 
> 2. Regardless of the disposition of 2011-5, the vendors and protocol
> authors who made assumptions about NAT based on the assigned IP
> address are about to get an object lesson in respecting the corner
> case.


This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.

  - Alain.

From bill at herrin.us  Wed Jun 29 10:35:00 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jun 2011 10:35:00 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
Message-ID: <BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>

On Wed, Jun 29, 2011 at 10:02 AM, Alain Durand <adurand at juniper.net> wrote:
> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>> authors who made assumptions about NAT based on the assigned IP
>> address are about to get an object lesson in respecting the corner
>> case.
>
> This logic is hard coded just about everywhere. Check your Windows
> machine and see what it does based on which IP address it is
> configured with.

Alain,

You'll have to elaborate on that, because while windows firewall makes
assumptions about what it's allowed to do if it encounters an RFC1918
address, it makes no assumptions I'm aware of about what it can do
with an address that isn't. If anything, the ISP choosing to employ
RFC1918 addresses would cause Windows to incorrectly configure a
permissive firewall.


> One could reverse your comment and say: ISP
> who do not take this fact into account take the risk of generating
> high volume of service call.

They'll get the service calls from the five-percenters regardless. The
difference is that with a non-RFC1918 address the support tech can
solve the problem with $5 extra per month for a static IP address and
-no- changes to the customer's computer.

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 adurand at juniper.net  Wed Jun 29 10:59:08 2011
From: adurand at juniper.net (Alain Durand)
Date: Wed, 29 Jun 2011 07:59:08 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
Message-ID: <9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>


On Jun 29, 2011, at 10:35 AM, William Herrin wrote:

> On Wed, Jun 29, 2011 at 10:02 AM, Alain Durand <adurand at juniper.net> wrote:
>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>> authors who made assumptions about NAT based on the assigned IP
>>> address are about to get an object lesson in respecting the corner
>>> case.
>> 
>> This logic is hard coded just about everywhere. Check your Windows
>> machine and see what it does based on which IP address it is
>> configured with.
> 
> Alain,
> 
> You'll have to elaborate on that, because while windows firewall makes
> assumptions about what it's allowed to do if it encounters an RFC1918
> address, it makes no assumptions I'm aware of about what it can do
> with an address that isn't. If anything, the ISP choosing to employ
> RFC1918 addresses would cause Windows to incorrectly configure a
> permissive firewall.
> 

If [public address] then start 6to4
if [private address] then start teredo (if app ask for IPv6)





> 
>> One could reverse your comment and say: ISP
>> who do not take this fact into account take the risk of generating
>> high volume of service call.
> 
> They'll get the service calls from the five-percenters regardless. The
> difference is that with a non-RFC1918 address the support tech can
> solve the problem with $5 extra per month for a static IP address and
> -no- changes to the customer's computer.

I guess we differ of the actual value of this five-percenter.

  - Alain.


From bill at herrin.us  Wed Jun 29 11:14:05 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jun 2011 11:14:05 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
Message-ID: <BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>

On Wed, Jun 29, 2011 at 10:59 AM, Alain Durand <adurand at juniper.net> wrote:
> On Jun 29, 2011, at 10:35 AM, William Herrin wrote:
>> You'll have to elaborate on that, because while windows firewall makes
>> assumptions about what it's allowed to do if it encounters an RFC1918
>> address, it makes no assumptions I'm aware of about what it can do
>> with an address that isn't. If anything, the ISP choosing to employ
>> RFC1918 addresses would cause Windows to incorrectly configure a
>> permissive firewall.
>
> If [public address] then start 6to4

Never seen it. And they'd be seriously crazy to enable it by default
-- it would cause incredible brokenness even when the assumptions were
met.

-Bill


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


From joelja at bogus.com  Wed Jun 29 12:55:25 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jun 2011 09:55:25 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
Message-ID: <AE8AAC3E-9FB8-4B52-8798-B3511A645615@bogus.com>


On Jun 29, 2011, at 8:14 AM, William Herrin wrote:

> On Wed, Jun 29, 2011 at 10:59 AM, Alain Durand <adurand at juniper.net> wrote:
>> On Jun 29, 2011, at 10:35 AM, William Herrin wrote:
>>> You'll have to elaborate on that, because while windows firewall makes
>>> assumptions about what it's allowed to do if it encounters an RFC1918
>>> address, it makes no assumptions I'm aware of about what it can do
>>> with an address that isn't. If anything, the ISP choosing to employ
>>> RFC1918 addresses would cause Windows to incorrectly configure a
>>> permissive firewall.
>> 
>> If [public address] then start 6to4
> 
> Never seen it. And they'd be seriously crazy to enable it by default
> -- it would cause incredible brokenness even when the assumptions were
> met.

Sorry it's on by default in windows vista and windows 7...

in the case of cpe, there are a number of cpe products passing the windows 7 logo compliance requirements which also either implement it, have it on by default, or in fact cannot have it disabled via ui.

> -Bill
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From owen at delong.com  Wed Jun 29 14:38:13 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 11:38:13 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <20110629200358.4e70541b@opy.nosense.org>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<20110629185416.018450e2@opy.nosense.org>
	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
Message-ID: <A32EC5AA-8D55-4205-8395-550EA0C64BD1@delong.com>


On Jun 29, 2011, at 3:33 AM, Mark Smith wrote:

> 
> 
> On Wed, 29 Jun 2011 02:30:00 -0700
> Owen DeLong <owen at delong.com> wrote:
> 
>> The problems are multiple:
>> 
>> 	1.	It will increase the number of customers that must be moved from
>> 		current access technologies to NAT444.
>> 
> 
> So? IPv4 address sharing is inevitable. The only way to be fair about
> it to customers is to provide two product offerings - a shared and
> non-shared IPv4 address service, and make the latter pay more for it if
> they value it.
> 

Arguably it is more fair to grandfather existing customers as they are
and inflict this on new customers.

> Regardless, 2011-5 does not say minimising NAT444 use is one
> of it's goals. Being a /10, I think it is implying that NAT444 is going
> to be the default for normal residential customers.
> 

Being a /10 it is implying that very large providers anticipate being forced
to deploy very large NAT444 regional environments. It does not imply that
they expect to force all existing customers into that environment. It does
not imply otherwise.

Obviously beyond a certain point, NAT444 will be the default for new
normal residential customers. Whether it is to be inflicted on existing
customers is not clear and not addressed in the policy.

> 
>> 	2.	It will not allow the larger ISPs to approach this on a regional basis
>> 		(which 2001-5 would). By using 2011-5, the ISP can set up a defined
>> 		address space per region and start allocating to NAT boxes and
>> 		customers. While it won't provide one globally unique IP per customer,
>> 		it will allow each customer to have a regionally unique IP.
>> 
> 
> I don't agree. The 1/16th, 1/4, 1/8th etc. I used as examples are likely
> to be regions, as an ISP's network's topology tends to map to
> geographical regions. Regions might vary in size, however that is easy
> enough to deal with by setting your shared IPv4 address "unit of
> allocation" to the smallest of either that or the maximum number of
> customers the LSN box can handle. IIRC, based on a presentation on
> Cisco's CRS1 LSN blade, the latter is around 128K customers. Managing
> varying sizes of regional shared addresses is pretty much the same
> problem as managing variable length subnetting. 

You're ignoring the logistics of the transition process.

> 
>> 	3.	The approach you recommend below requires a lot of moving pieces
>> 		to all fall into place at the same time or nearly the same time and is a
>> 		much more complex and perilous migration scheme.
>> 
> 
> I know a number of networking people at ISPs who are not afraid of this
> "perilous migration", as it isn't any different to moving existing
> dynamic IP addressing pools around between BRASes/LNSes. Here's the
> process of deploying what I suggested -
> 
> 1. Install first LSN and switch it on, leaving this group of customer's
> public addressing as it is.
> 2. Install second LSN and switch it on. Move this group of customers to
> the address space being used by the group in step 1 when the LSN is put
> into production.
> 3. Repeat 2 until finished, likely over a time period of months.
> 
Not everything is a BRAS and all ISPs are not created equal.

> I can think of and have done much more "complex and perilous
> migration[s]". 
> 
So have I, but, that doesn't change the fact that this is a bad idea and
an unnecessary cost and risk.

> That being said, I didn't think RIRs were concerned with any of the
> issues related to how ISPs deploy the address space, and whether that
> deployment was "complex" or "perilous", just how much and what they
> wanted to use it for.
> 

Correct. However, you asked the question, so, I answered it.

> 
>> 	4.	See 1 above... it bears repeating.
> 
> So I'll repeat, IPv4 address sharing is inevitable. Giving away a /10
> implies that it is going to be the default. Giving away a /10 will only
> encourage NAT444's deployment, not reduce it. Only more IPv4 address
> space can reduce the need for it's deployment, and there's none left.
> 

IPv4 address sharing for new customers is inevitable. Nothing says that
IPv4 address sharing is inevitable for everyone. Making a /10 universally
available for shared use for this purpose will actually decrease the
number of customers that must be forced into this environment. It will
not encourage the deployment of NAT444 which is something every
provider I have talked to prefers to minimize and only deploy to the
extent and number of customers absolutely necessary.

More IPv4 space is not the actual answer to reduce the need for it's
deployment. First, it's an impossible goal. Second, the real way to
reduce the need for NAT444 is greater migration to IPv6 which provides
an actual long-term solution.

~15 years ago, we started with NAT as a necessary evil to buy us
enough time to develop and deploy IPv6. Unfortunately, in that time,
we developed and failed to deploy IPv6, so, now we ware where we
are, with NAT444 becoming a necessary evil to allow some IPv4
services to sort of continue to function in a degraded way until
we can migrate those services, devices, etc. over to IPv6.

Other than a few hardware vendors who expect big profits from it,
I don't know of anyone who regards NAT444 as a desirable solution.
Most that I speak to regard it as an inevitable necessary deployment
which will be ineffective and costly and which they thus hope to
deploy only to the extent absolutely necessary and only for the
amount of time it is absolutely required.

Fortunately for me, I'm fully dual stacked and have my own
addresses in both protocols. NAT444 will not affect me other
than to the extent it affects the ability of others to reach my
systems.

When I can't get public IPv4 from my residential ISPs, I'll
insist on public IPv6 and move my tunnels from IPv4 to
IPv6 transport. The dual-stack inside the tunnels will
remain the same and will continue to function just fine
without any NAT of any form.

Owen



From joelja at bogus.com  Wed Jun 29 14:48:08 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jun 2011 11:48:08 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <A32EC5AA-8D55-4205-8395-550EA0C64BD1@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<20110629185416.018450e2@opy.nosense.org>
	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
	<A32EC5AA-8D55-4205-8395-550EA0C64BD1@delong.com>
Message-ID: <736B246B-9EEE-4328-9533-5368E733EE75@bogus.com>


On Jun 29, 2011, at 11:38 AM, Owen DeLong wrote:
>> Regardless, 2011-5 does not say minimising NAT444 use is one
>> of it's goals. Being a /10, I think it is implying that NAT444 is going
>> to be the default for normal residential customers.
>> 
> 
> Being a /10 it is implying that very large providers anticipate being forced
> to deploy very large NAT444 regional environments. It does not imply that
> they expect to force all existing customers into that environment. It does
> not imply otherwise.

A /10 or even a /8 imply that the providers will have multiple parallel instances of the prefix just as north american wireless network providers do today.

> Obviously beyond a certain point, NAT444 will be the default for new
> normal residential customers. Whether it is to be inflicted on existing
> customers is not clear and not addressed in the policy.

how you run your network is a business decision.



From owen at delong.com  Wed Jun 29 14:48:10 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 11:48:10 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <4E0B2061.3090000@chl.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>	<20110629185416.018450e2@opy.nosense.org>	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
	<4E0B2061.3090000@chl.com>
Message-ID: <126B0ABA-4C7B-4A34-BAA3-8905DC5FEBDC@delong.com>


On Jun 29, 2011, at 5:53 AM, Joe Maimon wrote:

> 
> 
> Mark Smith wrote:
>> 
>> 
>> On Wed, 29 Jun 2011 02:30:00 -0700
>> Owen DeLong<owen at delong.com>  wrote:
>> 
>>> The problems are multiple:
>>> 
>>> 	1.	It will increase the number of customers that must be moved from
>>> 		current access technologies to NAT444.
>>> 
>> 
>> So? IPv4 address sharing is inevitable. The only way to be fair about
>> it to customers is to provide two product offerings - a shared and
>> non-shared IPv4 address service, and make the latter pay more for it if
>> they value it.
>> 
>> Regardless, 2011-5 does not say minimising NAT444 use is one
>> of it's goals. Being a /10, I think it is implying that NAT444 is going
>> to be the default for normal residential customers.
>> 
> 
> Precisely. Expect organizations who have had sufficient positive results with their NAT444 deployments to not limit it to new users only, for many reasons, some of which they cannot be faulted for.
> 

Why? And what about all the other organizations that have had sufficient negative results?


> Some of these organizations will as a result have more available resources then anybody else put together.
> 

This is relevant how?

> So either NAT444 is so horrible that only new users can be put into it, or there is a new sheriff in town, along the lines of the golden rule.
> 

I'd go with the latter of those two options.

Owen



From owen at delong.com  Wed Jun 29 15:01:34 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 12:01:34 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <4E0B23ED.5040504@chl.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<4E0B23ED.5040504@chl.com>
Message-ID: <B0965871-9F28-42B7-88E5-A5170676A930@delong.com>


On Jun 29, 2011, at 6:09 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 
> 
>> 
>> Due to the support issues, no provider in their right mind is going to use 1918 space for the middle-layer in a NAT444 scenario.
> 
> Due to the support issue, no provider in their right mind is going to share addresses across multiple customers.
> 
> Apparently, when it comes to support issue, the question remains one of degree. And I disagree sharply with you as to the effect on the equation the use of 1918 brings.
> 

You can disagree all you want, but, the majority of (large) providers that have studied the issue do not.

>> 
>> As such, the question remains the same...
>> 
>> Do we allocate a single /10 so that everyone can use the same address space, or, do we force each provider to build their own collection of GUA addresses allocated to this same purpose?
>> 
>> Owen
>> 
> 
> False dichotomy.
> 
> Or providers will use GUA regardless of the /10. Or providers will pool a collection together. Or providers will go ahead and use space that already exists, either their own or rfc1918 or even 240/4.
> 
Lack of support in the CPE makes 240/4 a likely non-starter for this.

RFC-1918 is also a non-starter for most of the large providers. They'll get GUA allocations before they'll use 1918 in most cases.

I doubt anyone wants to use GUA regardless of the /10, what would be the advantage?

As to pooling a collection together, that's essentially the same effect as allocating this /10, just in a much more complicated and less documented/reliable manner.

So, basically you've narrowed it down to two variants of the /10 and GUA as the other two options you presented are unlikely to see much acceptance vs. the available alternatives.

Of the remaining feasible alternatives, 2011-5 is certainly the cleanest approach. I hope the IAB/IETF will reconsider this and bring it to a favorable outcome.

> Even if they do not find those options as attractive as this /10.
> 

If I were to rank the options in order of attractiveness (from an ISP perspective), they would be:

	2011-5
	Consortium-based assignment
	Community pool of GUA addresses
	New GUA allocations or assignments from RIR (individually to various ISPs)
	Use of existing GUA space (forcing some fraction of existing customers into NAT-444 degraded services)
	Use of RFC-1918 space
	Use of 240/4

I'm pretty sure that they'll find a way to make one of the top 4 work. Since the first 3 basically boil down to the same effect as 2011-5, I would say that it's a relatively safe bet that the dichotomy between 1-3 and 4 is a valid and accurate one.

Owen



From owen at delong.com  Wed Jun 29 15:05:15 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 12:05:15 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
Message-ID: <699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>


On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:

> 
> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
> 
>> 
>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>> authors who made assumptions about NAT based on the assigned IP
>> address are about to get an object lesson in respecting the corner
>> case.
> 
> 
> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
> 
>  - Alain.

But the only place it will matter in these cases is the home gateways.

Owen



From joelja at bogus.com  Wed Jun 29 15:21:00 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jun 2011 12:21:00 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
Message-ID: <8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>


On Jun 29, 2011, at 12:05 PM, Owen DeLong wrote:

> 
> On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:
> 
>> 
>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>> 
>>> 
>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>> authors who made assumptions about NAT based on the assigned IP
>>> address are about to get an object lesson in respecting the corner
>>> case.
>> 
>> 
>> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
>> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
>> 
>> - Alain.
> 
> But the only place it will matter in these cases is the home gateways.

Actually it exists anywhere a home pc is directly connected to the cable modem, like my grandfathers house for example...

And, the logic exists in home gateways, that you can buy at frys, they say linksys on them, and and d-link and so forth.

> 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 owen at delong.com  Wed Jun 29 15:34:18 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 12:34:18 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
	<8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
Message-ID: <BDD78492-AD5E-40F6-9727-2565283008F5@delong.com>


On Jun 29, 2011, at 12:21 PM, Joel Jaeggli wrote:

> 
> On Jun 29, 2011, at 12:05 PM, Owen DeLong wrote:
> 
>> 
>> On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:
>> 
>>> 
>>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>>> 
>>>> 
>>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>>> authors who made assumptions about NAT based on the assigned IP
>>>> address are about to get an object lesson in respecting the corner
>>>> case.
>>> 
>>> 
>>> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
>>> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
>>> 
>>> - Alain.
>> 
>> But the only place it will matter in these cases is the home gateways.
> 
> Actually it exists anywhere a home pc is directly connected to the cable modem, like my grandfathers house for example...
> 
> And, the logic exists in home gateways, that you can buy at frys, they say linksys on them, and and d-link and so forth.
> 

Any place NAT444 gets implemented with non-1918 addresses (which I think is likely to be the vast majority of NAT444
deployments), this assumption will break. Allocating this /10 won't change that fact, it will just reduce the total number
of addresses allocated for that purpose _AND_ allow firmware updates to address that breakage if the CPE/OS vendors
choose to do so.

Owen



From owen at delong.com  Wed Jun 29 15:31:36 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 12:31:36 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <736B246B-9EEE-4328-9533-5368E733EE75@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<20110629185416.018450e2@opy.nosense.org>
	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
	<A32EC5AA-8D55-4205-8395-550EA0C64BD1@delong.com>
	<736B246B-9EEE-4328-9533-5368E733EE75@bogus.com>
Message-ID: <8F3EA442-3BDE-49F4-BD29-4DC03BA600E0@delong.com>


On Jun 29, 2011, at 11:48 AM, Joel Jaeggli wrote:

> 
> On Jun 29, 2011, at 11:38 AM, Owen DeLong wrote:
>>> Regardless, 2011-5 does not say minimising NAT444 use is one
>>> of it's goals. Being a /10, I think it is implying that NAT444 is going
>>> to be the default for normal residential customers.
>>> 
>> 
>> Being a /10 it is implying that very large providers anticipate being forced
>> to deploy very large NAT444 regional environments. It does not imply that
>> they expect to force all existing customers into that environment. It does
>> not imply otherwise.
> 
> A /10 or even a /8 imply that the providers will have multiple parallel instances of the prefix just as north american wireless network providers do today.
> 

Certainly if they inflict NAT444 on ALL of their customers, it would imply this.

It may, however, be that they are able to do new customers for quite some time
from a /10 and certainly from a /8 if they are not converting their existing customers.

Owen



From adurand at juniper.net  Wed Jun 29 16:20:36 2011
From: adurand at juniper.net (Alain Durand)
Date: Wed, 29 Jun 2011 13:20:36 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BDD78492-AD5E-40F6-9727-2565283008F5@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
	<8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
	<BDD78492-AD5E-40F6-9727-2565283008F5@delong.com>
Message-ID: <0F1A1F53-FF02-4D79-B9C9-FBE26D346635@juniper.net>



Sent from my iPhone

On Jun 29, 2011, at 3:35 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Jun 29, 2011, at 12:21 PM, Joel Jaeggli wrote:
> 
>> 
>> On Jun 29, 2011, at 12:05 PM, Owen DeLong wrote:
>> 
>>> 
>>> On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:
>>> 
>>>> 
>>>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>>>> 
>>>>> 
>>>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>>>> authors who made assumptions about NAT based on the assigned IP
>>>>> address are about to get an object lesson in respecting the corner
>>>>> case.
>>>> 
>>>> 
>>>> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
>>>> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
>>>> 
>>>> - Alain.
>>> 
>>> But the only place it will matter in these cases is the home gateways.
>> 
>> Actually it exists anywhere a home pc is directly connected to the cable modem, like my grandfathers house for example...
>> 
>> And, the logic exists in home gateways, that you can buy at frys, they say linksys on them, and and d-link and so forth.
>> 
> 
> Any place NAT444 gets implemented with non-1918 addresses (which I think is likely to be the vast majority of NAT444
> deployments), this assumption will break. Allocating this /10 won't change that fact, it will just reduce the total number
> of addresses allocated for that purpose _AND_ allow firmware updates to address that breakage if the CPE/OS vendors
> choose to do so.
> 
> Owen
> 


This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.

Alain.

From owen at delong.com  Wed Jun 29 16:52:24 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 13:52:24 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <0F1A1F53-FF02-4D79-B9C9-FBE26D346635@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
	<8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
	<BDD78492-AD5E-40F6-9727-2565283008F5@delong.com> <0F1A1F53-!
	FF02-4D79-B9C9-FBE26D346635@juniper.net>
Message-ID: <5CF14D23-4C3C-4C1A-A52B-E24F92BD73F6@delong.com>


On Jun 29, 2011, at 1:20 PM, Alain Durand wrote:

> 
> 
> Sent from my iPhone
> 
> On Jun 29, 2011, at 3:35 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Jun 29, 2011, at 12:21 PM, Joel Jaeggli wrote:
>> 
>>> 
>>> On Jun 29, 2011, at 12:05 PM, Owen DeLong wrote:
>>> 
>>>> 
>>>> On Jun 29, 2011, at 7:02 AM, Alain Durand wrote:
>>>> 
>>>>> 
>>>>> On Jun 29, 2011, at 9:53 AM, William Herrin wrote:
>>>>> 
>>>>>> 
>>>>>> 2. Regardless of the disposition of 2011-5, the vendors and protocol
>>>>>> authors who made assumptions about NAT based on the assigned IP
>>>>>> address are about to get an object lesson in respecting the corner
>>>>>> case.
>>>>> 
>>>>> 
>>>>> This logic is hard coded just about everywhere. Check your Windows machine and see what it does based on which IP address it is configured with.
>>>>> One could reverse your comment and say: ISP who do not take this fact into account take the risk of generating high volume of service call.
>>>>> 
>>>>> - Alain.
>>>> 
>>>> But the only place it will matter in these cases is the home gateways.
>>> 
>>> Actually it exists anywhere a home pc is directly connected to the cable modem, like my grandfathers house for example...
>>> 
>>> And, the logic exists in home gateways, that you can buy at frys, they say linksys on them, and and d-link and so forth.
>>> 
>> 
>> Any place NAT444 gets implemented with non-1918 addresses (which I think is likely to be the vast majority of NAT444
>> deployments), this assumption will break. Allocating this /10 won't change that fact, it will just reduce the total number
>> of addresses allocated for that purpose _AND_ allow firmware updates to address that breakage if the CPE/OS vendors
>> choose to do so.
>> 
>> Owen
>> 
> 
> 
> This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.
> 

Your opinion is not shared by the majority of network operators. I would regard the choice as more of a business decision than one that ARIN or the IETF should inflict upon them.


Owen



From adurand at juniper.net  Wed Jun 29 18:06:11 2011
From: adurand at juniper.net (Alain Durand)
Date: Wed, 29 Jun 2011 15:06:11 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <5CF14D23-4C3C-4C1A-A52B-E24F92BD73F6@delong.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
	<8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
	<BDD78492-AD5E-40F6-9727-2565283008F5@delong.com> <0F1A1F53-!
	FF02-4D79-B9C9-FBE26D346635@juniper.net>
	<5CF14D23-4C3C-4C1A-A52B-E24F92BD73F6@delong.com>
Message-ID: <8171FFFB-B8C4-492D-996F-AD103FFA58CF@juniper.net>


On Jun 29, 2011, at 4:52 PM, Owen DeLong wrote:

>> 
>> This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.
>> 
> 
> Your opinion is not shared by the majority of network operators. I would regard the choice as more of a business decision than one that ARIN or the IETF should inflict upon them.

My concern is that the technical breakage caused by extending RFC1918 have been seriously underestimated by the proponents of 2011-5.
An ISP making the business decision to use an overlapping part of its address space is one thing, ARIN augmenting RFC1918 in another.

    - Alain.

From owen at delong.com  Wed Jun 29 19:00:52 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jun 2011 16:00:52 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <8171FFFB-B8C4-492D-996F-AD103FFA58CF@juniper.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<699C3928-09E4-43EF-9AFE-F8EAEAF2967D@delong.com>
	<8C394C32-D3E3-468B-A86F-3E145F56F3C5@bogus.com>
	<BDD78492-AD5E-40F6-9727-2565283008F5@delong.com> <0F1A1F53-!
	! FF02-4D79-B9C9-FBE26D346635@juniper.net>
	<5CF14D23-4C3C-4C1A-A52B-E24F92BD73F6@delong.com>
	<8171FFFB-B8C4-492D-996F-AD103FFA58CF@juniper.net>
Message-ID: <BAA6DB10-8FE7-49D2-A420-AA9024D8E08C@delong.com>


On Jun 29, 2011, at 3:06 PM, Alain Durand wrote:

> 
> On Jun 29, 2011, at 4:52 PM, Owen DeLong wrote:
> 
>>> 
>>> This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.
>>> 
>> 
>> Your opinion is not shared by the majority of network operators. I would regard the choice as more of a business decision than one that ARIN or the IETF should inflict upon them.
> 
> My concern is that the technical breakage caused by extending RFC1918 have been seriously underestimated by the proponents of 2011-5.
> An ISP making the business decision to use an overlapping part of its address space is one thing, ARIN augmenting RFC1918 in another.
> 
>    - Alain.

It wouldn't be an overlapping part of their address space, but, it would cause all the same issues for all the same customers, so the only differences I see between the ISP doing so and ARIN doing so are:

	1.	Firmware/software updates cannot be created to address the breakage since it will be a random assortment
		of GUA instead of a consistent well known /10 that can be added to the exception list.

	2.	It will consume more GUA for each ISP to have their own pool.

	3.	As a result of the increased GUA consumption, more customers will be afflicted with LSN (NAT444).

Seems to me that each of those makes a consistent well known /10 the preferable alternative for reducing the likely amount of breakage, mitigating that breakage more easily, and reducing the unnecessary GUA consumption. If ARIN/IETF make the pool available, then, providers that will do this anyway can at least use a consistent pool. Those who believe that 1918 conflicts will generate less support costs than GUA-based breakage can still use 1918. If we don't allocate the space, then, the providers that do not want to use 1918 will likely use disparate GUA spaces leading to all of the problems described above.

Owen



From bill at herrin.us  Wed Jun 29 19:44:47 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jun 2011 19:44:47 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <AE8AAC3E-9FB8-4B52-8798-B3511A645615@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<AE8AAC3E-9FB8-4B52-8798-B3511A645615@bogus.com>
Message-ID: <BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>

On Wed, Jun 29, 2011 at 12:55 PM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jun 29, 2011, at 8:14 AM, William Herrin wrote:
>> On Wed, Jun 29, 2011 at 10:59 AM, Alain Durand <adurand at juniper.net> wrote:
>>> On Jun 29, 2011, at 10:35 AM, William Herrin wrote:
>>>> You'll have to elaborate on that, because while windows firewall makes
>>>> assumptions about what it's allowed to do if it encounters an RFC1918
>>>> address, it makes no assumptions I'm aware of about what it can do
>>>> with an address that isn't. If anything, the ISP choosing to employ
>>>> RFC1918 addresses would cause Windows to incorrectly configure a
>>>> permissive firewall.
>>>
>>> If [public address] then start 6to4
>>
>> Never seen it. And they'd be seriously crazy to enable it by default
>> -- it would cause incredible brokenness even when the assumptions were
>> met.
>
> Sorry it's on by default in windows vista and windows 7...

As a Linux enthusiast, I enjoy tales of Microsoft doing something
ignorant. And truly, what could be more foolish than arranging for
your flagship product to automatically reroute packets through
low-bandwidth volunteer-run 6to4 gateways?

Sadly, I must report the story to be false. My Windows 7 laptop did
not, in fact, install a 6to4 adapter or configure an IPv6 address when
I reprogrammed my DHCP server to give out a global scope IPv4 address.
And the Teredo Tunneling interface remained in state "Media
disconnected." Indeed, only the normal fe80 link local IPv6 address
configured itself on my machine.

You are mistaken sir.

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 victor.kuarsingh at gmail.com  Wed Jun 29 21:10:54 2011
From: victor.kuarsingh at gmail.com (Victor Kuarsingh)
Date: Wed, 29 Jun 2011 21:10:54 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <8171FFFB-B8C4-492D-996F-AD103FFA58CF@juniper.net>
Message-ID: <CA3142F4.F7FA%victor.kuarsingh@gmail.com>



On 11-06-29 6:06 PM, "Alain Durand" <adurand at juniper.net> wrote:

>
>On Jun 29, 2011, at 4:52 PM, Owen DeLong wrote:
>
>>> 
>>> This is why going with RFC1918 is the safest choice. Dealing with
>>>inside/outside address range conflict is,  IMHO, much easier than
>>>dealing with the brokeness induced here.
>>> 
>> 
>> Your opinion is not shared by the majority of network operators. I
>>would regard the choice as more of a business decision than one that
>>ARIN or the IETF should inflict upon them.
>
>My concern is that the technical breakage caused by extending RFC1918
>have been seriously underestimated by the proponents of 2011-5.
>An ISP making the business decision to use an overlapping part of its
>address space is one thing, ARIN augmenting RFC1918 in another.

Very interesting and opinionated discussion.

>From an operator's point of view...

We have tested GUA space and RFC1918 in CGN trials.  Results - RFC1918 [no
go], GUA [manageable].

We have found issues in our network attempting to run RFC1918 addresses in
the CGN zone.  These reasons may be the same as others, or slightly
different.

Either way, we need to use GUA space... So the community is either going
to make this workable with the /10, or will subject the real Internet
Customers to not just the pain of NAT444, but NAT444 with all kinds of
dissimilar ways of finding GUA space (squatting etc).  Again, I don't like
CGN, but my dislike for a technology is not a determining factor as to
whether I need to use it.

I do appreciate the concerns of some on the list about trying to contain
brokenness, but the fact remains that operators have said (for many
reasons) that GUA space will be needed.

Yes, there are some know issues (like 6to4), but these issues will be
anticipated and managed by the Operators.

I think continuing to argue against the 2011-5 /10 proposal at this point
is just making the inevitable more difficult for operators and therefore
real Internet Customers.

Regards,

Victor Kuarsingh



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




From jmaimon at chl.com  Wed Jun 29 23:03:51 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 29 Jun 2011 23:03:51 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <126B0ABA-4C7B-4A34-BAA3-8905DC5FEBDC@delong.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>	<20110629185416.018450e2@opy.nosense.org>	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
	<4E0B2061.3090000@chl.com>
	<126B0ABA-4C7B-4A34-BAA3-8905DC5FEBDC@delong.com>
Message-ID: <4E0BE797.5080107@chl.com>



Owen DeLong wrote:
> On Jun 29, 2011, at 5:53 AM, Joe Maimon wrote:
>    
>> Precisely. Expect organizations who have had sufficient positive results with their NAT444 deployments to not limit it to new users only, for many reasons, some of which they cannot be faulted for.
>>
>>      
> Why? And what about all the other organizations that have had sufficient negative results?
>    

I cant see how the solution can be usable for new customers but not for 
old. Either it works for both or it works for neither.

>> Some of these organizations will as a result have more available resources then anybody else put together.
>>
>>      
> This is relevant how?
>
>    

A reality in where the vast majority of available ipv4 resources are 
held by a group of entities other than RiRs should have some relevancy 
somewhere in policy discussions, perhaps along with policies that help 
to further those odds.


Joe


From jmaimon at chl.com  Wed Jun 29 23:03:58 2011
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 29 Jun 2011 23:03:58 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <B0965871-9F28-42B7-88E5-A5170676A930@delong.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<4E0B23ED.5040504@chl.com>
	<B0965871-9F28-42B7-88E5-A5170676A930@delong.com>
Message-ID: <4E0BE79E.2050606@chl.com>



Owen DeLong wrote:
> On Jun 29, 2011, at 6:09 AM, Joe Maimon wrote:
>
>    
>> Due to the support issue, no provider in their right mind is going to 
>> share addresses across multiple customers.
>> Apparently, when it comes to support issue, the question remains one of degree. And I disagree sharply with you as to the effect on the equation the use of 1918 brings.
>>
>>      
> You can disagree all you want, but, the majority of (large) providers that have studied the issue do not.
>    

Frankly, the advantages to them are clear. It is the disadvantages which 
are far less clear, studied or not. And I am including as an advantage 
the likelyhood that non-rfc1918 happen to look prettier and shinier to 
customers.

>> False dichotomy.
>>
>> Or providers will use GUA regardless of the /10. Or providers will pool a collection together. Or providers will go ahead and use space that already exists, either their own or rfc1918 or even 240/4.
>>
>>      
> Lack of support in the CPE makes 240/4 a likely non-starter for this.
>    

If a CPE update to roll out DS-Lite is on the table, not to mention 
ipv6, so is 240/4.

> RFC-1918 is also a non-starter for most of the large providers. They'll get GUA allocations before they'll use 1918 in most cases.
>    
That is assuming it is available. And if it is available, why wouldnt 
they get it? False dichotomy. They will get gua until they cant get no 
more and then they will use 1918 or whatever else is available.

>> Even if they do not find those options as attractive as this /10.
>>
>>      
> If I were to rank the options in order of attractiveness (from an ISP perspective), they would be:
>
> 	2011-5
>    
Benefits only a specific segment of the community, ignores the needs of 
the rest.
> 	Consortium-based assignment
>    
Has its own advantages.
> 	Community pool of GUA addresses
>    
Just a variation of above
> 	New GUA allocations or assignments from RIR (individually to various ISPs)
>    
Going to happen anyway
> 	Use of existing GUA space (forcing some fraction of existing customers into NAT-444 degraded services)
>    
Going to happen anyway
> 	Use of RFC-1918 space
>    
Which will work well enough with some intelligence applied.
> 	Use of 240/4
>    
Continuously torpedoed by self fulfilling prophets.
> I'm pretty sure that they'll find a way to make one of the top 4 work. Since the first 3 basically boil down to the same effect as 2011-5, I would say that it's a relatively safe bet that the dichotomy between 1-3 and 4 is a valid and accurate one.
>
> Owen
>
>
>    

Joe



From joelja at bogus.com  Thu Jun 30 02:15:25 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jun 2011 23:15:25 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com> <A!
	E8AAC3E-9FB8-4B52-8798-B3511A645615@bogus.com>
	<BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
Message-ID: <8D626745-0294-4E82-8816-65C21F36B0C2@bogus.com>


On Jun 29, 2011, at 4:44 PM, William Herrin wrote:

> On Wed, Jun 29, 2011 at 12:55 PM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Jun 29, 2011, at 8:14 AM, William Herrin wrote:
>>> On Wed, Jun 29, 2011 at 10:59 AM, Alain Durand <adurand at juniper.net> wrote:
>>>> On Jun 29, 2011, at 10:35 AM, William Herrin wrote:
>>>>> You'll have to elaborate on that, because while windows firewall makes
>>>>> assumptions about what it's allowed to do if it encounters an RFC1918
>>>>> address, it makes no assumptions I'm aware of about what it can do
>>>>> with an address that isn't. If anything, the ISP choosing to employ
>>>>> RFC1918 addresses would cause Windows to incorrectly configure a
>>>>> permissive firewall.
>>>> 
>>>> If [public address] then start 6to4
>>> 
>>> Never seen it. And they'd be seriously crazy to enable it by default
>>> -- it would cause incredible brokenness even when the assumptions were
>>> met.
>> 
>> Sorry it's on by default in windows vista and windows 7...
> 
> Sadly, I must report the story to be false. My Windows 7 laptop did
> not, in fact, install a 6to4 adapter or configure an IPv6 address when
> I reprogrammed my DHCP server to give out a global scope IPv4 address.
> And the Teredo Tunneling interface remained in state "Media
> disconnected." Indeed, only the normal fe80 link local IPv6 address
> configured itself on my machine.

This is a freshly imaged windows 7 home premium machine... you will see that with a public ip address on it's ethernet interface it has a  6to4 address and without one it does not. This is the documented and intended behavior of  the stack. you will note that the 6to4 tunnel interface ip is 2002:80df:990b::80df:990b which maps to 128.223.153.11

with public ip address

C:\Users\joelja>ipconfig

Windows IP Configuration


Ethernet adapter Realtek onboard:

  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::8d98:3b82:299a:80b7%26
  IPv4 Address. . . . . . . . . . . : 128.223.153.11
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . : 128.223.153.1

Ethernet adapter Bluetooth Network Connection 3:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Ethernet adapter VMware Network Adapter VMnet1:

  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::c4b9:aa98:5bc0:52a%18
  IPv4 Address. . . . . . . . . . . : 192.168.129.1
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet8:

  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::5530:2f18:ad9e:5910%19
  IPv4 Address. . . . . . . . . . . : 192.168.110.1
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Tunnel adapter isatap.{7D1E1580-FF9E-4DB5-89DB-D3F24FC6657D}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{960F19DD-CE5A-414F-864B-F39D6B9EB772}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{3B4419D2-0911-4067-A157-F13E2C9DEBAE}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter Teredo Tunneling Pseudo-Interface:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter 6TO4 Adapter:

  Connection-specific DNS Suffix  . :
  IPv6 Address. . . . . . . . . . . : 2002:80df:990b::80df:990b
  Default Gateway . . . . . . . . . :

Tunnel adapter isatap.lan:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

this is without it.

C:\Users\joelja>ipconfig

Windows IP Configuration


Ethernet adapter Realtek onboard:

  Connection-specific DNS Suffix  . : lan
  Link-local IPv6 Address . . . . . : fe80::8d98:3b82:299a:80b7%26
  IPv4 Address. . . . . . . . . . . : 192.168.1.135
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter Bluetooth Network Connection 3:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Ethernet adapter VMware Network Adapter VMnet1:

  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::c4b9:aa98:5bc0:52a%18
  IPv4 Address. . . . . . . . . . . : 192.168.129.1
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet8:

  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::5530:2f18:ad9e:5910%19
  IPv4 Address. . . . . . . . . . . : 192.168.110.1
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Tunnel adapter isatap.{7D1E1580-FF9E-4DB5-89DB-D3F24FC6657D}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{960F19DD-CE5A-414F-864B-F39D6B9EB772}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{3B4419D2-0911-4067-A157-F13E2C9DEBAE}:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter Teredo Tunneling Pseudo-Interface:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . :

Tunnel adapter isatap.lan:

  Media State . . . . . . . . . . . : Media disconnected
  Connection-specific DNS Suffix  . : lan


> You are mistaken sir.

I would like an apology.

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



From owen at delong.com  Thu Jun 30 06:54:52 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Jun 2011 03:54:52 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <4E0BE797.5080107@chl.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>	<20110629185416.018450e2@opy.nosense.org>	<CE5B6149-FFE1-4468-BC1D-025A7742ACE5@delong.com>
	<20110629200358.4e70541b@opy.nosense.org>
	<4E0B2061.3090000@chl.com>
	<126B0ABA-4C7B-4A34-BAA3-8905DC5FEBDC@delong.com>
	<4E0BE797.5080107@chl.com>
Message-ID: <8A0175D1-7534-40E2-A74C-5D848F4F508C@delong.com>


On Jun 29, 2011, at 8:03 PM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> On Jun 29, 2011, at 5:53 AM, Joe Maimon wrote:
>>   
>>> Precisely. Expect organizations who have had sufficient positive results with their NAT444 deployments to not limit it to new users only, for many reasons, some of which they cannot be faulted for.
>>> 
>>>     
>> Why? And what about all the other organizations that have had sufficient negative results?
>>   
> 
> I cant see how the solution can be usable for new customers but not for old. Either it works for both or it works for neither.
> 

I have existing customers. They like the service they have. They may leave if I degrade their service. I run out of addresses.

New customers may not sign up for my NAT444 service, but, it's all I can offer them.

I certainly don't want to encourage my existing customers to leave by subjecting them to degraded service compared to what they are used to. I have to accept that my ability to attract new customers may be limited by the amount of native IPv4 space I can obtain. There is no way around that fact.

>>> Some of these organizations will as a result have more available resources then anybody else put together.
>>> 
>>>     
>> This is relevant how?
>> 
>>   
> 
> A reality in where the vast majority of available ipv4 resources are held by a group of entities other than RiRs should have some relevancy somewhere in policy discussions, perhaps along with policies that help to further those odds.
> 

I don't see how it is relevant to the discussion of this policy. This policy doesn't affect that and there's really nothing we can do to improve this policy by considering that issue.

Owen



From owen at delong.com  Thu Jun 30 07:04:28 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Jun 2011 04:04:28 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <4E0BE79E.2050606@chl.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<4E0B23ED.5040504@chl.com>
	<B0965871-9F28-42B7-88E5-A5170676A930@delong.com>
	<4E0BE79E.2050606@chl.com>
Message-ID: <E69D73B4-040F-4A8F-AED0-5D62114E755F@delong.com>

> 
>> RFC-1918 is also a non-starter for most of the large providers. They'll get GUA allocations before they'll use 1918 in most cases.
>>   
> That is assuming it is available. And if it is available, why wouldnt they get it? False dichotomy. They will get gua until they cant get no more and then they will use 1918 or whatever else is available.
> 

Yes, they will get GUA until they can't get more. The question is whether we make it possible to make more of that GUA available for traditional usage (better for the providers and the internet in general) or whether we force providers to each reserve some portion of the GUA they can get near runout for an intermediate NAT444 pool. In the latter case, we consume multiple different address spaces out of the global free pool for this purpose removing it from other uses. In the case of the /10 granted under this policy, we allow all ISPs to draw that space from a common pool, leaving the space outside of this single /10 available for other uses.

>>> Even if they do not find those options as attractive as this /10.
>>> 
>>>     
>> If I were to rank the options in order of attractiveness (from an ISP perspective), they would be:
>> 
>> 	2011-5
>>   
> Benefits only a specific segment of the community, ignores the needs of the rest.

That segment of the community happens to provide services to something on the order of 75% of the users of the internet, so, I wouldn't exactly say we're looking to benefit a handful of corner cases here.

>> 	Consortium-based assignment
>>   
> Has its own advantages.

And many disadvantages, not the least of which is it is unclear whether ARIN would approve such an assignment.

>> 	Community pool of GUA addresses
>>   
> Just a variation of above

Yep.

>> 	New GUA allocations or assignments from RIR (individually to various ISPs)
>>   
> Going to happen anyway

Not really.

If we do this, they may get other allocations/assignments, but, they'll get them for other purposes. If we don't do this, then, much more than a /10 may well get collectively reserved by various ISPs for this purpose and not shared. You cannot ignore the fact that this will take address space away from other usage.

>> 	Use of existing GUA space (forcing some fraction of existing customers into NAT-444 degraded services)
>>   
> Going to happen anyway

I am not convinced of this. I know of several providers that if they have this space available do not plan to take addresses away from existing customers to support their NAT444 deployment and do not plan to degrade their existing customers, instead, inflicting NAT444 only on new customers and volunteers.

Were I running an ISP where I actually wanted to keep my customers, that's certainly the approach I would take. (I work for an ISP, but, I don't run one).

>> 	Use of RFC-1918 space
>>   
> Which will work well enough with some intelligence applied.

Only if you're running a much smaller network with much larger margins than is the case for the large residential ISPs that I have discussed the matter with.

>> 	Use of 240/4
>>   
> Continuously torpedoed by self fulfilling prophets.

Studied multiple times and rejected on the basis that the amount of software that would have to be modified is roughly equivalent effort to the software modifications required to switch to IPv6 without the dividends provided by IPv6. Seems like a poor investment of time and effort to me.

Owen

>> I'm pretty sure that they'll find a way to make one of the top 4 work. Since the first 3 basically boil down to the same effect as 2011-5, I would say that it's a relatively safe bet that the dichotomy between 1-3 and 4 is a valid and accurate one.
>> 
>> Owen
>> 
>> 
>>   
> 
> Joe
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Thu Jun 30 09:46:47 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jun 2011 09:46:47 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <8D626745-0294-4E82-8816-65C21F36B0C2@bogus.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
	<8D626745-0294-4E82-8816-65C21F36B0C2@bogus.com>
Message-ID: <BANLkTikh7r0DU17gKHVrCWEJ=MNj0Dh=hA@mail.gmail.com>

On Thu, Jun 30, 2011 at 2:15 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> On Jun 29, 2011, at 4:44 PM, William Herrin wrote:
>> You are mistaken sir.
>
> I would like an apology.

Joel,

Your experience differs from others'. Is it because you tested with
home premium and I tested with another version? Is it because you
tested with the rare store-bought version while I tested with a
preinstall? Is it because you tested with an unpatched version while
my service pack and patches are up to date?

I also can't help but notice that your "freshly installed" windows
already has vmware server on it. What other extra features and
software were installed that aren't ordinarily there?

When you can explain why your experience differs from everybody
else's, we'll talk about who is owed an apology.

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 alh-ietf at tndh.net  Thu Jun 30 09:49:56 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 30 Jun 2011 06:49:56 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>	<AE
	8AAC3E-9FB8-4B52-8798- B3511A645615@bogus.com>
	<BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
Message-ID: <01b701cc372c$9a425970$cec70c50$@net>

William Herrin wrote:
> On Wed, Jun 29, 2011 at 12:55 PM, Joel Jaeggli <joelja at bogus.com>
> wrote:
> > On Jun 29, 2011, at 8:14 AM, William Herrin wrote:
> >> On Wed, Jun 29, 2011 at 10:59 AM, Alain Durand <adurand at juniper.net>
> wrote:
> >>> On Jun 29, 2011, at 10:35 AM, William Herrin wrote:
> >>>> You'll have to elaborate on that, because while windows firewall
> makes
> >>>> assumptions about what it's allowed to do if it encounters an
> RFC1918
> >>>> address, it makes no assumptions I'm aware of about what it can do
> >>>> with an address that isn't. If anything, the ISP choosing to
> employ
> >>>> RFC1918 addresses would cause Windows to incorrectly configure a
> >>>> permissive firewall.
> >>>
> >>> If [public address] then start 6to4
> >>
> >> Never seen it. And they'd be seriously crazy to enable it by default
> >> -- it would cause incredible brokenness even when the assumptions
> were
> >> met.
> >
> > Sorry it's on by default in windows vista and windows 7...
> 
> As a Linux enthusiast, I enjoy tales of Microsoft doing something
> ignorant. And truly, what could be more foolish than arranging for
> your flagship product to automatically reroute packets through
> low-bandwidth volunteer-run 6to4 gateways?

The braindead concept that 6to4 gateways are required is driven by the
myopic view of the content providers. Look closely at the technology, and
you will find that those are artifacts, not a fundamental requirement of
packet delivery. If the content providers would simply add a local 6to4
router (note I said router, not relay), then add a 2002:: prefix to their
content servers, the packet delivery path would be *-exactly-* the same as
it is for IPv4. 


> 
> Sadly, I must report the story to be false. My Windows 7 laptop did
> not, in fact, install a 6to4 adapter or configure an IPv6 address when
> I reprogrammed my DHCP server to give out a global scope IPv4 address.
> And the Teredo Tunneling interface remained in state "Media
> disconnected." Indeed, only the normal fe80 link local IPv6 address
> configured itself on my machine.
> 
> You are mistaken sir.

Look around, because your symptoms indicate there is an IPv4 firewall
filtering both 6to4 and teredo packets. 

Tony



> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From farmer at umn.edu  Thu Jun 30 10:01:43 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 30 Jun 2011 09:01:43 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu>
	<78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
Message-ID: <4E0C81C7.8070409@umn.edu>

On 6/29/11 01:40 CDT, John Curran wrote:
> On Jun 28, 2011, at 3:05 AM, David Farmer wrote:
>
>> I would like to request John and ARIN staff to investigate possible precedent documented in RFC 3849[1] by the allocation of 2001:DB8::/32 by APNIC.  My interpretation of the text in the RFC is that APNIC passed a policy allocating a prefix for documentation purposes and then members of the APNIC community authored an Informational RFC documenting the allocation and the technical justifications to the IETF.
>
> David - I'm quite familiar with the RFC 3849 document, but that does not
> automatically alter the existing agreements which outline the roles of the
> IANA and the RIRs (and one might readily argue that there is far more at
> issue with shared transition reservation versus a documentation prefix...)

Thank you, John.

I agree there is definitely more at stake than in the case of the 
documentation prefix.

In reviewing RFC 2860 again and the IAB response you provided, I no 
longer believe ARIN should move forward with any action on 2011-5 
without express direction from the IAB.  I have come to this conclusion 
because of section 4.2 of RFC 2860 which defines the IAB as the arbiter 
of any conflict between IESG and IANA (ARIN in this case).  Originally, 
I was focusing on section 4.3 as that is what was quoted in your inquiry 
and the response.

> Note - this doesn't mean that your suggestion regarding the next step isn't
> perfectly reasonable, as follows:
>
>> Therefore, I would like to suggest representatives from the ARIN Community, and the ARIN AC, author and submit and Informational RFC documenting the allocation of the /10 per ARIN policy development process, including the technical details and justification surrounding it.
>
> I believe that there are folks working on exactly that: I know that Chris
> Grundemann and Benson Schliesser both expressed interest to me to working
> on this effort, and I encourage anyone else interested in helping out to
> reach out to them accordingly.

I will provide specific suggestions and feedback for such an Internet 
Draft elsewhere on the thread.  However, here I think it is important to 
mention that; the intent of the ID should be, and I believe the intent 
of 2011-5 is, that this allocation is a necessary option and preferable 
to multiple providers requesting separate allocations from the RIRs.  It 
is this later possible outcome that makes this more than just a 
technical allocation that is a matter for the IETF and that has 
addressing policy implications that at least overlap the ARIN policy 
community's interests.

Beyond focusing on the needs of some operators for an option other than 
just classic RFC 1918 allocated space, the ID should be clear it is not 
prescribing the use of this allocation either and should probably 
recommend the use of RFC 1918 space as preferable when that is possible. 
Further, it should be honest about the short comings of use the 
allocation and should suggest technical means of mitigating these short 
coming where possible.

To put it plainly, there isn't a good option available here, only bad 
options, in such a situation it is usually best to provide several 
option and allow the local conditions to dictated what the least-worst 
option is on a case-by-case basis.

>> And, once the Draft is submitted, the board move forward with implementing 2011-5 based on the precedence of the allocation of 2001:DB8::/32 by APNIC, as documented in RFC3849.  I believe RFC2860 is clear that the IETF has a role, and it is desirable and necessary that such an allocation should be documented in RFCs, but it is not clear to me that ARIN cannot and MUST not make such an allocation base on the clear policy will of its community, especially based on the precedent of RFC 3849.
>
> I will convey this to the ARIN Board as one possible course of action
> when it considers the IAB response. Making the reservation for this
> purpose without conferring with IAB would not have respected the nature
> of the ARIN/IANA relationship, and the exact degree of engagement with
> the IETF community which is most appropriate is a matter of judgement.
> To the extent that we have a clear document in the IETF which explains
> why the reservation is needed, along with a strong show of support in
> that community, the path forward will not be difficult.

As I said, I now believe the proper course of action is to hold off on 
any action and coordinate with the IAB.  But, ARIN probably needs to 
clarify its exceptions with the IAB asking for the IAB to ensure fair 
and timely consideration within the IETF and by the IESG, and that any 
delaying tactics would be unacceptable. ARIN should probably reiterate 
that while this may be a technical allocation, it has serious addressing 
policy implications that are within the scope of ARIN's policy process. 
This is not simply a case of forum shopping, the ARIN policy community 
has legitimate concerns regarding this issue and that need to be 
provided equal weight to the technical considerations of the IETF.

Thanks

> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN


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


From alh-ietf at tndh.net  Thu Jun 30 10:15:53 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 30 Jun 2011 07:15:53 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikh7r0DU17gKHVrCWEJ=MNj0Dh=hA@mail.gmail.com>
References: <4D596163.7000009@arin.net>	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>	<4E0928EF.8030702@umn.edu>
	<20110628052528.GB23316@nsn.com>	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>	<BA
	NLkTiko=A01vQpBNdBs+6d
	Y9kjHBNfYDQ@mail.gmail.com>	<8D626745-0294-4E82-8816-65C21F36B0C2@bogus.com>
	<BANLkTikh7r0DU17gKHVrCWEJ=MNj0Dh=hA@mail.gmail.com>
Message-ID: <01d301cc3730$3a664300$af32c900$@net>

William Herrin wrote:
> On Thu, Jun 30, 2011 at 2:15 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> > On Jun 29, 2011, at 4:44 PM, William Herrin wrote:
> >> You are mistaken sir.
> >
> > I would like an apology.
> 
> Joel,
> 
> Your experience differs from others'. Is it because you tested with
> home premium and I tested with another version? Is it because you
> tested with the rare store-bought version while I tested with a
> preinstall? Is it because you tested with an unpatched version while
> my service pack and patches are up to date?
> 
> I also can't help but notice that your "freshly installed" windows
> already has vmware server on it. What other extra features and
> software were installed that aren't ordinarily there?
> 
> When you can explain why your experience differs from everybody
> else's, we'll talk about who is owed an apology.

The defined behavior for Vista onward is for IPv6 to be on by default, and
attempt the most efficient tunneling in sequence when native is not on the
local network, and the previous tunnel failed. This is not SKU dependent, as
the stack is common across Vista/W7/Server2008/SBS2008/SBS2011. It really
doesn't matter what apps get installed, this is the core Windows stack
functionality. 

The only difference you will find between service pack versions of those is
in recent address selection policy changes. Those changes are not the most
effective for getting IPv6 enabled applications deployed, but they are
pragmatic in the face of the lame infrastructure deployment that is still
not really happening. The most significant difference is found between the
current stack and the XP/W2003 stack, but even in the older stack the tunnel
approach is consistent.

The entire point of tunneling from the host was to "make the API just work".
It was clear a decade ago that infrastructure providers would not deploy
until there were apps, but app developers couldn't make progress without a
network. To break the stalemate I put the stake in the ground that the API
would just work and the stack would take care of the details of making that
happen. It will always defer to native, and will prefer the most efficient
mechanism first, but at the end of the day bit delivery was the point. 

Where that falls down is that the content providers have decided they want
to play a purest game of 'the single address model is how I do IPv4 and I
will do the same for IPv6'. By refusing to put content directly on the "IPv4
as a global NBMA L2" infrastructure, they force traffic through 3rd parties.
This is not a technology requirement, it is an operational choice, and even
when the Dr. says "stop banging your head against the wall and it will stop
hurting", they continue to insist on historical practice.

Given your local system doesn't seem to be establishing tunnels, I suspect
you will find there is an IPv4 firewall blocking both protocol 41 and the
UDP port teredo needs. If you watch it will likely also be asking DNS for
isatap.your.domain because it is not getting anything native to work with.
It will periodically try all 3 tunnels unless it hears a native RA, and even
if one tunnel technology gets established, it will periodically try more
efficient ones and switch to the 'best available'. Again, the point is that
app developers don't want to care about how bits get delivered, they just
want their app to work without causing them support nightmares. Synchronized
global deployment is not going to happen, and anything less becomes a
nightmare for app support. Masking over the haphazard native deployment
events is the only way to break the stalemate.

Tony


> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Thu Jun 30 10:15:53 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jun 2011 10:15:53 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <01b701cc372c$9a425970$cec70c50$@net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<BANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
	<01b701cc372c$9a425970$cec70c50$@net>
Message-ID: <BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>

On Thu, Jun 30, 2011 at 9:49 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> The braindead concept that 6to4 gateways are required is driven by the
> myopic view of the content providers.

Tony,

I wish that was the case. Sadly, traffic is two-way. Even if the
content providers encapsulate the packets back to IPv4 before they
leave their network, the the client-side's nearest usually
volunteer-run anycast gateway from the v4 to the v6 core also has to
be reasonably located.

I like the 6to4 protocol. I too wish its use had turned out
differently. But the unfortunate choice not to allow its prefixes to
migrate into the global table guaranteed it would be a side show
instead of the major transition tool that would have smoothed the path
into v6.


>> Sadly, I must report the story to be false. My Windows 7 laptop did
>> not, in fact, install a 6to4 adapter or configure an IPv6 address when
>> I reprogrammed my DHCP server to give out a global scope IPv4 address.
>> And the Teredo Tunneling interface remained in state "Media
>> disconnected." Indeed, only the normal fe80 link local IPv6 address
>> configured itself on my machine.
>>
>> You are mistaken sir.
>
> Look around, because your symptoms indicate there is an IPv4 firewall
> filtering both 6to4 and teredo packets.

Ordinarily. However, in my tests last night I removed that equipment
from the path. And I should know. I personally built the network in
question all the way out to where it trades BGP upstream.

But then, if Windows is smart enough to test for actual connectivity
before bringing up a v6 auto-tunnel my point is proven anyway. It'll
fail to find 6to4 connectivity in the NAT444 scenario using a public
scope IPv4 address, invalidating Joel's claim of relevance to ARIN
proposal 2011-5.

Regards,
Bill Herrin



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


From cengel at conxeo.com  Thu Jun 30 10:41:32 2011
From: cengel at conxeo.com (Chris Engel)
Date: Thu, 30 Jun 2011 10:41:32 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB30EBC28FFCA@Skyhawk>





> William Herrin wrote:
> > On Thu, Jun 30, 2011 at 2:15 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> > > On Jun 29, 2011, at 4:44 PM, William Herrin wrote:
> > >> You are mistaken sir.
> > >
> > > I would like an apology.
> >
> > Joel,
> >
> > Your experience differs from others'. Is it because you tested with
> > home premium and I tested with another version? Is it because you
> > tested with the rare store-bought version while I tested with a
> > preinstall? Is it because you tested with an unpatched version while
> > my service pack and patches are up to date?
> >
> > I also can't help but notice that your "freshly installed" windows
> > already has vmware server on it. What other extra features and
> > software were installed that aren't ordinarily there?
> >
> > When you can explain why your experience differs from everybody
> > else's, we'll talk about who is owed an apology.
> 
> The defined behavior for Vista onward is for IPv6 to be on by default, and
> attempt the most efficient tunneling in sequence when native is not on the
> local network, and the previous tunnel failed. This is not SKU dependent, as
> the stack is common across Vista/W7/Server2008/SBS2008/SBS2011. It really
> doesn't matter what apps get installed, this is the core Windows stack
> functionality.
> 
> The only difference you will find between service pack versions of those is
> in recent address selection policy changes. Those changes are not the most
> effective for getting IPv6 enabled applications deployed, but they are
> pragmatic in the face of the lame infrastructure deployment that is still
> not really happening. The most significant difference is found between the
> current stack and the XP/W2003 stack, but even in the older stack the tunnel
> approach is consistent.
> 
> The entire point of tunneling from the host was to "make the API just work".
> It was clear a decade ago that infrastructure providers would not deploy
> until there were apps, but app developers couldn't make progress without a
> network. To break the stalemate I put the stake in the ground that the API
> would just work and the stack would take care of the details of making that
> happen. It will always defer to native, and will prefer the most efficient
> mechanism first, but at the end of the day bit delivery was the point.
> 
> Where that falls down is that the content providers have decided they want
> to play a purest game of 'the single address model is how I do IPv4 and I
> will do the same for IPv6'. By refusing to put content directly on the "IPv4
> as a global NBMA L2" infrastructure, they force traffic through 3rd parties.
> This is not a technology requirement, it is an operational choice, and even
> when the Dr. says "stop banging your head against the wall and it will stop
> hurting", they continue to insist on historical practice.
> 
> Given your local system doesn't seem to be establishing tunnels, I suspect
> you will find there is an IPv4 firewall blocking both protocol 41 and the
> UDP port teredo needs. If you watch it will likely also be asking DNS for
> isatap.your.domain because it is not getting anything native to work with.
> It will periodically try all 3 tunnels unless it hears a native RA, and even
> if one tunnel technology gets established, it will periodically try more
> efficient ones and switch to the 'best available'. Again, the point is that
> app developers don't want to care about how bits get delivered, they just
> want their app to work without causing them support nightmares.
> Synchronized
> global deployment is not going to happen, and anything less becomes a
> nightmare for app support. Masking over the haphazard native deployment
> events is the only way to break the stalemate.
> 
> Tony
> 

I can confirm that Tony's description of the Vista/Win7/Server 2008 stack matches the behavior we've seen on all the OEM installs we've gotten in from that generation. It's why unbinding IPv6 and disabling teredo are part of are standard setup routine for all Windows machines. The two inevitably cause things to break within the Enterprise and are a potential security complication as well. But I can confirm that MS doggedly does it's best to try to get you to use them, whether you want to or not ;)


Christopher Engel




From alh-ietf at tndh.net  Thu Jun 30 11:10:52 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 30 Jun 2011 08:10:52 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com> <BA
	NLkTiko=A01vQpBNdBs+6d
	Y9kjHBNfYDQ@mail.gmail.com> <01b701cc372c$9a425970$cec70c50$@net>
	<BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
Message-ID: <020401cc3737$e885bef0$b9913cd0$@net>

William Herrin:

> On Thu, Jun 30, 2011 at 9:49 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> > The braindead concept that 6to4 gateways are required is driven by
> the
> > myopic view of the content providers.
> 
> Tony,
> 
> I wish that was the case. Sadly, traffic is two-way. Even if the
> content providers encapsulate the packets back to IPv4 before they
> leave their network, the the client-side's nearest usually
> volunteer-run anycast gateway from the v4 to the v6 core also has to
> be reasonably located.

Look closely at the technology. I understand it is two way, and the point is
that if they are running a 6to4 ROUTER (note not -relay- as recent testing
results are doing) they will be doing a peer-to-peer IPv4 encapsulation. The
thing they need to do is ADD a 2002:: prefix to their content. Address
selection on the client will prefer longest match, so if it is in 2002::
space it will pick the 2002:: destination and the 6to4 routers will do
direct encaps to each other. The only time a 3rd party gets involved is when
one end of the conversation is not in 2002:: space.

> 
> I like the 6to4 protocol. I too wish its use had turned out
> differently. But the unfortunate choice not to allow its prefixes to
> migrate into the global table guaranteed it would be a side show
> instead of the major transition tool that would have smoothed the path
> into v6.

This is another FUD / BS / ... position that is an operational choice.
People violate RFCs all the time, but the FUD mindset here puts a one-liner
added at the last minute as sacrosanct. If every access provider ran a 6to4
relay and injected the 2002:local:prefix:: into IPv6 BGP, yes the table
would grow, but it would be exactly the same outcome as deploying 6rd. What
are people doing? They are certainly not concerned about IPv4 table growth,
as they continue to do intentional deaggregation. They are deploying 6rd in
separate prefixes, again not caring about table growth. If someone suggests
that they do the same to support 6to4, all the zealots come out and scream
about violating an RFC. This is nothing more than theatrics intended to
stall deployment...

> 
> 
> >> Sadly, I must report the story to be false. My Windows 7 laptop did
> >> not, in fact, install a 6to4 adapter or configure an IPv6 address
> when
> >> I reprogrammed my DHCP server to give out a global scope IPv4
> address.
> >> And the Teredo Tunneling interface remained in state "Media
> >> disconnected." Indeed, only the normal fe80 link local IPv6 address
> >> configured itself on my machine.
> >>
> >> You are mistaken sir.
> >
> > Look around, because your symptoms indicate there is an IPv4 firewall
> > filtering both 6to4 and teredo packets.
> 
> Ordinarily. However, in my tests last night I removed that equipment
> from the path. And I should know. I personally built the network in
> question all the way out to where it trades BGP upstream.

I understand, but look again. I am not speaking for MSFT, but I was the
program manager the put the stake in the ground and set the direction for
how that stack works and why. This is a much bigger problem than managing a
network, and all the problems created in the network core are noise in the
grand scheme of managing all the application endpoints. This is all about
trade-offs, and sometimes the core has to be less efficient for the good of
the overall eco-system.

> 
> But then, if Windows is smart enough to test for actual connectivity
> before bringing up a v6 auto-tunnel my point is proven anyway. It'll
> fail to find 6to4 connectivity in the NAT444 scenario using a public
> scope IPv4 address, invalidating Joel's claim of relevance to ARIN
> proposal 2011-5.

It doesn't test for connectivity because there is no valid test. Just
because it can or cannot find a relay means nothing in terms of its utility
for peer-to-peer functions. You have to test every endpoint separately
because the logical substrate is an NBMA L2 network. 

Today you will find failure cases where people are using public IPv4 behind
a nat, and that will only be worse as carriers deploy more nat using
non-1918 space. Again, there is no valid test at the 6to4 level to figure
out if this is happening. One might use something like stun to detect the
presence of a nat, but lack of one does not tell you if a firewall is
blocking protocol 41. Both of those will prevent 6to4 from working. Even if
you tested and found a relay at the anycast address, you don't know there is
a valid path. One of the mitigations I tell enterprise managers about is to
deploy a 6to4 relay on the anycast internally, then null-route the back
side. This will both ensure that client systems are not automatically
bypassing firewall rules by tunneling, as well as provide an IPv4 identity
of a client that is attempting to do so if they intended that function to be
turned off. 

The point is there are lots of ways to break things, the trick is to find
ways to make them work without requiring end user awareness, or massive
support structures...

Tony

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



From bill at herrin.us  Thu Jun 30 12:29:37 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jun 2011 12:29:37 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <020401cc3737$e885bef0$b9913cd0$@net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<01b701cc372c$9a425970$cec70c50$@net>
	<BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
	<020401cc3737$e885bef0$b9913cd0$@net>
Message-ID: <BANLkTimvAgB28LbCQD7WLOk0Hfx2O2oUBA@mail.gmail.com>

On Thu, Jun 30, 2011 at 11:10 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> William Herrin:
>> I wish that was the case. Sadly, traffic is two-way. Even if the
>> content providers encapsulate the packets back to IPv4 before they
>> leave their network, the the client-side's nearest usually
>> volunteer-run anycast gateway from the v4 to the v6 core also has to
>> be reasonably located.
>
> Look closely at the technology. I understand it is two way, and the point is
> that if they are running a 6to4 ROUTER (note not -relay- as recent testing
> results are doing) they will be doing a peer-to-peer IPv4 encapsulation. The
> thing they need to do is ADD a 2002:: prefix to their content. Address
> selection on the client will prefer longest match, so if it is in 2002::
> space it will pick the 2002:: destination and the 6to4 routers will do
> direct encaps to each other. The only time a 3rd party gets involved is when
> one end of the conversation is not in 2002:: space.

Tony,

To be clear, you mean that if you're both using an IPv6 address from
the 6to4 range (2002::/16) and have the appropriate encapsulators
nearby then it will work reasonably. This is true to a point.

The point where it breaks is that the IPv6 address selection
algorithms are not smart enough to prefer the 6to4-range IP address
when the source is a 6to4 address and deprefrence it when the source
isn't. V6's address selection algorithm uses the same
order-I-got-it-from-the-name-server approach that IPv4 uses and the
name server uses the same round-robining on AAAA records that it uses
for A records.

Multiple address assignments on a single machine or single DNS name is
IPv6's great White Whale. Like Ahab, we chase it at our peril.


> People violate RFCs all the time, but the FUD mindset here puts a one-liner
> added at the last minute as sacrosanct. If every access provider ran a 6to4
> relay and injected the 2002:local:prefix:: into IPv6 BGP, yes the table
> would grow, but it would be exactly the same outcome as deploying 6rd. What
> are people doing? They are certainly not concerned about IPv4 table growth,
> as they continue to do intentional deaggregation. They are deploying 6rd in
> separate prefixes, again not caring about table growth. If someone suggests
> that they do the same to support 6to4, all the zealots come out and scream
> about violating an RFC. This is nothing more than theatrics intended to
> stall deployment...

You offer a draft to remove the restriction on 2002:local:prefix
appearing in the Internet's BGP table from the 6to4 RFC and I'll stand
in support.



>> Ordinarily. However, in my tests last night I removed that equipment
>> from the path. And I should know. I personally built the network in
>> question all the way out to where it trades BGP upstream.
>
> I understand, but look again. I am not speaking for MSFT, but I was the
> program manager the put the stake in the ground and set the direction for
> how that stack works and why.

It isn't there, but let's back off and talk about two points it seems
we *all* agree on:

1. Win7 won't configure a 6to4 tunnel if it sees an RA with another
IPv6 address. Therefore even if Joel's problem were exactly as serious
as he claims, it is within every ISP's power to prevent it from
showing up by simply configuring an IPv6 pool alongside the 2011-5
IPv4 address pool.

If Joel's concern was real, then IPv6 deployment is indicated in
parallel with NAT444 using ARIN 2011-5's addresses. As policy
side-effects go, that strikes me as very beneficial.


2. Win7 also defaults to installing Microsoft patches automatically.
This means the one modifying tunnelling behavior for ARIN's new pool
will be installed on the overwhelming majority of Win7 machines
shortly after ARIN issues the space. Anyone with the wherewithal to
alter that behavior can deal with other Windows oddities.


> Today you will find failure cases where people are using public IPv4 behind
> a nat,

I observe that most of the US Federal agencies use public IPv4
addresses behind a NAT. Renumbering the internal networks out of their
class B's when they deployed their NAT firewalls a decade ago was seen
as costly and unnecessary.

Regards,
Bill Herrin


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


From joelja at bogus.com  Thu Jun 30 12:34:16 2011
From: joelja at bogus.com (Joel Jaeggli)
Date: Thu, 30 Jun 2011 09:34:16 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTikh7r0DU17gKHVrCWEJ=MNj0Dh=hA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com> <B!
	ANLkTiko=A01vQpBNdBs+6dY9kjHBNfYDQ@mail.gmail.com>
	<8D626745-0294-4E82-8816-65C21F36B0C2@bogus.com>
	<BANLkTikh7r0DU17gKHVrCWEJ=MNj0Dh=hA@mail.gmail.com>
Message-ID: <664B4D01-B935-456D-B13E-175A7975B325@bogus.com>


On Jun 30, 2011, at 6:46 AM, William Herrin wrote:

> On Thu, Jun 30, 2011 at 2:15 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>> On Jun 29, 2011, at 4:44 PM, William Herrin wrote:
>>> You are mistaken sir.
>> 
>> I would like an apology.
> 
> Joel,
> 
> Your experience differs from others'. Is it because you tested with
> home premium and I tested with another version? Is it because you
> tested with the rare store-bought version while I tested with a
> preinstall? Is it because you tested with an unpatched version while
> my service pack and patches are up to date?

The default behavior with 6to4 tunnel interfaces is common across all versions of windows vista, 7, and 2008 that I'm aware of. ipv6 is core network functionality.

> I also can't help but notice that your "freshly installed" windows
> already has vmware server on it. What other extra features and
> software were installed that aren't ordinarily there?

It also has service pack 1, neither that or the fact that vmware player is installed are germain to the issue of the existance of a 6to4 tunnel interface. I didn't reimage the machine just for the purpose of doing address selection testing.

> When you can explain why your experience differs from everybody
> else's, we'll talk about who is owed an apology.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> 



From mike at nationwideinc.com  Thu Jun 30 12:39:42 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Thu, 30 Jun 2011 12:39:42 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space
	forIPv4 Address Extension - IAB comment
References: <4D596163.7000009@arin.net><AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com><70ABB360-E28B-4A9D-BC10-0D5
	EBD158B63@corp.arin.net><503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net><BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com><207
	37EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net><4E0928EF.8030702@umn.edu><78477291-B4C3-4D0A-AE59-3F19B02CF03B@arin.net>
	<4E0C81C7.8070409@umn.edu>
Message-ID: <433615AB193E4FA086746E2AECB1D23C@mike>


> As I said, I now believe the proper course of action is to hold off on
> any action and coordinate with the IAB.  But, ARIN probably needs to 
> clarify its exceptions with the IAB asking for the IAB to ensure fair and 
> timely consideration within the IETF and by the IESG, and that any 
> delaying tactics would be unacceptable. ARIN should probably reiterate 
> that while this may be a technical allocation, it has serious addressing 
> policy implications that are within the scope of ARIN's policy process. 
> This is not simply a case of forum shopping, the ARIN policy community has 
> legitimate concerns regarding this issue and that need to be provided 
> equal weight to the technical considerations of the IETF.
>
> David Farmer

I agree with David Farmer. The information he conveys is a dealbreaker for 
2011-5, IMO.

There is an MoU in place which binds IANA to RFC 2860, which states:

 4.2. In the event of technical dispute between the IANA and the IESG,
   both will seek guidance from the IAB whose decision shall be final.


It's wasteful to allocate GUA space to multiple allocants for the purpose of 
CGN.
But if they have to use RFC1918 space for this purpose, some things will 
break in the network.

This sounds like a technical dispute and rules are in place to deal with 
these disputes.

We should abide by the rules and work on convincing the IAB to change its 
decision in this regard.
Which sucks, but in the technical debate on this issue, we are choosing 
between bad and less bad.
What we can't choose is whether or not to play by the established rules if 
we want Internet self-governance to persist.
We should be considering how best to change the mind of the IAB, but 2011-5 
is a policy which overlaps IETF and IANA roles and has to be settled by the 
IAB.
Would it help to convince IAB if we garnered the support of multiple RIRs 
and pressed the issue with a united front?

Regards,
Mike 



From alh-ietf at tndh.net  Thu Jun 30 14:44:00 2011
From: alh-ietf at tndh.net (Tony Hain)
Date: Thu, 30 Jun 2011 11:44:00 -0700
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
	IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTimvAgB28LbCQD7WLOk0Hfx2O2oUBA@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com> <01
	b701cc372c$9a425970$ce
	c70c50$@net> <BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
	<020401cc3737$e885bef0$b9913cd0$@net>
	<BANLkTimvAgB28LbCQD7WLOk0Hfx2O2oUBA@mail.gmail.com>
Message-ID: <02cb01cc3755$aec75a70$0c560f50$@net>

William Herrin wrote:
> On Thu, Jun 30, 2011 at 11:10 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> > William Herrin:
> >> I wish that was the case. Sadly, traffic is two-way. Even if the
> >> content providers encapsulate the packets back to IPv4 before they
> >> leave their network, the the client-side's nearest usually
> >> volunteer-run anycast gateway from the v4 to the v6 core also has to
> >> be reasonably located.
> >
> > Look closely at the technology. I understand it is two way, and the
> point is
> > that if they are running a 6to4 ROUTER (note not -relay- as recent
> testing
> > results are doing) they will be doing a peer-to-peer IPv4
> encapsulation. The
> > thing they need to do is ADD a 2002:: prefix to their content.
> Address
> > selection on the client will prefer longest match, so if it is in
> 2002::
> > space it will pick the 2002:: destination and the 6to4 routers will
> do
> > direct encaps to each other. The only time a 3rd party gets involved
> is when
> > one end of the conversation is not in 2002:: space.
> 
> Tony,
> 
> To be clear, you mean that if you're both using an IPv6 address from
> the 6to4 range (2002::/16) and have the appropriate encapsulators
> nearby then it will work reasonably. This is true to a point.
> 
> The point where it breaks is that the IPv6 address selection
> algorithms are not smart enough to prefer the 6to4-range IP address
> when the source is a 6to4 address and deprefrence it when the source
> isn't. 

Funny, mine has no problem with a 6to4, HE-prefix, & a ULA. Are you
suggesting IPv4 should be preferred to IPv6? If so you will never get there
because there will be no IPv6 traffic, therefore no investment by carriers,
therefore no traffic ... rinse & repeat. 

> V6's address selection algorithm uses the same
> order-I-got-it-from-the-name-server approach that IPv4 uses and the
> name server uses the same round-robining on AAAA records that it uses
> for A records.

That would be a broken implementation. The address selection rules
specifically state 'longest match'. The only time DNS order comes into play
is when you fall into the 'I don't care'/default policy table entry. 6to4
and teredo have explicit policy table entries, so DNS is a secondary
influence. 

> 
> Multiple address assignments on a single machine or single DNS name is
> IPv6's great White Whale. Like Ahab, we chase it at our peril.

It is a different model, so it will take time for people to get used to it.
We might even need a generational shift to get past mental blockages.

> 
> 
> > People violate RFCs all the time, but the FUD mindset here puts a
> one-liner
> > added at the last minute as sacrosanct. If every access provider ran
> a 6to4
> > relay and injected the 2002:local:prefix:: into IPv6 BGP, yes the
> table
> > would grow, but it would be exactly the same outcome as deploying
> 6rd. What
> > are people doing? They are certainly not concerned about IPv4 table
> growth,
> > as they continue to do intentional deaggregation. They are deploying
> 6rd in
> > separate prefixes, again not caring about table growth. If someone
> suggests
> > that they do the same to support 6to4, all the zealots come out and
> scream
> > about violating an RFC. This is nothing more than theatrics intended
> to
> > stall deployment...
> 
> You offer a draft to remove the restriction on 2002:local:prefix
> appearing in the Internet's BGP table from the 6to4 RFC and I'll stand
> in support.

At this point that approach is DOA. By the time you get it through the
process 6rd deployments will be widespread. This is one where operators have
to just decide it is a best practice and move on without the official stamp
of approval.

> 
> 
> 
> >> Ordinarily. However, in my tests last night I removed that equipment
> >> from the path. And I should know. I personally built the network in
> >> question all the way out to where it trades BGP upstream.
> >
> > I understand, but look again. I am not speaking for MSFT, but I was
> the
> > program manager the put the stake in the ground and set the direction
> for
> > how that stack works and why.
> 
> It isn't there, but let's back off and talk about two points it seems
> we *all* agree on:
> 
> 1. Win7 won't configure a 6to4 tunnel if it sees an RA with another
> IPv6 address. Therefore even if Joel's problem were exactly as serious
> as he claims, it is within every ISP's power to prevent it from
> showing up by simply configuring an IPv6 pool alongside the 2011-5
> IPv4 address pool.

Absolutely, but most ISPs are not foresighted enough to get past the
eye-candy of the 'easy out' in a NAT444.

> 
> If Joel's concern was real, then IPv6 deployment is indicated in
> parallel with NAT444 using ARIN 2011-5's addresses. As policy
> side-effects go, that strikes me as very beneficial.

Unfortunately allocation policy does not dictate deployment practice. 

> 
> 
> 2. Win7 also defaults to installing Microsoft patches automatically.
> This means the one modifying tunnelling behavior for ARIN's new pool
> will be installed on the overwhelming majority of Win7 machines
> shortly after ARIN issues the space. Anyone with the wherewithal to
> alter that behavior can deal with other Windows oddities.

It is not that trivial. Pushing out a policy table change is one thing, but
a stack code change that might have region specific 1918-ish blocks is
another. 

> 
> 
> > Today you will find failure cases where people are using public IPv4
> behind
> > a nat,
> 
> I observe that most of the US Federal agencies use public IPv4
> addresses behind a NAT. Renumbering the internal networks out of their
> class B's when they deployed their NAT firewalls a decade ago was seen
> as costly and unnecessary.

And those federal agencies were supposed to be working on IPv6 deployments
more than 3 years ago ... ;0
They also have a much simpler situation because they can deploy isatap
routers, and as soon as that name resolves and the prefix is acquired from
the router it will be preferred before 6to4. This works fine as several
non-fed (ostensibly for-profit) companies have been doing exactly that for
years. 

Tony


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



From bill at herrin.us  Thu Jun 30 15:22:33 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jun 2011 15:22:33 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <02cb01cc3755$aec75a70$0c560f50$@net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
	<020401cc3737$e885bef0$b9913cd0$@net>
	<BANLkTimvAgB28LbCQD7WLOk0Hfx2O2oUBA@mail.gmail.com>
	<02cb01cc3755$aec75a70$0c560f50$@net>
Message-ID: <BANLkTimoSOzHFbeMBU=Gr1-8iH9Yo6ZZKg@mail.gmail.com>

On Thu, Jun 30, 2011 at 2:44 PM, Tony Hain <alh-ietf at tndh.net> wrote:
> William Herrin wrote:
>> V6's address selection algorithm uses the same
>> order-I-got-it-from-the-name-server approach that IPv4 uses and the
>> name server uses the same round-robining on AAAA records that it uses
>> for A records.
>
> That would be a broken implementation. The address selection rules
> specifically state 'longest match'. The only time DNS order comes into play
> is when you fall into the 'I don't care'/default policy table entry. 6to4
> and teredo have explicit policy table entries, so DNS is a secondary
> influence.

If you'll refer me to the RFC and paragraph where the order of entries
returned by getaddrinfo is defined, I'll be pleased to correct any
misunderstanding I have about how IPv6 applications select destination
addresses from the name.


>> 1. Win7 won't configure a 6to4 tunnel if it sees an RA with another
>> IPv6 address. Therefore even if Joel's problem were exactly as serious
>> as he claims, it is within every ISP's power to prevent it from
>> showing up by simply configuring an IPv6 pool alongside the 2011-5
>> IPv4 address pool.
>
> Absolutely, but most ISPs are not foresighted enough to get past the
> eye-candy of the 'easy out' in a NAT444.
> Unfortunately allocation policy does not dictate deployment practice.

And if Joel is right, any who lack that foresight will suffer the
support calls as a result. Do you presume that ISPs are idiots? So
long as there -is- a reasonable way to use the 2011-5 addresses, one
that doesn't require touching all the customers' machines, I fail to
see the problem.


> And those federal agencies were supposed to be working on IPv6 deployments
> more than 3 years ago ... ;0

Longer than that. It was a running joke when I worked at the Census
Bureau in 2005.


> They also have a much simpler situation because they can deploy isatap
> routers, and as soon as that name resolves and the prefix is acquired from
> the router it will be preferred before 6to4. This works fine as several
> non-fed (ostensibly for-profit) companies have been doing exactly that for
> years.

And the ISP using 2011-5 addresses can't deploy an isatap router?
Pardon me for saying so, but it sounds like you already have the
technical solutions an ISP needs to mitigate the objections that Joel
raised. Documenting them is surely a good reason for the IETF to
produce an RFC, but it doesn't effectively argue against implementing
2011-5.

Regards,
Bill Herrin


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


From bill at herrin.us  Thu Jun 30 20:37:31 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jun 2011 20:37:31 -0400
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <BANLkTimoSOzHFbeMBU=Gr1-8iH9Yo6ZZKg@mail.gmail.com>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
	<020401cc3737$e885bef0$b9913cd0$@net>
	<BANLkTimvAgB28LbCQD7WLOk0Hfx2O2oUBA@mail.gmail.com>
	<02cb01cc3755$aec75a70$0c560f50$@net>
	<BANLkTimoSOzHFbeMBU=Gr1-8iH9Yo6ZZKg@mail.gmail.com>
Message-ID: <BANLkTi=19ieZeCH=54RsroSxRjxb01cecw@mail.gmail.com>

On Thu, Jun 30, 2011 at 3:22 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Jun 30, 2011 at 2:44 PM, Tony Hain <alh-ietf at tndh.net> wrote:
>> William Herrin wrote:
>>> V6's address selection algorithm uses the same
>>> order-I-got-it-from-the-name-server approach that IPv4 uses and the
>>> name server uses the same round-robining on AAAA records that it uses
>>> for A records.
>>
>> That would be a broken implementation. The address selection rules
>> specifically state 'longest match'. The only time DNS order comes into play
>> is when you fall into the 'I don't care'/default policy table entry. 6to4
>> and teredo have explicit policy table entries, so DNS is a secondary
>> influence.
>
> If you'll refer me to the RFC and paragraph where the order of entries
> returned by getaddrinfo is defined, I'll be pleased to correct any
> misunderstanding I have about how IPv6 applications select destination
> addresses from the name.

Hi Tony,

What I was looking for was section 6 of RFC 3484 (thanks Owen).
http://tools.ietf.org/html/rfc3484#section-6

I then did some tests on Linux to see what getaddrinfo would return. I
stand corrected. IPv6 address selection is smart as you claim.

However, the test revealed another result too: Linux (at least) seems
to prefer IPv4 over using an 6to4 tunnel to get to a host with both a
native IPv6 address and an IPv4 address. Assuming Windows exhibits the
same behavior, and assuming Joel's assertion about autoconfigured 6to4
adapters is 100% correct, it will still only impact connectivity to
hosts which have published 6to4 addresses for their servers. Which as
you complained is almost nobody.


A host name with:
2001:400::1
2002:101:1::1
2620:100::1
199.33.224.1

If I have only an IPv4 address:
199.33.224.1, {2001:400::1,2620:100::1}, 2002:101:1::1
(2001:400::1 and 2620:100::1 round-robin in subsequent requests)

If I have an IPv4 address and 2620:400::1:
  2620:100::1, 2001:400::1, 199.33.224.1, 2002:101:1::1

If I have an IPv4 address and 2002:8080:8080::1:
  2002:101:1::1, 199.33.224.1, 2001:400::1, 2620:100::1


A host name with:
199.33.224.1
2002:101:1::1

If I have only an IPv4 address:
  199.33.224.1, 2002:101:1::1

If I have an IPv4 address and 2620:400::1:
  199.33.224.1, 2002:101:1::1

If I have an IPv4 address and 2002:8080:8080::1:
  2002:101:1::1, 199.33.224.1

I find it very curious that it prefers the tunnel address in case 3
but the IPv4 address in case 2.


A host name with:
2620:100::1
199.33.224.1

If I have only an IPv4 address:
  199.33.224.1, 2620:100::1

If I have an IPv4 address and 2620:400::1:
  2620:100::1, 199.33.224.1

If I have an IPv4 address and 2002:8080:8080::1:
  199.33.224.1, 2620:100::1

Regards,
Bill Herrin


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


From mysidia at gmail.com  Thu Jun 30 21:29:49 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 30 Jun 2011 20:29:49 -0500
Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for
 IPv4 Address Extension - IAB comment
In-Reply-To: <020401cc3737$e885bef0$b9913cd0$@net>
References: <4D596163.7000009@arin.net>
	<AANLkTi=M2W728OtxA3EPwEtkfO8xZ12dVHNE3bHdghvb@mail.gmail.com>
	<70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net>
	<503AFB30-8119-4751-A95D-3CD17BF7B08D@arin.net>
	<BANLkTinNKT5FXdUa4bzAcxJQA6vwdiwr2g@mail.gmail.com>
	<20737EAA-FC99-4FB4-A7D8-69119656F7F2@queuefull.net>
	<4E0928EF.8030702@umn.edu> <20110628052528.GB23316@nsn.com>
	<688A6BC4-1D72-4213-9A6F-07428A9ADBBC@queuefull.net>
	<CA32EA97-36C4-4A35-863D-079CD2519030@bogus.com>
	<BANLkTikBTra0DXs-yoKMCnwUJAQfROHt2Q@mail.gmail.com>
	<047D9706-2DEB-47F6-A5C2-99CF2B287265@bogus.com>
	<BANLkTim8t1O6q59+=txALgQNts3nG3_tKw@mail.gmail.com>
	<707F8066-AA1A-40EF-891A-D5FC8D7D397F@bogus.com>
	<5575F175-E876-4803-B4E2-5B47DAEE3985@delong.com>
	<BANLkTi=WG71T+8XjJ8mT9dTGOMV7eO9yUw@mail.gmail.com>
	<1CE2F4B8-BCC0-4153-844A-87F375DD82D5@juniper.net>
	<BANLkTikxgHT-BCBy9EqM+Tk5Z-mnEDXYZA@mail.gmail.com>
	<9269ADA8-DA55-46F7-A713-8CB02946737A@juniper.net>
	<BANLkTik7G6j66uSkyBHPDe0TgWCASd=5nw@mail.gmail.com>
	<01b701cc372c$9a425970$cec70c50$@net>
	<BANLkTi==eP7WDqp9cRPWFma9vp36mdpCjA@mail.gmail.com>
	<020401cc3737$e885bef0$b9913cd0$@net>
Message-ID: <BANLkTimXjxqNE04c4ZZQkJbse=1iby+FGQ@mail.gmail.com>

On Thu, Jun 30, 2011 at 10:10 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> William Herrin:
> The point is there are lots of ways to break things, the trick is to find
> ways to make them work without requiring end user awareness, or massive
> support structures...

My suggestion would be that 2011-5  space, when assigned to CPE
always be conjoined with  full, proper, native IPv6 support.


You are talking about breaking IPv6 transition technologies that don't
work with RFC1918 space in the first place;  the breakage is highly
similar, when non-recognizable unroutable public IPs are used.

At least a shared /10 allocated under 2011-5  would be recognizable.

> Tony
--
-JH