[Apwg-ipv6-papi] [pdo] last changes?
Marco Schmidt
mschmidt at ripe.net
Fri Sep 20 14:23:37 CEST 2013
Hello Elvis,
Thank you for the new flowchart - looks good.
Now I will pass everything to our webmasters and let you know their
estimation when we can publish - hurray!
Cheers,
Marco
On 9/19/13 4:34 PM, Elvis Velea wrote:
> Hi Marco,
>
> attached is the updated flowchart.
>
> Let me know if anything else is needed.
>
> cheers,
> elvis
>
> On 9/19/13 9:57 AM, Marco Schmidt wrote:
>> 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