[Apwg-ipv6-papi] policy proposal done?
Sonderegger Olaf ABRAXAS INFORMATIK AG
Olaf.Sonderegger at abraxas.ch
Mon Aug 12 08:46:43 CEST 2013
Hi Elvis
First: I want to thank you for your great work.
Unfortunately, I wasn't able to contribute as I hoped for. I got a new job function after my commitment for our working group.
I try to read your proposal as soon as possible, and give you my feedback.
Best regards, Olaf
-----Original Message-----
From: apwg-ipv6-papi-bounces at ripe.net [mailto:apwg-ipv6-papi-bounces at ripe.net] On Behalf Of Elvis Velea
Sent: Sonntag, 11. August 2013 13:38
To: apwg-ipv6-papi at ripe.net
Subject: [Apwg-ipv6-papi] policy proposal done?
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
More information about the Apwg-ipv6-papi
mailing list