[Apwg-ipv6-papi] [pdo] last changes?

[Elvis Velea]

Hi,

On 9/9/13 6:29 PM, Daniel Stolpe wrote:
>
> Hi,
>
> I see we will have enless layers of IR:s now. :-)
>
> But yes. All the layers will in some sense be IR:s themseleves.
>

because we have removed the assignment (which was the last layer) now 
anyone can be an IR if they receive a sub-allocation.

so, yes.. there's an infinite number of IRs within an allocation made by 
the RIPE NCC :)

Do you agree with the last comments/edits?

cheers,
elvis

> On Mon, 9 Sep 2013, Elvis Velea wrote:
>
>> Hi everyone,
>>
>> Taking into account Olaf's comments, and after a few minutes and an
>> other coffee I decided to implement a new change.
>>
>> Introducing the PIR - Portable Internet Registry \o/
>>
>> (@Olaf and Daniel - please respond asap and let me know if you agree,
>> only then Marco can request Comms and the webmaster to implement the
>> change)
>>
>> please see below:
>>
>> On 9/9/13 3:24 PM, Marco Schmidt 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)
>>
>> Actually, according to the current proposal, End User will become an IR.
>> It will be an organisation or private person that will receive a
>> sub-allocation and will be able to make further sub-allocations if
>> allowed by the holder of the larger (sub-)allocation.
>>
>> I would not unify the End User and End-Site terms, as these are
>> completely different in most cases.
>> The End-Site is the last level of sub-allocation, the actual site (be it
>> a computer, a mobile device or a small network).
>> The End User is an organisation that may have one or more End-Sites.
>>
>>>>
>>>> 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.
>>
>> I initially agreed with your suggestion, however, we could only change
>> the references to 'LIR's Customer' or 'Customer of (the) LIR', see
>> below, most have been changed to PIR.
>>
>> But we can not change the End-Site to End User, that would cause a whole
>> other problem.
>>
>>>
>>>>
>>>> 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.
>>>
>>
>> Indeed, IR is a general term and I actually thought that I made mistakes
>> in editing the proposed text. However, some of the definitions apply to
>> all IRs while some others apply only to the RIR, others only to the LIR.
>>
>> 5.1.1 does mention IRs because initial allocations can be made either to
>> the LIR or to the EU (via Sponsoring LIR). In this case the EU is also
>> an IR, as they will be making sub-allocations to their own
>> infrastructure or to their customers. Please see the changes below.
>>
>>
>>
>> @Marco, please ask Comms to update the following:
>>
>> - add
>>
>> 2.5 Portable Internet Registry (PIR)
>>
>> A Portable Internet Registry is an IR which can request (via a
>> Sponsoring LIR) a portable allocation from the RIR. The PIR
>> sub-allocates address space to the users of the network services that it
>> provides.
>>
>> - change
>>
>> from
>> 2.4 Sponsoring LIR
>>
>> Members of the RIPE NCC (LIRs) can request portable allocations on
>> behalf of a third party, and the RIPE NCC will allocate resources
>> directly to this third party. In these cases, the role of the LIR is to
>> facilitate the administrative processes and to maintain a link between
>> the RIPE NCC and the third party that holds the resources. An LIR
>> fulfilling this role is called the Sponsoring LIR for the third party.
>> Third parties can choose another LIR to be their Sponsoring LIR at any
>> time.
>>
>> to
>> 2.5 Sponsoring LIR
>>
>> Members of the RIPE NCC (LIRs) can request portable allocations on
>> behalf of PIRs, and the RIPE NCC will allocate resources directly to the
>> PIR. In these cases, the role of the LIR is to facilitate the
>> administrative processes and to maintain a link between the RIPE NCC and
>> the PIR that holds the resources. An LIR fulfilling this role is called
>> the Sponsoring LIR for the PIR. PIRs can choose another LIR to be their
>> Sponsoring LIR at any time.
>>
>> -change current 2.5 to 2.6, etc..
>>
>> -change
>> 5.1.1
>>
>> from
>> To qualify for an initial allocation of IPv6 address space, an IR must
>> have a plan for making sub-allocations to other customers and/or End
>> Sites within two years.
>>
>> to
>> To qualify for an initial allocation of IPv6 address space, an LIR or an
>> PIR must have a plan for making sub-allocations to other customers
>> and/or End Sites within two years.
>>
>> -change
>> 5.1.2
>>
>> from
>> IRs may qualify for a larger initial allocation by submitting
>> documentation that reasonably justifies the request.
>>
>> to
>> LIRs or PIRs may qualify for a larger initial allocation by submitting
>> documentation that reasonably justifies the request.
>>
>> -change
>> (also in 5.1.2)
>>
>> from
>> /48 allocations can be made by the RIPE NCC to customers of the LIR that
>> do not expect to ever need more or for special purposes.
>>
>> to
>> /48 allocations can be made by the RIPE NCC to PIRs that do not expect
>> to ever need more or for special purposes.
>>
>> -change
>> 5.1.4
>>
>> from
>> To qualify for portable address space, an LIR?s customer must meet the
>> requirements of the policies described in the RIPE Document ripe-452 or
>> it?s updates.
>> The RIPE NCC will allocate the prefix directly to the customer of the
>> Sponsoring LIR upon a request properly submitted to the RIPE NCC by the
>> Sponsoring LIR.
>>
>> to
>> To qualify for portable address space, an PIR must meet the requirements
>> of the policies described in the RIPE Document ripe-452 or it?s updates.
>> The RIPE NCC will allocate the prefix directly to the PIR upon a request
>> properly submitted to the RIPE NCC by the Sponsoring LIR.
>>
>>
>> -change
>> 5.2.1
>>
>> from
>> An additional allocation will also be provided when an IR satisfies the
>> evaluation threshold of past address utilisation in terms of the number
>> of sites in units of /56s.
>>
>> to
>> An additional allocation will also be provided when an LIR or PIR
>> satisfies the evaluation threshold of past address utilisation in terms
>> of the number of sites in units of /56s.
>>
>> -change
>> 5.2.3
>>
>> from
>> When an LIR or its customer has achieved an acceptable utilisation level
>> for its allocated address space, it is immediately eligible to receive
>> an additional allocation that results in a doubling of the address space
>> allocated to it.
>>
>> to
>> When an LIR or PIR has achieved an acceptable utilisation level for its
>> allocated address space, it is immediately eligible to receive an
>> additional allocation that results in a doubling of the address space
>> allocated to it.
>>
>> -change
>> 5.3
>>
>> from
>> The RIPE NCC will make allocations to LIRs or their customers according
>> to the points 5.1 and 5.2 of this policy. These allocations can be made
>> to the LIR (not portable) or (via a Sponsoring LIR) to a customer of the
>> LIR (portable).
>>
>> to
>> The RIPE NCC will make allocations to LIRs or PIRs according to the
>> points 5.1 and 5.2 of this policy. These allocations can be made to the
>> LIR or to a PIR.
>>
>>
>> -change
>>
>> from
>> 5.4.2 Sub-allocations Made by the Customer of the (Sponsoring) LIR
>>
>> A customer of an LIR which has received an allocation (portable or not)
>> can further sub-allocate parts of this allocation to a downstream
>> customer.
>>
>> to
>> 5.4.2 Sub-allocations Made by the PIR
>>
>> An PIR which has received an allocation can further sub-allocate parts
>> of this allocation to a downstream customer.
>>
>> -add
>>
>> 5.4.3 Sub-allocations Made by the Customers
>>
>> A customer which has received a sub-allocation can further sub-allocate
>> parts of it to a downstream customer. These sub-allocations must be
>> registered in the RIPE Database.
>>
>> -change current 5.4.3 to 5.4.4, etc...
>>
>> -change
>> current 5.4.3
>>
>> from:
>> End Sites or customers are sub-allocated an IPv6 block. The size of the
>> sub-allocation is a local decision for the IR to make, using the minimum
>> value of a /64 (if only one subnet is anticipated for the End Site).
>>
>> to:
>> End Sites or customers are sub-allocated an IPv6 block. The size of the
>> sub-allocation is a local decision for the LIR or the PIR to make, using
>> the minimum value of a /64 (if only one subnet is anticipated for the
>> End Site).
>>
>> -change
>> current 5.4.5
>>
>> from
>> An IR may sub-allocate a network prefix per point of presence (PoP) as
>> the service infrastructure of an IPv6 service operator. Each
>> sub-allocation to a PoP is regarded as one regardless of the number of
>> users using the PoP. A separate sub-allocation can be obtained for the
>> operator?s in-house operations.
>>
>> to
>> An LIR or PIR may sub-allocate a network prefix per point of presence
>> (PoP) as the service infrastructure of an IPv6 service operator. Each
>> sub-allocation to a PoP is regarded as one regardless of the number of
>> users using the PoP. A separate sub-allocation can be obtained for the
>> operator?s in-house operations.
>>
>> -change
>> 5.5
>>
>> from
>> When an IR holding an IPv6 address allocation makes allocations,
>> sub-allocations or aggregations, these must be registered in the RIPE
>> Database.
>>
>> to
>> When an organisation holding an IPv6 address allocation makes
>> allocations, sub-allocations or aggregations, these must be registered
>> in the RIPE Database.
>>
>> -change
>> 5.6
>>
>> from
>> When an RIR allocates IPv6 address space to an IR, it also delegates the
>> responsibility to manage the reverse lookup zone that corresponds to the
>> allocated IPv6 address space. Each LIR or customer should properly
>> manage its reverse lookup zone. When making sub-allocations, the IR can
>> delegate to its customer, upon request, the responsibility to manage the
>> reverse lookup zone that corresponds to the sub-allocated block.
>>
>> to
>> When an RIR allocates IPv6 address space to an LIR or PIR, it also
>> delegates the responsibility to manage the reverse lookup zone that
>> corresponds to the allocated IPv6 address space. Each LIR or PIR should
>> properly manage its reverse lookup zone. When making sub-allocations,
>> the LIR or PIR can delegate to its customer, upon request, the
>> responsibility to manage the reverse lookup zone that corresponds to the
>> sub-allocated block.
>>
>> -change
>> 5.7.2
>>
>> from
>> Organisations holding an allocation lower than a /32 (except those made
>> for special purposes) can request an extension of this allocation to a
>> /32. Where this extension is not possible, the organisation has the
>> option to return the allocation and automatically receive a /32 (or
>> larger if justified).
>>
>> to
>> LIRs or PIRs holding an allocation lower than a /32 (except those made
>> for special purposes) can request an extension of this allocation to a
>> /32. Where this extension is not possible, the LIR or PIR has the option
>> to return the allocation and automatically receive a /32 (or larger if
>> justified).
>>
>> -end of changes
>>
>>
>> And with this changes, I hope we get to publish the proposal as soon as
>> possible :)
>>
>> We will all still get a chance to have a look at the proposal before it
>> is announced to the mailing list. Hope there won't be anything else to
>> change.
>>
>> --
>> 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
>