[Apwg-ipv6-papi] first draft?

[Emilio Madaio]

Hi all,
   I made some small comments in the document online.

I also wanted to share something that can be helpful in the long term.

I run the Cosmetic Surgery Project (CSP) to improve the readability of
some policy documents and one of the deliverable was to redraft the
merger of the 3 IPv6 documents:

-ripe-589 "IPv6 Address Allocation and Assignment Policy"
-ripe-451 "IPv6 Address Space Policy for Internet Exchange Points"
-ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region"

So, in all the cases where a rewording is due (i.e.: the new chart of
RIR/LIRs, section 4.1 etc), I kindly ask you to have a look at the CSP
draft in attachment.

Looking forward to hearing from you
Regards
Emilio





On 7/17/13 5:05 PM, Daniel Stolpe wrote:
> 
> On Mon, 15 Jul 2013, Elvis Velea wrote:
> 
>> Hi,
>>
>> On 7/15/13 8:38 PM, Gert Doering wrote:
>>>  Hi,
>>>
>>>  On Mon, Jul 15, 2013 at 05:32:24PM +0300, Elvis Daniel Velea wrote:
>>>>  Hope you had a great vacation Daniel.
>>>>
>>>>  can't wait to see your input/comments.
>>>>
>>>>  Basically, I'm still wondering if it's going to be ok (accepted by the
>>>>  community) to have a minimum allocation of a /32 either made by the
>>>>  RIPE NCC or by the LIR.
>>>
>>>  Allocations are always made by the RIPE NCC :-) - I assume this is
>>>  sub-allocations?
>>>
>>
>> in the document, there are only allocations and assignments. Allocations can 
>> be made by the RIPE NCC to the LIR (not portable) or to the customer of the 
>> LIR (portable). (Sub-)Allocations can also be made by a customer (to it's 
>> downstream customer).
> 
> I guess you would have to call it a sub-allocation if it is address space 
> that comes from a (bigger) allocation.
> 
>>>>  I would see a few problems:
>>>>  - if the LIR makes minimum /32 allocations.. they will run out of
>>>>  space in their allocations after 8 customers and will need an
>>>>  additional allocation. Should the /32 allocated to a customer (the
>>>>  sub-allocation) be considered fully used once it's made?
>>>
>>>  When introducing sub-allocations to IPv4, I think I said "sub-allocations
>>>  are not considered used".  So if a LIR is careless with sub-allocs, and
>>>  runs out of space, they need to ensure that the sub-allocs are properly
>>>  filled by the receipients.
>>
>> True, in IPv4 sub-allocations are not considered in use. However, in the 
>> model in my head, and as I understood from you, the big allocations would 
>> have been of a minimum /32.
>> Either the allocations made by the RIPE NCC (portable) or the ones made by 
>> the LIR (sub-allocations, or non-portable allocations) would have been of a 
>> minimum /32.
>>
>> I might have misunderstood and I actually think that we should allow any 
>> allocations between a /48 and a /32 (or even larger). However, in this case, 
>> we may risk seeing ultra-conservative LIRs which would not give enough space 
>> to their customers and therefore force the customers to use /64s or smaller 
>> prefixes.
> 
> There might be risks both ways. What if you make a big sub-allocation for 
> a customer who is then not using very much of it, and then you need more 
> space for yourself? Do you have to take back space from that customer?
> 
>>>  If this is properly documented, I think LIRs will not carelessly hand
>>>  out large swaths of space, but really consider what they are doing - some
>>>  might be fine with /32s (because they know that they are serving a
>>>  specific
>>>  constituency, and won't ever have more than 3 direkt customers...), others
>>>  might prefer to go for /40s or so.
>>
>> ok, so we will not make the smaller allocation size a /32.
> 
> Not carelessly, no. But plans might change. See above.
> 
>>>>  -if the NCC will make minimum /32 portable allocations.. what will be
>>>>  the incentive for someone to become an LIR? should the cost for the
>>>>  portable allocations be different then the 50? paid for the /48
>>>>  (portable) assignment?
>>>
>>>  That will be an interesting can of worms, as APWG cannot decide on the
>>>  cost of things...
>>>
>>>  My initial idea was to make the "big allocation" slightly more expensive
>>>  than the "small allocation" (like, 200 EUR vs. 50 EUR), to avoid giving
>>>  the wrong signal - if we make "big allocations" too expensive, we signal
>>>  "hey, use a /48, and give all your dial-in customers just a /128 and
>>>  have them make NAT66!" - which we should not do.
>>>
>>>  But in the end, this is something for the RIPE AGM to sort out.
>>
>> correct
> 
> Yes. This could be interesting. :-)
> 
>>>  An incentive to become a RIPE member: "direct dealings with the RIPE NCC"
>>>  (some really want to be "that independent!"), plus "voting rights at the
>>>  AGM", and possibly other services that are members-only, like dnsmon,
>>>  Atlas, etc.
>>>
>>
>> ok :)
> 
> Ha ha. You do now that some people are ready to go a long way in order to 
> *avoid* direct dealings with the RIPE NCC? :-)
> 
> But that is of cource not really our business right now.
> 
> I have made a couple of comments. More will probably come later.
> 
> Cheers,
> 
> Daniel
> 
> _________________________________________________________________________________
> Daniel Stolpe           Tel:  08 - 688 11 81                   stolpe at resilans.se
> Resilans AB             Fax:  08 - 55 00 21 63            http://www.resilans.se/
> Box 13 054							      556741-1193
> 103 02 Stockholm
> 
> 
> _______________________________________________
> Apwg-ipv6-papi mailing list
> Apwg-ipv6-papi at ripe.net
> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPv6_old-new-v3_2.doc
Type: application/x-ole-storage
Size: 299520 bytes
Desc: not available
Url : https://www.ripe.net/ripe/mail/archives/apwg-ipv6-papi/attachments/20130718/ffe417fc/attachment-0001.bin