[Apwg-ipv6-papi] [pdo] policy proposal done?

Mon Sep 9 09:45:23 CEST 2013

Hi,

Yes. Good last minute point (the rationale).

On Mon, 9 Sep 2013, Elvis Velea wrote:

> Hi Marco,
>
> thank you for answering to my e-mail on Sunday at 11PM :-)
>
> @Olaf and Daniel - can you please reply as well by Monday evening? This
> way it will be published and sent to the mailing list on Tuesday.
>
> @Marco - please see my answers and a few other comments in line
>
> On 9/8/13 11:02 PM, Marco Schmidt wrote:
>> Hello,
>>
>> On 9/7/13 2:40 PM, Elvis Velea wrote:
>>> Hi everyone,
>>>
>>> I managed to read the whole document and I want to thank Comms for
>>> their great work.
>>>
>>> @Marco - I'd like to request three small changes, if that is still
>>> possible.
>>>
>>> 1. please update the e-mail address in the Authors section from
>>> elvis at velea.eu to elvis at v4escrow.net
>>>
>> No problem.
>
> thanks
>
>>>
>>> 2. I would like to add an other short rationale supporting the proposal:
>>>
>>> Currently, organisations that want to offer services (other than
>>> shared) to their customers over IPv6 can only to this if they become
>>> an LIR. Non-LIRs can use IPv6 PI only to number their internal network
>>> and offer shared hosted services. This policy allows Non-LIRs to offer
>>> all of their services to customers over IPv6 as well.
>> Sounds reasonable. Are the other proposers fine with that?
>>
>
> let's see what Olaf and Daniel think as well. My initial goal was to
> come up with this fix additional to the pa/pi unification. Basically, by
> removing all the differences, this policy proposal will allow non-LIRs
> to also offer services over IPv6. Current policy do not allow non-LIRs
> to offer any services (other than SaaS) over IPv6.. That is why I think
> this is a very important point to make in the rationale.
>
>>>
>>> (I had my coffee before writing this paragraph but I don't like how
>>> it's written, maybe you can reword it and make it shorter and clearer :)
>>>
>> I will ask a native English speaker from Comms to have a look and I'll
>> send you their approach as soon I get it.
>
> thanks
>
>>
>>>
>>> 3. I would split 6.1 in two different sections
>>>
>>> 6.1 Allocations for Anycasting TLD and
>>> 6.2 Allocations for Tier 0/1 ENUM Nameservers
>>>
>>> (what do you think? would it be better to split it or just leave it as
>>> it is right now?)
>> As I'm not so involved in the proposal development I don't see yet what
>> would be the advantage of this split. But it's your proposal :) What do
>> the other proposers think?
>
> section 6 of the policy includes all current special cases.
>
> 6.1 talks about anycast and enum and mixes these two purposes in one
> section, 6.2 is for IXP and 6.3 for root dns.
>
> while anycast and enum could stay in the same section (they have the
> same allocation rules) I believe that splitting these two would make the
> section cleaner..
>
> anyway, it does not really matter if policies for allocating to anycast
> and enum are two different sub-sections or only one.. let's not waste
> time with this request.
>
>
>>
>>>
>>>
>>> the rest looks great.
>
> great, just a few more things...
>
> a. Because I noticed the forgotten 'assignment' word in 2.9, and a
> comment from the COMMS editor in section 2.9 that I forgot to respond to
> - here is my response:
>
> section 2.9 is already part of the current policy and the text has only
> been updated to mention sub-allocation instead of assignment.
> please note that I had forgotten the word assignment in the first
> phrase, it has now been updated to sub-allocation.
>
> Please ask COMMS to re-review the following edit:
>
> current text:
>
> "The actual usage of addresses within each sub-allocation may be low
> when compared to IPv4. In IPv6, ?utilisation? is only measured in terms
> of the bits to the left of the efficiency measurement unit (/56). In
> other words, ?utilisation? effectively refers to the sub-allocation of
> network prefixes to End Sites and not the number of addresses in use
> within the /56."
>
> COMMS reviewed text:
>
> "The actual usage of addresses within each assignment may be low when
> compared to IPv4 assignments. In IPv6, ?utilisation? is only measured in
> terms of the bits to the left of the efficiency measurement unit (/56).
> In other words, ?utilisation? effectively refers to the (sub-)allocation
> of network prefixes to End Sites and not the number of addresses
> (sub-)allocated within individual End Site (sub-)allocations.
> Throughout this document, the term ?utilisation? refers to the
> sub-allocation of network prefixes to End Sites and not the number of
> addresses used with the /56."
>
> let me know what COMMS thinks of this change.
>
>
> b. please remove from the policy text the following phrase from section 8.0
>
> "It is an address allocation utilisation ratio and not an address
> assignment utilisation ratio."
>
> since assignments have completely been removed from the policy proposal,
> I do not see a reason why this phrase should be kept.
>
>
> c. section 3.2
>
> please change the . to the ,
>
> Registering objects in the database is the final step in making an
> allocation. sub-allocation or aggregation
>
> to:
>
> Registering objects in the database is the final step in making an
> allocation, sub-allocation or aggregation
>
>
> d. I've just noticed that the changes made to paragraph 5.1.2 may change
> the intent of the policy proposal.
>
> current text, as proposed by COMMS is:
>
> Initial allocations made by the RIPE NCC to an LIR may be up to a /29
> with no additional documentation required. The minimum initial
> allocation size is a /32.
>
> IRs may qualify for an initial allocation greater than a /29 by
> submitting documentation that reasonably justifies the request. If so,
> the allocation size will be based on the number of existing users, the
> extent of the organisation's infrastructure and by taking into account
> growth plans for up to two years in the future.
>
> I'd like to ask them to change it back so that the initial intent is kept..
> - initial allocation for LIR is /32, can go up to /29 with no additional
> documentation required
> - initial portable allocation size is a /32
>
>
> e. changes made to 5.4.4 sound a bit awkward:
>
> Requests for multiple or additional prefixes exceeding a /48
> sub-allocation for a single End Site will be processed and reviewed at
> the RIR level to evaluate the justification.
>
> I would actually change it further to:
>
> Requests for multiple or additional prefixes exceeding a /48 for a
> single End Site must be approved by the RIPE NCC.
>
>
>>
>> My plan is to publish the proposal on Tuesday. This gives you the chance
>> to to agree with the final version or provide last minute changes during
>> the whole Monday. And I have enough time with our webmaster to set up
>> everything.
>
> great :-) say hello to Mihnea ;)
>
>>
>> Best regards,
>> Marco
>>
>
> cheers,
> elvis
>
>
> _______________________________________________
> 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