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

Daniel Stolpe stolpe at resilans.se
Tue Sep 17 08:27:47 CEST 2013 

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