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

Elvis Velea elvis at velea.eu
Mon Sep 16 17:29:15 CEST 2013 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPv6-policyproposal-v1reviewed3-2-2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 182694 bytes
Desc: not available
Url : https://www.ripe.net/ripe/mail/archives/apwg-ipv6-papi/attachments/20130916/b9a31835/attachment-0001.bin

More information about the Apwg-ipv6-papi mailing list