[Apwg-ipv6-papi] [pdo] last changes?
Elvis Velea
elvis at velea.eu
Wed Sep 18 16:53:55 CEST 2013
Hi everyone,
the updates to the text sound ok, I had a look and it's all fine.
Regarding the flowchart, I actually had it done by a friend which is not
reachable today. I'll try to update it tomorrow.
@Marco - if any of the NCC designers could change it, that would be
great, if not.. I'll chase my friend tomorrow ;)
cheers,
elvis
On 9/18/13 3:31 PM, Daniel Stolpe wrote:
>
> Hi,
>
> I agree as well. EU definitely sounds like the European Union.
>
> On Wed, 18 Sep 2013, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>
>> 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
>>>>>
>>>>
>>>
>>
>>
>
> 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
>
More information about the Apwg-ipv6-papi
mailing list