[Apwg-ipv6-papi] [pdo] last changes?
Sonderegger Olaf ABRAXAS INFORMATIK AG
Olaf.Sonderegger at abraxas.ch
Wed Sep 18 13:54:38 CEST 2013
Hi Marco
>From my side, I agree to change to "End User" instead "EU".
@ Elvis: Could you change flowchart?
Cheers, Olaf
-----Original Message-----
From: Marco Schmidt [mailto:mschmidt at ripe.net]
Sent: Mittwoch, 18. September 2013 12:09
To: elvis at velea.eu; elvis at v4escrow.net; Sonderegger Olaf ABRAXAS INFORMATIK AG; Daniel Stolpe
Cc: Sander Steffann; Gert Doering; Ingrid Wijte; Andrea Cima; apwg-ipv6-papi at ripe.net
Subject: Re: [Apwg-ipv6-papi] [pdo] last changes?
Hello proposers,
Please find attached your proposal proofread.
Comms actually found now an important issue that you might like to change:
They have serious doubts to use the abbreviation EU for end user because
- It clashes with the better-known European Union abbreviation
- This would make quotes from the policy confusing
- "End User" is too small to justify abbreviating
So the proofread version has all EU replaced by End User but the flowchart in section 2 should be updated by you.
I have to admit I was not thinking about this issue before but it make sense to me now to don't use EU.
Do you agree or you want to stick with EU?
If you agree then can you please send me an updated flowchart for section 2?
Cheers,
Marco
On 9/16/13 5:29 PM, Elvis Velea wrote:
> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Apwg-ipv6-papi mailing list
>>>>>>>>>> Apwg-ipv6-papi at ripe.net
>>>>>>>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Kind regards, Elvis Velea
>>>
>>
>
More information about the Apwg-ipv6-papi
mailing list