[arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10

[Scott Leibrand]

On Sat 8/7/2010 8:07 PM, Owen DeLong wrote:
> On Aug 7, 2010, at 5:14 PM, Scott Leibrand wrote:
>
>    
>> On Wed 8/4/2010 2:23 PM, ARIN wrote:
>>      
>>
>>> Add the following to section 4 of the NRPM
>>>
>>> 4.11 Required utilization for subsequent allocation under section 4.10
>>>
>>> No organization shall receive more than one allocation or assignment
>>> under section 4.10 unless all prior space issued under 4.10 meets the
>>> utilization requirements of this section:
>>>
>>> 1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
>>> 2. All utilization must be permitted under section 4.12
>>> 3. All prior 4.10 allocation/assignments must be at least 90% utilized.
>>>        
>> Is there any reason to limit this requirement to just 4.10 allocations and assignments?  If we struck 4.10 there, and require that "All prior  allocation/assignments must be at least 90% utilized", would that be better?
>>      
> I think it is infeasible to put a 90% requirement on pre-4.10 allocations and
> assignments unless we changed some of the mechanisms for counting
> utilization. I think this could place an undue burden on some providers as
> it would represent a radical ex-post-facto shift in the way they've allocated
> addresses to their customers prior to runout.
>    

I agree with what Bill said:

On Sat 8/7/2010 8:44 PM, William Herrin wrote:
> I think Scott's point is: if they haven't consumed 90% of their
> existing allocations, do they genuinely -need- addresses from the 4.10
> pool? If they do, I haven't been convinced of why.
>
> Ex post facto has to do with retroactive effect. There's no change
> here to folks have to do to retain, transfer, etc. any addresses
> outside the pool reserved for 4.10.
>    

On Sat 8/7/2010 8:07 PM, Owen DeLong wrote:
> I'm not opposed to this change personally, but, I would expect some
> opposition from the community and wouldn't want such opposition to reduce
> the consensus on the rest of this proposal.
>
> I encourage others to provide feedback (positive or negative on this idea).
>    

Agreed.  I'd also like to hear from anyone who thinks that 90% of all 
previous allocations is too high a bar for this kind of space.  As I see 
it, anyone who has more than 10% of their previous allocations sitting 
unused and hasn't figured out a way to use it probably isn't in the 
situation of needing more space for transition purposes yet.

>>> 4. For purposes of this computation, space received under 4.10(a) shall
>>> be considered separately from space received under 4.10(b) if an
>>> organization has received resources of both types.
>>>
>>> 4.12 Permitted uses of allocations or assignments under section 4.10(b)
>>>
>>> No organization shall use space received under section 4.10 for any
>>> purpose other than as specified in this section
>>>
>>> 1. To provide the required public IPv4 address(es) for transitional
>>> technologies operated by the recipient organization.
>>> a. Large scale or "Carrier Grade" NAT
>>> b. NAT-PT
>>> c. DS-LITE/B4/AFTeR
>>> d. DNS64 or other transitional DNS enablers
>>>        
>> The existing 4.10 language mentions "key dual stack DNS servers", but you don't mention that here.  Can you elaborate on what you think should be allowed there?
>>      
> I would consider those to be covered under "other transitional DNS enablers", but, I can easily add that to the list if you feel it's helpful.
> I've basically tried to write this section such that it gives staff the clearest possible statement of the intent of the policy and will of the
> community while not preventing innovation in this area or creating unnecessary limits on legitimate uses of the space for actual
> transitional technologies.
>    

I think it's probably covered there, but I think including it in d would 
help your goal of providing the clearest possible statement of intent.

> More community guidance here would be very useful.
>
> Did you intentionally cut e off below your signature? (Note it is an important part of the intent of this section).
>    

I was just focusing my comments on d.  I see e. and 2. as a good 
catch-alls, but would rather enumerate known-good technologies and 
strategies where appropriate, rather than rely too much on the catch-all.

>>> e. For other technologies of similar purpose and scope.
>>>
>>> 2. For other transitional technologies not envisioned at the time of
>>> this proposal, but, in no case for general IPv4 addressing provided to
>>> customers.

-Scott