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

[Elvis Daniel Velea]

lemme re-read the document again, Marco does have a point :)

will be back with a reply within the hour.

Excuse the briefness of this mail, it was sent from a mobile device.

On 9 sep. 2013, at 15:24, Marco Schmidt <mschmidt at ripe.net> wrote:

> Hello Olaf,
>
> the final decision is of course with the proposers but please allow me mention the following:
>
> With the proposed changes we the publishing will get delayed by at least a week as the complete text must be reviewed for references and cross-references as often the terms are related.
>
> Please see below:
>
> On 9/9/13 2:01 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>> Dear Elvis
>>
>> It took time, but I got it. From my point of view, WG, especially Elvis, and Comms did a great job.
>>
>>
>> If it is still possible (I think not based on our timeline), I have following suggestions for a better understanding of the policy:
>>
>> 1: "End User" vs. "End Site":
>> In the beginning, policy defines "End Site" is the same as "End User". But, "end site" hasn't really been used within policy (once within chapter 2.9, twice within chapter 5.4). So, we could directly define term "End User" instead "End Site". In this case, acronym "EU" has been defined, which has been used inside illustration under chapter 2.0.
> Even if end site is described as an end user there is a different to the term end user used in the policy. An End User/LIR's customer can have serveral end sites (e.g. company with several branches) - like shown in the graph in 2.0.
> If this would be unified then as per 5.4.4. then every assignment bigger than a /48 per end user must be evaluated by the RIPE NCC.
> (Imagine McDonalds is an LIR customer and want to connect 1000 restaurants)
>>
>> 2. "End user(s)" instead "LIR's customer" / "customer of (the) LIR" / "End Site" / "customer" in conjunction with "LIR":
>> Based on first suggestion, policy could only use term "end user" instead "LIR's customer", "customer of (the) LIR" and so on. A service provider, who has a business with another service provider (LIR), is also an "end user" at this particular time. A end user, who has a business with another end user (service provider), is also an "end user" at this particular time. From my point of view, term "end user" describes a role.
>>
>> Changes could be done at following chapters: 2.7, 2.9, 5.1.1, 5.1.2, 5.1.4, 5.2.3, 5.3, 5.4.1, 5.4.2, 5.4.3, 5.4.4, 5.6
> As above.
>
>>
>> 3. "LIR" instead "IR":
>> Sometimes policy is talking about "IR" for rules, which apply only to "LIR". Policy defines, that two types of "IR" are available inside our service region: RIR and LIR. "Sponsoring LIR" is a kind of type "LIR".
>> - Example 1: Chapter 5.1.1 refer to "IR", following chapter 5.1.2 refer firstly to "LIR" and one paragraph later to "IR". But, any definition within 5.1 is only valid for "LIR", because IANA policies are valid for RIR.
>> - Example 2: Chapter 5.5 refer firstly to "IR", and it refer one paragraph later to "LIR".
>>
>> Changes could be done at following chapters: 5.1.1, 5.1.2, 5.2.1, 5.4.3, 5.4.5, 5.5, 5.6
> IR is the general term and later in the policy rules are described that sometimes apply only for RIRs, sometimes only for LIRs and sometimes for both.
> And for these general rules it is probably good to keep IR (instead of writing "RIRs and LIRs") - for example in 4.2 RIR and LIRs must apply procedures that reduce the possibility of fragmented address space...
>
> Related to this I noticed that in 5.1.1 probably it really should be LIR instead of IR - I adjusted this already - let me know if I'm wrong.
>
>
>>
>>
>> I know, I am a little bit late. But, my points have been revealed after reading whole document at once.
>>
>> Do you agree to my suggestions?
>
> Again, this are only my 2 cents and the decision is with you proposers :)
>
> Let me know how to proceed.
>
> Best regards,
> Marco Schmidt
>
>>
>> AND:
>>>> 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?
>> Yes, I am.
>>
>>
>>
>> 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: Montag, 9. September 2013 01:26
>> To: Marco Schmidt
>> Cc: pdo at ripe.net; apwg-ipv6-papi at ripe.net
>> Subject: Re: [Apwg-ipv6-papi] [pdo] policy proposal done?
>>
>> 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
>