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

Marco Schmidt mschmidt at ripe.net
Thu Sep 19 09:57:07 CEST 2013 

Hello Elvis,

On 9/18/13 4:53 PM, Elvis Velea wrote:
> 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 ;)
Our designers are all quite busy (upcoming meetings etc) - do you thing 
your friend can do the update today or tomorrow?

Cheers,
Marco


>
> 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