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

Elvis Daniel Velea elvis at velea.eu
Tue Sep 17 13:35:48 CEST 2013 

Hi Marco,

we are now ready, can you ask comms to do a last review of the document ?

cheers,
elvis

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

On 17 sep. 2013, at 08:27, Daniel Stolpe <stolpe at resilans.se> wrote:

>
> Yes,
>
> We have to let it go at some point. Please proceed.
>
> Cheers,
>
> Daniel
>
> On Tue, 17 Sep 2013, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>
>> Hi Elvis
>>
>> Last small change: Could you change my company name to "Abraxas Informatik AG"? Whole name is currently in capital letters, what is wrong.
>>
>> After that: Please go ahead with comms.
>>
>> Cheers, Olaf
>>
>> -----Original Message-----
>> From: Elvis Velea [mailto:elvis at velea.eu]
>> Sent: Montag, 16. September 2013 17:29
>> To: elvis at v4escrow.net
>> Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; Marco Schmidt; Daniel Stolpe; Sander Steffann; Gert Doering; Ingrid Wijte; Andrea Cima; apwg-ipv6-papi at ripe.net
>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>
>> Hi everyone,
>>
>> I've updated the document, please have a look at it and let me know if it's clear now :)
>>
>> cheers,
>> elvis
>>
>> On 9/16/13 4:37 PM, Elvis Velea wrote:
>>> Hi all,
>>>
>>> I'll work on the final touch of this proposal and will send you the
>>> final document.
>>>
>>> 5.3.5 was in the original text and allows an operator (ISP) to use a
>>> /48 per pop and an additional /48 for the in-house operations.
>>>
>>> Considering the changes that we have made, 5.3.5 will not really make
>>> much sense but we'll see what the community thinks.
>>>
>>> Cheers,
>>> elvis
>>>
>>> On 9/16/13 3:56 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>> Hi Elvis
>>>>
>>>> About 5.3.5: I'm not sure. I think, 5.3.5 doesn't make something
>>>> exactly clear. If 5.3.5 is in our proposal, community will discuss it.
>>>> Therefore, I would keep it. Better we discuss it than we forget it.
>>>>
>>>> Cheers, Olaf
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Elvis Velea [mailto:elvis at velea.eu]
>>>> Sent: Montag, 16. September 2013 14:50
>>>> To: Sonderegger Olaf ABRAXAS INFORMATIK AG
>>>> Cc: Marco Schmidt; Daniel Stolpe; Sander Steffann; Gert Doering;
>>>> Ingrid Wijte; Andrea Cima; apwg-ipv6-papi at ripe.net
>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>
>>>> Hi Olaf,
>>>>
>>>> great to know that we are on the same page :)
>>>>
>>>> I'm waiting for Daniel's decision before I change the proposal text
>>>> again, if he also agrees with Option #1, we will have:
>>>>
>>>> - RIPE NCC allocates by default a /32
>>>> - if LIR requests, up to a /29 can be allocated with no further
>>>> justification needed
>>>> - LIR can request more than a /29 by providing justification
>>>> - EU can request more than a /32 by providing justification
>>>>
>>>> LIR or EU sub-allocates up to a /48 with no request needed
>>>> - LIR can sub-allocate more than a /48 to themselves, an EU or End
>>>> Site but approval is needed from the RIPE NCC
>>>> - EU can sub-allocate more than a /48 to themselves, an EU or End
>>>> Site but they must submit a request for approval via the Sponsoring
>>>> LIR
>>>> - some exceptions in 5.3.5 (should we keep it?)
>>>>
>>>> cheers,
>>>> elvis
>>>>
>>>> On 9/16/13 2:41 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>>> Dear all
>>>>>
>>>>> Option #1 is okay for me. I wanted to clarify it, before we open
>>>>> discussion for the whole community.
>>>>>
>>>>> Q1 / Q2: End Users need a relationship (contract, ...) with a
>>>>> Sponsoring LIR. In my opinion, if an End User request anything, it
>>>>> has to be processed by Sponsoring LIR. Sponsoring LIR could realize
>>>>> some kind of business with End User, that's why Sponsoring LIR
>>>>> should also do the work (on behalf of End User). Section 2.4
>>>>> "Sponsoring LIR" defines, that Sponsoring LIR have to "facilitate
>>>>> the administrative processes". In my opinion, it's everything defined.
>>>>>
>>>>> Cheers, Olaf
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Elvis Velea [mailto:elvis at velea.eu]
>>>>> Sent: Montag, 16. September 2013 12:59
>>>>> To: Marco Schmidt
>>>>> Cc: Daniel Stolpe; Sonderegger Olaf ABRAXAS INFORMATIK AG; Sander
>>>>> Steffann; Gert Doering; Ingrid Wijte; Andrea Cima;
>>>>> apwg-ipv6-papi at ripe.net
>>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>>
>>>>> Good morning everyone,
>>>>> (it was still morning when I started writing this message)
>>>>>
>>>>> (an other long email incoming, if you do not have time to read all
>>>>> of it, see the last paragraph with my proposed solution)
>>>>>
>>>>> We still have a few decisions to make regarding what kind of
>>>>> requests should the RIPE NCC evaluate (excepting the
>>>>> initial/additional allocation request) and who can send these requests.
>>>>>
>>>>> A bit of background.. just as Marco said, the RIPE NCC has received
>>>>> a handful of requests for assignments to End Sites larger than /48.
>>>>> Out of these requests, only one was actually a request for one
>>>>> single End Site that justified need for more than a /48, the rest
>>>>> were requests for multiple End Sites of the same customer or
>>>>> requests where the need for more than a /48 was not justified.
>>>>>
>>>>>
>>>>> Now, since we are removing the differences between Assignment and
>>>>> Sub-Allocation, we may want to revisit this idea.
>>>>>
>>>>> How can the RIPE NCC/LIR/EU differentiate between an EU that has
>>>>> more than one End Site and needs a /47 (let's say 2x/48s for their 2
>>>>> sites) and an EU that only has one End Site and needs one /47?
>>>>> - we did remove the idea of the Assignment from the policy and that
>>>>> makes the evaluation of these a bit more difficult.
>>>>>
>>>>> One solution would be - the RIPE NCC evaluates all requests for
>>>>> sub-allocation for any EU or End Site that needs more than a /48.
>>>>> This may create a bit of work for the RIPE NCC and limit what the
>>>>> LIR or the EU can do without RIPE NCC approval.
>>>>>
>>>>> A second solution would be to limit the size of the sub-allocation
>>>>> (with no need for RIPE NCC approval) to an arbitrary number, let's
>>>>> say a /40.
>>>>> I don't think I've ever seen any request for an customer that needed
>>>>> more than a /40.
>>>>>
>>>>> A third solution would be to clearly show in the RIPE Database
>>>>> objects that these two or more sub-allocations are for different End
>>>>> Sites of the same customer, but that means that we will let the
>>>>> LIR/EU to decide how to add this information in the RIPE Database
>>>>> objects.
>>>>>
>>>>> A fourth solution would be to completely remove the need for a
>>>>> request and allow the LIR/EU to sub-allocate as much as they want to
>>>>> an EU or End Site. However, this may lead to cases where an LIR/EU
>>>>> sub-allocates a /33 to a customer (EU or End Site) and qualifies for
>>>>> an additional allocation immediately.
>>>>>
>>>>> I think that as this policy proposal is already changing everything
>>>>> in IPv6, we should be a bit cautious on what we allow and what not.
>>>>> That is why I would vote for option #1 and see how it works for a
>>>>> year or two.
>>>>> If this creates too much workload for the LIR or the RIPE NCC, we
>>>>> could in the future modify the policy (if this proposal is accepted)
>>>>> to be a bit more liberal.
>>>>>
>>>>>
>>>>> A second question that I had in my mind this past weekend is:
>>>>>
>>>>> Q1: currently the RIPE NCC accepts requests from LIRs (and only from
>>>>> LIRs) for assignments made out of their allocation.
>>>>>
>>>>> By allowing EUs to sub-allocate address space, we may see cases
>>>>> where an EU needs to send a request to request approval of a /47
>>>>> sub-allocation.
>>>>> There is no clear process defined on this situation.
>>>>> Additionally, in the current version we are allowing LIRs to make
>>>>> sub-allocations of up to a /32 and any sub-allocation made by an LIR
>>>>> that is larger than a /32 must be approved by the RIPE NCC.
>>>>>
>>>>> Q2: What do we do with EUs that want/need to sub-allocate a /32 or
>>>>> larger? How can the EU send any request to the RIPE NCC? ( maybe via
>>>>> the Sponsoring LIR?)
>>>>>
>>>>>
>>>>> I think that all the above questions could be solved by:
>>>>>
>>>>> - making it mandatory that any sub-allocation larger than a /48 to
>>>>> be approved by the RIPE NCC (even for a customer with multiple End
>>>>> Sites)
>>>>> - asking the RIPE NCC to evaluate requests from EU if these are sent
>>>>> by the Sponsoring LIR.
>>>>>
>>>>> (at least for a while, to see if this creates overload of work and
>>>>> if it does, revisit the IPv6 policy and make it less restrictive)
>>>>>
>>>>>
>>>>> What do you all think?
>>>>>
>>>>> cheers,
>>>>> elvis
>>>>>
>>>>> On 9/16/13 11:43 AM, Marco Schmidt wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I had a look in your latest changes and it looks good so far.
>>>>>>
>>>>>> Regarding OIaf's and Daniels comment please see my answer below:
>>>>>>
>>>>>>
>>>>>> On 9/16/13 11:04 AM, Daniel Stolpe wrote:
>>>>>>>
>>>>>>> Now we seem to have lost the list. I put it back in the CC again.
>>>>>>>
>>>>>>> On Mon, 16 Sep 2013, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>>>>>
>>>>>>>> Dear Elvis
>>>>>>>>
>>>>>>>> Thanks a lot for your editing. I started a similar definition of
>>>>>>>> End User, but a friend had an emergency, and he was took to the
>>>>>>>> hospital.
>>>>>>>>
>>>>>>>> Updated version is nearby its final stage. I found only one last
>>>>>>>> point.
>>>>>>>>
>>>>>>>>
>>>>>>>> Marco started a discussion about section 5.3 last time:
>>>>>>>> ---
>>>>>>>> 5.3 Sub-allocations Shorter Than a /48 to a Single End Site When
>>>>>>>> a single End Site requires a sub-allocation shorter than a /48,
>>>>>>>> it must request the sub-allocation with documentation or
>>>>>>>> materials that justify the request.  Requests for multiple or
>>>>>>>> additional prefixes exceeding a /48 sub-allocation for a single
>>>>>>>> End Site must be evaluated and by the RIPE NCC.
>>>>>>>> ---
>>>>>>>> I think, an evaluation of sub-allocations for End Sites aren't
>>>>>>>> necessary. If a LIR or an EU distributes its allocations in a
>>>>>>>> manner, that it run out of addresses, RIPE NCC could reject
>>>>>>>> LIR's/EU's additional allocation request. I know, this way is
>>>>>>>> more reactive than proactive. But otherwise, RIPE NCC has to
>>>>>>>> evaluates a lot of request, which want be necessary.
>>>>>>>>
>>>>>>>> Could you shortly explain, what was your initial idea with this
>>>>>>>> section?
>>>>>>>
>>>>>>> Looks lika heritage from the old ways? I can agree that if you
>>>>>>> waste to many addresses in the same place it could be a better way
>>>>>>> to make life harder the next time you ask for more space, rather
>>>>>>> than having the NCC look at each sub-allocation immediately.
>>>>>>>
>>>>>>> I like the idea of delegated responsibility. Request with
>>>>>>> documentation yes, but it can stay att LIR level until the next
>>>>>>> NCC audit. I guess that was your point Olaf?
>>>>>> If you would remove that section then the RIPE NCC would have no
>>>>>> base to reject additional allocation requests. Because there would
>>>>>> be nothing in the policy to restrict an LIR/EU to sub-allocate for
>>>>>> example 1000x /48's or a /38 to one customer - and this customer
>>>>>> could be your grandmother in her little house ;) Maybe I've chosen
>>>>>> an extreme example but just to show that this would be an easy way
>>>>>> to reach the HD-ratio - and then on what ground the RIPE NCC can
>>>>>> discuss that an LIR/EU can not give several /48's to one end site?
>>>>>>
>>>>>>
>>>>>> Already now we only would evaluate such request if somebody really
>>>>>> estimate to connect more than 65K hosts in a subnet (so far only
>>>>>> one time a University managed to justify that).
>>>>>> Most of the cases we get such requests when in reality an end user
>>>>>> need more than a /48 because he has several end sites or customers
>>>>>> - and then we recommend to assign a /48 per end site or use the
>>>>>> status AGGREGATED-BY-LIR
>>>>>>
>>>>>>
>>>>>> Regarding your proposal I just would like to stress again that I
>>>>>> would need the confirmation from *all* proposer to the final version.
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>> Marco
>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Elvis Velea [mailto:elvis at velea.eu]
>>>>>>>> Sent: Samstag, 14. September 2013 17:23
>>>>>>>> To: Sander Steffann; Gert Doering; Ingrid Wijte; Andrea Cima;
>>>>>>>> Sonderegger Olaf ABRAXAS INFORMATIK AG; Daniel Stolpe; Marco
>>>>>>>> Schmidt
>>>>>>>> Subject: Fwd: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> the message below needs moderator approval on the
>>>>>>>> [Apwg-ipv6-papi] as it was too large due to the attached doc.
>>>>>>>> "Message body is too big: 254011 bytes with a limit of 40 KB"
>>>>>>>>
>>>>>>>> Therefore, I'm sending it to everyone subscribed to that list :)
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> elvis
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: Re: [Apwg-ipv6-papi] [pdo]     last changes?
>>>>>>>> Date: Sat, 14 Sep 2013 17:13:18 +0200
>>>>>>>> From: Elvis Velea <elvis at velea.eu>
>>>>>>>> Reply-To: elvis at velea.eu
>>>>>>>> To: Sonderegger Olaf ABRAXAS INFORMATIK AG
>>>>>>>> <Olaf.Sonderegger at abraxas.ch>
>>>>>>>> CC: Daniel Stolpe <stolpe at resilans.se>, "pdo at ripe.net"
>>>>>>>> <pdo at ripe.net>, Marco Schmidt <mschmidt at ripe.net>,
>>>>>>>> "apwg-ipv6-papi at ripe.net"
>>>>>>>> <apwg-ipv6-papi at ripe.net>
>>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> again, sorry for the lack of presence in the past few days. I
>>>>>>>> have been very busy setting up various procedures in our company.
>>>>>>>>
>>>>>>>> @Olaf - sorry I did not reply to the e-mail from the 11th..
>>>>>>>>
>>>>>>>> I managed to find a few hours today and worked on the document
>>>>>>>> taking into account all your ideas :)
>>>>>>>>
>>>>>>>> I my mind I had the following:
>>>>>>>> - remove the idea of portable addresses, allocations are allocations.
>>>>>>>> - remove the crazy idea of PIR, not sure what I was smoking that
>>>>>>>> day :)
>>>>>>>> - define the EU
>>>>>>>> - re-define the End Site
>>>>>>>>
>>>>>>>> Changes:
>>>>>>>> - added 2.5 End User (EU) definition
>>>>>>>> - updated 2.6 - End Site definition
>>>>>>>> - moved 5.3 (Allocations made by the RIR) to 5.0 (I think it adds
>>>>>>>> a bit more structure to the policy this way)
>>>>>>>> - updated 5.1.2 to clarify what is the initial allocation size
>>>>>>>> for LIR and for the EU
>>>>>>>> - updated 5.1.3 and 5.1.4 (removed the idea of portable
>>>>>>>> allocation)
>>>>>>>> - updated "LIR's customer" with EU in various places
>>>>>>>> - clarified where we use IR, LIR, EU or End Site
>>>>>>>>
>>>>>>>> I'm hoping that this time the update turned out quite good.
>>>>>>>>
>>>>>>>> The document is attached.
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> elvis
>>>>>>>>
>>>>>>>> On 9/11/13 1:02 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>>>>>>> Dear Daniel, Dear Elvis
>>>>>>>>>
>>>>>>>>> I could edit file while I travel home by train.
>>>>>>>>>
>>>>>>>>> Should I take the last document from Marco? Or did you change
>>>>>>>>> everything on Google Drive?
>>>>>>>>>
>>>>>>>>> Cheers, Olaf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Daniel Stolpe [mailto:stolpe at resilans.se]
>>>>>>>>> Sent: Mittwoch, 11. September 2013 12:53
>>>>>>>>> To: Elvis Velea
>>>>>>>>> Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; pdo at ripe.net; Marco
>>>>>>>>> Schmidt; apwg-ipv6-papi at ripe.net
>>>>>>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm currently not sure about what time I might have. Probably
>>>>>>>>> not very much unfortunatly.
>>>>>>>>>
>>>>>>>>> On Tue, 10 Sep 2013, Elvis Velea wrote:
>>>>>>>>>
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> ok, introducing a new term gave a heart attack to Gert.. that
>>>>>>>>>> usually means it's a bad idea ;)
>>>>>>>>>>
>>>>>>>>>> I will read the feedback each of you has provided and will come
>>>>>>>>>> back with a revised document ;)
>>>>>>>>>>
>>>>>>>>>> However, these days I am very very busy, so I am not sure I
>>>>>>>>>> will be able to find time to revise it by Friday.. I will try
>>>>>>>>>> as much as I can.
>>>>>>>>>>
>>>>>>>>>> I like the definitions from Marco, can we add him to the list
>>>>>>>>>> of proposers ? (joke)
>>>>>>>>>>
>>>>>>>>>> If any of you has time by Friday to work on these changes, let
>>>>>>>>>> me know..
>>>>>>>>>>
>>>>>>>>>> If not, I'll try on Friday or during the weekend to come up
>>>>>>>>>> with the last (this time I mean it) version.
>>>>>>>>>>
>>>>>>>>>> cheers,
>>>>>>>>>> elvis
>>>>>>>>>>
>>>>>>>>>> On 9/10/13 2:48 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>>>>>>>>>>> Hi all
>>>>>>>>>>>
>>>>>>>>>>>> 1)
>>>>>>>>>>>> Definition "End User (EU)" with a clear demarcation to "End
>>>>>>>>>>>> Site". End users are the organisations that can receive
>>>>>>>>>>>> sub-allocations or portable allocations. End sites are LIRs
>>>>>>>>>>>> and EU locations of local networks/customers (like in your
>>>>>>>>>>>> graph section 2).
>>>>>>>>>>>
>>>>>>>>>>> +1, that's a good proposal and a better way.
>>>>>>>>>>>
>>>>>>>>>>>> 2)
>>>>>>>>>>>> So why not simply write "LIR and EU" when something applies
>>>>>>>>>>>> for both, and only "LIR" or "EU" if something applies only
>>>>>>>>>>>> for one type?
>>>>>>>>>>>
>>>>>>>>>>> +1, that's also a good idea.
>>>>>>>>>>>
>>>>>>>>>>> What are you meaning, Elvis?
>>>>>>>>>>>
>>>>>>>>>>> Cheers, Olaf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: apwg-ipv6-papi-bounces at ripe.net
>>>>>>>>>>> [mailto:apwg-ipv6-papi-bounces at ripe.net] On Behalf Of Marco
>>>>>>>>>>> Schmidt
>>>>>>>>>>> Sent: Dienstag, 10. September 2013 10:17
>>>>>>>>>>> To: Gert Doering
>>>>>>>>>>> Cc: pdo at ripe.net; apwg-ipv6-papi at ripe.net
>>>>>>>>>>> Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> First of all I think the topics that you discuss are too
>>>>>>>>>>> relevant to just implement them on the fly. The risk of
>>>>>>>>>>> inconsistencies in the proposal is just too big.
>>>>>>>>>>>
>>>>>>>>>>> Also I checked with the webmasters and they need some time to
>>>>>>>>>>> re-do all the pages, especially the policy text. They need to
>>>>>>>>>>> have enough notification time to schedule their work as their
>>>>>>>>>>> are also busy with all the upcoming meetings (MENOG, ENOG, RIPE).
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> May I propose the following:
>>>>>>>>>>>
>>>>>>>>>>> - the proposal gets back to you, you all agree what to edit
>>>>>>>>>>> and then send the final version back to the RIPE NCC
>>>>>>>>>>> - if you wish Comms make another review of the changes
>>>>>>>>>>> - our webmaster get the final version and can set up
>>>>>>>>>>> everything and then we publish :)
>>>>>>>>>>>
>>>>>>>>>>> If you agree during this week on the final version I think it
>>>>>>>>>>> is realistic that we can publish (early) next week. Then the
>>>>>>>>>>> discussion phase would end perfectly timed during the RIPE
>>>>>>>>>>> meeting.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I believe the following two issues spotted by you should be
>>>>>>>>>>> solved before publishing:
>>>>>>>>>>>
>>>>>>>>>>> 1)
>>>>>>>>>>> Definition "End User (EU)" with a clear demarcation to "End Site".
>>>>>>>>>>> End users are the organisations that can receive
>>>>>>>>>>> sub-allocations or portable allocations. End sites are LIRs
>>>>>>>>>>> and EU locations of local networks/customers (like in your graph section 2).
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2)
>>>>>>>>>>> Currently "IR" is often used when it should read "LIRs and End
>>>>>>>>>>> Users"
>>>>>>>>>>> (for example in section 5) which could lead to confusion as
>>>>>>>>>>> one hand RIRs are also IRs and on the other hand it is not
>>>>>>>>>>> clear that EUs are IRs (and should they actually always seen
>>>>>>>>>>> as Internet Registry?)
>>>>>>>>>>>
>>>>>>>>>>> As Gert mentioned it might be too much to introduce now also
>>>>>>>>>>> new terms in this policy proposal (you will change the IPv6
>>>>>>>>>>> world anyhow ;-) ).
>>>>>>>>>>>
>>>>>>>>>>> So why not simply write "LIR and EU" when something applies
>>>>>>>>>>> for both, and only "LIR" or "EU" if something applies only for
>>>>>>>>>>> one type?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If you choose this way then we can keep the biggest part of
>>>>>>>>>>> the current version, only extended by a more clear EU
>>>>>>>>>>> definition and replace "IR"
>>>>>>>>>>> where it is applicable.
>>>>>>>>>>>
>>>>>>>>>>> This would be my practical approach.
>>>>>>>>>>> (for example Comms only would need to review the EU
>>>>>>>>>>> definition)
>>>>>>>>>>>
>>>>>>>>>>> But again, you have the last word as this is your baby :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've attached you the latest reviewed proposal version again.
>>>>>>>>>>> Do all the changes you would like to do and agree on it. Then
>>>>>>>>>>> you send me your final version back.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Marco
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/9/13 9:38 PM, Gert Doering wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Sep 09, 2013 at 05:20:53PM +0200, Elvis Velea wrote:
>>>>>>>>>>>>> Introducing the PIR - Portable Internet Registry \o/
>>>>>>>>>>>> Uh, what?
>>>>>>>>>>>>
>>>>>>>>>>>> And - no, let's not go there.  RIR and LIR are well-defined
>>>>>>>>>>>> terms and well-understood, introducing something that sounds
>>>>>>>>>>>> similar enough to be confused with it while not being part of
>>>>>>>>>>>> the "IR tree structure"
>>>>>>>>>>>> would need quite a few *good* arguments to convince me.
>>>>>>>>>>>>
>>>>>>>>>>>>> @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.
>>>>>>>>>>>> If I have anything to say here, please let's *not* do that.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, I think we should not use the term "IR" for "something
>>>>>>>>>>>> that acts like a LIR but is not".
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, where is "portable allocation" coming from?  All
>>>>>>>>>>>> allocations are "portable", by definition...
>>>>>>>>>>>>
>>>>>>>>>>>> Gert Doering
>>>>>>>>>>>>             -- APWG chair
>
>
> _________________________________________________________________________________
> 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
>

More information about the Apwg-ipv6-papi mailing list