From saku at ytti.fi Thu May 1 12:10:44 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 1 May 2014 13:10:44 +0300 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <20140501101044.GA4000@pob.ytti.fi> On (2014-04-30 18:30 +0100), James Blessing wrote: Hi James, > > https://www.ripe.net/ripe/policies/proposals/2014-03 > > Other than the use cases suggested in the document (which could be > achieved using private ASNs) is there a reason for this that I'm > missing? Without having public ASN, migrating from upstream X to upstream Y will be problematic. And as private ASN won't be distributed from your upstream, you cannot use communities to communicate with far-end system. So it won't be the same in every use-case. Also consider: customerLAN CE PE If CE is managed by same instance as PE, what ASN should you use for your CE? Every CE in whole network can use same ASN, but what ASN to use? If you choose privateASN, you can easily collidate with customerLAN and you cannot know what configuration to use beforehand, creating complexity (which reduces quality). Infact, this is not even change to a implicit policy, implicit policy shared by community today is, that having ASN without two upstream is justifiable and quite common. It's so common, RIPE does not even enforce the current policy in any way, since community would not want that. It's just about making the explicit policy match the implicit/practical policy. Few things I'm somewhat concerned of, but seem to be out-of-scope for this particular policy, but may require work in other places. a) should 16b ASN be special? You get GLOP/24 with it and you get BGP communities. Some use-cases absolutely depend on these, some use-cases don't. Is it realistic/possible to have different requirements for 16b and 32b? b) policy is quite (and was) soft is it possible to have hard policy? I define soft policy as abstract or approximate and open to interpretation, where as hard policy is exact and unambiguous. But hard policies seems nearly impossible, at least Finnish law always fails my definition of hard policy. And this policy also fails that. Hard policy would be for example one which does not have _any_ requirement on requesting and getting ASN, however that would lead to a situation where someone can request 32b of them, which could be made non-issue by having 1EUR YRC, but billing changes is out-of-scope. Right now, the policy stops hoarding with sentence 'cannot be satisfied with an existing or private AS Number.', which is soft, as it's interpreted by hostmaster, but it is in tradition of other RIPE policies. -- ++ytti From mschmidt at ripe.net Thu May 1 14:01:20 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 01 May 2014 14:01:20 +0200 Subject: [address-policy-wg] 2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer) Message-ID: Dear colleagues, The Discussion Period for the proposal 2014-02, "Allow IPv4 PI transfer" has been extended until 23 May 2014. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From frettled at gmail.com Thu May 1 15:48:38 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 1 May 2014 15:48:38 +0200 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20140501101044.GA4000@pob.ytti.fi> References: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> <20140501101044.GA4000@pob.ytti.fi> Message-ID: First, I'd like to say that I support the proposal. On Thu, May 1, 2014 at 12:10 PM, Saku Ytti wrote: > > b) policy is quite (and was) soft is it possible to have hard policy? I > define soft policy as abstract or approximate and open to interpretation, > where as hard policy is exact and unambiguous. But hard policies seems > nearly > impossible, at least Finnish law always fails my definition of hard > policy. And this policy also fails that. > Hard policy would be for example one which does not have _any_ > requirement on > requesting and getting ASN, however that would lead to a situation where > someone can request 32b of them, which could be made non-issue by having > 1EUR > YRC, but billing changes is out-of-scope. > Right now, the policy stops hoarding with sentence 'cannot be satisfied > with > an existing or private AS Number.', which is soft, as it's interpreted by > hostmaster, but it is in tradition of other RIPE policies. > > I like the soft policy. I think that if there are signs that someone starts hoarding, RIPE NCC would notify the community about the issue and request that we consider a policy for that, or perhaps someone outside the NCC would notice and create their own policy proposal. Until then, it is unnecessary to do anything in particular about it, except think about it and be prepared for this eventuality. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Thu May 1 16:13:19 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 1 May 2014 16:13:19 +0200 Subject: [address-policy-wg] [policy-announce] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <5360fbb9.48c70e0a.179a.6dafSMTPIN_ADDED_MISSING@mx.google.com> References: <5360fbb9.48c70e0a.179a.6dafSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Support. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Thu May 1 17:23:42 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 May 2014 08:23:42 -0700 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20140501101044.GA4000@pob.ytti.fi> References: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> <20140501101044.GA4000@pob.ytti.fi> Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30CD1@EXVPMBX100-1.exc.icann.org> Hi, I'm writing to provide some information and am neither speaking for or against the proposal. Saku Ytti wrote: [...] > Few things I'm somewhat concerned of, but seem to be out-of-scope for this > particular policy, but may require work in other places. > > a) should 16b ASN be special? You get GLOP/24 with it and you get BGP > communities. Some use-cases absolutely depend on these, some use-cases don't. > Is it realistic/possible to have different requirements for 16b and 32b? I should probably point out that there are other sources of IPv4 multicast address space if this is a consideration. Firstly, there are the Unicast-Prefix-Based IPv4 Multicast Addresses, which are assigned algorithmically. Every IPv4 /24 prefix gives the user a /32 multicast address from 234/8. If a network operator does not have GLOP or Unicast-Prefix-Based IPv4 Multicast Addresses, or has used all those addresses, then it also possible to request an assignment (https://www.iana.org/form/multicast-ipv4). There is no charge for multicast address assignments and there's no immediate danger of running out of multicast space to assign. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From kuenzler at init7.net Thu May 1 17:38:25 2014 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 01 May 2014 17:38:25 +0200 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) Message-ID: <53626A71.9090907@init7.net> Am 30.04.2014 15:28, schrieb Marco Schmidt: > A proposed change to RIPE Document ripe-525, "Autonomous System (AS) > Number Assignment Policies" is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 I support this proposal. However I suggest a small change in the text: "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing or private AS Number." should be "A new AS Number should only be assigned when there is a technical requirement that cannot be satisfied with an existing AS Number." Since we arrived in the 32bit-ASN century, private ASN should not matter anymore, i.e. noone should be forced to use private ASN permanently. Re hoarding: If someone thinks hoarding of AS206832 to AS207363 is useful, so be it... -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 / @kuenzler http://www.init7.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From nick at inex.ie Thu May 1 18:17:47 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 May 2014 17:17:47 +0100 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20140501101044.GA4000@pob.ytti.fi> References: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> <20140501101044.GA4000@pob.ytti.fi> Message-ID: <536273AB.7090704@inex.ie> On 01/05/2014 11:10, Saku Ytti wrote: > a) should 16b ASN be special? You get GLOP/24 with it and you get BGP > communities. Some use-cases absolutely depend on these, some use-cases don't. > Is it realistic/possible to have different requirements for 16b and 32b? running an ASN32 leaf network is fine, otherwise it's a bit tragic due to community pain. Would probably not be a bad idea to differentiate between asn16 and asn32 until we see a functional bgp community spec widely available which is fully asn32 compatible. Nick From andreas.larsen at ip-only.se Fri May 2 18:15:27 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Fri, 2 May 2014 16:15:27 +0000 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: <70569E92-44B0-43CB-8B89-AA3A272CC5B6@ip-only.se> +1 Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Bes?ksadress Uppsala: S:t Persg 6 Bes?ksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 30 apr 2014 kl. 18:05 skrev Johan Boger >: Dear Colleagues, I hereby vote YES on the proposal linked at https://www.ripe.net/ripe/policies/proposals/2014-03 Best Regards, -- Johan Boger, Project Manager (AS48285) e: johan at robtex.com w: http://www.robtex.com l: cy.robtex -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun May 4 16:12:43 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 4 May 2014 16:12:43 +0200 Subject: [address-policy-wg] Fwd: Updates to RIPE-500: Policy Development in RIPE References: <53662ACB.8030902@oslo.net> Message-ID: Hello WG, Work is being done on ripe-500, the Policy Development Process (PDP). As the PDP is quite important to the Address _Policy_ Working Group this is probably of interest to you. Hans Petter Holen, our RIPE Deputy Chair, has posted the proposed new revision on the RIPE list. For those of you who are not subscribed to the RIPE list: here is a copy of his message. If you want to comment on this proposed new text please do so on the RIPE list. Sincerely, Sander APWG Co-chair Begin doorgestuurd bericht: > Van: Hans Petter Holen > Onderwerp: Updates to RIPE-500: Policy Development in RIPE > Datum: 4 mei 2014 13:55:55 CEST > Aan: ripe-list at ripe.net > > Dear colleagues, > The Working-group chairs have for some time been discussing how to improve the Policy Development Process as described in RIPE-500. A small task force with Brian Nisbet as the coordinator and Ondrej Filip, Nick Hilliard and Hans Petter Holen as members has worked out the final details in the text. > > The wg-chairs have reached consensus on the attached proposal. > > The main change in the PDP is to allow the Working-group Chairs of the working-group developing the policy to declare consensus. > > This allows for a more timely conclusion of the PDP, but also allows for the Working-group chairs collectively to act as an appeals body. > > I am circulating the new text now for community review and the intent is to put this in place at the coming RIPE meeting. > > > Yours Sincerely, > > Hans Petter Holen > RIPE Deputy Chair > -------------- next part -------------- A non-text attachment was scrubbed... Name: revised PDP_1.pdf Type: application/pdf Size: 218950 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: revised PDP_1.0.txt URL: -------------- next part -------------- > From tore at fud.no Mon May 5 07:18:29 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 05 May 2014 07:18:29 +0200 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: <53671F25.4070907@fud.no> * Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-03 Makes sense to me. Tore From rogerj at gmail.com Mon May 5 08:52:32 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Mon, 5 May 2014 08:52:32 +0200 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: On Wed, Apr 30, 2014 at 6:05 PM, Johan Boger wrote: > Dear Colleagues, > > I hereby vote YES on the proposal linked at > https://www.ripe.net/ripe/policies/proposals/2014-03 I guess what you ment to say was that you supported the proposal?:-) http://en.wikipedia.org/wiki/Consensus_decision-making and https://tools.ietf.org/html/draft-resnick-on-consensus-07 btw: good to see you active here:-) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From johan at robtex.com Mon May 5 09:07:05 2014 From: johan at robtex.com (Johan Boger) Date: Mon, 5 May 2014 10:07:05 +0300 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: On Mon, May 5, 2014 at 9:52 AM, Roger J?rgensen wrote: > > > I guess what you ment to say was that you supported the proposal?:-) > > http://en.wikipedia.org/wiki/Consensus_decision-making > and https://tools.ietf.org/html/draft-resnick-on-consensus-07 > > > > > btw: good to see you active here:-) > > -- > > Roger Jorgensen | ROJO9-RIPE > rogerj at gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger at jorgensen.no > Dear Colleagues, Yes, apologies for voting in the wrong place. Then again, isn't a fake vote the strongest sign of support? I genuinely feel this proposal would strongly benefit the community, and it is one of those "why has this not been written before"-moments for me. Thanks for the welcome. I hope I can contribute. JB. -- Johan Boger, Project Manager (AS48285) e: johan at robtex.com w: http://www.robtex.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon May 5 12:58:34 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 5 May 2014 12:58:34 +0200 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: Hi Johan, > Yes, apologies for voting in the wrong place. Then again, isn't a fake vote the strongest sign of support? > I genuinely feel this proposal would strongly benefit the community, and it is one of those "why has this not been written before"-moments for me. Thank you for your very useful message. While the common '+1' messages are useful to determine the difference between 'nobody cares enough to comment' and 'people think this is a useful proposal', actually having comments that show the reasons and/or feelings for supporting a proposal are much much more valuable. > Thanks for the welcome. I hope I can contribute. You seem to have started well :) Welcome! Cheers, Sander APWG co-chair From elvis at v4escrow.net Mon May 5 13:05:40 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 05 May 2014 13:05:40 +0200 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: <53677084.2050404@v4escrow.net> Hi, you have my support for this policy change proposal. While the current policy was/is working fine, the RIPE NCC has no tools to actually enforce and/or verify the multihoming of an AS Number once it is issued. cheers, elvis On 05/05/14 12:58, Sander Steffann wrote: > Hi Johan, > >> Yes, apologies for voting in the wrong place. Then again, isn't a fake vote the strongest sign of support? >> I genuinely feel this proposal would strongly benefit the community, and it is one of those "why has this not been written before"-moments for me. > Thank you for your very useful message. While the common '+1' messages are useful to determine the difference between 'nobody cares enough to comment' and 'people think this is a useful proposal', actually having comments that show the reasons and/or feelings for supporting a proposal are much much more valuable. > >> Thanks for the welcome. I hope I can contribute. > You seem to have started well :) Welcome! > > Cheers, > Sander > APWG co-chair > > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From sid at free.net Mon May 5 13:17:36 2014 From: sid at free.net (Dimitri I Sidelnikov) Date: Mon, 05 May 2014 15:17:36 +0400 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: <53677084.2050404@v4escrow.net> References: <53677084.2050404@v4escrow.net> Message-ID: <53677350.8040806@free.net> +1 05.05.2014 15:05, Elvis Daniel Velea ?????: > Hi, > > you have my support for this policy change proposal. > > While the current policy was/is working fine, the RIPE NCC has no > tools to actually enforce and/or verify the multihoming of an AS > Number once it is issued. > > cheers, > elvis > -- Kind regards, --- D.Sidelnikov -------------- next part -------------- An HTML attachment was scrubbed... URL: From lir at elisa.fi Mon May 5 14:46:16 2014 From: lir at elisa.fi (lir at elisa.fi) Date: Mon, 5 May 2014 15:46:16 +0300 (EEST) Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 Message-ID: +1 I support this proposal. Rgds, Ray From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Elvis Daniel Velea Sent: 5. toukokuuta 2014 14:06 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 Hi, you have my support for this policy change proposal. While the current policy was/is working fine, the RIPE NCC has no tools to actually enforce and/or verify the multihoming of an AS Number once it is issued. cheers, elvis On 05/05/14 12:58, Sander Steffann wrote: Hi Johan, Yes, apologies for voting in the wrong place. Then again, isn't a fake vote the strongest sign of support? I genuinely feel this proposal would strongly benefit the community, and it is one of those "why has this not been written before"-moments for me. Thank you for your very useful message. While the common '+1' messages are useful to determine the difference between 'nobody cares enough to comment' and 'people think this is a useful proposal', actually having comments that show the reasons and/or feelings for supporting a proposal are much much more valuable. Thanks for the welcome. I hope I can contribute. You seem to have started well :) Welcome! Cheers, Sander APWG co-chair -- ************************************************************ Raymond Jetten ??? Phone: +358 3 41024 139 Senior System Specialist Fax: +358 3 41024 199 Elisa Oyj / Network Management Mobile: +358 45 6700 139 Hermiankatu 3A?? ?????????? raymond.jetten at elisa.fi FIN-33720, TAMPERE????????? http://www.elisa.fi ************************************************************ From mschmidt at ripe.net Mon May 5 15:17:56 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 05 May 2014 15:17:56 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: Dear colleagues, 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 We encourage you to review this proposal and send your comments to before 3 June 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From elvis at v4escrow.net Mon May 5 15:27:12 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 05 May 2014 15:27:12 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: <536791B0.1030006@v4escrow.net> Hi, I support this policy proposal. That being said, I do not understand why is this policy proposal making a difference between IPv6 PA and IPv6 PI assignments. I would say that someone can request the last /22 if they have an IPv6 block registered on their name - be it an allocation (ALLOCATED-BY-RIR), a sub-allocation (ALLOCATED-BY-LIR), using an aggregated block (AGGREGATED-BY-LIR) or an IPv6 PI or PA assignment. Regards, Elvis On 05/05/14 15:17, Marco Schmidt wrote: > Dear colleagues, > > > 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 > > We encourage you to review this proposal and send your comments to > before 3 June 2014. > > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From tom.smyth at wirelessconnect.eu Mon May 5 15:20:16 2014 From: tom.smyth at wirelessconnect.eu (Tom Smyth) Date: Mon, 5 May 2014 14:20:16 +0100 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 In-Reply-To: References: Message-ID: +1 for us also On Mon, May 5, 2014 at 1:46 PM, wrote: > > > +1 > > I support this proposal. > > Rgds, > > Ray > > > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Elvis Daniel Velea > Sent: 5. toukokuuta 2014 14:06 > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Support of https://www.ripe.net/ripe/ > policies/proposals/2014-03 > > > Hi, > > you have my support for this policy change proposal. > > While the current policy was/is working fine, the RIPE NCC has no tools to > actually enforce and/or verify the multihoming of an AS Number once it is > issued. > > cheers, > elvis > > On 05/05/14 12:58, Sander Steffann wrote: > Hi Johan, > > Yes, apologies for voting in the wrong place. Then again, isn't a fake > vote the strongest sign of support? > I genuinely feel this proposal would strongly benefit the community, and > it is one of those "why has this not been written before"-moments for me. > > Thank you for your very useful message. While the common '+1' messages are > useful to determine the difference between 'nobody cares enough to comment' > and 'people think this is a useful proposal', actually having comments that > show the reasons and/or feelings for supporting a proposal are much much > more valuable. > > Thanks for the welcome. I hope I can contribute. > > You seem to have started well :) Welcome! > > Cheers, > Sander > APWG co-chair > > > -- > ************************************************************ > Raymond Jetten Phone: +358 3 41024 139 > Senior System Specialist Fax: +358 3 41024 199 > Elisa Oyj / Network Management Mobile: +358 45 6700 139 > Hermiankatu 3A raymond.jetten at elisa.fi > FIN-33720, TAMPERE http://www.elisa.fi > ************************************************************ -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Mon May 5 15:46:01 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 5 May 2014 15:46:01 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5367901a.49620e0a.1bf7.1548SMTPIN_ADDED_MISSING@mx.google.com> References: <5367901a.49620e0a.1bf7.1548SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: +1 for the reasons listed in the proposal. Richard From frettled at gmail.com Mon May 5 17:13:20 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 5 May 2014 17:13:20 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, May 5, 2014 at 3:17 PM, Marco Schmidt 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggiannou at gmail.com Mon May 5 19:40:11 2014 From: ggiannou at gmail.com (George Giannousopoulos) Date: Mon, 5 May 2014 20:40:11 +0300 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5367901a.49620e0a.1bf7.1548SMTPIN_ADDED_MISSING@mx.google.com> References: <5367901a.49620e0a.1bf7.1548SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi, I support the proposal. I'll agree with the previous about the distinction between PI and PA. In my mind both were valid in order to get the last /22.. Regards, George On Mon, May 5, 2014 at 4:17 PM, Marco Schmidt wrote: > > Dear colleagues, > > > 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 > > We encourage you to review this proposal and send your comments to > before 3 June 2014. > > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon May 5 19:58:46 2014 From: gert at space.net (Gert Doering) Date: Mon, 5 May 2014 19:58:46 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <20140505175846.GR43641@Space.Net> Hi, On Mon, May 05, 2014 at 05:13:20PM +0200, Jan Ingvoldstad wrote: > 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. Historically it was put in there as an encouragement for "last /8" LIRs to "do something with IPv6"... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From frettled at gmail.com Mon May 5 20:43:41 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 5 May 2014 20:43:41 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20140505175846.GR43641@Space.Net> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> Message-ID: On Mon, May 5, 2014 at 7:58 PM, Gert Doering wrote: > Hi, > > On Mon, May 05, 2014 at 05:13:20PM +0200, Jan Ingvoldstad wrote: > > 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. > > Historically it was put in there as an encouragement for "last /8" LIRs > to "do something with IPv6"... > > I know that, but that's not quite what I meant. What I meant is that I don't see why the current requirement for IPv6 PA is there, but that the current document didn't already have IPv6 PI as a valid requirement. Not either-or. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon May 5 21:08:41 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 5 May 2014 21:08:41 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> Message-ID: <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> Hi Jan, >> Historically it was put in there as an encouragement for "last /8" LIRs >> to "do something with IPv6"... > > I know that, but that's not quite what I meant. > > What I meant is that I don't see why the current requirement for IPv6 PA is there, but that the current document didn't already have IPv6 PI as a valid requirement. > > Not either-or. I first thought that the last /8 policy was written before IPv6 PI for LIRs became possible, so I checked: - IPv6 PI for LIRS was 2009-08 (concluded in 2009) - Last /8 was 2010-02 Seems I was wrong. IPv6 PI for LIRs did exist at the time that the last /8 policy was written. I think at the time we just didn't even consider LIRs that didn't want/need IPv6 PA space. Cheers, Sander From tore at fud.no Mon May 5 21:53:34 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 05 May 2014 21:53:34 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> Message-ID: <5367EC3E.5040209@fud.no> * Sander Steffann > I think at the time we just didn't even consider LIRs that didn't > want/need IPv6 PA space. Right. But the summary of the proposal identifies the *actual* problem here: ?In order to qualify [for IPv6 PA], they need to request an IPv6 allocation and subsequently return their existing PI assignment (per ripe-589 section 7.1)? If that PI assignment is already in use, a requirement to renumber and return it might be a showstopper for getting PA space. Renumbering is *hard* - it is *a lot* of work. So while I don't think 2014-04 is harmful in any way and I don't have any objections to it, I do find it quite puzzling that it does not try to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 were to pass, would remain just as ?downright deleterious to IPv6 adoption? as before. Tore From sander at steffann.nl Mon May 5 22:02:36 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 5 May 2014 22:02:36 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5367EC3E.5040209@fud.no> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> Message-ID: <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> Hi, >> I think at the time we just didn't even consider LIRs that didn't >> want/need IPv6 PA space. > > Right. But the summary of the proposal identifies the *actual* problem here: > > ?In order to qualify [for IPv6 PA], they need to request an IPv6 > allocation and subsequently return their existing PI assignment > (per ripe-589 section 7.1)? Yep, seen that. > If that PI assignment is already in use, a requirement to renumber and > return it might be a showstopper for getting PA space. Renumbering is > *hard* - it is *a lot* of work. Ack > So while I don't think 2014-04 is harmful in any way and I don't have > any objections to it, I do find it quite puzzling that it does not try > to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 > were to pass, would remain just as ?downright deleterious to IPv6 > adoption? as before. It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? Cheers, Sander From richih.mailinglist at gmail.com Mon May 5 22:02:49 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 5 May 2014 22:02:49 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5367EC3E.5040209@fud.no> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> Message-ID: On Mon, May 5, 2014 at 9:53 PM, Tore Anderson wrote: > If that PI assignment is already in use, a requirement to renumber and > return it might be a showstopper for getting PA space. Renumbering is > *hard* - it is *a lot* of work. As the guy who renumbered a /17 in a few months: Yes. Oh my $deity... yes. > So while I don't think 2014-04 is harmful in any way and I don't have > any objections to it, I do find it quite puzzling that it does not try > to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 > were to pass, would remain just as ?downright deleterious to IPv6 > adoption? as before. I would also support such a proposal or maybe even help spearhead it. ...Tore? Richard From sander at steffann.nl Mon May 5 22:07:08 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 5 May 2014 22:07:08 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> Message-ID: <005C7559-A48E-4F8C-B858-BB18A58F7909@steffann.nl> Hi, >> So while I don't think 2014-04 is harmful in any way and I don't have >> any objections to it, I do find it quite puzzling that it does not try >> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >> were to pass, would remain just as ?downright deleterious to IPv6 >> adoption? as before. > > I would also support such a proposal or maybe even help spearhead it. ...Tore? /me feels an agenda item for section Y coming up... Cheers, Sander From tore at fud.no Tue May 6 07:13:54 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 06 May 2014 07:13:54 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> Message-ID: <53686F92.5060400@fud.no> * Sander Steffann > It is again a balance of address policy vs routing table > conservation. I personally wouldn't have a problem with letting an > LIR keep their PI space when they get their PA space. How does this > working group feel about that? Me neither. I think is fine to *encourage* newly formed LIRs to return IPv6 PI when they're requesting PA, but *requiring* it is a tad too tough. If the end result is that the newly formed LIRs cannot provision their End Users with IPv6 addresses because they cannot realistically get PA space, we're doing something wrong... That said, this isn't my itch to scratch really (I already have all the IPv6 I need)...so if you want to do a proposal, Richard, go right ahead! I promised myself 2014 would be a proposal-free year...and besides I won't be going to Warszawa either. :-/ Tore From cfriacas at fccn.pt Tue May 6 08:22:49 2014 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 6 May 2014 07:22:49 +0100 (WEST) Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> Message-ID: On Mon, 5 May 2014, Sander Steffann wrote: (...) > > It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? Should be allowed to keep the PI, i.e. avoiding renumbering at all cost. Cheers, Carlos > Cheers, > Sander > > From ebais at a2b-internet.com Tue May 6 11:48:49 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 6 May 2014 11:48:49 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> Message-ID: <005a01cf6910$67958880$36c09980$@a2b-internet.com> Hi, > > Right. But the summary of the proposal identifies the *actual* problem here: > > > > ?In order to qualify [for IPv6 PA], they need to request an IPv6 > > allocation and subsequently return their existing PI assignment > > (per ripe-589 section 7.1)? > Yep, seen that. Why should an LIR have to return his PI space if they have valid reasons for its use and are already using it ? I agree with Tore that to encourage a LIR to return a v6 PI assignments if they can, but if it is in use and active, I would feel strongly against a requirement to return the space and get a PA block. Having a v6 allocation doesn't guarantee the usage of v6 ... and if someone went through the trouble in the past to actually get a v6 PI assignment and later decides to become a LIR, they get a penalty and are required to return the space !! Besides that and the issue that a v6 PI assignment doesn't 'qualify' for the final /8 v4 allocation list, are in my opinion the 2 items that should be fixed. As a suggestion to the authors for the policy text: Skip the distinction between v6 PA or PI in the policy text and rephrase it to : b. New policy text 5.1 Allocations made by the RIPE NCC to LIRs [...] Allocations will only be made to LIRs if they have already received v6 resources from an upstream LIR or the RIPE NCC. And include a change to ripe-589 section 7.1 ( http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments ) Original text: 7.1 IPv6 Provider Independent (PI) Assignments for LIRs LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment. The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid. If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both. Updated text: 7.1 IPv6 Provider Independent (PI) Assignments for LIRs LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment. The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid. If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation, if the original criteria on which the assignment was based are no longer valid. Regards, Erik Bais From h.lu at anytimechinese.com Tue May 6 22:57:25 2014 From: h.lu at anytimechinese.com (Lu Heng) Date: Tue, 6 May 2014 15:57:25 -0500 Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: References: Message-ID: I personally believe we might no longer need to distinguish PI and PA--it might solve all the question all together. On Tue, May 6, 2014 at 4:49 AM, wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at 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 at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at 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: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 2. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Tore Anderson) > 3. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 4. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Richard Hartmann) > 5. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Sander Steffann) > 6. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Tore Anderson) > 7. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Carlos Friacas) > 8. Re: 2014-04 New Policy Proposal (Relaxing IPv6 Requirement > for Receiving Space from the Final /8) (Erik Bais) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 May 2014 21:08:41 +0200 > From: Sander Steffann > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Jan Ingvoldstad > Cc: Gert D?ring , "address-policy-wg at ripe.net Working > Group" > Message-ID: <092F992E-EC5E-403D-90DC-CF8186258D89 at steffann.nl> > Content-Type: text/plain; charset=us-ascii > > Hi Jan, > >>> Historically it was put in there as an encouragement for "last /8" LIRs >>> to "do something with IPv6"... >> >> I know that, but that's not quite what I meant. >> >> What I meant is that I don't see why the current requirement for IPv6 PA is there, but that the current document didn't already have IPv6 PI as a valid requirement. >> >> Not either-or. > > I first thought that the last /8 policy was written before IPv6 PI for LIRs became possible, so I checked: > - IPv6 PI for LIRS was 2009-08 (concluded in 2009) > - Last /8 was 2010-02 > > Seems I was wrong. IPv6 PI for LIRs did exist at the time that the last /8 policy was written. I think at the time we just didn't even consider LIRs that didn't want/need IPv6 PA space. > > Cheers, > Sander > > > > > ------------------------------ > > Message: 2 > Date: Mon, 05 May 2014 21:53:34 +0200 > From: Tore Anderson > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann , Jan Ingvoldstad > > Cc: Gert D?ring , "address-policy-wg at ripe.net Working > Group" > Message-ID: <5367EC3E.5040209 at fud.no> > Content-Type: text/plain; charset=ISO-8859-1 > > * Sander Steffann > >> I think at the time we just didn't even consider LIRs that didn't >> want/need IPv6 PA space. > > Right. But the summary of the proposal identifies the *actual* problem here: > > ?In order to qualify [for IPv6 PA], they need to request an IPv6 > allocation and subsequently return their existing PI assignment > (per ripe-589 section 7.1)? > > If that PI assignment is already in use, a requirement to renumber and > return it might be a showstopper for getting PA space. Renumbering is > *hard* - it is *a lot* of work. > > So while I don't think 2014-04 is harmful in any way and I don't have > any objections to it, I do find it quite puzzling that it does not try > to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 > were to pass, would remain just as ?downright deleterious to IPv6 > adoption? as before. > > Tore > > > > ------------------------------ > > Message: 3 > Date: Mon, 5 May 2014 22:02:36 +0200 > From: Sander Steffann > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Tore Anderson > Cc: "address-policy-wg at ripe.net Working Group" > , Gert D?ring > Message-ID: <4815E7AE-510E-4A78-81B9-AF4555D34ECF at steffann.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > >>> I think at the time we just didn't even consider LIRs that didn't >>> want/need IPv6 PA space. >> >> Right. But the summary of the proposal identifies the *actual* problem here: >> >> ?In order to qualify [for IPv6 PA], they need to request an IPv6 >> allocation and subsequently return their existing PI assignment >> (per ripe-589 section 7.1)? > > Yep, seen that. > >> If that PI assignment is already in use, a requirement to renumber and >> return it might be a showstopper for getting PA space. Renumbering is >> *hard* - it is *a lot* of work. > > Ack > >> So while I don't think 2014-04 is harmful in any way and I don't have >> any objections to it, I do find it quite puzzling that it does not try >> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >> were to pass, would remain just as ?downright deleterious to IPv6 >> adoption? as before. > > It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? > > Cheers, > Sander > > > > > ------------------------------ > > Message: 4 > Date: Mon, 5 May 2014 22:02:49 +0200 > From: Richard Hartmann > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Tore Anderson > Cc: Sander Steffann , "address-policy-wg at ripe.net > Working Group" , Gert D?ring > > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Mon, May 5, 2014 at 9:53 PM, Tore Anderson wrote: >> If that PI assignment is already in use, a requirement to renumber and >> return it might be a showstopper for getting PA space. Renumbering is >> *hard* - it is *a lot* of work. > > As the guy who renumbered a /17 in a few months: Yes. Oh my $deity... yes. > > >> So while I don't think 2014-04 is harmful in any way and I don't have >> any objections to it, I do find it quite puzzling that it does not try >> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >> were to pass, would remain just as ?downright deleterious to IPv6 >> adoption? as before. > > I would also support such a proposal or maybe even help spearhead it. ...Tore? > > > Richard > > > > ------------------------------ > > Message: 5 > Date: Mon, 5 May 2014 22:07:08 +0200 > From: Sander Steffann > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Richard Hartmann , Tore Anderson > , Gert D?ring > Cc: "address-policy-wg at ripe.net Working Group" > > Message-ID: <005C7559-A48E-4F8C-B858-BB18A58F7909 at steffann.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > >>> So while I don't think 2014-04 is harmful in any way and I don't have >>> any objections to it, I do find it quite puzzling that it does not try >>> to fix the actual problem in ripe-589 section 7.1 - which, if 2014-04 >>> were to pass, would remain just as ?downright deleterious to IPv6 >>> adoption? as before. >> >> I would also support such a proposal or maybe even help spearhead it. ...Tore? > > /me feels an agenda item for section Y coming up... > > Cheers, > Sander > > > > > ------------------------------ > > Message: 6 > Date: Tue, 06 May 2014 07:13:54 +0200 > From: Tore Anderson > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann > Cc: "address-policy-wg at ripe.net Working Group" > , Gert D?ring > Message-ID: <53686F92.5060400 at fud.no> > Content-Type: text/plain; charset=ISO-8859-1 > > * Sander Steffann > >> It is again a balance of address policy vs routing table >> conservation. I personally wouldn't have a problem with letting an >> LIR keep their PI space when they get their PA space. How does this >> working group feel about that? > > Me neither. I think is fine to *encourage* newly formed LIRs to return > IPv6 PI when they're requesting PA, but *requiring* it is a tad too > tough. If the end result is that the newly formed LIRs cannot provision > their End Users with IPv6 addresses because they cannot realistically > get PA space, we're doing something wrong... > > That said, this isn't my itch to scratch really (I already have all the > IPv6 I need)...so if you want to do a proposal, Richard, go right ahead! > I promised myself 2014 would be a proposal-free year...and besides I > won't be going to Warszawa either. :-/ > > Tore > > > > ------------------------------ > > Message: 7 > Date: Tue, 6 May 2014 07:22:49 +0100 (WEST) > From: Carlos Friacas > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: Sander Steffann > Cc: "address-policy-wg at ripe.net Working Group" > > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 5 May 2014, Sander Steffann wrote: > > (...) >> >> It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? > > Should be allowed to keep the PI, i.e. avoiding renumbering at all cost. > > Cheers, > Carlos > >> Cheers, >> Sander >> >> > > > > ------------------------------ > > Message: 8 > Date: Tue, 6 May 2014 11:48:49 +0200 > From: "Erik Bais" > Subject: Re: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing > IPv6 Requirement for Receiving Space from the Final /8) > To: "'Sander Steffann'" , "'Tore Anderson'" > > Cc: address-policy-wg at ripe.net, 'Gert D?ring' > Message-ID: <005a01cf6910$67958880$36c09980$@a2b-internet.com> > Content-Type: text/plain; charset="Windows-1252" > > Hi, > >> > Right. But the summary of the proposal identifies the *actual* problem > here: >> > >> > ?In order to qualify [for IPv6 PA], they need to request an IPv6 >> > allocation and subsequently return their existing PI assignment >> > (per ripe-589 section 7.1)? > >> Yep, seen that. > > Why should an LIR have to return his PI space if they have valid reasons for > its use and are already using it ? > > I agree with Tore that to encourage a LIR to return a v6 PI assignments if > they can, but if it is in use and active, I would feel strongly against a > requirement to return the space and get a PA block. > > Having a v6 allocation doesn't guarantee the usage of v6 ... and if someone > went through the trouble in the past to actually get a v6 PI assignment and > later decides to become a LIR, they get a penalty and are required to return > the space !! > > Besides that and the issue that a v6 PI assignment doesn't 'qualify' for the > final /8 v4 allocation list, are in my opinion the 2 items that should be > fixed. > > As a suggestion to the authors for the policy text: > > Skip the distinction between v6 PA or PI in the policy text and rephrase it > to : > > b. New policy text > 5.1 Allocations made by the RIPE NCC to LIRs > [...] > Allocations will only be made to LIRs if they have already received v6 > resources from an upstream LIR or the RIPE NCC. > > And include a change to ripe-589 section 7.1 ( > http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments ) > > Original text: > 7.1 IPv6 Provider Independent (PI) Assignments for LIRs > LIRs can qualify for an IPv6 PI assignment for parts of their own > infrastructure that are not used for customer end sites. Where an LIR has an > IPv6 allocation, the LIR must demonstrate the unique routing requirements > for the PI assignment. > > The LIR must return the IPv6 PI assignment within a period of six months if > the original criteria on which the assignment was based are no longer valid. > > If an organisation already received a PI assignment before becoming an LIR, > the PI assignment should be returned upon receiving an IPv6 allocation if > there are no specific routing requirements to justify both. > > Updated text: > 7.1 IPv6 Provider Independent (PI) Assignments for LIRs > LIRs can qualify for an IPv6 PI assignment for parts of their own > infrastructure that are not used for customer end sites. Where an LIR has an > IPv6 allocation, the LIR must demonstrate the unique routing requirements > for the PI assignment. > > The LIR must return the IPv6 PI assignment within a period of six months if > the original criteria on which the assignment was based are no longer valid. > > If an organisation already received a PI assignment before becoming an LIR, > the PI assignment should be returned upon receiving an IPv6 allocation, if > the original criteria on which the assignment was based are no longer valid. > > Regards, > Erik Bais > > > > > > > > > End of address-policy-wg Digest, Vol 33, Issue 10 > ************************************************* -- -- Kind regards. Lu 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. From ripe-ml-2012 at ssd.axu.tm Wed May 7 03:50:24 2014 From: ripe-ml-2012 at ssd.axu.tm (Aleksi Suhonen) Date: Wed, 07 May 2014 04:50:24 +0300 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> Message-ID: <53699160.309@ssd.axu.tm> Hello, On 05/05/2014 10:08 PM, Sander Steffann wrote: >>> Historically it was put in there as an encouragement for "last /8" LIRs >>> to "do something with IPv6"... >> What I meant is that I don't see why the current requirement for >> IPv6 PA is there, but that the current document didn't already have >> IPv6 PI as a valid requirement. > Seems I was wrong. IPv6 PI for LIRs did exist at the time that the > last /8 policy was written. I think at the time we just didn't even > consider LIRs that didn't want/need IPv6 PA space. The particular case that motivated me to take part in this policy proposal is that one of TREX's members got their address space as direct end user assignments during the brief while that was possible. Their organization was later auto-converted to be a LIR. They are perfectly happy with their IPv6 PI block, which they do not wish to renumber away from, because they have name servers registered in a hundred TLDs using addresses from that block already. In fact, as an alternative: they might like it if their IPv6 PI could be converted into an IPv6 PA without making it any larger. :-) Cheers, -- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy You say "potato", I say "closest-exit." From ripe-ml-2012 at ssd.axu.tm Wed May 7 04:24:16 2014 From: ripe-ml-2012 at ssd.axu.tm (Aleksi Suhonen) Date: Wed, 07 May 2014 05:24:16 +0300 Subject: [address-policy-wg] 2014-04 new radical suggestions Message-ID: <53699950.5060105@ssd.axu.tm> Hi, While we were formulating the proposal 2014-04, we came up with a handful of other more radical alternatives too. We decided to leave them out of the initial proposal text, because of their controversial nature. We decided to instead present them to the discussion on the mailing list, which I'm doing now: OTHER RIRS The current policy for final /8 IPv4 assignments requires that the IPv6 address space is assigned by RIPE NCC. Assignments by other RIRs aren't accepted. Proposal 2014-04 does not change this oversight. I can see one snag, if IPv6 assignments from other RIRs were accepted: multi-national corporations would hoard "an automatic /22" from every RIR slightly more easily than the current policy allows. In that case I would also add policy text that would make sure that if the applicant already has a final /8 IPv4 assignment from some other RIR, they can't get one from RIPE. PROMOTE IPv6 USAGE Gert Doering wrote: > Historically it was put in there as an encouragement for "last /8" LIRs > to "do something with IPv6"... The something that the current policy encourages LIRs to do with IPv6: * register a block and forget about it To really promote IPv6 adoption, why not require final /8 applicants to demonstrate their IPv6 capability before being given the IPv4 address block? The simplest way I came up with would be to create a service mailbox under an IPv6 only sub-domain (e.g. hostmaster at v6only.ripe.net) and require that the applicants complete some steps of their process with this mailbox. This would verify that the applicant has access to IPv6 capable: * routing * DNS resolvers * authoritative DNS * SMTP servers ... and is not afraid to use them! Well, of course the applicant could be using someone else's mail system to complete those steps. I'm not sure if that matters. When the original policy was written, I guess the community felt that the global routing system was not ripe enough for these requirements. I would argue that the world should be ready now! There's only one RIR left that has more than 16 million IPv4 addresses in their free pool. There, that's two provocative radical suggestions for you, from -- Aleksi Suhonen / Axu TM Oy You say "potato", I say "closest-exit." From elvis at v4escrow.net Wed May 7 04:39:59 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 07 May 2014 04:39:59 +0200 Subject: [address-policy-wg] 2014-04 new radical suggestions In-Reply-To: <53699950.5060105@ssd.axu.tm> References: <53699950.5060105@ssd.axu.tm> Message-ID: <53699CFF.3030502@v4escrow.net> Hi Aleksi, a few comments inline: On 07/05/14 04:24, Aleksi Suhonen wrote: > Hi, > > While we were formulating the proposal 2014-04, we came up with a > handful of other more radical alternatives too. We decided to leave > them out of the initial proposal text, because of their controversial > nature. We decided to instead present them to the discussion on the > mailing list, which I'm doing now: > > OTHER RIRS > > The current policy for final /8 IPv4 assignments requires that the > IPv6 address space is assigned by RIPE NCC. Assignments by other RIRs > aren't accepted. Proposal 2014-04 does not change this oversight. and I agree that it should also be fixed. If you have IPv6 (no matter from where and which color it has) then you should be allowed to receive your /22. > > I can see one snag, if IPv6 assignments from other RIRs were accepted: > multi-national corporations would hoard "an automatic /22" from every > RIR slightly more easily than the current policy allows. In that case > I would also add policy text that would make sure that if the > applicant already has a final /8 IPv4 assignment from some other RIR, > they can't get one from RIPE. > that won't fly. other RIRs have different policies regarding their last /8 (APNIC's is the only one similar to RIPE's AFAIK). Some RIRs don't even have a /22 policy. And if someone needs IPv4 in the RIPE Region, getting the /22 should not be limited to the last /8 policy from an other region. That would be plain wrong. > PROMOTE IPv6 USAGE > > Gert Doering wrote: >> Historically it was put in there as an encouragement for "last /8" LIRs >> to "do something with IPv6"... > > The something that the current policy encourages LIRs to do with IPv6: > > * register a block and forget about it > > To really promote IPv6 adoption, why not require final /8 applicants > to demonstrate their IPv6 capability before being given the IPv4 > address block? The simplest way I came up with would be to create a > service mailbox under an IPv6 only sub-domain (e.g. > hostmaster at v6only.ripe.net) and require that the applicants complete > some steps of their process with this mailbox. > > This would verify that the applicant has access to IPv6 capable: > * routing > * DNS resolvers > * authoritative DNS > * SMTP servers > > ... and is not afraid to use them! > > Well, of course the applicant could be using someone else's mail > system to complete those steps. I'm not sure if that matters. if you really want to go on that path, you may want to say that the LIRs which can receive their last /22 must have at least 4 IPv6 RIPEness stars. But I really think a lot of people will oppose to such an idea. cheers, elvis -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From gert at space.net Wed May 7 11:17:29 2014 From: gert at space.net (Gert Doering) Date: Wed, 7 May 2014 11:17:29 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: References: Message-ID: <20140507091729.GA43641@Space.Net> Hi, On Tue, May 06, 2014 at 03:57:25PM -0500, Lu Heng wrote: > I personally believe we might no longer need to distinguish PI and > PA--it might solve all the question all together. We tried to go there, the WG rejected the proposal... and I can understand that, as the complications in the actual implementations are significant. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sander at steffann.nl Wed May 7 15:56:11 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 7 May 2014 15:56:11 +0200 Subject: [address-policy-wg] 2014-04 new radical suggestions In-Reply-To: <53699950.5060105@ssd.axu.tm> References: <53699950.5060105@ssd.axu.tm> Message-ID: <469B8E27-0262-495B-9B06-75AE78A1FB79@steffann.nl> Hi Aleksi, > I can see one snag, if IPv6 assignments from other RIRs were accepted: multi-national corporations would hoard "an automatic /22" from every RIR slightly more easily than the current policy allows. In that case I would also add policy text that would make sure that if the applicant already has a final /8 IPv4 assignment from some other RIR, they can't get one from RIPE. I have to point out that making our own policy dependent on policies in other regions is a dangerous thing to do. As Elvis has already pointed out not all regions have a final /8 policy. Lat's use ARIN as an example: They have adopted proposal 2008-5 (https://www.arin.net/policy/proposals/2008_5.html) called 'Dedicated IPv4 block to facilitate IPv6 deployment'. This is a needs-based policy where someone can get between a /28 and a /24 for e.g. dual-stack DNS servers, NAT64 etc. ARIN also has a waiting list for IPv4 requests (https://www.arin.net/policy/proposals/2010_1.html), and a policy that returned IPv4 address space will be re-distributed as quickly as possible (https://www.arin.net/policy/proposals/2011_6.html). If you go down this road, exactly which address blocks an organisation gets from ARIN will prohibit them from getting a /22 from RIPE NCC? And if you look at organisational structure it becomes even more complicated: what if a big corporation has subsidiaries in both the US and EU, and the US company gets address space from ARIN. Does that disqualify the EU company/LIR from getting address space? Remember: someone has to be able to implement the policies we create here! :) Cheers, Sander From frettled at gmail.com Wed May 7 16:01:02 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 7 May 2014 16:01:02 +0200 Subject: [address-policy-wg] 2014-04 new radical suggestions In-Reply-To: <469B8E27-0262-495B-9B06-75AE78A1FB79@steffann.nl> References: <53699950.5060105@ssd.axu.tm> <469B8E27-0262-495B-9B06-75AE78A1FB79@steffann.nl> Message-ID: On Wed, May 7, 2014 at 3:56 PM, Sander Steffann wrote: > > If you go down this road, exactly which address blocks an organisation > gets from ARIN will prohibit them from getting a /22 from RIPE NCC? And if > you look at organisational structure it becomes even more complicated: what > if a big corporation has subsidiaries in both the US and EU, and the US > company gets address space from ARIN. Does that disqualify the EU > company/LIR from getting address space? > > Remember: someone has to be able to implement the policies we create here! > :) > I was about to post something very similar to this, but then you stole the show. ;) Very well put, I agree completely, although I think it's a bit of a mess that we have regional separation of IP registries in the first place, this isn't something that's fixed or mitigated by making policies dependent on what I consider unpredictable remote social dynamics. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Thu May 8 00:00:04 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Thu, 8 May 2014 00:00:04 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: <20140507091729.GA43641@Space.Net> References: <20140507091729.GA43641@Space.Net> Message-ID: On Wed, May 7, 2014 at 11:17 AM, Gert Doering wrote: > Hi, > > On Tue, May 06, 2014 at 03:57:25PM -0500, Lu Heng wrote: >> I personally believe we might no longer need to distinguish PI and >> PA--it might solve all the question all together. > > We tried to go there, the WG rejected the proposal... and I can > understand that, as the complications in the actual implementations > are significant. Hmm as I remember there was no rejection of the idea, more a cancellation of the started work due to the implication and complication involved in getting done. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From elvis at v4escrow.net Thu May 8 01:18:52 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 08 May 2014 01:18:52 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: References: <20140507091729.GA43641@Space.Net> Message-ID: <536ABF5C.90800@v4escrow.net> Hi Roger, On 08/05/14 00:00, Roger J?rgensen wrote: > On Wed, May 7, 2014 at 11:17 AM, Gert Doering wrote: >> Hi, >> >> On Tue, May 06, 2014 at 03:57:25PM -0500, Lu Heng wrote: >>> I personally believe we might no longer need to distinguish PI and >>> PA--it might solve all the question all together. >> We tried to go there, the WG rejected the proposal... and I can >> understand that, as the complications in the actual implementations >> are significant. > Hmm as I remember there was no rejection of the idea, more a > cancellation of the started work due to the implication and > complication involved in getting done. > it was rejected mostly because it would have caused a lot of changes and it was too complex. I still have the idea to come back and do it with a step-by-step approach but I haven't yet managed to decide what would be the first step :-) elvis -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From stolpe at resilans.se Thu May 8 13:46:46 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 8 May 2014 13:46:46 +0200 (CEST) Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: References: <20140507091729.GA43641@Space.Net> Message-ID: On Thu, 8 May 2014, Roger J?rgensen wrote: > On Wed, May 7, 2014 at 11:17 AM, Gert Doering wrote: >> Hi, >> >> On Tue, May 06, 2014 at 03:57:25PM -0500, Lu Heng wrote: >>> I personally believe we might no longer need to distinguish PI and >>> PA--it might solve all the question all together. >> >> We tried to go there, the WG rejected the proposal... and I can >> understand that, as the complications in the actual implementations >> are significant. > > Hmm as I remember there was no rejection of the idea, more a > cancellation of the started work due to the implication and > complication involved in getting done. We received mainly positive feed back on the mailing list but at the presentation what we heard was generally negative and "don't go there", "please stop" etc. Not that many voices but those who spoke were firmly negative. So while many members seem to agree that the PA/PI difference is something we should get rid of, the roots go deep and a even if we just want to start fresh in IPv6 it affects almost every area. I still think it would be a good thing but I am not sure about how to accomplish such a change. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From h.lu at anytimechinese.com Thu May 8 13:55:22 2014 From: h.lu at anytimechinese.com (Lu Heng) Date: Thu, 8 May 2014 06:55:22 -0500 Subject: [address-policy-wg] address-policy-wg Digest, Vol 33, Issue 10 In-Reply-To: References: <20140507091729.GA43641@Space.Net> Message-ID: Hi I guess the earlier we get rid of the difference, the easier it is to implemented PI space will only cause more and more future problems/administrative hassles as long as its exists. End of the day, they are all IP addresses, you can use your own allocation in any other LIR's network and let them manage for you, that is perfectly fine practise(like what you do nowadays with PI space), so there is no real operational difference between PI space or allocation to start with, why should we keep the difference? On Thu, May 8, 2014 at 6:46 AM, Daniel Stolpe wrote: > > On Thu, 8 May 2014, Roger J?rgensen wrote: > >> On Wed, May 7, 2014 at 11:17 AM, Gert Doering wrote: >>> >>> Hi, >>> >>> On Tue, May 06, 2014 at 03:57:25PM -0500, Lu Heng wrote: >>>> >>>> I personally believe we might no longer need to distinguish PI and >>>> PA--it might solve all the question all together. >>> >>> >>> We tried to go there, the WG rejected the proposal... and I can >>> understand that, as the complications in the actual implementations >>> are significant. >> >> >> Hmm as I remember there was no rejection of the idea, more a >> cancellation of the started work due to the implication and >> complication involved in getting done. > > > We received mainly positive feed back on the mailing list but at the > presentation what we heard was generally negative and "don't go there", > "please stop" etc. > > Not that many voices but those who spoke were firmly negative. > > So while many members seem to agree that the PA/PI difference is something > we should get rid of, the roots go deep and a even if we just want to start > fresh in IPv6 it affects almost every area. > > I still think it would be a good thing but I am not sure about how to > accomplish such a change. > > Cheers, > > Daniel > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 45 094 > 556741-1193 > 104 30 Stockholm -- -- Kind regards. Lu 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. From Piotr.Strzyzewski at polsl.pl Tue May 13 11:24:46 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 13 May 2014 11:24:46 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <5367EC3E.5040209@fud.no> <4815E7AE-510E-4A78-81B9-AF4555D34ECF@steffann.nl> Message-ID: <20140513092446.GF24089@hydra.ck.polsl.pl> On Tue, May 06, 2014 at 07:22:49AM +0100, Carlos Friacas wrote: > > On Mon, 5 May 2014, Sander Steffann wrote: > > (...) >> >> It is again a balance of address policy vs routing table conservation. I personally wouldn't have a problem with letting an LIR keep their PI space when they get their PA space. How does this working group feel about that? > > Should be allowed to keep the PI, i.e. avoiding renumbering at all cost. I support both the original proposal and the idea of getting rid of renumbering requirement. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Piotr.Strzyzewski at polsl.pl Tue May 13 11:34:18 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 13 May 2014 11:34:18 +0200 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <514f6fe2-4e73-4758-a440-c611c6edfa71@REKSIO.polsl.pl> References: <514f6fe2-4e73-4758-a440-c611c6edfa71@REKSIO.polsl.pl> Message-ID: <20140513093418.GG24089@hydra.ck.polsl.pl> On Wed, Apr 30, 2014 at 03:28:17PM +0200, Marco Schmidt wrote: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 I support this proposal. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From rogerj at gmail.com Wed May 14 15:21:42 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Wed, 14 May 2014 15:21:42 +0200 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, May 5, 2014 at 3:17 PM, Marco Schmidt wrote: > > Dear colleagues, > > > 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 > > We encourage you to review this proposal and send your comments to > before 3 June 2014. The idea is good. However - can we please stop introducing the term PI and PA into yet another document? The other problem is as mention in the working group today, do we really need to mention IPv6 there? If we should keep IPv6 there, I suggest something like this: "Allocations will only be made to LIRs if they have already received an IPv6 allocation or assignment" (old text : Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.) This just require them to have some sort of IPv6 registred to them, no difference between PI/PA, RIPE NCC or other regions... This is quite similar to what we had back in 6bone days, you first needed a connection to 6bone and some address space before you would get your own block. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From mschmidt at ripe.net Thu May 15 10:05:08 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 15 May 2014 10:05:08 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) Message-ID: 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. Some of the differences from version 1.0 include: - Adding the abandonment of Minimum Sub-Allocation Size concept - Minor wording adjustments in the arguments supporting the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-01 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-01/draft We encourage you to read the draft document text and send any comments to before 13 June 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From tore at fud.no Thu May 15 10:42:38 2014 From: tore at fud.no (Tore Anderson) Date: Thu, 15 May 2014 10:42:38 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: References: Message-ID: <53747DFE.8060002@fud.no> * 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 From frettled at gmail.com Thu May 15 10:52:06 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 15 May 2014 10:52:06 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53747DFE.8060002@fud.no> References: <53747DFE.8060002@fud.no> Message-ID: On Thu, May 15, 2014 at 10:42 AM, Tore Anderson wrote: > * 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. I support it too, this is in line with other policy cleanup work. -- Jan From Piotr.Strzyzewski at polsl.pl Thu May 15 11:42:47 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 15 May 2014 11:42:47 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: References: <53747DFE.8060002@fud.no> Message-ID: <20140515094246.GC9954@hydra.ck.polsl.pl> On Thu, May 15, 2014 at 10:52:06AM +0200, Jan Ingvoldstad wrote: > On Thu, May 15, 2014 at 10:42 AM, Tore Anderson wrote: > > * 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. > > I support it too, this is in line with other policy cleanup work. +1 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From lists-ripe at c4inet.net Thu May 15 12:08:14 2014 From: lists-ripe at c4inet.net (Mailing List Account) Date: Thu, 15 May 2014 11:08:14 +0100 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140515080718.7B8ED4E9A4@mail.c4inet.net> References: <20140515080718.7B8ED4E9A4@mail.c4inet.net> Message-ID: <20140515100814.GD87032@cilantro.c4inet.net> All, On Thu, May 15, 2014 at 10:05:08AM +0200, Marco Schmidt wrote: >You can find the full proposal and the impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2014-01 >And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2014-01/draft Yes, I think I can sign up to this. Maybe, it is also a step towards removing the PI/PA separation. One question though, if the minimum (sub-)/allocation size is now /24, is the part regarding classless reverse delegation in the impact statement now obsolete? rgds, Sascha Luck From lists-ripe at c4inet.net Thu May 15 12:13:20 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 15 May 2014 11:13:20 +0100 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140515100814.GD87032@cilantro.c4inet.net> References: <20140515080718.7B8ED4E9A4@mail.c4inet.net> <20140515100814.GD87032@cilantro.c4inet.net> Message-ID: <20140515101320.GE87032@cilantro.c4inet.net> On Thu, May 15, 2014 at 11:08:14AM +0100, Mailing List Account wrote: >One question though, if the minimum (sub-)/allocation size is >now /24, is the part regarding classless reverse delegation in >the impact statement now obsolete? Never mind, that is in the current policy text. Oh, for proper diffs. rgds, Sascha Luck From ripe at opteamax.de Thu May 15 12:25:12 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 15 May 2014 13:25:12 +0300 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) Message-ID: <53749608.3090507@opteamax.de> I fully support this proposal and I was requested by 3 additional LIRs that I assist in maintainment-works to also express their support for this proposal. BR Jens On 15.05.2014 11:05, Marco Schmidt wrote: > 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. > > Some of the differences from version 1.0 include: > > - Adding the abandonment of Minimum Sub-Allocation Size concept > - Minor wording adjustments in the arguments supporting the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-01 > > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-01/draft > > > We encourage you to read the draft document text and send any comments > to before 13 June 2014. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > > !DSPAM:637,537475b230748687177688! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Thu May 15 12:27:22 2014 From: gert at space.net (Gert Doering) Date: Thu, 15 May 2014 12:27:22 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53749608.3090507@opteamax.de> References: <53749608.3090507@opteamax.de> Message-ID: <20140515102722.GG46558@Space.Net> Hi, On Thu, May 15, 2014 at 01:25:12PM +0300, Opteamax GmbH wrote: > I fully support this proposal and I was requested by 3 additional LIRs > that I assist in maintainment-works to also express their support for > this proposal. JFTR, *this* is about personal opinion from the community (and thanks for the support), not about waving "I have 4 LIRs, and 4 votes!" voting slips :-) - so since we're aiming for (rough) consensus, it's really individual contributions that count. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe at opteamax.de Thu May 15 12:30:28 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 15 May 2014 13:30:28 +0300 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140515102722.GG46558@Space.Net> References: <53749608.3090507@opteamax.de> <20140515102722.GG46558@Space.Net> Message-ID: <53749744.2030308@opteamax.de> On 15.05.2014 13:27, Gert Doering wrote: > JFTR, *this* is about personal opinion from the community (and thanks > for the support), not about waving "I have 4 LIRs, and 4 votes!" voting > slips :-) - so since we're aiming for (rough) consensus, it's really > individual contributions that count. > Guess you missunderstood my mail. I am currently hard working getting those other LIRs partitipating and contributing more to the community, it is at least a first step, that I made them expressing their support "thru me" ... I hope I get them to sign up apwg-ml soon ... keep trying ;) -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From ggiannou at gmail.com Thu May 15 13:42:59 2014 From: ggiannou at gmail.com (George Giannousopoulos) Date: Thu, 15 May 2014 14:42:59 +0300 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <537475af.49b40e0a.498b.fffff23dSMTPIN_ADDED_MISSING@mx.google.com> References: <537475af.49b40e0a.498b.fffff23dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: I support too. - George On Thu, May 15, 2014 at 11:05 AM, Marco Schmidt wrote: > > 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. > > Some of the differences from version 1.0 include: > > - Adding the abandonment of Minimum Sub-Allocation Size concept > - Minor wording adjustments in the arguments supporting the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-01 > > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-01/draft > > > We encourage you to read the draft document text and send any comments > to before 13 June 2014. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu May 15 14:09:06 2014 From: gert at space.net (Gert Doering) Date: Thu, 15 May 2014 14:09:06 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53749744.2030308@opteamax.de> References: <53749608.3090507@opteamax.de> <20140515102722.GG46558@Space.Net> <53749744.2030308@opteamax.de> Message-ID: <20140515120906.GH46558@Space.Net> Hi, On Thu, May 15, 2014 at 01:30:28PM +0300, Opteamax GmbH wrote: > On 15.05.2014 13:27, Gert Doering wrote: > > > JFTR, *this* is about personal opinion from the community (and thanks > > for the support), not about waving "I have 4 LIRs, and 4 votes!" voting > > slips :-) - so since we're aiming for (rough) consensus, it's really > > individual contributions that count. > > > > Guess you missunderstood my mail. I am currently hard working getting > those other LIRs partitipating and contributing more to the community, > it is at least a first step, that I made them expressing their support > "thru me" ... I hope I get them to sign up apwg-ml soon ... keep trying ;) I think I understood you, and I appreciate the effort - thanks :-) - it's just that every now and then, for the benefit of the *other* readers, I feel I need to point out that this is really all about "individual contributions" :-) Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From andreas.larsen at ip-only.se Thu May 15 15:04:04 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Thu, 15 May 2014 13:04:04 +0000 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140515094246.GC9954@hydra.ck.polsl.pl> References: <53747DFE.8060002@fud.no> <20140515094246.GC9954@hydra.ck.polsl.pl> Message-ID: I support this policy, this is the right step with the other cleanup policys. // Andreas Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Bes?ksadress Uppsala: S:t Persg 6 Bes?ksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se 15 maj 2014 kl. 11:42 skrev Piotr Strzyzewski : > On Thu, May 15, 2014 at 10:52:06AM +0200, Jan Ingvoldstad wrote: >> On Thu, May 15, 2014 at 10:42 AM, Tore Anderson wrote: >>> * 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. >> >> I support it too, this is in line with other policy cleanup work. > > +1 > > Piotr > > -- > gucio -> Piotr Strzy?ewski > E-mail: Piotr.Strzyzewski at polsl.pl From ripe.address-policy-wg at ml.karotte.org Thu May 15 15:21:42 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Thu, 15 May 2014 15:21:42 +0200 Subject: [address-policy-wg] 2014-01 New Draft Document and Impact Analysis Published (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <201405150809.s4F894n0012756@danton.fire-world.de> References: <201405150809.s4F894n0012756@danton.fire-world.de> Message-ID: <20140515132142.GB12529@danton.fire-world.de> * Marco Schmidt [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 From skeeve+ripepolicywg at v4now.com Sat May 17 16:11:17 2014 From: skeeve+ripepolicywg at v4now.com (Skeeve Stevens) Date: Sun, 18 May 2014 00:11:17 +1000 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" Message-ID: 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 at v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sat May 17 16:14:09 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 16:14:09 +0200 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" In-Reply-To: References: Message-ID: <20140517141409.GD46558@Space.Net> Hi, On Sun, May 18, 2014 at 12:11:17AM +1000, Skeeve Stevens wrote: > 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. This was on hold due to various reasons, and is now being restarted, with new policy text and as a "fully new proposal", likely to end up as 2014-05. We discussed this at the APWG meeting in Warsaw last Wednesday, and the new formal proposal will hit the list "soon". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From skeeve+ripepolicywg at v4now.com Sat May 17 16:17:53 2014 From: skeeve+ripepolicywg at v4now.com (Skeeve Stevens) Date: Sun, 18 May 2014 00:17:53 +1000 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" In-Reply-To: <20140517141409.GD46558@Space.Net> References: <20140517141409.GD46558@Space.Net> Message-ID: Good to hear Gert. Is the new text available somewhere? ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks Business skeeve at v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Sun, May 18, 2014 at 12:14 AM, Gert Doering wrote: > Hi, > > On Sun, May 18, 2014 at 12:11:17AM +1000, Skeeve Stevens wrote: > > 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. > > This was on hold due to various reasons, and is now being restarted, with > new policy text and as a "fully new proposal", likely to end up as 2014-05. > > We discussed this at the APWG meeting in Warsaw last Wednesday, and the > new formal proposal will hit the list "soon". > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sat May 17 16:38:06 2014 From: gert at space.net (Gert Doering) Date: Sat, 17 May 2014 16:38:06 +0200 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" In-Reply-To: References: <20140517141409.GD46558@Space.Net> Message-ID: <20140517143806.GF46558@Space.Net> Hi, On Sun, May 18, 2014 at 12:17:53AM +1000, Skeeve Stevens wrote: > Good to hear Gert. > > Is the new text available somewhere? It is not yet final, thus, only what Sandra presented at the meeting - look for "Sandra Brown" on https://ripe68.ripe.net/presentations/presentation-archive/ Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From skeeve+ripepolicywg at v4now.com Sun May 18 05:28:57 2014 From: skeeve+ripepolicywg at v4now.com (Skeeve Stevens) Date: Sun, 18 May 2014 13:28:57 +1000 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" In-Reply-To: <20140517143806.GF46558@Space.Net> References: <20140517141409.GD46558@Space.Net> <20140517143806.GF46558@Space.Net> Message-ID: Hey Gert, Thanks for that. When can we expect the text? ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks Business skeeve at v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Sun, May 18, 2014 at 12:38 AM, Gert Doering wrote: > Hi, > > On Sun, May 18, 2014 at 12:17:53AM +1000, Skeeve Stevens wrote: > > Good to hear Gert. > > > > Is the new text available somewhere? > > It is not yet final, thus, only what Sandra presented at the meeting - > look for "Sandra Brown" on > > https://ripe68.ripe.net/presentations/presentation-archive/ > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun May 18 13:41:30 2014 From: gert at space.net (Gert Doering) Date: Sun, 18 May 2014 13:41:30 +0200 Subject: [address-policy-wg] Status of Policy "Policy for Inter-RIR Transfers of IPv4 Address Space" In-Reply-To: References: <20140517141409.GD46558@Space.Net> <20140517143806.GF46558@Space.Net> Message-ID: <20140518114130.GL46558@Space.Net> Hi, On Sun, May 18, 2014 at 01:28:57PM +1000, Skeeve Stevens wrote: > Thanks for that. When can we expect the text? "Whenever Sandra is done writing it, and Marco and the chairs are done proofreading it". Dunno, hopefully soon. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sandra.sendra.upv at gmail.com Tue May 20 11:09:25 2014 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Tue, 20 May 2014 11:09:25 +0200 Subject: [address-policy-wg] IEEE International Workshop on Cloud-integrated Cyber Physical Systems 2014 (IEEE Cloud-CPS 2014) Message-ID: <201405200909.s4K99PGn017452@smtp.upv.es> ********************************************************* 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-393e-4a04-9551-3a45535c5198&groupId=525773 LaTeX Package: http://www.computer.org/portal/c/document_library/get_file?uuid=cda2f9b2-516f-43b8-ba8d-da91c0503dac&groupId=525773 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 From andy at nosignal.org Tue May 20 13:30:42 2014 From: andy at nosignal.org (Andy Davidson) Date: Tue, 20 May 2014 11:30:42 +0000 Subject: [address-policy-wg] 2014-04 New Policy Proposal (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53699160.309@ssd.axu.tm> References: <53679019.48ae0e0a.451d.140eSMTPIN_ADDED_MISSING@mx.google.com> <20140505175846.GR43641@Space.Net> <092F992E-EC5E-403D-90DC-CF8186258D89@steffann.nl> <53699160.309@ssd.axu.tm> Message-ID: <3fb0b779b2e046699ee544010bfc5f4a@AMSPR07MB211.eurprd07.prod.outlook.com> Hi, Aleksi wrote: > They are perfectly happy with their IPv6 PI block, which they do > not wish to renumber away from, because they have name servers > registered in a hundred TLDs using addresses from that block already. It makes sense to change the policy on this basis as this also does not discourage v6 adoption. I support this proposal. Andy From ebais at a2b-internet.com Wed May 21 14:34:20 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 21 May 2014 14:34:20 +0200 Subject: [address-policy-wg] 2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer) In-Reply-To: <130904ac-729f-459d-b3bc-c1a43ed50b0b@E2010-EXHUB11.exchange2010.nl> References: <130904ac-729f-459d-b3bc-c1a43ed50b0b@E2010-EXHUB11.exchange2010.nl> Message-ID: <007201cf74f1$027f47f0$077dd7d0$@a2b-internet.com> 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 From elvis at v4escrow.net Wed May 21 16:20:03 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 21 May 2014 16:20:03 +0200 Subject: [address-policy-wg] 2014-02 Discussion Period extended until 23 May 2014 (Allow IPv4 PI transfer) In-Reply-To: <007201cf74f1$027f47f0$077dd7d0$@a2b-internet.com> References: <130904ac-729f-459d-b3bc-c1a43ed50b0b@E2010-EXHUB11.exchange2010.nl> <007201cf74f1$027f47f0$077dd7d0$@a2b-internet.com> Message-ID: <537CB613.6000004@v4escrow.net> Hi Erik, as mentioned during the RIPE Meeting, I support this policy proposal. cheers, elvis On 21/05/14 14:34, Erik Bais wrote: > 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 > > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From sandra.sendra.upv at gmail.com Wed May 28 12:26:36 2014 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Wed, 28 May 2014 12:26:36 +0200 Subject: [address-policy-wg] Special Issue on "Underwater Sensor Networks" in (JSAN) Message-ID: <201405281026.s4SAQa2j023203@smtp.upv.es> =================================================== 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 at dcom.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain Dr. Sandra Sendra (sansenco at posgrado.upv.es) Integrated Management Coastal Research Institute, Polytechnic University of Valencia, Camino de Vera 46022, Valencia, Spain =================================================== From mschmidt at ripe.net Fri May 30 10:06:51 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 30 May 2014 10:06:51 +0200 Subject: [address-policy-wg] 2014-02 Draft Document and Impact Analysis will be produced (Allow IPv4 PI transfer) Message-ID: 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