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

Mon Sep 9 15:24:48 CEST 2013

Good point.

On Mon, 9 Sep 2013, 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.
>
> 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
>
> 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
>
>
> 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?
>
> 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
>
> _______________________________________________
> 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