[Apwg-ipv6-papi] [pdo] last changes?
Elvis Velea
elvis at velea.eu
Mon Sep 9 20:57:33 CEST 2013
Hi,
On 9/9/13 8:44 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
> Hi all
>
> Sorry, my meeting took longer as expected. Now, I have to catch my last train to home.
>
> PIR: I think, Elvis' edit is one way, we could go. Maybe my proposals were too sketchy. I wished, that there is a way without additional terms. What impact does this change have on RIPE NCC?
>
I don't think it has any impact.. but we will find out when they will do
an Impact Analysis. That will happen only weeks after the proposal has
been sent and discussed on the mailing list.
> End Sites and End user: Do we need any term definition with "End user"? "EU" (End User) is available at diagram, so it should be defined.
We do have a definition on an End Site which I wasn't very happy with..
but nobody could come up with a better one. As for the EU.. none of the
policies written until now have had a definition on the end user.
Maybe that's one to discuss on the mailing list and see if others come
with better ideas?
cheers,
elvis
>
> Cheers, Olaf
>
>
>
> -----Original Message-----
> From: apwg-ipv6-papi-bounces at ripe.net [mailto:apwg-ipv6-papi-bounces at ripe.net] On Behalf Of Daniel Stolpe
> Sent: Montag, 9. September 2013 19:43
> To: Elvis Velea
> Cc: pdo at ripe.net; apwg-ipv6-papi at ripe.net
> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>
> On Mon, 9 Sep 2013, Elvis Velea wrote:
>
>> 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?
>
> Yes, I think it's a nice way to show exactly that.
>
> Cheers,
>
> Daniel
>
>>> 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
>>>
>>
>>
>>
>
> 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
>
>
> _______________________________________________
> Apwg-ipv6-papi mailing list
> Apwg-ipv6-papi at ripe.net
> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>
--
Kind regards, Elvis Velea
More information about the Apwg-ipv6-papi
mailing list