- address-policy-wg - mailman.ripe.net

2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer)
by Marco Schmidt 10 Jul '14

10 Jul '14

Dear colleagues, The draft document for the proposal described in 2014-02, "Allow IPv4 PI transfer" has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-02 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 8 August 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Question about Last /8 Policy
by Daniel Baeza (Red y Sistemas TVT) 08 Jul '14

08 Jul '14

Hi all, This is another topic about Last /8. Im seeing in the Listing Service ppl offering their last /22 from the 185/8 For example, creating a LIR on 1st January cost arround 4.000€ (more or less) and selling the whole allocation at currect prices (lets say, 8€/IP) is giving you a benefit of ~4.000€ IMHO, we should not allow LIRs to sell their last /8 allocation. If they dont need it anymore, it should be returned to RIPE. Only allowed transfers of /22 from last /8 should be: - When LIR bought another LIRs bussiness (for not keeping the 2 LIRs the transfer should be allowed - More reasons? I know there should be at least another one, but I cant remember it now. This will help to dont especulate with the last /8 and will help slowing the depletion. Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza(a)tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.

9 14

the solution to v4 runout?
by Jim Reid 02 Jul '14

02 Jul '14

I think this might be the answer: http://www.bbc.co.uk/news/technology-28125336 Perhaps the RIRs could come up with a definition of "chores" that LIRs have to complete in order to get (time-limited?) use of a v4 address. :-)

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 35, Issue 1
by Lu 02 Jul '14

02 Jul '14

Let's put it that way, it is over, so let it be it. Opening the pandora box won't changing the end results. Plus current /8 maybe able last long time-- in which is a good thing. Lu > On 2014年7月2日, at 下午12:00, address-policy-wg-request(a)ripe.net wrote: > > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Use of the Reserved IP Pool > (Dpto. Datos Television Costa Blanca) > 2. Re: Use of the Reserved IP Pool (Richard Hartmann) > 3. Re: Use of the Reserved IP Pool > (Dpto. Datos Television Costa Blanca) > 4. Re: Use of the Reserved IP Pool (Jim Reid) > 5. Re: Use of the Reserved IP Pool > (Dpto. Datos Television Costa Blanca) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 02 Jul 2014 10:47:13 +0200 > From: "Dpto. Datos Television Costa Blanca" <datos(a)tvt-datos.es> > Subject: Re: [address-policy-wg] Use of the Reserved IP Pool > To: address-policy-wg(a)ripe.net > Message-ID: <53B3C711.9000701(a)tvt-datos.es> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi all, > > As I said in this list, and since the Available IP Pool grow to near a > /8 I want to start this topic again. > And the question is: Should be use the Available IP Pool > (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po…), > what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 > IPv4 allocation for another /22 (or other prefix)??? > > Please, comment it. > > Regards, > > El 30/04/2014 12:23, Dpto. Datos Television Costa Blanca escribi?: >> Hi Carsten, >> >> I know, but before sending any proposal, and to be honest, I dont know >> what proposal I would need to change for the use of the Reserved IP >> Pool, I'd like to see others opinions, changes, etc... >> >> Regards, >> >> El 30/04/2014 12:20, Carsten Schiefner escribi?: >>> Hi Daniel, >>> >>>> On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote: >>>> Seems everybody stop writting with this topic, what I have changed to >>>> "Use of the Reserved IP Pool" >>>> >>>> Are we going to discuss if we made an use of the Reserved IP Pool when >>>> it reachs a non-defined-yet prefix to give at least another /22 to >>>> those >>>> LIRs with only 1 /22? >>> >>> it appears that you would need to send some text wrt. the parts of >>> the relevant policies you would like to see changed. >>> >>> Best, >>> >>> -C. > > -- > Daniel Baeza > Centro de Observaci?n de Red > Dpto. Internet y Telefon?a > Television Costa Blanca S.L. > Telf. 966190565 > WEB: http://www.tvt.es > Correo: datos(a)tvt-datos.es > > --AVISO LEGAL-- > > En cumplimiento de la Ley Org?nica 15/1999, de 13 de diciembre de protecci?n de datos de car?cter personal, se pone en conocimiento del destinatario del presente correo electr?nico, que los datos incluidos en este mensaje, est?n dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de env?o y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. > Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificaci?n, cancelaci?n y especificaci?n de los mismos, derechos que podr? hacer efectivos dirigi?ndose a Televisi?n Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante). > > > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Jul 2014 10:56:03 +0200 > From: Richard Hartmann <richih.mailinglist(a)gmail.com> > Subject: Re: [address-policy-wg] Use of the Reserved IP Pool > To: "Dpto. Datos Television Costa Blanca" <datos(a)tvt-datos.es> > Cc: Address Policy Working Group <address-policy-wg(a)ripe.net> > Message-ID: > <CAD77+gTQMS7nsq0JP3m=YawfFhOMYkaWAV1X17bh4W9vxkK9ZQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Wed, Jul 2, 2014 at 10:47 AM, Dpto. Datos Television Costa Blanca > <datos(a)tvt-datos.es> wrote: >> Should be use the Available IP Pool >> (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po…), >> what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 >> allocation for another /22 (or other prefix)??? > > While I can see where you are coming from, this would open the door > for perpetual "this is the last time, promise!" situations. If this > was accepted policy, time passed, and addresses were used up, what > would happen with all new LIRs which only have one /21? After the next > upgrade, what would happen with those which only have one /20? > > Given the history of those threads, I can not see consensus forming to > undo this change. > > > Sorry, > Richard > > > > ------------------------------ > > Message: 3 > Date: Wed, 02 Jul 2014 11:10:35 +0200 > From: "Dpto. Datos Television Costa Blanca" <datos(a)tvt-datos.es> > Subject: Re: [address-policy-wg] Use of the Reserved IP Pool > Cc: Address Policy Working Group <address-policy-wg(a)ripe.net> > Message-ID: <53B3CC8B.3060705(a)tvt-datos.es> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > El 02/07/2014 10:56, Richard Hartmann escribi?: >> On Wed, Jul 2, 2014 at 10:47 AM, Dpto. Datos Television Costa Blanca >> <datos(a)tvt-datos.es> wrote: >>> Should be use the Available IP Pool >>> (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po…), >>> what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 >>> allocation for another /22 (or other prefix)??? >> While I can see where you are coming from, this would open the door >> for perpetual "this is the last time, promise!" situations. If this >> was accepted policy, time passed, and addresses were used up, what >> would happen with all new LIRs which only have one /21? After the next >> upgrade, what would happen with those which only have one /20? >> >> Given the history of those threads, I can not see consensus forming to >> undo this change. > I really understand what you mean, but take our position (New LIR with > only a /22). > I have IPv6 deployed on our network, at least half of our customers have > Dual-Stack access, the other half dont have IPv6 due to dont have a IPv6 > enabled equiptment (most of actual home routers (TPLINK, Conceptronic, > etc.) dont support it. > Our LIR have 5 stars IPv6, we have reserved from our /22 a /24 for > possible transitional mechanism if we run out of IPv4, but since > transitional mechanism harm mental health I wish to dont need it. > > I know opening the door to this could make IPv6 deploy slower, but if > one of the requirements to get another /22 (or other prefix) is to have > 5 stars plus other ones to ensure the deploy and use of IPv6 it may help > on IPv6 deployment. > > To ensure Im not crazy about asking for that, APNIC is doing something > similar http://www.apnic.net/policy/proposals/prop-105 > > Regards, > >> >> Sorry, >> Richard > > -- > Daniel Baeza > Centro de Observaci?n de Red > Dpto. Internet y Telefon?a > Television Costa Blanca S.L. > Telf. 966190565 > WEB: http://www.tvt.es > Correo: datos(a)tvt-datos.es > > --AVISO LEGAL-- > > En cumplimiento de la Ley Org?nica 15/1999, de 13 de diciembre de protecci?n de datos de car?cter personal, se pone en conocimiento del destinatario del presente correo electr?nico, que los datos incluidos en este mensaje, est?n dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de env?o y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. > Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificaci?n, cancelaci?n y especificaci?n de los mismos, derechos que podr? hacer efectivos dirigi?ndose a Televisi?n Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante). > > > > > ------------------------------ > > Message: 4 > Date: Wed, 2 Jul 2014 10:35:44 +0100 > From: Jim Reid <jim(a)rfc1035.com> > Subject: Re: [address-policy-wg] Use of the Reserved IP Pool > To: Dpto. Datos Television Costa Blanca <datos(a)tvt-datos.es> > Cc: Address Policy Working Group <address-policy-wg(a)ripe.net> > Message-ID: <B485997B-74D9-402A-AFC8-A43A45A99717(a)rfc1035.com> > Content-Type: text/plain; charset=us-ascii > >> On 2 Jul 2014, at 10:10, Dpto. Datos Television Costa Blanca <datos(a)tvt-datos.es> wrote: >> >> I know opening the door to this could make IPv6 deploy slower, but if one of the requirements to get another /22 (or other prefix) is to have 5 stars plus other ones to ensure the deploy and use of IPv6 it may help on IPv6 deployment. > > I am not sure what problem you are trying to solve. Or how changing address policy will solve that problem. > > You say half your customers don't have IPv6-enabled CPE. This does not seem to me to be a justification for ripping up the current address policy to burn through the remaining dregs of IPv4 and leave absolutely nothing for any newcomers in 5, 10 or 20 years from now. > > To be quite blunt, ISPs these days really must be shipping dual-stack CPE AND have the supporting IPv6 infrastructure in place: working v6 transport/routing; provisioning; DNS; addressing/subnetting plans; etc, etc. > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 02 Jul 2014 11:52:48 +0200 > From: "Dpto. Datos Television Costa Blanca" <datos(a)tvt-datos.es> > Subject: Re: [address-policy-wg] Use of the Reserved IP Pool > To: Address Policy Working Group <address-policy-wg(a)ripe.net> > Message-ID: <53B3D670.1080600(a)tvt-datos.es> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Jim, > > You understandme wrong or I did not said it well. > Im saying I have deployed IPv6 on my network. I cant "force" a customer > to buy another home router supporting IPv6. Anyways, as all of you know, > IPv6 isnt globally deployed to work only on that, so you need Dual-Stack > or DS-lite,NAT64, etc... if you run out of IPv4. > My infrastucture support full IPv6 conectivity, we as an ISP do our job > on IPv6 deployment. > > About newcomers on 5,10 or 20 years... I will not talk about 5 years, > but 10 or 20....if in 10-20 years IPv6 is not the main protocol as IPv4 > is now, dude, we have a very big problem. We cant know what will happen > then. > > But now, year 2014, LIRs with only /22 are having "troubles" managing > their network with only 1024 addresses. What Im trying is to help them > (and me!) with that additional /22 (or it could start with /24 since > there is a proposal to remove the minium allocation of /22) so they will > have a breath while IPv6 are fully deployed on the world. > > A /24 can give you the chance to grow in customers without wasting in > expensive equipment for CGNAT, NAT64, etc.. for some time, maybe the > time needed by the rest of the world to finish in the IPv6 deployment. > > Please, sorry about my very bad english, I know some phrases could not > have sense. If so, please tell me and I will try to explain in other way > so you all can understand what Im trying to say. > > Regards, > > El 02/07/2014 11:35, Jim Reid escribi?: >> On 2 Jul 2014, at 10:10, Dpto. Datos Television Costa Blanca <datos(a)tvt-datos.es> wrote: >> >>> I know opening the door to this could make IPv6 deploy slower, but if one of the requirements to get another /22 (or other prefix) is to have 5 stars plus other ones to ensure the deploy and use of IPv6 it may help on IPv6 deployment. >> I am not sure what problem you are trying to solve. Or how changing address policy will solve that problem. >> >> You say half your customers don't have IPv6-enabled CPE. This does not seem to me to be a justification for ripping up the current address policy to burn through the remaining dregs of IPv4 and leave absolutely nothing for any newcomers in 5, 10 or 20 years from now. >> >> To be quite blunt, ISPs these days really must be shipping dual-stack CPE AND have the supporting IPv6 infrastructure in place: working v6 transport/routing; provisioning; DNS; addressing/subnetting plans; etc, etc. > > -- > Daniel Baeza > Centro de Observaci?n de Red > Dpto. Internet y Telefon?a > Television Costa Blanca S.L. > Telf. 966190565 > WEB: http://www.tvt.es > Correo: datos(a)tvt-datos.es > > --AVISO LEGAL-- > > En cumplimiento de la Ley Org?nica 15/1999, de 13 de diciembre de protecci?n de datos de car?cter personal, se pone en conocimiento del destinatario del presente correo electr?nico, que los datos incluidos en este mensaje, est?n dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de env?o y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. > Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificaci?n, cancelaci?n y especificaci?n de los mismos, derechos que podr? hacer efectivos dirigi?ndose a Televisi?n Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante). > > > > > End of address-policy-wg Digest, Vol 35, Issue 1 > ************************************************

1 0

why-pi question still in request form after 2011-02 acceptance?
by Daniel Roesen 26 Jun '14

26 Jun '14

Hi, could someone explain the rationale that the "why-pi" question is still in the IPv6 PI request form? Given that since acceptance and implementation of 2011-02 there are no special requirements attached to IPv6 PI anymore (other than the bureaucracy), I see absolutely no point in having people explain "why PA address space cannot be used for this assignment". The obvious, totally acceptable yet completely superfluous answer would be "because PA is not provider independent". I'd suggest to simply remove this "why-pi" question from the request form and supporting notes. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 2

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Tore Anderson 23 Jun '14

23 Jun '14

* Marco Schmidt > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 2 July 2014. I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of «LIR» should be avoided. However, I'd also like to add that suggested replacement «organisation» could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as «resource holder»/«resource holder to be» or «entity». 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: «When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.» These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, «fulfill» is incorrectly spelled.) 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: «If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.» This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. Tore

1 0

Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4)
by Sander Steffann 17 Jun '14

17 Jun '14

Dear working group, The working group chairs have decided to send policy proposal 2014-01, Abandoning the Minimum Allocation Size for IPv4, to Last Call. During the discussion phase there was already general support for this policy proposal. Some people asked for the minimum size of sub-allocations too be included in this policy proposal as well. This was done in version 2 of the proposal text. After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: - Tore Anderson - Jan Ingvoldstad - Piotr Strzyzewski - Sascha Luck - Jens Ott - George Giannousopoulos - Andreas Larsen - Sebastian Wiesinger The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. Cheers, Gert and Sander Your APWG chairs

5 4

2014-01 Last Call for Comments (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 16 Jun '14

16 Jun '14

Dear colleagues, The proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 15 July 2014 and must be supported by an explanation. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-01 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 15 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10
by Lu 10 Jun '14

10 Jun '14

+1 This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. > On 2014年6月10日, at 下午12:00, address-policy-wg-request(a)ripe.net wrote: > > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Nick Hilliard) > 2. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Dimitri I Sidelnikov) > 3. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources > (Jens Ott - Opteamax GmbH) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 09 Jun 2014 15:40:52 +0100 > From: Nick Hilliard <nick(a)inex.ie> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395C774.2040403(a)inex.ie> > Content-Type: text/plain; charset=ISO-8859-1 > >> On 09/06/2014 14:53, Hank Nussbacher wrote: >> On a related matter, is it possible currently to setup my aut-num that if >> anyone adds my autnum to their import/export/as-set objects I would receive >> a notification about it? Currently the "notify" field only informs me of >> changes to the specific aut-num, not people who reference my aut-num w/o my >> permission? > > +1 > > I'd also like to see when someone includes my autnums or as-sets in their > as-sets. This has clobbered me in the past with highly unwelcome changes > to production traffic flows. > > Nick > > > > > ------------------------------ > > Message: 2 > Date: Mon, 09 Jun 2014 21:05:39 +0400 > From: Dimitri I Sidelnikov <sid(a)free.net> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395E963.5030005(a)free.net> > Content-Type: text/plain; charset=UTF-8 > > I support it. > > 09.06.2014 16:49, Jo?o Damas ?????: >> Dear all, >> at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. >> >> The observed consensus during the meeting was that: >> >> - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. >> - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; >> - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. >> >> We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. >> We propose a 15 day comment period, ending June 24th 2014. >> >> Sander Steffann, Gert D?ring, Rob Evans, Jo?o Damas > > -- > > Kind regards, > --- > D.Sidelnikov > > > > > ------------------------------ > > Message: 3 > Date: Mon, 09 Jun 2014 16:20:54 +0200 > From: Jens Ott - Opteamax GmbH <jo(a)opteamax.de> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9(a)email.android.com> > Content-Type: text/plain; charset=UTF-8 > > > >> On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher <hank(a)efes.iucc.ac.il> wrote: >> At 14:49 09/06/2014 +0200, Jo?o Damas wrote: >>> Dear all, >>> at the recent RIPE 68 meeting there was a discussion about issues >>> concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and >>> possible modifications to the content of routing-related attributes in >> >>> RIPE Database objects, namely the routing policy attributes of autnum >> and >>> as-set objects. >>> >>> The observed consensus during the meeting was that: >>> >>> - the RIPE NCC should not to remove references to recovered ASNs from >>> import and export lines, and neither from as-set objects; routing >> policies >>> are the realm of the object owner and are not related to allocation >> data. >> >> On a related matter, is it possible currently to setup my aut-num that >> if >> anyone adds my autnum to their import/export/as-set objects I would >> receive >> a notification about it? Currently the "notify" field only informs me >> of >> changes to the specific aut-num, not people who reference my aut-num >> w/o my >> permission? >> >> If this is not feasible with the system today, would it be possible to >> add >> this feature? I'll explain the rationale: we have recently discovered >> that >> hostile aut-num's that intend to perform a BGP hijack, will add the >> victims >> aut-num to their routing policy or to their unsuspecting upstream. >> This >> policy is then picked up as legitimate and propogated. By having a >> "notify-on-policy" email address field, I would be able to quickly see >> who >> is planning on hijacking my IP ranges. >> >> Comments? >> > > I fully support your point. I also observed what you told here. Therefore we enhanced our Prefixlist-Generator doing counter-checks if an import statement also have a corresponding export - statement. Result is, that the prefixlist generation takes about 10 times longer, our caching database grew by factor eight (as we now also need to cache autnum objects of child- and grandchild-objects) ... > > So a "notify-on-policy" - how you called it - would be very appreciated! > > BR Jens >> Thanks, >> Hank >> >> >> >> >> >> !DSPAM:637,5395bdec188062364380171! > > -- > Jens Ott > Opteamax GmbH > Simrockstr. 4G > 53619 Rheinbreitbach > Tel. +49 2224 969500 > Email: jo(a)opteamax.de > > > > End of address-policy-wg Digest, Vol 34, Issue 10 > *************************************************

3 2

Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources
by João Damas 09 Jun '14

09 Jun '14

Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. The observed consensus during the meeting was that: - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014. Sander Steffann, Gert Döring, Rob Evans, João Damas

7 7

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Jan Ingvoldstad 07 Jun '14

07 Jun '14

On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > https://www.ripe.net/ripe/policies/proposals/2014-05 I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers. I have a comment regarding the second argument against the policy, "*The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers*." I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process. In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan

6 9

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Nigel Titley 07 Jun '14

07 Jun '14

On 03/06/14 14:13, Marco Schmidt wrote: > Dear colleagues, > > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 2 July 2014. > > Speaking as myself and myself only. Much as I disliked the woolly language of its predecessor I think this version is crisp and clean. Once the already mentioned nits about LIR/Member/Organisation/Stonecutter are sorted out, and with a possible fix to 2014-01, as mentioned by Carsten, I think this would be a good addition to RIPE region policy. Nigel

1 0

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by sandrabrown＠ipv4marketgroup.com 06 Jun '14

06 Jun '14

On Thu, Jun 5, 2014 at 2:25 PM, Jan Ingvoldstad <frettled(a)gmail.com> wrote: > On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand <scottleibrand(a)gmail.com> > wrote: > >> Overall, this policy looks good to me. However, I believe there is one >> problem with the text. The language regarding recipients in other regions >> requires that the recipient be an LIR. However, the transfer policies of >> the other regions do not make any such distinction. Therefore, I believe it >> would be more appropriate to use the word organization instead of LIR when >> referring to recipients in other regions. >> > > That's a fair point. > > -When Internet number resources are transferred to another RIR, the RIPE > NCC will work with the destination RIR to allow the transfer to the > receiving LIR. > +When Internet number resources are transferred to another RIR, the RIPE > NCC will work with the destination RIR to allow the transfer to the > receiving organization. > > Like that? > Yes. ________________________ I am in agreement with Scott and Jan on this revision..."LIR" becomes "receiving organization". Thank you to you both. - Sandra Also: -Address space may only be re-allocated to another LIR that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. +Address space may only be re-allocated to another organization that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. However, that may have implications for intra-RIR transfers, so you might need to separate out the two cases if you don't want to imply that non-LIR organizations can receive transfers in the RIPE region. Maybe something like "to another LIR in the RIPE region, or an organization that is a member of an RIR that allows transfers." -Scott _______________ Replacing "LIR" with "organization" should also be ok within the context of RIPE Transfer Policy. - Sandra _________________

1 0

Re: [address-policy-wg] [sig-policy] RIPE Policy Text for Inter-RIR Transfers - 2014-05
by Sander Steffann 05 Jun '14

05 Jun '14

Hi John, Op 5 jun. 2014, om 16:54 heeft John Curran <jcurran(a)arin.net> het volgende geschreven: > On Jun 5, 2014, at 7:24 AM, Skeeve Stevens <skeeve(a)eintellegonetworks.com> wrote: > >> Here is the policy text being proposed in RIPE for Inter-RIR Transfers - 2014-05 >> >> https://www.ripe.net/ripe/policies/proposals/2014-05 I think this policy should be discussed on the RIPE address policy mailing list. Feedback in other places does not have much effect ;) CC'ing APWG now. > From the proposed policy text (with labels added for reference) - > > (a) > When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. > > (b) > When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR. > > (c) > If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources. > > The intent of the above text may not be clear with respect to resources coming from > another region (b) which are presently "legacy" resources in that region, i.e. it might > be possible to reasonable argue that the policy intent is (b) or (c) for that case. When receiving resources from another region then (b) will always apply. At a minimum the RIRs have to work together to keep the databases consistent. If the originating RIR tells the RIPE NCC that those resources are legacy resources then the receiver can choose to have them treated as legacy resources in the RIPE region as well. But the policy does not allow conversion in the other direction. If ARIN would tell the RIPE NCC that the resources are *not* legacy resources (not ever, or not anymore) then they can not not be treated as legacy after transfer. > (Not a comment in favor or opposition to the proposed policy; just seeking clarity so > that implementation, if it were adopted, has solid alignment with the policy intent.) Thanks. Please continue the discussion on the RIPE APWG list ;) Cheers! Sander

1 0

2012-02 Policy Proposal Withdrawn (Policy for Inter-RIR transfers of IPv4 address space)
by Marco Schmidt 03 Jun '14

03 Jun '14

Dear colleagues, The proposal 2012-02, "Policy for Inter-RIR transfers of IPv4 address space" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/ripe/policies/proposals/2012-02 Reason for withdrawal: The proposer of 2012-02 proposed 2014-05, a new inter-RIR transfer policy. 2014-05 focuses on being aligned with internal resource transfers as well as being more cohesive with the policies of other RIRs. As a consequence, the proposer decided to withdraw 2012-02. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Marco Schmidt 03 Jun '14

03 Jun '14

Dear colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-05 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 2 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-03 Draft Document and Impact Analysis will be produced (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 02 Jun '14

02 Jun '14

Dear colleagues, The discussion period for the proposal described in 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-02 Draft Document and Impact Analysis will be produced (Allow IPv4 PI transfer)
by Marco Schmidt 30 May '14

30 May '14

Dear colleagues, The discussion period for the proposal described in 2014-02, "Allow IPv4 PI transfer" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-02 Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Special Issue on "Underwater Sensor Networks" in (JSAN)
by Sandra Sendra 28 May '14

28 May '14

=================================================== Journal of Sensor and Actuator Networks (JSAN) Special Issue "Underwater Sensor Networks" http://www.mdpi.com/journal/jsan/special_issues/usn Deadline for manuscript submissions: 30 September 2014 ---------------------------------------------------- === SPECIAL ISSUE === New advances in information technologies, circuits, systems and communication protocols have made possible the deployment of underwater sensor networks. These issues have lead researchers to propose new underwater sensor nodes, sensor node placement, protocols for their communication, architectures, and study new ways to communicate with higher bandwidth at higher distances. Moreover, the range of underwater applications is growing fast because of the last research in oceanography, marine science and aquiculture, so there is a need of underwater sensor networks in order to support these disciplines. This special Issue is tries to collect unpublished works on theory and practice on underwater sensor networks, with special interest on real implementations and deployments. We also seek new proposals on wireless communication technologies. === KEYWORDS === The Special Issue "Underwater Sensor Networks" topics include (but are not limited to) the following: - Underwater sensor nodes - Underwater sensor node placement - Routing protocols for underwater sensor networks - Underwater communications - Underwater architectures - Underwater wireless communications - Underwater sensor network deployments === SUBMISSION === Manuscripts should be submitted online at www.mdpi.com by registering and logging in to this website. Once you are registered, click here to go to the submission form (http://www.mdpi.com/user/manuscripts/upload/?journal=jsan). Manuscripts can be submitted until the deadline. Papers will be published continuously (as soon as accepted) and will be listed together on the special issue website. Research articles, review articles as well as communications are invited. For planned papers, a title and short abstract (about 100 words) can be sent to the Editorial Office for announcement on this website. Submitted manuscripts should not have been published previously, nor be under consideration for publication elsewhere (except conference proceedings papers). All manuscripts are refereed through a peer-review process. A guide for authors and other relevant information for submission of manuscripts is available on the Instructions for Authors page. Journal of Sensor and Actuator Networks is an international peer-reviewed Open Access quarterly journal published by MDPI. Please visit the Instructions for Authors page (http://www.mdpi.com/journal/jsan/instructions) before submitting a manuscript. For the first couple of issues the Article Processing Charge (APC) will be waived for well-prepared manuscripts. English correction and/or formatting fees of 250 CHF (Swiss Francs) will be charged in certain cases for those articles accepted for publication that require extensive additional formatting and/or English corrections. === SPECIAL ISSUE EDITORS === Guest Editors Prof. Dr. Jaime Lloret Mauri (jlloret(a)dcom.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain Dr. Sandra Sendra (sansenco(a)posgrado.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain ===================================================

1 0

Re: [address-policy-wg] 2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer)
by Erik Bais 21 May '14

21 May '14

Hi I want to point out that the discussion period of this policy proposal ( 2014-02 Allow IPv4 PI Transfer) will end in a couple days. https://www.ripe.net/ripe/policies/proposals/2014-02 During the RIPE68 AP-WG session I provided a presentation based on the feedback on this list and the policy. https://ripe68.ripe.net/archives/video/167/ The webcast and presentation can be found on the link above for those that missed it. If there are specific questions on the way of the proposal is written or if there are questions about the proposal, please respond here on the list. And also if you agree with the proposal, do state your support here on the list. Kind regards, Erik Bais Author of 2014-02

2 1

Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Jan Ingvoldstad 20 May '14

20 May '14

On Mon, May 5, 2014 at 3:17 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-04 > My feelings are mixed. On one hand, I don't quite see why the current requirement for IPv6 PA is there, and therefore it seems obvious that having IPv6 PI should be a valid requirement as well. On the other hand, if any proposal ever had the look of rearranging deck chairs, this seems like it. So I'm a bit on the fence here, awaiting further discussion to see what I haven't thought about – you, my colleagues here, always seem to think of and speak of such things. -- Jan

10 13

IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014)
by Sandra Sendra 20 May '14

20 May '14

********************************************************* CALL FOR PAPERS IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014) Submission due July 31, 2014 http://cloudcps.cwins.org Dec 15 � 18, 2014, Singapore Singapore in conjunction with IEEE CloudCom 2014, Dec 15 � 18, 2014, Singapore ******************************************************************** Technology has gone through tremendous changes in terms of computing, communications and control to provide wide range of applications in all domains. This advancement provides the opportunities to bridge the physical components/processes and the cyber space leading to the Cyber Physical Systems (CPS). The notion of CPS is to use computing (sensing, analyzing, predicting, understanding, etc.), communication (interaction, intervene, interface management, etc.) and control (inter-operate, evolve, evidence-based certification, etc.) to make intelligent and autonomous systems. Such systems are playing an increasingly prevalent and important role in this electronic era such as healthcare, manufacturing, civil infrastructure, aerospace, entertainment, transportation and many automated physical systems. Computing and networking are two major components of CPS and Cloud has infinite resources for both. Cloud-integrated CPS will not only enhance CPS itself but also process, analyze! and manage (CPS) big data efficien tly. However, there are many issues and hurdles of Cloud-integrated CPS that need discussions. Our aim is to provide a platform for researchers and practitioners to present their research results in the area of Cloud-integrated Cyber-Physical Systems. The proposed workshop CloudCPS-2014 will serve as a forum for researchers from academia, government and industries to exchange ideas, present new results and provide future visions on these topics. Topics of interest include but not limited to: - Cloud-CPS Architecture - Cloud-CPS Modeling and Simulation - Virtualization of Physical Components in Cloud-CPS - Design and Performance Optimization in Cloud-CPS - Cloud-assisted Situation-aware and decision support - Big-data Processing and Visualization in Cloud-CPS - Mobile Cloud-CPS - Game Theory for Cloud-CPS - Tools and Methods for Cloud-CPS - Sensor-actuator Networks - Security, Privacy, and Trust in Cloud-CPS - Intelligent (Road/Air) Transportation Cloud-CPS - Cloud-CPS in healthcare - Cloud-CPS in energy - Fog computing - Cloud-CPS: Tools, test beds and deployment issues - Opportunistic spectrum access for Cloud-CPS ***************************** SUBMISSION INSTRUCTIONS ***************************** The authors are advised to submit their research paper following the IEEE CS format: two columns, single-spaced, including figures and references, using 10 fonts, and number each page. Instructions for authors how to format the manuscript can be found at: http://www.computer.org/portal/web/cscps/submission/ http://www.computer.org/portal/web/cscps/formatting/ The following templates below, are general templates designed for conferences using an US Letter (8.5" x 11") trim size. MS Word Template: http://www.computer.org/portal/c/document_library/get_file?uuid=4cc57ba2-39… LaTeX Package: http://www.computer.org/portal/c/document_library/get_file?uuid=cda2f9b2-51… Papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. The papers, in pdf format, should be submitted electronically through https://www.easychair.org/conferences/?conf=ieeecloudcps2014. If there is any problem during submission, please contact the workshop general chairs or db.rawat(at)ieee.org. All accepted papers will be published by IEEE CS Press (submitted to IEEEXplore) and submitted for indexing by EI and ISSN. *********************** Important Dates *********************** Deadline for paper submissions: July 31, 2014 Notification of Paper acceptance: Sept. 2, 2014 Deadline for camera-ready: Sept.16, 2014 Deadline for author registration: Oct. 1, 2014 Conference: December 15-18, 2014 WORKSHOP WEBSITE For more information, please visit the workshop website at http://cloudcps.cwins.org ++++++++++++++++ Organizers ++++++++++++++++ **************** General Chairs **************** Ivan Stojmenovic, University of Ottawa, Canada Danda B. Rawat, Georgia Southern University, USA Jaime Lloret Mauri, Polytechnic University of Valencia, Spain ****************** Program Chairs ****************** Bhed B. Bista, Iwate Prefectural University, Japan Song Guo, The University of Aizu, Japan ******************* Publicity Chairs ******************* Sandra Sendra, Polytechnic University of Valencia, Spain

1 0

Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space"
by Skeeve Stevens 18 May '14

18 May '14

Hi all, I wanted to understand the current status of Inter-RIR transfers in the RIPE region. The website for the policy being proposed: http://www.ripe.net/ripe/policies/proposals/2012-02 States that the current phase is: "Review Phase: Awaiting Decision from Working Group Chair", but that the current phase ends on 17 April 2013 - over a year ago. The 'inter-RIR transfers' section of http://www.ripe.net/lir-services/resource-management/ipv4-transfers refers back to the policy above. Given that RIPE has run out of resources, is it really not allowing other RIR's with a conditional policy like ARIN ( https://www.arin.net/resources/request/transfers_8_4.html) not to transfer into the region? APNIC does not have this restriction, but should have the same condition if an RIR doesn't have a reciprocal policy in place. Thoughts? ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks Business skeeve(a)v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers

2 5

Re: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by Sebastian Wiesinger 15 May '14

15 May '14

* Marco Schmidt <mschmidt(a)ripe.net> [2014-05-15 10:09]: > > Dear colleagues, > > > The draft document for version 2.0 of the policy proposal 2014-01, > "Abandoning the Minimum Allocation Size for IPv4" has now been published, > along with an impact analysis conducted by the RIPE NCC. I support this. Continue with the cleanup. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4)
by Tore Anderson 15 May '14

15 May '14

* Marco Schmidt > The draft document for version 2.0 of the policy proposal 2014-01, > "Abandoning the Minimum Allocation Size for IPv4" has now been published, > along with an impact analysis conducted by the RIPE NCC. I support this proposal - especially after taking the NCC's reassuring impact analysis into account. Tore

4 3