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

[Daniel Stolpe]

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.

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