[Apwg-ipv6-papi] policy proposal done?
Daniel Stolpe
stolpe at resilans.se
Wed Aug 21 15:22:07 CEST 2013
Please Elvis,
It is august and I have been completely off line. I am trying to catch up
now.
On Sun, 11 Aug 2013, Elvis Velea wrote:
> Hi everyone,
>
> one week has passed since the message below and I have not received any
> replies back.. no feedback :(
>
> If an other week passes without any feedback, I will contact Emilio and
> push the policy proposal on my own.
>
> It feels a bit weird to have been working at such a document/proposal
> for days and not to receive any kind of feedback once the work is done.
>
> cheers,
> elvis (a bit sad)
>
> On 8/4/13 8:54 PM, Elvis Velea wrote:
>> Hi everyone,
>>
>> The wedding is over and both me and my wife had a great time :-)
>> I'm still in Romania enjoying some great weather at my mother-in-law's
>> house.
>> As this is a very quiet place, I've found some peaceful time to compare
>> the current policy text, Emilio's document which resulted from the
>> Cosmetic Surgery Project + the already edited text.
>>
>> I'm proud to say that I am done with editing the policy text.
>>
>> I'd like to ask you all to verify all the current comments and either
>> mark them as resolved if the answers to them are satisfactory or add
>> more questions to the comments.
>>
>> Additionally, I'd like to ask all of you to read the whole document and
>> add comments to it if anything is unclear.
>> I'd like to ask Emilio to formally send the policy proposal to the WG
>> within the next 2-3 weeks.
>>
>>
>> There are still some open questions/comments:
>>
>> 1. To which WG should we send the policy proposal? AP-WG or IPv6-WG?
>>
>> 2. What should be the rationale? I haven't yet compiled these.
>>
>> 3. Is it ok to consider that everyone who makes an allocation is an IR?
>>
>> 4. Is it ok to consider that an LIR should not make a sub-allocation
>> smaller than /48?
>>
>> 5. Is it ok to request LIRs that make sub-allocations bigger than /32 to
>> send a request to the RIPE NCC for approval?
>>
>> 6. Is the definition of a Sponsoring LIR good enough?
>>
>> 7. Can someone come up with a better definition of an end-site?
>>
>> 8. Is it ok to have all the information required for registration in the
>> registration goal?
>>
>> 9. Is it ok to have a minimum allocation of a /32? For both LIRs and the
>> customers that previously used to receive a PI assignment?
>>
>> 10. Is it ok to specifically mention in the policy that current PI
>> holders can extend their /48 PI assignment/now allocation (upon request)
>> to a /32 and where this is not possible, they can return the /48 and
>> receive a /32 instead?
>>
>> 11. In the 10th paragraph, ATTRIBUTION, next to those mentioned by
>> Emilio in the CSP document, I've also added the three of us working
>> currently at the policy proposal.
>> Olaf and Daniel, if you do not want to be mentioned, please delete
>> yourselves from the document.
>> Emilio - I suppose it's fine to mention ourselves in that paragraph.
>>
>>
>> Looking forward to your feedback.
>>
>> cheers,
>> elvis
>>
>> On 7/30/13 4:54 PM, Daniel Stolpe wrote:
>>>
>>> Same here. I guess we will see some more action again in a few weeks.
>>>
>>> On Wed, 24 Jul 2013, Elvis Daniel Velea wrote:
>>>
>>>> Hi Emilio, everyone,
>>>>
>>>> I haven't had any time in the past few day as I was attending my
>>>> brother's wedding. I'll have a look at all the e-mails and the
>>>> documents from Emilio next week.
>>>>
>>>> cheers,
>>>> elvis
>>>>
>>>> Excuse the briefness of this mail, it was sent from a mobile device.
>>>>
>>>> On 24 jul. 2013, at 08:57, Emilio Madaio <emadaio at ripe.net> wrote:
>>>>
>>>>> Hi Elvis,
>>>>> here in attachment the picture as requested in your comments on the
>>>>> google doc.
>>>>>
>>>>> It could be retrieve also from the IPv6_old_new document I sent to our
>>>>> mailing list some days ago.
>>>>>
>>>>>
>>>>> Cheers
>>>>> Emilio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/18/13 10:13 AM, Emilio Madaio wrote:
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apwg-ipv6-papi mailing list
>>>>>>> Apwg-ipv6-papi at ripe.net
>>>>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>> <PIC-NewIPv6Policy.docx>
>>>>
>>>> _______________________________________________
>>>> Apwg-ipv6-papi mailing list
>>>> Apwg-ipv6-papi at ripe.net
>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>
>>>>
>>>
>>> mvh
>>>
>>> Daniel Stolpe
>>>
>>> _________________________________________________________________________________
>>>
>>>
>>> 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
>>>
>>
>
> --
> Kind regards, Elvis Velea
>
> _______________________________________________
> Apwg-ipv6-papi mailing list
> Apwg-ipv6-papi at ripe.net
> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>
>
mvh
Daniel Stolpe
_________________________________________________________________________________
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
More information about the Apwg-ipv6-papi
mailing list