From ebais at a2b-internet.com Mon Jun 3 14:08:46 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 3 Jun 2013 14:08:46 +0200 Subject: [address-policy-wg] Resource Certification for non-RIPE NCC Members Message-ID: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Dear community members of the AP ? WG and the NCC Services WG, As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders) Currently we are in the phase: Discussion ? Open for discussion And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy. For those that are not subscribed to the NCC Services mail-list -=> http://www.ripe.net/mailman/listinfo/ncc-services-wg/ During the creation of the policy I made a small error in the intention to limit the policy to entities in the RIPE NCC service region and the policy currently states: ? The Internet resources reside within the RIPE NCC service region I?ll update this in the review phase. I?m not sure yet if we need to skip that part entirely or change it to the actual intention. Your input and stated support on the NCC Services WG mail list would be highly appreciated. Kind regards, Erik Bais Link to the policy proposal: https://www.ripe.net/ripe/policies/proposals/2013-04 From randy at psg.com Mon Jun 3 16:57:34 2013 From: randy at psg.com (Randy Bush) Date: Mon, 03 Jun 2013 09:57:34 -0500 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: > And I would like to invite you to the service wg mail list for your > support for this policy and a discussion on wording of the policy. my routers do not know the difference between PI, PA, Legacy, or whatever. i suspect that no one has routers which differentiate. randy From jo at opteamax.de Tue Jun 4 00:39:35 2013 From: jo at opteamax.de (Jens Ott - Opteamax GmbH) Date: Tue, 04 Jun 2013 00:39:35 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: <51AD1B27.4080500@opteamax.de> Am Mo 03 Jun 2013 16:57:34 CEST schrieb Randy Bush: > > my routers do not know the difference between PI, PA, Legacy, or > whatever. i suspect that no one has routers which differentiate. > > randy +1 IMHO the whole system only make sense, when it is open for all resources! BR -- 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 mansaxel at besserwisser.org Tue Jun 4 04:26:51 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 4 Jun 2013 04:26:51 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: <20130604022651.GB1902@besserwisser.org> Subject: Re: [ncc-services-wg] Resource Certification for non-RIPE NCC Members Date: Mon, Jun 03, 2013 at 09:57:34AM -0500 Quoting Randy Bush (randy at psg.com): > > And I would like to invite you to the service wg mail list for your > > support for this policy and a discussion on wording of the policy. > > my routers do not know the difference between PI, PA, Legacy, or > whatever. i suspect that no one has routers which differentiate. a router that differentiates is not only a router but also a cgn. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It's OKAY -- I'm an INTELLECTUAL, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Woeber at CC.UniVie.ac.at Fri Jun 7 15:32:31 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 07 Jun 2013 15:32:31 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: <51B1E0EF.7010303@CC.UniVie.ac.at> Hi Erik, Community, a couple of general comments before potentially going into details on the Services WG. Whether we need a formal "policy" or just an agreement (amongst the members of the NCC) to a Service Description and a review of the CPS as maintained by the NCC is a sideline issue, imho. For now using the framework of the PDP maybe useful and appropriate. I concur with other comments already, that - at the moment - there is, and probably shouldn't be - a different colour related to PA, PI, ERX, v4, v6, you name it. So, whatever we come up with should be "the same", technically. Looking at the proposed text for discussion, I sense a mindset of "the NCC is the sole source of the Certificates". This may be reasonable for those paries, which do have a direct Service Contract with the NCC (Direct End User, Legacy). For all the others, there is - or structurally, will be - a managed foodchain and Hierarchy. This may be ? the path of NCC - LIR for PA (v4+v6) - assignments, or ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). In the end we SHOULD, imo, structure the service definition *and* the implementation to be congruent to this structe. I.e. the LIRs SHOULD be the parties issuing the certificates for those resources which are held by their users/customers, and for which there is a contract. Trying to bypass the LIRs and/or messing around with some sort of backdoor structure for cert.creation, and "verification" by the NCC, would become messy. We (my team) DO have real life experience, that such a disjunct and artificial mechanism is a pain, and a source for inconsistencies. And, last but not least, in order to potentially, in the (near?) future, overcome the "single point of failure thing" (that we are creating now by building a "proper" tree structure!), removing any and all notion of the Service Region would have my *strong* support. Not just because it will be difficult to find a proper definition of "reside within", but more so because it would open the chance to actually acquire certificates from more than one "root", aka CA. These multiple roots/CAs could either (preferably?) be the set of RIRs, but other parties as well. This would take away most of my worries and reservation related to the proliferation of the RPKI. Sorry for the long text ;-) Wilfried. Erik Bais wrote: > Dear community members of the AP ? WG and the NCC Services WG, > > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > / Legacy space and PI space holders) > > Currently we are in the phase: Discussion ? Open for discussion > > And I would like to invite you to the service wg mail list for your support > for this policy and a discussion on wording of the policy. > For those that are not subscribed to the NCC Services mail-list -=> > http://www.ripe.net/mailman/listinfo/ncc-services-wg/ > > During the creation of the policy I made a small error in the intention to > limit the policy to entities in the RIPE NCC service region and the policy > currently states: > > ? The Internet resources reside within the RIPE NCC service region > > I?ll update this in the review phase. I?m not sure yet if we need to skip > that part entirely or change it to the actual intention. > > Your input and stated support on the NCC Services WG mail list would be > highly appreciated. > > Kind regards, > Erik Bais > > Link to the policy proposal: > https://www.ripe.net/ripe/policies/proposals/2013-04 > > From ebais at a2b-internet.com Fri Jun 7 18:37:38 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 7 Jun 2013 18:37:38 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <51B1E0EF.7010303@CC.UniVie.ac.at> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> Message-ID: <007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com> Hi Wilfried, First of all, let me say thanks for the feedback. > Whether we need a formal "policy" or just an agreement (amongst the members > of the NCC) to a Service Description and a review of the CPS as maintained > by the NCC is a sideline issue, imho. > For now using the framework of the PDP maybe useful and appropriate. So do I. > Looking at the proposed text for discussion, I sense a mindset of "the NCC is > the sole source of the Certificates". This may be reasonable for those paries, > which do have a direct Service Contract with the NCC (Direct End User, Legacy). > For all the others, there is - or structurally, will be - a managed foodchain > and Hierarchy. > This may be > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > In the end we SHOULD, imo, structure the service definition *and* the > implementation to be congruent to this structe. I.e. the LIRs SHOULD be the > parties issuing the certificates for those resources which are held by their > users/customers, and for which there is a contract. > Trying to bypass the LIRs and/or messing around with some sort of backdoor > structure for cert.creation, and "verification" by the NCC, would become > messy. We (my team) DO have real life experience, that such a disjunct and > artificial mechanism is a pain, and a source for inconsistencies. The proposal was specifically written without a structure on how the NCC should implement the system towards the PI or Legacy resource holders. In my opinion that is a complete different discussion than a decision on IF we want resource certification for resources of non-RIPE NCC members. I understand that it might be tempting to state how we want to have it implemented or even move into the area where we ask ourselves the question, who is going to pay for this and how? However in order to keep the discussion as simple as possible and not to force the discussion or proposal about how to do the implementation into a certain direction or to hand-cuff the NCC on how they operate the systems, it was specifically written without how / who / SHOULD or structure. It is simply a question to allow non-RIPE NCC members their resources to be certified. I'm sure that there will be questions after this, about what the better structure would be (option 1,2,3), implications etc etc. > And, last but not least, in order to potentially, in the (near?) future, > overcome the "single point of failure thing" (that we are creating now by > building a "proper" tree structure!), removing any and all notion of the > Service Region would have my *strong* support. Not just because it will be > difficult to find a proper definition of "reside within", but more so because > it would open the chance to actually acquire certificates from more than one > "root", aka CA. The specific sentence has been adjusted as it was provided based on input during the discussion phase to: -the Internet resources are registered in the RIPE registry. As certification is very closely related to the registration of resources, I would like to limit it to the RIPE registry for now. I can see your point on a more global view and desire, however I would prefer to take small steps here. Let's get this in place for the resources in the RIPE registry. If we have this step taken, we can always adjust the specifics if we need/want to move to a more distributed model. Currently it is my goal to have this sorted for the resources in the RIPE registry. > These multiple roots/CAs could either (preferably?) be the set of RIRs, but > other parties as well. This would take away most of my worries and reservation > related to the proliferation of the RPKI. As stated earlier, I'm not going, in the current discussion, going to move away from the as-is situation. There is a current implementation and it is missing most of the resources. Yes I see how a more distributed environment might be better, however it is beyond the scope of this proposal. Any discussion on a distributed model is in vain imho if we exclude the current group for which this proposal is created. > Sorry for the long text ;-) > Wilfried. Thanks for the input and I hope to have answered your questions. Regards & have a nice weekend, Erik Bais From yurax at mail.ru Sat Jun 8 12:08:01 2013 From: yurax at mail.ru (=?UTF-8?B?QUNDRVNT?=) Date: Sat, 08 Jun 2013 14:08:01 +0400 Subject: [address-policy-wg] =?utf-8?q?address-policy-wg_Digest=2C_Vol_22?= =?utf-8?q?=2C_Issue_2?= In-Reply-To: References: Message-ID: <1370686081.980193959@f87.mail.ru> ???????, 8 ???? 2013, 12:00 +02:00 ?? address-policy-wg-request at ripe.net: > 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: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Wilfried Woeber) > 2. Re: [ncc-services-wg] Resource Certification for non-RIPE NCC > Members (Erik Bais) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 07 Jun 2013 15:32:31 +0200 > From: Wilfried Woeber < Woeber at CC.UniVie.ac.at > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: Erik Bais < ebais at a2b-internet.com > > Cc: ncc-services-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: < 51B1E0EF.7010303 at CC.UniVie.ac.at > > Content-Type: text/plain; charset=windows-1252 > > Hi Erik, Community, > > a couple of general comments before potentially going into details on the > Services WG. > > Whether we need a formal "policy" or just an agreement (amongst the members > of the NCC) to a Service Description and a review of the CPS as maintained > by the NCC is a sideline issue, imho. > > For now using the framework of the PDP maybe useful and appropriate. > > I concur with other comments already, that - at the moment - there is, and > probably shouldn't be - a different colour related to PA, PI, ERX, v4, v6, > you name it. So, whatever we come up with should be "the same", technically. > > Looking at the proposed text for discussion, I sense a mindset of "the NCC is > the sole source of the Certificates". This may be reasonable for those paries, > which do have a direct Service Contract with the NCC (Direct End User, Legacy). > > For all the others, there is - or structurally, will be - a managed foodchain > and Hierarchy. > > This may be > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > In the end we SHOULD, imo, structure the service definition *and* the > implementation to be congruent to this structe. I.e. the LIRs SHOULD be the > parties issuing the certificates for those resources which are held by their > users/customers, and for which there is a contract. > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > structure for cert.creation, and "verification" by the NCC, would become > messy. We (my team) DO have real life experience, that such a disjunct and > artificial mechanism is a pain, and a source for inconsistencies. > > And, last but not least, in order to potentially, in the (near?) future, > overcome the "single point of failure thing" (that we are creating now by > building a "proper" tree structure!), removing any and all notion of the > Service Region would have my *strong* support. Not just because it will be > difficult to find a proper definition of "reside within", but more so because > it would open the chance to actually acquire certificates from more than one > "root", aka CA. > > These multiple roots/CAs could either (preferably?) be the set of RIRs, but > other parties as well. This would take away most of my worries and reservation > related to the proliferation of the RPKI. > > Sorry for the long text ;-) > Wilfried. > > Erik Bais wrote: > > > Dear community members of the AP ? WG and the NCC Services WG, > > > > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to > > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > > / Legacy space and PI space holders) > > > > Currently we are in the phase: Discussion ? Open for discussion > > > > And I would like to invite you to the service wg mail list for your support > > for this policy and a discussion on wording of the policy. > > For those that are not subscribed to the NCC Services mail-list -=> > > http://www.ripe.net/mailman/listinfo/ncc-services-wg/ > > > > During the creation of the policy I made a small error in the intention to > > limit the policy to entities in the RIPE NCC service region and the policy > > currently states: > > > > ? The Internet resources reside within the RIPE NCC service region > > > > I?ll update this in the review phase. I?m not sure yet if we need to skip > > that part entirely or change it to the actual intention. > > > > Your input and stated support on the NCC Services WG mail list would be > > highly appreciated. > > > > Kind regards, > > Erik Bais > > > > Link to the policy proposal: > > https://www.ripe.net/ripe/policies/proposals/2013-04 > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Jun 2013 18:37:38 +0200 > From: "Erik Bais" < ebais at a2b-internet.com > > Subject: Re: [address-policy-wg] [ncc-services-wg] Resource > Certification for non-RIPE NCC Members > To: < Woeber at CC.UniVie.ac.at > > Cc: ncc-services-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: < 007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com > > Content-Type: text/plain; charset="Windows-1252" > > Hi Wilfried, > > First of all, let me say thanks for the feedback. > > > Whether we need a formal "policy" or just an agreement (amongst the > members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > For now using the framework of the PDP maybe useful and appropriate. > > So do I. > > > Looking at the proposed text for discussion, I sense a mindset of "the NCC > is > > the sole source of the Certificates". This may be reasonable for those > paries, > > which do have a direct Service Contract with the NCC (Direct End User, > Legacy). > > > For all the others, there is - or structurally, will be - a managed > foodchain > > and Hierarchy. > > > This may be > > ? the path of NCC - LIR for PA (v4+v6) - assignments, or > > ? the path of NCC - LIR - contract for DER (Direct Enduser Resources). > > > In the end we SHOULD, imo, structure the service definition *and* the > > implementation to be congruent to this structe. I.e. the LIRs SHOULD be > the > > parties issuing the certificates for those resources which are held by > their > > users/customers, and for which there is a contract. > > > Trying to bypass the LIRs and/or messing around with some sort of backdoor > > structure for cert.creation, and "verification" by the NCC, would become > > messy. We (my team) DO have real life experience, that such a disjunct and > > artificial mechanism is a pain, and a source for inconsistencies. > > The proposal was specifically written without a structure on how the NCC > should implement the system towards the PI or Legacy resource holders. > In my opinion that is a complete different discussion than a decision on IF > we want resource certification for resources of non-RIPE NCC members. > > I understand that it might be tempting to state how we want to have it > implemented or even move into the area where we ask ourselves the question, > who is going to pay for this and how? > However in order to keep the discussion as simple as possible and not to > force the discussion or proposal about how to do the implementation into a > certain direction or to hand-cuff the NCC on how they operate the systems, > it was specifically written without how / who / SHOULD or structure. It is > simply a question to allow non-RIPE NCC members their resources to be > certified. > > I'm sure that there will be questions after this, about what the better > structure would be (option 1,2,3), implications etc etc. > > > And, last but not least, in order to potentially, in the (near?) future, > > overcome the "single point of failure thing" (that we are creating now by > > building a "proper" tree structure!), removing any and all notion of the > > Service Region would have my *strong* support. Not just because it will be > > difficult to find a proper definition of "reside within", but more so > because > > it would open the chance to actually acquire certificates from more than > one > > "root", aka CA. > > The specific sentence has been adjusted as it was provided based on input > during the discussion phase to: > > -the Internet resources are registered in the RIPE registry. > > As certification is very closely related to the registration of resources, I > would like to limit it to the RIPE registry for now. > > I can see your point on a more global view and desire, however I would > prefer to take small steps here. > Let's get this in place for the resources in the RIPE registry. If we have > this step taken, we can always adjust the specifics if we need/want to move > to a more distributed model. > Currently it is my goal to have this sorted for the resources in the RIPE > registry. > > > These multiple roots/CAs could either (preferably?) be the set of RIRs, > but > > other parties as well. This would take away most of my worries and > reservation > > related to the proliferation of the RPKI. > > As stated earlier, I'm not going, in the current discussion, going to move > away from the as-is situation. > There is a current implementation and it is missing most of the resources. > > Yes I see how a more distributed environment might be better, however it is > beyond the scope of this proposal. > Any discussion on a distributed model is in vain imho if we exclude the > current group for which this proposal is created. > > > Sorry for the long text ;-) > > Wilfried. > > Thanks for the input and I hope to have answered your questions. > > Regards & have a nice weekend, > Erik Bais > > End of address-policy-wg Digest, Vol 22, Issue 2 > ************************************************ ACCE$$ ?????????? ?? ????????? ????? Mail.Ru From maildanrl at gmail.com Mon Jun 10 10:24:52 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Mon, 10 Jun 2013 10:24:52 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> <007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com> Message-ID: > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC to > allow Resource Certification for non-RIPE NCC member resource holders. (IXP > / Legacy space and PI space holders) As a PI holder and a router operator I support this proposal. I want others be able to verify my prefixes. RPKI, if used widely, can be a much more acurate source for routing information than the databases are. Even in RIPE region, where the database tends to be well maintained. The more resource holders are allowed to use RPKI, the better. I would even pay a fee for the signing process of my resources, just in case this is about money. From corebug at corebug.net Mon Jun 10 11:13:57 2013 From: corebug at corebug.net (=?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KLRg9GA0L7QstC10YY=?=) Date: Mon, 10 Jun 2013 12:13:57 +0300 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> <007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com> Message-ID: I must admit that i myself as PI holder and service operator completely agree with Dan and think that RPKI certification should be somehow achievable by PI holders themselves without need to do any kinds of requests to LIR. 2013/6/10 Dan Luedtke > > As you may have seen, I?ve created a policy proposal to ask the RIPE NCC > to > > allow Resource Certification for non-RIPE NCC member resource holders. > (IXP > > / Legacy space and PI space holders) > > As a PI holder and a router operator I support this proposal. I want > others be able to verify my prefixes. > > RPKI, if used widely, can be a much more acurate source for routing > information than the databases are. Even in RIPE region, where the > database tends to be well maintained. The more resource holders are > allowed to use RPKI, the better. I would even pay a fee for the > signing process of my resources, just in case this is about money. > > -- ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Mon Jun 10 17:20:30 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 10 Jun 2013 17:20:30 +0200 Subject: [address-policy-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <51B1E0EF.7010303@CC.UniVie.ac.at> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> Message-ID: <20130610152030.GK14598@x28.adm.denic.de> On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: > Whether we need a formal "policy" or just an agreement (amongst the members > of the NCC) to a Service Description and a review of the CPS as maintained > by the NCC is a sideline issue, imho. > > For now using the framework of the PDP maybe useful and appropriate. I respectfully suggest it is not. The current modus operandi for RPKI in the NCC service region is not only not based on a policy created by the PDP, it exists despite a policy proposal for that very subject having failed. Whether or not that creates a schism might be interesting to discuss, but is not relevant for the case at hand. What counts here is that the absence of policy is not an 'omission' or accident. So far I have seen support for 2013-04 based on symmetry or equality of PA, PI and other (former) special cases. While this might have merit operationally, it cannot support a parallel policy just because there's nothing to draw the parallel to. This point of order has not been addressed so far (and there are multiple solutions to this situation). Therefore I formally object to 2013-04 being elevated into the next PDP phase. -Peter From kjell at ripe.net Tue Jun 11 08:43:29 2013 From: kjell at ripe.net (Kjell Leknes) Date: Tue, 11 Jun 2013 08:43:29 +0200 Subject: [address-policy-wg] Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented Message-ID: <11E136AE-2A9A-4798-9F2E-D57CF49672D8@ripe.net> [Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster at ripe.net If you have any questions, please contact ncc at ripe.net Regards, Kjell Leknes Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From yurax at mail.ru Tue Jun 11 14:21:58 2013 From: yurax at mail.ru (=?UTF-8?B?QUNDRVNT?=) Date: Tue, 11 Jun 2013 16:21:58 +0400 Subject: [address-policy-wg] =?utf-8?q?address-policy-wg_Digest=2C_Vol_22?= =?utf-8?q?=2C_Issue_5?= In-Reply-To: References: Message-ID: <1370953318.518737123@f174.mail.ru> ???????, 11 ???? 2013, 12:00 +02:00 ?? address-policy-wg-request at ripe.net: > 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: Resource Certification for non-RIPE NCC Members (Peter Koch) > 2. Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a > per-allocation vs per-LIR basis" implemented (Kjell Leknes) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jun 2013 17:20:30 +0200 > From: Peter Koch < pk at DENIC.DE > > Subject: Re: [address-policy-wg] Resource Certification for non-RIPE > NCC Members > To: ncc-services-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: < 20130610152030.GK14598 at x28.adm.denic.de > > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: > > > Whether we need a formal "policy" or just an agreement (amongst the members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > > For now using the framework of the PDP maybe useful and appropriate. > > I respectfully suggest it is not. The current modus operandi for RPKI > in the NCC service region is not only not based on a policy created > by the PDP, it exists despite a policy proposal for that very subject > having failed. Whether or not that creates a schism might be interesting > to discuss, but is not relevant for the case at hand. What counts here is > that the absence of policy is not an 'omission' or accident. > > So far I have seen support for 2013-04 based on symmetry or equality of > PA, PI and other (former) special cases. While this might have merit > operationally, it cannot support a parallel policy just because there's > nothing to draw the parallel to. This point of order has not been addressed > so far (and there are multiple solutions to this situation). > > Therefore I formally object to 2013-04 being elevated into the next PDP phase. > > -Peter > > ------------------------------ > > Message: 2 > Date: Tue, 11 Jun 2013 08:43:29 +0200 > From: Kjell Leknes < kjell at ripe.net > > Subject: [address-policy-wg] Policy Proposal 2012-10 "Extension of > IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented > To: "address-policy-wg at ripe.net" < address-policy-wg at ripe.net >, > "policy-announce at ripe.net" < policy-announce at ripe.net > > Message-ID: < 11E136AE-2A9A-4798-9F2E-D57CF49672D8 at ripe.net > > Content-Type: text/plain; charset="us-ascii" > > [Apologies for duplicate emails] > > Dear colleagues, > > We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. > > The full policy proposal can be found at: > http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] > > The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: > http://www.ripe.net/ripe/docs/ripe-589 [Open URL] > > You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster at ripe.net > > If you have any questions, please contact ncc at ripe.net > > Regards, > > Kjell Leknes > Registration Services > RIPE NCC > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20130611/43c54b96/attachment-0001.html > > End of address-policy-wg Digest, Vol 22, Issue 5 > ************************************************ ACCE$$ ?????????? ?? ????????? ????? Mail From Woeber at CC.UniVie.ac.at Wed Jun 12 11:05:51 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 12 Jun 2013 11:05:51 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <20130610152030.GK14598@x28.adm.denic.de> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> <20130610152030.GK14598@x28.adm.denic.de> Message-ID: <51B839EF.4010705@CC.UniVie.ac.at> Peter Koch wrote: > On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: [...] > Therefore I formally object to 2013-04 being elevated into the next PDP phase. Fair enough, and I do see where you are coming from :-) But at least we started to discuss the mess around this rather wide and diverse topic. :-) I'll come back to Erik's reply separately, but *technically* I am not so much worried now about what the formal "wrapper" is, but rather to *eventually* get a hold of the architectural aspects of issuing certificates to the holders of *all* resources, irrespective of their "colour" - if at all. At least for me, it *does* make a difference, policy- and support-wise, if the implementation is "reasonable" or adds more grief. > -Peter Wilfried. From Woeber at CC.UniVie.ac.at Wed Jun 12 11:10:26 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 12 Jun 2013 11:10:26 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51B1E0EF.7010303@CC.UniVie.ac.at> <007801ce639d$529eb0b0$f7dc1210$@a2b-internet.com> Message-ID: <51B83B02.4040201@CC.UniVie.ac.at> ??????? ??????? wrote: > I must admit that i myself as PI holder and service operator completely > agree with Dan and think that RPKI certification should be somehow > achievable by PI holders themselves without need to do any kinds of > requests to LIR. So it seems you are meking a cse for a direct service relationship with the NCC, and not using the concept of the "Sponsoring LIR"? Wilfried. > 2013/6/10 Dan Luedtke > > > > As you may have seen, I?ve created a policy proposal to ask the > RIPE NCC to > > allow Resource Certification for non-RIPE NCC member resource > holders. (IXP > > / Legacy space and PI space holders) > > As a PI holder and a router operator I support this proposal. I want > others be able to verify my prefixes. > > RPKI, if used widely, can be a much more acurate source for routing > information than the databases are. Even in RIPE region, where the > database tends to be well maintained. The more resource holders are > allowed to use RPKI, the better. I would even pay a fee for the > signing process of my resources, just in case this is about money. > -- [...] > ~~~ > WBR, > Vitaliy Turovets > NOC Lead @TV-Net ISP > +38(093)265-70-55 > VITU-RIPE > X-NCC-RegID: ua.tv From Woeber at CC.UniVie.ac.at Wed Jun 12 13:01:05 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 12 Jun 2013 13:01:05 +0200 Subject: [address-policy-wg] the interpretation of "transfer" - somewhat related to 2012-07 Message-ID: <51B854F1.1080208@CC.UniVie.ac.at> Quoting Andrea's comment of today regarding "authoritative" RIR: Legacy resources issued to organisations within the RIPE region have been transferred to the RIPE region during the ERX project. Legacy resources that have not been transferred at that time, have been issued and registered to organisations in other RIR regions. RIPE policy has no authority over legacy resources registered in other RIR regions. For this reason, in order to transfer those resources to the RIPE registry (and register them with a RIPE NCC LIR), there needs to be a transfer policy that would allow transfers between the RIPE NCC and the RIR that has the authority over those resources. First of all, I appreciate the NCC's cautious approach to moving things around without a clear consensus and guidance on preocedures! Two comments for discussion or clarification: ? until now I always read policies or policy proposals regarding a "transfer" of addresses from userA to userB. With either both of them sharing the same assignment to an authoritative RIR (intra-region xfr) or relating to different authoritative RIRs (inter-region xfr). The comment as quoted above indicates a different, or rather an additional interpretation and applicability: the transfer of address *registration* data pertaining to some (the very same!) userX from one authoritative RIR to a different one. I am not sure that the community did or does have that interpetation in mind? ? the "good old ERX" project, back then, was based on simple clerical inputs, a procedural agreement amongst the RIRs, and with no formal policy background, IIRC. Thus I do not really understand, why we would need a formal "policy" regarding inter-regeion transfers, as long as the registration subject remains the same. I may have missed some things, of course. Wilfried. From fw at deneb.enyo.de Sun Jun 16 18:49:07 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Jun 2013 18:49:07 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <51AD1B27.4080500@opteamax.de> (Jens Ott's message of "Tue, 04 Jun 2013 00:39:35 +0200") References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51AD1B27.4080500@opteamax.de> Message-ID: <87zjuqm264.fsf@mid.deneb.enyo.de> * Jens Ott: > IMHO the whole system only make sense, when it is open for all > resources! Wouldn't this mean that ARIN (or LACNIC or ...) could issue resource certification for resources allocated to you by RIPE NCC? Resource certification outside the regular hierarchical model can get very messy. (That's probably the most significant advantage of DNSSEC over the out-of-tree browser PKI.) From ripe at opteamax.de Sun Jun 16 19:51:14 2013 From: ripe at opteamax.de (Opteamax GmbH) Date: Sun, 16 Jun 2013 19:51:14 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <87zjuqm264.fsf@mid.deneb.enyo.de> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51AD1B27.4080500@opteamax.de> <87zjuqm264.fsf@mid.deneb.enyo.de> Message-ID: <51BDFB12.4080609@opteamax.de> On 16.06.2013 18:49, Florian Weimer wrote: > * Jens Ott: > >> IMHO the whole system only make sense, when it is open for all >> resources! > > Wouldn't this mean that ARIN (or LACNIC or ...) could issue resource > certification for resources allocated to you by RIPE NCC? > > Resource certification outside the regular hierarchical model can get > very messy. (That's probably the most significant advantage of DNSSEC > over the out-of-tree browser PKI.) Maybe the context was not pointed good enough in my post. I was talking about making RPKI available for RIPE-PI-Space identicalliy for as for RIPE-PA, not about signing ARIN, LACNIC or whatever space... The hierarchical model should be kept in my opinion ... BR Jens > > > !DSPAM:637,51bdf2e746056786959777! > -- 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 Woeber at CC.UniVie.ac.at Thu Jun 20 09:14:40 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 20 Jun 2013 09:14:40 +0200 Subject: [address-policy-wg] [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <51BDFB12.4080609@opteamax.de> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <51AD1B27.4080500@opteamax.de> <87zjuqm264.fsf@mid.deneb.enyo.de> <51BDFB12.4080609@opteamax.de> Message-ID: <51C2ABE0.4060804@CC.UniVie.ac.at> Opteamax GmbH wrote: > On 16.06.2013 18:49, Florian Weimer wrote: > >>* Jens Ott: >> >> >>>IMHO the whole system only make sense, when it is open for all >>>resources! >> >>Wouldn't this mean that ARIN (or LACNIC or ...) could issue resource >>certification for resources allocated to you by RIPE NCC? >> >>Resource certification outside the regular hierarchical model can get >>very messy. (That's probably the most significant advantage of DNSSEC >>over the out-of-tree browser PKI.) > > > Maybe the context was not pointed good enough in my post. I was talking > about making RPKI available for RIPE-PI-Space identicalliy for as for > RIPE-PA, not about signing ARIN, LACNIC or whatever space... The > hierarchical model should be kept in my opinion ... Maybe initially, while the "market penetration" is not big, yet. But keeping the "traditional" single-root hierarchy also means keeping the single pooint / paths of failure. > BR Jens I am somewhat relieved that I learned today that the IETF is supposedly working on extensions to the current formats. This c|would then support multiple roots / certificates / whatevcer we need. Wilfried. >>!DSPAM:637,51bdf2e746056786959777! >> > > -- > 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 andrea at ripe.net Thu Jun 20 09:49:43 2013 From: andrea at ripe.net (andrea) Date: Thu, 20 Jun 2013 09:49:43 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Message-ID: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Dear colleagues, The RIPE NCC has seen an increase in the number of organisations requesting to change the status of IP addresses from "assigned PI" to "allocated PA". At the Address Policy WG session during RIPE 66, we requested guidance from the RIPE community on what we should do with these requests. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the requests to turn PI assignments into PA allocations are coming from organisations that received a PI assignment in the past and have since become LIRs. These requests may also come from LIRs that have taken over End User organisations with PI addresses. PA allocations have more flexibility than PI assignments. With the scarcity of IPv4 addresses, organisations are looking to use this space for customer assignments or to transfer it, but are prevented from doing so by the policy for PI addresses. Problem: current RIPE Policy does not address the change in status from assigned PI to allocated PA. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) B. Do not allow LIRs to change the status of their PI assignments to PA allocations Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf Thank you in advance for your feedback Andrea Cima RIPE NCC From tore at fud.no Thu Jun 20 10:20:01 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 20 Jun 2013 10:20:01 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <51C2BB31.5060701@fud.no> * andrea > A. Allow LIRs to change the status of their PI assignments to PA > allocations (if equal or larger than the minimum allocation size) This. I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway. There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation. Besides, it is some precedent here too afaict: ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated Tore From undefine at aramin.net Thu Jun 20 11:04:37 2013 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Thu, 20 Jun 2013 11:04:37 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2BB31.5060701@fud.no> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> Message-ID: <51C2C5A5.5060404@aramin.net> W dniu 20.06.2013 10:20, Tore Anderson pisze: > * andrea >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations (if equal or larger than the minimum allocation size) I think, that allow changing purpose of address space from pi to pa will allow more optimal using of address space. Some of pi allocations which i know, are used only because there are "fixed" ip which can't be changed (vpn concetrators, dns servers). rest of pi space isn't used. Allow of translation would allow use of rest of this space and assign it to customers. > I cannot see how denying such requests could possibly be to the benefit > of the community. On the other hand I can clearly see that denying them > would be detrimental by making the NCC appear rigid, inflexible, and > customer-unfriendly; and likely also running counter to the policy's > Registration goal, as some of the LIRs that got such conversion requests > refused would likely go ahead and use the addresses as if they were > labeled PA anyway. > > There is some related precedent, cf. section 5.4 regarding conversion > from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. > > Personally, I'd even take it one step further and omit the minimum > allocation size constraint too. I consider the minimum allocation size a > policy mechanism that is only there to serve the Aggregation goal. > However, as these delegations are already made, merely relabeling them > does not make any difference when it comes to aggregation. I'm for this idea. If allocation is already made - and it's already visible in internet - there is no reason to treat it differently only because it's a bit smaller than others. > Besides, it is some precedent here too afaict: > > ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated > ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated > ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated > ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated > > > Tore > -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ From james.blessing at despres.co.uk Thu Jun 20 11:10:13 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 20 Jun 2013 10:10:13 +0100 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: On 20 June 2013 08:49, andrea wrote: > A. Allow LIRs to change the status of their PI assignments to PA allocations This > (if equal or larger than the minimum allocation size) but this makes no sense, since the object already exists in the db (and routing table) why restrict it? J -- James Blessing 07989 039 476 From richih.mailinglist at gmail.com Thu Jun 20 11:37:46 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 20 Jun 2013 11:37:46 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2BB31.5060701@fud.no> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> Message-ID: I agree with both his points: Allow translation and don't check allocation size. Do we still care about usage on v4? If yes, when does such a check happen? Before PI is translated to PA or afterwards, I.e. when they need more? Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuenzler at init7.net Thu Jun 20 11:53:18 2013 From: kuenzler at init7.net (Fredy Kuenzler) Date: Thu, 20 Jun 2013 11:53:18 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <51C2D10E.4040807@init7.net> Am 20.06.2013 11:10, schrieb James Blessing: >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations > > This +1 -- Fredy K?nzler Init7 (Switzerland) AG AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @kuenzler / @init7 http://www.init7.net/ From Keith.Nolan at pgi.com Thu Jun 20 12:06:04 2013 From: Keith.Nolan at pgi.com (Nolan, Keith) Date: Thu, 20 Jun 2013 10:06:04 +0000 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2D10E.4040807@init7.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2D10E.4040807@init7.net> Message-ID: <7499A83368D8A34F84AD6E8A70EE46642C64F4@IECLYMBOX2.Europe.premconf.com> +1 -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Fredy Kuenzler Sent: 20 June 2013 10:53 To: Address Policy Working Group Subject: Re: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Am 20.06.2013 11:10, schrieb James Blessing: >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations > > This +1 -- Fredy K?nzler Init7 (Switzerland) AG AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @kuenzler / @init7 http://www.init7.net/ From frettled at gmail.com Thu Jun 20 13:07:11 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 20 Jun 2013 13:07:11 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: On Thu, Jun 20, 2013 at 9:49 AM, andrea wrote: > > A. Allow LIRs to change the status of their PI assignments to PA > allocations (if equal or larger than the minimum allocation size) > This solution is acceptable without the parenthetical limitation. If the limitation is removed, I support solution A. Solution B is not worth considering, IMHO. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Neukirch at xing.com Thu Jun 20 12:53:02 2013 From: Christoph.Neukirch at xing.com (Christoph Neukirch) Date: Thu, 20 Jun 2013 10:53:02 +0000 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2BB31.5060701@fud.no> Message-ID: * Tore Anderson >* andrea > >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations (if equal or larger than the minimum allocation size) > >This. > >I cannot see how denying such requests could possibly be to the benefit >of the community. On the other hand I can clearly see that denying them >would be detrimental by making the NCC appear rigid, inflexible, and >customer-unfriendly; and likely also running counter to the policy's >Registration goal, as some of the LIRs that got such conversion requests >refused would likely go ahead and use the addresses as if they were >labeled PA anyway. > >There is some related precedent, cf. section 5.4 regarding conversion >from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. > >Personally, I'd even take it one step further and omit the minimum >allocation size constraint too. I consider the minimum allocation size a >policy mechanism that is only there to serve the Aggregation goal. >However, as these delegations are already made, merely relabeling them >does not make any difference when it comes to aggregation. > >Besides, it is some precedent here too afaict: > >ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated >ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated >ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated >ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated > > >Tore fully agreed +1 kind regards Christoph From lists-ripe at c4inet.net Thu Jun 20 13:26:17 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 20 Jun 2013 12:26:17 +0100 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <20130620112617.GA58394@cilantro.c4inet.net> On Thu, Jun 20, 2013 at 09:49:43AM +0200, andrea wrote: >At RIPE 66, the RIPE NCC suggested the following potential solutions: > >A. Allow LIRs to change the status of their PI assignments to PA >allocations (if equal or larger than the minimum allocation size) Support, without the size limitation. rgds, Sascha Luck From ripe-wgs.cs at schiefner.de Thu Jun 20 13:28:19 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 20 Jun 2013 13:28:19 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2BB31.5060701@fud.no> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> Message-ID: <51C2E753.50307@schiefner.de> Andrea, all - full ACK to both: * Allow status change from LIRs' PI assignments to PA allocations and to Tore's point: * Omission of the minimum allocation size constraint Cheers, -C. On 20.06.2013 10:20, Tore Anderson wrote: > * andrea > >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations (if equal or larger than the minimum allocation size) > > This. > > I cannot see how denying such requests could possibly be to the benefit > of the community. On the other hand I can clearly see that denying them > would be detrimental by making the NCC appear rigid, inflexible, and > customer-unfriendly; and likely also running counter to the policy's > Registration goal, as some of the LIRs that got such conversion requests > refused would likely go ahead and use the addresses as if they were > labeled PA anyway. > > There is some related precedent, cf. section 5.4 regarding conversion > from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. > > Personally, I'd even take it one step further and omit the minimum > allocation size constraint too. I consider the minimum allocation size a > policy mechanism that is only there to serve the Aggregation goal. > However, as these delegations are already made, merely relabeling them > does not make any difference when it comes to aggregation. > > Besides, it is some precedent here too afaict: > > ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated > ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated > ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated > ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated > > > Tore From stolpe at resilans.se Thu Jun 20 15:15:23 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 20 Jun 2013 15:15:23 +0200 (CEST) Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2E753.50307@schiefner.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> Message-ID: Agreed. On Thu, 20 Jun 2013, Carsten Schiefner wrote: > Andrea, all - > > full ACK to both: > > * Allow status change from LIRs' PI assignments to PA allocations > > and to Tore's point: > > * Omission of the minimum allocation size constraint > > Cheers, > > -C. > > On 20.06.2013 10:20, Tore Anderson wrote: >> * andrea >> >> > A. Allow LIRs to change the status of their PI assignments to PA >> > allocations (if equal or larger than the minimum allocation size) >> >> This. >> >> I cannot see how denying such requests could possibly be to the benefit >> of the community. On the other hand I can clearly see that denying them >> would be detrimental by making the NCC appear rigid, inflexible, and >> customer-unfriendly; and likely also running counter to the policy's >> Registration goal, as some of the LIRs that got such conversion requests >> refused would likely go ahead and use the addresses as if they were >> labeled PA anyway. >> >> There is some related precedent, cf. section 5.4 regarding conversion >> from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. >> >> Personally, I'd even take it one step further and omit the minimum >> allocation size constraint too. I consider the minimum allocation size a >> policy mechanism that is only there to serve the Aggregation goal. >> However, as these delegations are already made, merely relabeling them >> does not make any difference when it comes to aggregation. >> >> Besides, it is some precedent here too afaict: >> >> ripencc| SE|ipv4|193.108.42.0|512|20010406|allocated >> ripencc| DE|ipv4|193.218.220.0|512|19981110|allocated >> ripencc| PT|ipv4|194.117.48.0|512|19941206|allocated >> ripencc| IT|ipv4|194.153.212.0|512|20000509|allocated >> >> >> Tore > > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From ripe at opteamax.de Thu Jun 20 15:29:42 2013 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 20 Jun 2013 15:29:42 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C2E753.50307@schiefner.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> Message-ID: <51C303C6.5040408@opteamax.de> On 20.06.2013 13:28, Carsten Schiefner wrote: > Andrea, all - > > full ACK to both: > > * Allow status change from LIRs' PI assignments to PA allocations > > and to Tore's point: > > * Omission of the minimum allocation size constraint > Full +1 from my side. from ripe perspective the only difference I can see is the fact that PI is charged seperately. I clearly remember the (funny mentioned) words at last GM: "we are already trying hard to make a deficit, but obviously we failed again" ... so allowing new LIR to migrate there PI into PA could be at least a way to reduce the income ;) Regards -- Jens Ott 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 nigel at titley.com Thu Jun 20 16:09:08 2013 From: nigel at titley.com (Nigel Titley) Date: Thu, 20 Jun 2013 15:09:08 +0100 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C303C6.5040408@opteamax.de> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C2BB31.5060701@fud.no> <51C2E753.50307@schiefner.de> <51C303C6.5040408@opteamax.de> Message-ID: <51C30D04.8090809@titley.com> On 20/06/2013 14:29, Opteamax GmbH wrote: > On 20.06.2013 13:28, Carsten Schiefner wrote: >> Andrea, all - >> >> full ACK to both: >> >> * Allow status change from LIRs' PI assignments to PA allocations >> >> and to Tore's point: >> >> * Omission of the minimum allocation size constraint >> > Full +1 from my side. > > from ripe perspective the only difference I can see is the fact that PI > is charged seperately. I clearly remember the (funny mentioned) words at > last GM: "we are already trying hard to make a deficit, but obviously we > failed again" ... so allowing new LIR to migrate there PI into PA could > be at least a way to reduce the income ;) > I'm glad someone was listening :-) FWIW, and wearing my own personal hat (the grey-green waterproof one that I had to buy in Amsterdam one year to stop from drowning in the rain), I think this is a good idea. We're going to discuss it at the board meeting next week. Nigel From emadaio at ripe.net Fri Jun 21 15:43:51 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 21 Jun 2013 15:43:51 +0200 Subject: [address-policy-wg] 2013-02 Proposal Accepted (Removal of requirement for certification of reallocated IPv4 addresses) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-02 The updated RIPE Policy document is ripe-592 and is available at: https://www.ripe.net/ripe/docs/ripe-592 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From dcunningham at airspeed.ie Mon Jun 24 12:49:39 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Mon, 24 Jun 2013 10:49:39 +0000 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: > A. Allow LIRs to change the status of their PI assignments to PA > allocations (if equal or larger than the minimum allocation size) +1, and prefer not to include the bit in parentheses. D. -- Donal Cunningham | DC323-RIPE Peering Coordinator, AirSpeed Telecom http://as29644.peeringdb.com/ Airspeed Telecom From Woeber at CC.UniVie.ac.at Mon Jun 24 13:15:10 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 24 Jun 2013 13:15:10 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <51C82A3E.9030508@CC.UniVie.ac.at> James Blessing wrote: > On 20 June 2013 08:49, andrea wrote: > > >>A. Allow LIRs to change the status of their PI assignments to PA allocations > > > This > > >>(if equal or larger than the minimum allocation size) > > > but this makes no sense, since the object already exists in the db > (and routing table) why restrict it? I soemwhat lost track about the RIPE Region's Address Transfer Policy (proposal/s), so please bear with me. IMHO we SHOULD try to remove insconsistencies and special cases in the various policies and their interpretation. Thus: if there is (or will be) a (lower) limit in a/the Transfer Policy, then the same SHOULD apply in moving blocks from PI to PA. OTOH, if the community agrees and lifting size restrictions, then this should be done consistently across the board. > J > -- > > James Blessing > 07989 039 476 Wilfried. From maildanrl at gmail.com Mon Jun 24 13:43:40 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Mon, 24 Jun 2013 13:43:40 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C82A3E.9030508@CC.UniVie.ac.at> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> Message-ID: * Allow status change from LIRs' PI assignments to PA allocations +1 * Omission of the minimum allocation size constraint +1 -- Dan Luedtke http://www.danrl.de From tore at fud.no Mon Jun 24 14:06:45 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 24 Jun 2013 14:06:45 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C82A3E.9030508@CC.UniVie.ac.at> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> Message-ID: <51C83655.3020000@fud.no> * Wilfried Woeber > I soemwhat lost track about the RIPE Region's Address Transfer Policy > (proposal/s), so please bear with me. > > IMHO we SHOULD try to remove insconsistencies and special cases in > the various policies and their interpretation. > > Thus: if there is (or will be) a (lower) limit in a/the Transfer > Policy, then the same SHOULD apply in moving blocks from PI to PA. > > OTOH, if the community agrees and lifting size restrictions, then > this should be done consistently across the board. The current PA-only transfer policy states: ?The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation?. In other words blocks smaller than /22 may not be transferred, regardless of PI or PA status. Since the policy is quite explicit on this point, changing it would require the community to adopt a policy proposal that explicitly made such a change. [BTW: The policy also states that the minimum allocation size is /21, but there have been a couple of /22 transfers already. I assume the NCC is considering the /21 statement as superseded by the last /8 policy and considers the minimum allocation size to be /22 instead.] Tore From ripe.address-policy-wg at ml.karotte.org Mon Jun 24 16:14:46 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Mon, 24 Jun 2013 16:14:46 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> Message-ID: <20130624141446.GA15031@danton.fire-world.de> * andrea [2013-06-20 09:51]: > A. Allow LIRs to change the status of their PI assignments to PA > allocations (if equal or larger than the minimum allocation size) I support this without the allocation size limit. There are a lot PI assignments smaller than the minimum allocation size. Regards 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 Woeber at CC.UniVie.ac.at Tue Jun 25 11:58:19 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 25 Jun 2013 11:58:19 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C83655.3020000@fud.no> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> <51C83655.3020000@fud.no> Message-ID: <51C969BB.9080704@CC.UniVie.ac.at> Tore Anderson wrote: > * Wilfried Woeber > > >>I soemwhat lost track about the RIPE Region's Address Transfer Policy >>(proposal/s), so please bear with me. >> >>IMHO we SHOULD try to remove insconsistencies and special cases in >>the various policies and their interpretation. >> >>Thus: if there is (or will be) a (lower) limit in a/the Transfer >>Policy, then the same SHOULD apply in moving blocks from PI to PA. >> >>OTOH, if the community agrees and lifting size restrictions, then >>this should be done consistently across the board. > > > The current PA-only transfer policy states: ?The block that is to be > re-allocated must not be smaller than the minimum allocation block size > at the time of re-allocation?. > > In other words blocks smaller than /22 may not be transferred, > regardless of PI or PA status. Since the policy is quite explicit on > this point, changing it would require the community to adopt a policy > proposal that explicitly made such a change. > > [BTW: The policy also states that the minimum allocation size is /21, > but there have been a couple of /22 transfers already. I assume the NCC > is considering the /21 statement as superseded by the last /8 policy and > considers the minimum allocation size to be /22 instead.] OK, thanks Tore! So - question to the IPRAs: what sizes of PI blocks did you see when the PI->PA conversion requests were submitted? Wilfried. > Tore From andrea at ripe.net Tue Jun 25 12:28:36 2013 From: andrea at ripe.net (Andrea Cima) Date: Tue, 25 Jun 2013 12:28:36 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <51C969BB.9080704@CC.UniVie.ac.at> References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> <51C83655.3020000@fud.no> <51C969BB.9080704@CC.UniVie.ac.at> Message-ID: <51C970D4.9000902@ripe.net> Hi All, On 6/25/13 11:58 AM, Wilfried Woeber wrote: > Tore Anderson wrote: > >> * Wilfried Woeber >> >> >>> I soemwhat lost track about the RIPE Region's Address Transfer Policy >>> (proposal/s), so please bear with me. >>> >>> IMHO we SHOULD try to remove insconsistencies and special cases in >>> the various policies and their interpretation. >>> >>> Thus: if there is (or will be) a (lower) limit in a/the Transfer >>> Policy, then the same SHOULD apply in moving blocks from PI to PA. >>> >>> OTOH, if the community agrees and lifting size restrictions, then >>> this should be done consistently across the board. >> >> The current PA-only transfer policy states: ?The block that is to be >> re-allocated must not be smaller than the minimum allocation block size >> at the time of re-allocation?. >> >> In other words blocks smaller than /22 may not be transferred, >> regardless of PI or PA status. Since the policy is quite explicit on >> this point, changing it would require the community to adopt a policy >> proposal that explicitly made such a change. >> >> [BTW: The policy also states that the minimum allocation size is /21, >> but there have been a couple of /22 transfers already. I assume the NCC >> is considering the /21 statement as superseded by the last /8 policy and >> considers the minimum allocation size to be /22 instead.] This statement is correct: we consider the /21 statement as superseded by the last /8 policy, according to which the minimum allocation size is /22. > OK, thanks Tore! > > So - question to the IPRAs: what sizes of PI blocks did you see when the > PI->PA conversion requests were submitted? Most of the requests for conversion from assigned PI to allocated PA have been for IP blocks larger than the minimum allocation size (mainly /20 and /19 blocks). Just in very few cases the IP blocks were smaller than the minimum allocation size (/23 and /24 blocks). Best regards, Andrea Cima RIPE NCC > Wilfried. > >> Tore > > From andrea at ripe.net Tue Jun 25 15:02:21 2013 From: andrea at ripe.net (Andrea Cima) Date: Tue, 25 Jun 2013 15:02:21 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs Message-ID: <51C994DD.1040005@ripe.net> [Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC From emadaio at ripe.net Tue Jun 25 15:29:45 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 25 Jun 2013 15:29:45 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects Message-ID: <51C99B49.10800@ripe.net> Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". A draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents The Address Policy Working Group Co-Chairs decided to extend the review period until 9 July 2013 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at . Kind regards, Emilio Madaio Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Tue Jun 25 15:38:32 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 25 Jun 2013 14:38:32 +0100 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C994DD.1040005@ripe.net> References: <51C994DD.1040005@ripe.net> Message-ID: On 25 June 2013 14:02, Andrea Cima wrote: > C. Clean up the RIPE Database from references and then reassign the AS > numbers > C.1. "Silent" update; or > C.2. Informing the object holder of the update Okay couple of questions... 1. Have people with these objects been notified yet (might be a good place to start)? As a matter of course are returns actually announced/published anywhere? 2. Is there a single list of returned and referenced ASNs that a concerned netcitizen could parse and then fix their records from? I think cart and horse spring to mind J -- James Blessing 07989 039 476 From davidm at futureinquestion.net Tue Jun 25 16:09:09 2013 From: davidm at futureinquestion.net (David Monosov) Date: Tue, 25 Jun 2013 16:09:09 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C9A395.8080600@futureinquestion.net> References: <51C99B49.10800@ripe.net> <51C9A395.8080600@futureinquestion.net> Message-ID: <51C9A485.4050100@futureinquestion.net> Dear address-policy-wg, This has unintentionally gone out as a reply to Emilio's post '[address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects' but was meant as a response to Andrea's post '[address-policy-wg] Guidance Requested: Reassigning Referenced ASNs'; my apologies. -- Respectfully yours, David Monosov On 06/25/2013 04:05 PM, David Monosov wrote: > Dear Andrea Cima, address-policy-wg, > > Since it is not included as an option, is there any reason why simply > reassigning the AS numbers after a period of time, but notifying object > maintainers which reference the AS number that this has occurred (or is about to > occur) would not be the best solution? > > Keeping limited resources out of the recycling pool because of laziness or lack > of situational awareness of some operators seems like a poor approach. > > Butchering object and outdated RPSL policies of operators and replacing them > with selectively less outdated versions automatically seems undesirable as well > since it may break any further operator automation which (wrongfully or not) may > rely on those objects. > > -- > Respectfully yours, > > David Monosov > > On 06/25/2013 03:29 PM, Emilio Madaio wrote: >> >> >> Dear colleagues, >> >> As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward >> with a review of the policy document ripe-513, "Value of the "status:" >> and "assignment-size:" attributes in INET6NUM objects for sub-assigned >> PA space". >> >> A draft of the policy document is online and ready for community >> review at: >> >> https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents >> >> The Address Policy Working Group Co-Chairs decided to extend the review >> period until 9 July 2013 to allow the community more time to give their >> feedback. >> >> Please send your feedback on this draft document to the Address Policy >> Working Group at . >> >> Kind regards, >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> From davidm at futureinquestion.net Tue Jun 25 16:05:09 2013 From: davidm at futureinquestion.net (David Monosov) Date: Tue, 25 Jun 2013 16:05:09 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects In-Reply-To: <51C99B49.10800@ripe.net> References: <51C99B49.10800@ripe.net> Message-ID: <51C9A395.8080600@futureinquestion.net> Dear Andrea Cima, address-policy-wg, Since it is not included as an option, is there any reason why simply reassigning the AS numbers after a period of time, but notifying object maintainers which reference the AS number that this has occurred (or is about to occur) would not be the best solution? Keeping limited resources out of the recycling pool because of laziness or lack of situational awareness of some operators seems like a poor approach. Butchering object and outdated RPSL policies of operators and replacing them with selectively less outdated versions automatically seems undesirable as well since it may break any further operator automation which (wrongfully or not) may rely on those objects. -- Respectfully yours, David Monosov On 06/25/2013 03:29 PM, Emilio Madaio wrote: > > > Dear colleagues, > > As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward > with a review of the policy document ripe-513, "Value of the "status:" > and "assignment-size:" attributes in INET6NUM objects for sub-assigned > PA space". > > A draft of the policy document is online and ready for community > review at: > > https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents > > The Address Policy Working Group Co-Chairs decided to extend the review > period until 9 July 2013 to allow the community more time to give their > feedback. > > Please send your feedback on this draft document to the Address Policy > Working Group at . > > Kind regards, > Emilio Madaio > Policy Development Officer > RIPE NCC > From nick at inex.ie Tue Jun 25 16:35:31 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 25 Jun 2013 15:35:31 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects In-Reply-To: <51C99B49.10800@ripe.net> References: <51C99B49.10800@ripe.net> Message-ID: <51C9AAB3.9010109@inex.ie> On 25/06/2013 14:29, Emilio Madaio wrote: > A draft of the policy document is online and ready for community > review at: > > https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents There's a typo in section 3.0: > you would create an object similar to: > > inet6num: 2000::/46 status: I'm guessing that this is a deliberate typo to check whether people actually review policy updates from the readability project :-) Otherwise it looks fine to me. Nick From nick at inex.ie Tue Jun 25 17:47:46 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 25 Jun 2013 16:47:46 +0100 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C994DD.1040005@ripe.net> References: <51C994DD.1040005@ripe.net> Message-ID: <51C9BBA2.8030806@inex.ie> On 25/06/2013 14:02, Andrea Cima wrote: > A. Not reassign referenced AS numbers > B. Reassign AS numbers even if referenced > C. Clean up the RIPE Database from references and then reassign the AS numbers > C.1. "Silent" update; or > C.2. Informing the object holder of the update My preference would be for C.1, and that the process of reassignment should not be delayed by replies or a lack of replies from object holders who are referencing the ASNs. As this is an operational issue, is there a need for a policy proposal? Nick From pk at DENIC.DE Tue Jun 25 17:51:30 2013 From: pk at DENIC.DE (Peter Koch) Date: Tue, 25 Jun 2013 17:51:30 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects In-Reply-To: <51C99B49.10800@ripe.net> References: <51C99B49.10800@ripe.net> Message-ID: <20130625155130.GM25143@x28.adm.denic.de> On Tue, Jun 25, 2013 at 03:29:45PM +0200, Emilio Madaio wrote: > https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents May I express some doubts about the 'cosmetic surgery project'? The project was introduced as early as October 2009 and RIPE 513 was published in February 2011. What appears to happen is a very late post publication copy editing. In this particular case, the policy itself is a change to the database attributes and - other than, say, address allocation/assignment policies - not very likely read its own. Any structural changes to the document (where's the template, by the way?) and changes to style (passive voice here and there) or readability might better be invested in the general database documentation. The new draft eliminates the data protection aspect from the introduction/motivation section, which I consider a loss. The abstract wins, though. The draft continues to use 2000::/46 for the example where some chunk of 2001:DB8::/32 as per RFC 3849 might be a better choice. -Peter From randy at psg.com Tue Jun 25 17:51:57 2013 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jun 2013 00:51:57 +0900 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C9BBA2.8030806@inex.ie> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> Message-ID: inform owner of dangling reference. wait a week. inform again. wait a month. inform again. wait a week. remove dangling reference. wait a month to see if anything has broken enough to get the attention of folk who do not respond to email. reassign AS number. randy From andreas.larsen at ip-only.se Wed Jun 26 09:18:50 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Wed, 26 Jun 2013 09:18:50 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <20130624141446.GA15031@danton.fire-world.de> Message-ID: A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) I support this without the allocation size limit. // Andreas Med v?nlig h?lsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-06-24 16:14 skrev Sebastian Wiesinger : >* andrea [2013-06-20 09:51]: >> A. Allow LIRs to change the status of their PI assignments to PA >> allocations (if equal or larger than the minimum allocation size) > >I support this without the allocation size limit. There are a lot PI >assignments smaller than the minimum allocation size. > >Regards > >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 emadaio at ripe.net Wed Jun 26 09:50:08 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 26 Jun 2013 09:50:08 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects In-Reply-To: <20130625155130.GM25143@x28.adm.denic.de> References: <51C99B49.10800@ripe.net> <20130625155130.GM25143@x28.adm.denic.de> Message-ID: <51CA9D30.4060806@ripe.net> Dear Peter, thank you very much for your input and remark. I apologize if I forgot to include the IPv6 and Database WG mailing lists as decided during RIPE 66 on request of the community. I slavishly followed the procedure defined by the Cosmetic Surgery Project that was meant for the Address Policy WG mailing list only. The original announcement for the extended Review Phase is available at: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007931.html For further feedback the draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents Please send your feedback on this draft document before 9 July 2013. Best Regards Emilio Madaio Policy Development Officer RIPE NCC On 6/25/13 5:51 PM, Peter Koch wrote: > On Tue, Jun 25, 2013 at 03:29:45PM +0200, Emilio Madaio wrote: > >> https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents > > May I express some doubts about the 'cosmetic surgery project'? > The project was introduced as early as October 2009 and RIPE 513 was published > in February 2011. What appears to happen is a very late post publication copy > editing. In this particular case, the policy itself is a change to the > database attributes and - other than, say, address allocation/assignment > policies - not very likely read its own. Any structural changes > to the document (where's the template, by the way?) and changes to style > (passive voice here and there) or readability might better be invested > in the general database documentation. > > The new draft eliminates the data protection aspect from the > introduction/motivation section, which I consider a loss. The abstract > wins, though. The draft continues to use 2000::/46 for the example > where some chunk of 2001:DB8::/32 as per RFC 3849 might be a better choice. > > -Peter > From cfriacas at fccn.pt Wed Jun 26 09:42:50 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 26 Jun 2013 08:42:50 +0100 (WEST) Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> Message-ID: Hi, I also think this is a good idea. So, +1. But shouldn't this go through the regular PDP...? (i.e. who really needs this should write a new policy proposal...) Regards, Carlos On Mon, 24 Jun 2013, Dan Luedtke wrote: > * Allow status change from LIRs' PI assignments to PA allocations > +1 > > * Omission of the minimum allocation size constraint > +1 > > -- > Dan Luedtke > http://www.danrl.de > From Olaf.Sonderegger at abraxas.ch Wed Jun 26 10:35:26 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Wed, 26 Jun 2013 08:35:26 +0000 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> Hi all Based on Randy's proposal: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. In my point of view, it is enough to inform once. Members have to update their information, members have to be contactable by e-mail. So: 1. Inform owner about its wrong objects (only once). 2. If an owner doesn't clean up its objects, RIPE NCC should be able to clean up by itself after a month. 3. Re-assign AS numbers after two month. Best regards, Olaf Sonderegger -------------- next part -------------- An HTML attachment was scrubbed... URL: From Olaf.Sonderegger at abraxas.ch Wed Jun 26 11:10:55 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Wed, 26 Jun 2013 09:10:55 +0000 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> Hi all My question is: Why RIPE NCC should go one step back instead one step forward? I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. Ref 1: http://ripe62.ripe.net/presentations/148-wg.pdf Ref 2: http://ripe63.ripe.net/presentations/143-wg3.pdf I think, I could accept request as our first step in direction of removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Best regards, Olaf Sonderegger -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Wed Jun 26 11:25:38 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 26 Jun 2013 11:25:38 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> Message-ID: <51CAB392.3030809@CC.UniVie.ac.at> Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > Hi all In general I support the recycling of AS #s, but for operational and consistency reasons I'd be a bit more careful... > Based on Randy's proposal: > > >>inform owner of dangling reference. wait a week. inform again. >>wait a month. inform again. wait a week. remove dangling reference. >>wait a month to see if anything has broken enough to get the attention >>of folk who do not respond to email. reassign AS number. > > > In my point of view, it is enough to inform once. Members have to update > their information, members have to be contactable by e-mail. > > So: > 1. Inform owner about its wrong objects (only once). ACK, although we may want to do a little bit more than just once, depending on the "failure mode" of the communication attempt. In particular, if the notification by email cannot be delivered, I'd suggest that the "member relations role" should follow up immediately. Depending on the outcome, we may try the alert again or take other, more serious steps as foreseen when a member[1] cannot be contacted. > 2. If an owner doesn't clean up its objects, RIPE NCC should be able > to clean up by itself after a month. While I do see the beauty of this approach, we may actually add to the inconsistencies between assignment reality, documentation and operational reality. Note that over the last few years we made changes to the behaviour of the DB, aka Registry, which make it more and more likely that the "authoritative copy" of an object is kept locally. So, even if the NCC modifies an object, it may easily be recreated/updated to the old "wrong" state. > 3. Re-assign AS numbers after two month. Relative to the completion of the alerting exercise. With the caveat that those AS#s should be recycled first which are "clean", assuming that the stockpile is big enough to satisfy the requests. > Best regards, > Olaf Sonderegger Wilfried [1] "members" to be interpreted as the tree of members/LIRs own resources, as well as sponsored end user assignments From DMenzulskiy at beeline.ru Wed Jun 26 11:23:19 2013 From: DMenzulskiy at beeline.ru (Dmitriy V Menzulskiy) Date: Wed, 26 Jun 2013 13:23:19 +0400 Subject: [address-policy-wg] =?koi8-r?b?SME6ICBHdWlkYW5jZSBSZXF1ZXN0ZWQ6?= =?koi8-r?b?IFJlYXNzaWduaW5nIFJlZmVyZW5jZWQgQVNOcw==?= In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> Message-ID: > > Based on Randy's proposal: > > > inform owner of dangling reference. wait a week. inform again. > > wait a month. inform again. wait a week. remove dangling reference. > > wait a month to see if anything has broken enough to get the attention > > of folk who do not respond to email. reassign AS number. > > In my point of view, it is enough to inform once. Members have to > update their information, members have to be contactable by e-mail. > > So: > 1. Inform owner about its wrong objects (only once). > 2. If an owner doesn't clean up its objects, RIPE NCC should be able > to clean up by itself after a month. > 3. Re-assign AS numbers after two month. > I agree vith Olaf : - inform once - clean up after a month - re-assign after two months. WBR, Dmitry Menzulskiy OJSC "VimpelCom" Moscwo, Russia -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Wed Jun 26 12:06:40 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 26 Jun 2013 12:06:40 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CAB392.3030809@CC.UniVie.ac.at> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: On Jun 26, 2013 11:25 AM, "Wilfried Woeber" wrote: > > In general I support the recycling of AS #s, > but for operational and consistency reasons I'd be a bit more careful... There is no shortage of ASn so we have the luxury of being able to be _very_ careful. Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From martynas at aleja.lt Wed Jun 26 12:11:16 2013 From: martynas at aleja.lt (=?windows-1257?Q?Martynas_UAB_=22Duomen=F8_Centras=22?=) Date: Wed, 26 Jun 2013 13:11:16 +0300 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> Message-ID: <006701ce7255$822fcb40$868f61c0$@aleja.lt> Agree From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sonderegger Olaf ABRAXAS INFORMATIK AG Sent: 2013 m. bir?elio 26 d. 12:11 To: address-policy-wg at ripe.net Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Hi all My question is: Why RIPE NCC should go one step back instead one step forward? I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. Ref 1: http://ripe62.ripe.net/presentations/148-wg.pdf Ref 2: http://ripe63.ripe.net/presentations/143-wg3.pdf I think, I could accept request as our first step in direction of removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Best regards, Olaf Sonderegger -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Wed Jun 26 12:22:09 2013 From: jim at rfc1035.com (Jim Reid) Date: Wed, 26 Jun 2013 11:22:09 +0100 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: <783C1695-7B4B-459F-8D10-A2C9F909189A@rfc1035.com> On 26 Jun 2013, at 11:06, Richard Hartmann wrote: > Even after an ASn had been reclaimed we can easily wait a significant > period of time before recycling them. +1. From jim at rfc1035.com Wed Jun 26 12:17:04 2013 From: jim at rfc1035.com (Jim Reid) Date: Wed, 26 Jun 2013 11:17:04 +0100 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: <0381F37C-61ED-46BC-9457-0AC46F6D7C93@rfc1035.com> On 26 Jun 2013, at 11:06, Richard Hartmann wrote: > Even after an ASn had been reclaimed we can easily wait a significant > period of time before recycling them. +1. From gert at space.net Wed Jun 26 12:42:15 2013 From: gert at space.net (Gert Doering) Date: Wed, 26 Jun 2013 12:42:15 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> Message-ID: <20130626104215.GD2706@Space.Net> Hi, On Wed, Jun 26, 2013 at 09:10:55AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > My question is: Why RIPE NCC should go one step back instead one step forward? > > I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. To change this would require a policy proposal that would change these bits of the IPv4 address policy, and go through the PDP process, and that's a somewhat major undertaking. Permitting relabeling of PI into PA space is "low effort", as it is not actually covered by policy today - so if the community says "we see no problem with that, let's do it" the NCC can go ahead without a formal process. (The current policy neither permits nor forbids the NCC to do so, so the guidance requested from the community is "what should the NCC do here, with no clear rules set by policy?" - and I think we have fairly clear guidance so far. I'll wait a few more days and then summarize the feedback received). 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From Olaf.Sonderegger at abraxas.ch Wed Jun 26 13:34:56 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Wed, 26 Jun 2013 11:34:56 +0000 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <20130626104215.GD2706@Space.Net> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> <20130626104215.GD2706@Space.Net> Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DBA9E3@SAX20244.bia.abraxas.ch> Hi Okay, I agree with Gert's point of view. If community doesn't see any problem with guidance request, let's do it. It would be nice if Address Policy WG could continue with the idea about removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Are there any plans? Olaf Sonderegger -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Mittwoch, 26. Juni 2013 12:42 To: Sonderegger Olaf ABRAXAS INFORMATIK AG Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Hi, On Wed, Jun 26, 2013 at 09:10:55AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > My question is: Why RIPE NCC should go one step back instead one step forward? > > I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. To change this would require a policy proposal that would change these bits of the IPv4 address policy, and go through the PDP process, and that's a somewhat major undertaking. Permitting relabeling of PI into PA space is "low effort", as it is not actually covered by policy today - so if the community says "we see no problem with that, let's do it" the NCC can go ahead without a formal process. (The current policy neither permits nor forbids the NCC to do so, so the guidance requested from the community is "what should the NCC do here, with no clear rules set by policy?" - and I think we have fairly clear guidance so far. I'll wait a few more days and then summarize the feedback received). 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 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Wed Jun 26 14:44:03 2013 From: gert at space.net (Gert Doering) Date: Wed, 26 Jun 2013 14:44:03 +0200 Subject: [address-policy-wg] PA/PI unification PI Address Space Message-ID: <20130626124403.GI2706@Space.Net> Hi, (subject changed and in-reply-to: removed, to make it clear that this is really a different thread) On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > It would be nice if Address Policy WG could continue with the > idea about removing status "Provider Aggregatable" (PA) and "Provider > Independent" (PI). Are there any plans? For IPv4, let's wait until Tore's proposal has come to a conclusion, as it's very hard to do two large-scale changes to the same text at the same time. For IPv6, it's still sitting on my lap, and I need to restart the process - thanks for the reminder. 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Wed Jun 26 14:48:50 2013 From: gert at space.net (Gert Doering) Date: Wed, 26 Jun 2013 14:48:50 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: References: <2302dfb8e2f3c09fbc7553912a2e3ce7@ripe.net> <51C82A3E.9030508@CC.UniVie.ac.at> Message-ID: <20130626124850.GJ2706@Space.Net> Hi Carlos, On Wed, Jun 26, 2013 at 08:42:50AM +0100, Carlos Friacas wrote: > But shouldn't this go through the regular PDP...? > (i.e. who really needs this should write a new policy proposal...) We're not actually changing policy - we have something here where the policy text isn't specifying anything, so if we can agree how we want the RIPE NCC to handle this, we can do this in a quicker and more light-weight way of "just asking the community for guidance". One of the important aspects here is that this will not change the way the RIPE NCC hands out resources. 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From stolpe at resilans.se Wed Jun 26 14:57:45 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 26 Jun 2013 14:57:45 +0200 (CEST) Subject: [address-policy-wg] PA/PI unification PI Address Space In-Reply-To: <20130626124403.GI2706@Space.Net> References: <20130626124403.GI2706@Space.Net> Message-ID: On Wed, 26 Jun 2013, Gert Doering wrote: > Hi, > > (subject changed and in-reply-to: removed, to make it clear that this is > really a different thread) > > On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: >> It would be nice if Address Policy WG could continue with the >> idea about removing status "Provider Aggregatable" (PA) and "Provider >> Independent" (PI). Are there any plans? > > For IPv4, let's wait until Tore's proposal has come to a conclusion, > as it's very hard to do two large-scale changes to the same text at the > same time. > > For IPv6, it's still sitting on my lap, and I need to restart the process - > thanks for the reminder. Just let us know if you need volonteers or cheering. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From randy at psg.com Wed Jun 26 15:06:42 2013 From: randy at psg.com (Randy Bush) Date: Wed, 26 Jun 2013 22:06:42 +0900 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> Message-ID: >> inform owner of dangling reference. wait a week. inform again. >> wait a month. inform again. wait a week. remove dangling reference. >> wait a month to see if anything has broken enough to get the attention >> of folk who do not respond to email. reassign AS number. > > In my point of view, it is enough to inform once. Members have to > update their information, members have to be contactable by e-mail. > So: > 1. Inform owner about its wrong objects (only once). > 2. If an owner doesn't clean up its objects, RIPE NCC should be > able to clean up by itself after a month. > 3. Re-assign AS numbers after two month. do we want to teach adults a lesson in proper behavior, or do we want to prudently run an operational internet? randy From Olaf.Sonderegger at abraxas.ch Wed Jun 26 15:22:29 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Wed, 26 Jun 2013 13:22:29 +0000 Subject: [address-policy-wg] PA/PI unification PI Address Space In-Reply-To: References: <20130626124403.GI2706@Space.Net> Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DBAA9F@SAX20244.bia.abraxas.ch> 1+ If i can, i will help. -----Original Message----- From: Daniel Stolpe [mailto:stolpe at resilans.se] Sent: Mittwoch, 26. Juni 2013 14:58 To: Gert Doering Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PA/PI unification PI Address Space On Wed, 26 Jun 2013, Gert Doering wrote: > Hi, > > (subject changed and in-reply-to: removed, to make it clear that this > is really a different thread) > > On Wed, Jun 26, 2013 at 11:34:56AM +0000, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: >> It would be nice if Address Policy WG could continue with the idea >> about removing status "Provider Aggregatable" (PA) and "Provider >> Independent" (PI). Are there any plans? > > For IPv4, let's wait until Tore's proposal has come to a conclusion, > as it's very hard to do two large-scale changes to the same text at > the same time. > > For IPv6, it's still sitting on my lap, and I need to restart the > process - thanks for the reminder. Just let us know if you need volonteers or cheering. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From michele at blacknight.com Wed Jun 26 15:53:53 2013 From: michele at blacknight.com (Michele Neylon :: Blacknight) Date: Wed, 26 Jun 2013 13:53:53 +0000 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130625155029.1BC345A402A@merlin.blacknight.ie> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <20130625155029.1BC345A402A@merlin.blacknight.ie> Message-ID: +1 seems sane On 25 Jun 2013, at 16:51, Randy Bush wrote: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. > > randy > Mr Michele Neylon Blacknight Solutions ? Hosting & Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From andrey at trifle.net Wed Jun 26 13:19:11 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Wed, 26 Jun 2013 14:19:11 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C9BBA2.8030806@inex.ie> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> Message-ID: <51CACE2F.7050406@trifle.net> On 06/25/13 18:47, Nick Hilliard wrote: > On 25/06/2013 14:02, Andrea Cima wrote: >> A. Not reassign referenced AS numbers >> B. Reassign AS numbers even if referenced >> C. Clean up the RIPE Database from references and then reassign the AS numbers >> C.1. "Silent" update; or >> C.2. Informing the object holder of the update > My preference would be for C.1, and that the process of reassignment should > not be delayed by replies or a lack of replies from object holders who are > referencing the ASNs. > > As this is an operational issue, is there a need for a policy proposal? > > Nick Fully agree with Nick Communication with resource holders that referenced to unused ASN is the way to waste time. If the ASN is already returned to the pool, it means that the RIPE had tried to communicate with the resource holder at least three times during at least 3 month. So, there's no necessity to provide additional time to communicate with someone. Moreover: the ASN assigned to no one, so clearing the database from the erroneous reference will not affect to any resource holder (it's because there's no the ASN holder any more) and all references may be cleared as soon the ASN is returned to the pool. All the RIPE may to do - is to notify a holder of the resource that was silently cleared (but after the object was cleared) So, C.1 - is the good choice -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From randy at psg.com Wed Jun 26 17:44:24 2013 From: randy at psg.com (Randy Bush) Date: Thu, 27 Jun 2013 00:44:24 +0900 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CACE2F.7050406@trifle.net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> Message-ID: > If the ASN is already returned to the pool, it means that the RIPE had > tried to communicate with the resource holder at least three times > during at least 3 month. the resource holder of a route: object owns the ip space, not necessarily the asn. randy From ripe at opteamax.de Wed Jun 26 18:40:21 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Wed, 26 Jun 2013 18:40:21 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> Message-ID: <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> Randy Bush schrieb: >> If the ASN is already returned to the pool, it means that the RIPE >had >> tried to communicate with the resource holder at least three times >> during at least 3 month. > >the resource holder of a route: object owns the ip space, not >necessarily the asn. > Actually I don't really understand the problem. If the ASN is back in the pool, this reads for me "it shall no longer appear in the routing table". This includes for me that any object referencing this ASN is illegal by definition. So these illegal objects may not exist and *must* be removed asap from the DB. After removing all illegal objects, they should stay in some "grace-period" - let's say 3 month - and then there should be no problem reallocating the asn. I mean, IPv4 is also reallocated pretty quickly, as my last /22 existed in my routing table announced from a London based ASN less than two months before it was allocated to my LIR. BTW: IMHO the database shall also be cleaned from route6 objects with invalid netmasks ... but that's a different topic ;) BR Jens >randy > > >!DSPAM:637,51cb0c70196951779145505! From gert at space.net Wed Jun 26 20:11:09 2013 From: gert at space.net (Gert Doering) Date: Wed, 26 Jun 2013 20:11:09 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> Message-ID: <20130626181109.GM2706@Space.Net> Hi, On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote: > Actually I don't really understand the problem. If the ASN is > back in the pool, this reads for me "it shall no longer appear in > the routing table". This includes for me that any object referencing > this ASN is illegal by definition. So these illegal objects may not > exist and *must* be removed asap from the DB. After removing all > illegal objects, they should stay in some "grace-period" - let's > say 3 month - and then there should be no problem reallocating the > asn. The database currently has no mechanics to prevent someone from entering an import/export line that says: aut-num: AS100000 remarks: have fun with Jens export: to AS5539 announce AS48200 which is exactly that sort of reference that would currently keep the NCC from reallocating AS48200 (assuming that one were free). Auto-cleaning the route: objects still referencing AS48200 is fairly easy, but auto-cleaning export/import policies and AS-SET objects is harder, especially as people might have the aut-num: object in question on file, just change stuff locally, and then re-send it when they have changes, overriding the cleaned-up object in the database... 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From leo.vegoda at icann.org Wed Jun 26 20:14:27 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 26 Jun 2013 11:14:27 -0700 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130626181109.GM2706@Space.Net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> <20130626181109.GM2706@Space.Net> Message-ID: <5648A8908CCB564EBF46E2BC904A75B184E0DEA539@EXVPMBX100-1.exc.icann.org> Hi, Gert Doering wrote: [...] > The database currently has no mechanics to prevent someone from entering > an import/export line that says: > > aut-num: AS100000 > remarks: have fun with Jens > export: to AS5539 announce AS48200 > > which is exactly that sort of reference that would currently keep the > NCC from reallocating AS48200 (assuming that one were free). Also, as was mentioned when this was discussed at RIPE 52, there may well be references in other - popular - routing registries. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From ripe at opteamax.de Wed Jun 26 21:05:31 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Wed, 26 Jun 2013 21:05:31 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130626181109.GM2706@Space.Net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> <20130626181109.GM2706@Space.Net> Message-ID: <53335dbc-2e40-4218-98a8-97bbe5fc67f0@email.android.com> Gert Doering schrieb: Hi, On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote: Actually I don't really understand the problem. If the ASN is back in the pool, this reads for me "it shall no longer appear in the routing table". This includes for me that any object referencing this ASN is illegal by definition. So these illegal objects may not exist and *must* be removed asap from the DB. After removing all illegal objects, they should stay in some "grace-period" - let's say 3 month - and then there should be no problem reallocating the asn. The database currently has no mechanics to prevent someone from entering an import/export line that says: aut-num: AS100000 remarks: have fun with Jens export: to AS5539 announce AS48200 Got the point, thanks for making it clearer to me (and maybe some others) So this might also be a task for the database working group then ;) Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Wed Jun 26 21:48:19 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 26 Jun 2013 21:48:19 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51C994DD.1040005@ripe.net> References: <51C994DD.1040005@ripe.net> Message-ID: <004801ce72a6$1d32d010$57987030$@a2b-internet.com> Hi Andrea, In general I agree to the idea of recycling the returned AS numbers. I also think that the contacts of referenced AS numbers in the database, should be contacted (probably multiple times as Randy suggested) and in the end, fix it in the database if nothing is fixed. The idea of cleaning the RIPE db is noble and we should do that, however there are also other locations where those AS numbers are referenced.. ( PeeringDB or RADB comes to mind..) Are we going to provide them with the list of current returned AS numbers to make sure they can also do their housekeeping ? Regards, Erik Bais -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Andrea Cima Sent: dinsdag 25 juni 2013 15:02 To: address-policy-wg at ripe.net Cc: db-wg at ripe.net Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs [Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC From ebais at a2b-internet.com Wed Jun 26 21:54:23 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 26 Jun 2013 21:54:23 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <0381F37C-61ED-46BC-9457-0AC46F6D7C93@rfc1035.com> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> <0381F37C-61ED-46BC-9457-0AC46F6D7C93@rfc1035.com> Message-ID: <004f01ce72a6$f4b986a0$de2c93e0$@a2b-internet.com> > On 26 Jun 2013, at 11:06, Richard Hartmann wrote: >> Even after an ASn had been reclaimed we can easily wait a significant >> period of time before recycling them. > +1. Waiting itself isn't going to fix the 'problem' ... I've removed a certain AS from an Internet Exchange about 18 months ago. And we still get occasional email stating that the peering session is down ... while it was clearly communicated that we wanted to change certain sessions to another AS number and after several tries, we shut the connection and clearly communicated that the AS was removed from the Internet Exchange. Sad story but true ... Erik Bais From nick at inex.ie Wed Jun 26 22:34:29 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 26 Jun 2013 21:34:29 +0100 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130626181109.GM2706@Space.Net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <2a6d708a-e999-42b3-bda5-0bb771f68b62@email.android.com> <20130626181109.GM2706@Space.Net> Message-ID: <51CB5055.7060909@inex.ie> On 26/06/2013 19:11, Gert Doering wrote: > which is exactly that sort of reference that would currently keep the > NCC from reallocating AS48200 (assuming that one were free). ... which is why I suggested that inaction shouldn't negatively affect timelines. People never clean up after themselves, so the RIPE NCC will either need to edit the affected objects themselves (which will work fine until someone's provisioning database respams the DB with out-of-date information) or else notify + wait, but then ultimately ignore if there's a problem. Other IRRDBs are other peoples' problems. A recycling period of a couple of months would seem sensible, as there will be a resource shortage for asn16s. There's no reason for the RIPE NCC not to notify references immediately. Nick From erik at bais.name Wed Jun 26 22:16:41 2013 From: erik at bais.name (Erik Bais) Date: Wed, 26 Jun 2013 20:16:41 +0000 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CACE2F.7050406@trifle.net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C5F1A6597@E2010-MBX03.exchange2010.nl> Hi Andrey, You stated (if I may quote you freely) ... that if an AS number is returned, it might / should not impact routing ... And you are probably right for 99.8% .. However ... there might be situations where someone would be using a certain BGP community in RPLS for internal reference still while the actual AS number isn't used anymore. Think about a similar way as how certain routeserver filtering is implemented. import: from AS6777 action pref=85; accept ANY AND NOT <^[ASAAAA ASXXXX ASYYYYY ASZZZZZ ASWWWW]> AND NOT {0.0.0.0/0} export: to AS6777 action community .= {6777:6777, 6777:AAAAA, 6777:XXXX, 6777:YYYYY, 6777:ZZZZ, 6777:WWWW}; announce AS- Erik Bais From andreas at schachtner.eu Thu Jun 27 00:52:58 2013 From: andreas at schachtner.eu (Andreas Schachtner) Date: Thu, 27 Jun 2013 00:52:58 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs Message-ID: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> Sanity checking upon submitting to the DB could prevent this. My 2c, Andreas Schachtner Send via mobile device. Please excuse brevity, typos and the funny spelling checker in particular. Gert Doering schrieb: >Hi, > >On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote: >> Actually I don't really understand the problem. If the ASN is >> back in the pool, this reads for me "it shall no longer appear in >> the routing table". This includes for me that any object referencing >> this ASN is illegal by definition. So these illegal objects may not >> exist and *must* be removed asap from the DB. After removing all >> illegal objects, they should stay in some "grace-period" - let's >> say 3 month - and then there should be no problem reallocating the >> asn. > >The database currently has no mechanics to prevent someone from entering >an import/export line that says: > > aut-num: AS100000 > remarks: have fun with Jens > export: to AS5539 announce AS48200 > >which is exactly that sort of reference that would currently keep the >NCC from reallocating AS48200 (assuming that one were free). > >Auto-cleaning the route: objects still referencing AS48200 is fairly >easy, but auto-cleaning export/import policies and AS-SET objects is >harder, especially as people might have the aut-num: object in question >on file, just change stuff locally, and then re-send it when they have >changes, overriding the cleaned-up object in the database... > >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 (89) 32356-444 USt-IdNr.: DE813185279 From john.crain at icann.org Wed Jun 26 15:31:32 2013 From: john.crain at icann.org (John L. Crain) Date: Wed, 26 Jun 2013 06:31:32 -0700 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <7C49C19C69319E4FB1279CA15A84D18B61DBA921@SAX20244.bia.abraxas.ch> <51CAB392.3030809@CC.UniVie.ac.at> Message-ID: <2EED3B67-05C2-4B62-87B0-9CCAD55E05DC@icann.org> +1 I'm a little baffled as to why anyone would choose to hasten this at the cost of giving adequate notice? If we followed Randy's proposal to the letter we are still talking about being able to reuse AS# in roughly three months after policy is agreed. That seems fast enough to me, if not a little too fast :) John Sent from my iPad On Jun 26, 2013, at 3:07 AM, "Richard Hartmann" > wrote: On Jun 26, 2013 11:25 AM, "Wilfried Woeber" > wrote: > > In general I support the recycling of AS #s, > but for operational and consistency reasons I'd be a bit more careful... There is no shortage of ASn so we have the luxury of being able to be _very_ careful. Even after an ASn had been reclaimed we can easily wait a significant period of time before recycling them. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey at trifle.net Wed Jun 26 19:50:29 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Wed, 26 Jun 2013 20:50:29 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> Message-ID: <51CB29E5.8090008@trifle.net> Randy Bush wrote: >> If the ASN is already returned to the pool, it means that the RIPE had >> tried to communicate with the resource holder at least three times >> during at least 3 month. >> > > the resource holder of a route: object owns the ip space, not > necessarily the asn. > Actually, he owns nothing. He holds. Nevertheless, how does it correlates with reassigning of ASNs and removing references to it? If the resource holder doesn't hold AS number - he shouldn't use it. If he shouldn't use it - any reference to object that doesn't hold by any End User may be (and should be) deleted for the future reassigning. I saw no information inside proposal to remove the objects that referenced to deleted ASN - it's just removing a broken references inside those objects. So, deleting of the broken references is the way to provide integrity to RIPE's database - nothing additional. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From andrey at trifle.net Thu Jun 27 08:43:50 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 09:43:50 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C5F1A6597@E2010-MBX03.exchange2010.nl> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <862A73D42343AE49B2FC3C32FDDFE91C5F1A6597@E2010-MBX03.exchange2010.nl> Message-ID: <51CBDF26.8010400@trifle.net> Hi, Erik On 06/26/13 23:16, Erik Bais wrote: > However ... there might be situations where someone would be using a certain BGP community in RPLS for internal reference still while the actual AS number isn't used anymore. Any reference to the returned ASN that do not affect to the routing by itself should not prevent RIPE from reassigning this ASN. No one will prevent End User from placing some references inside his objects to ASNs that wasn't assigned ever. It's not the reason to not assign these ASNs. I think that some validation should be used even for import/export entries and RIPE's database should prevent End User from updating objects with erroneous information. In this case any existing reference inside object to the ASNs that are not assigned (or ASN that were returned to the pool) will make object that is referenced to them non up-to-date and notification may be sent to the resource holder. But my opinion that all references to unassigned objects should be removed by RIPE's software with notification message to the resource holder's contacts. We shouldn't wait any actions from anybody to reassign the resources. As long we talking about RIPE database all similar references may be found by the RIPE's software. Those references may be removed and the resource holders may be notified about this situations. I don't think that it's the problem - multiple regular expressions will do this work for us. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From andrey at trifle.net Thu Jun 27 08:51:56 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 09:51:56 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> Message-ID: <51CBE10C.6070309@trifle.net> On 06/27/13 01:52, Andreas Schachtner wrote: > Sanity checking upon submitting to the DB could prevent this. And it's the main problem that we should talk. But not about removing some references to the objects that doesn't exists The lack of sanity check for the corresponding fields during database updates - is the root of the problem. +1 > Auto-cleaning the route: objects still referencing AS48200 is fairly > easy, but auto-cleaning export/import policies and AS-SET objects is > harder, especially as people might have the aut-num: object in > question on file, just change stuff locally, and then re-send it when > they have changes, overriding the cleaned-up object in the database... -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.ne From gert at space.net Thu Jun 27 09:59:26 2013 From: gert at space.net (Gert Doering) Date: Thu, 27 Jun 2013 09:59:26 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CBE10C.6070309@trifle.net> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> <51CBE10C.6070309@trifle.net> Message-ID: <20130627075926.GU2706@Space.Net> Hi, On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote: > On 06/27/13 01:52, Andreas Schachtner wrote: > > Sanity checking upon submitting to the DB could prevent this. > > And it's the main problem that we should talk. But not about removing > some references to the objects that doesn't exists > The lack of sanity check for the corresponding fields during database > updates - is the root of the problem. It's not the *root* of the problem, but just one aspect (when the AS number is returned, all references to it are perfectly fine, up to that point) - and even then, you can't really solve the whole issue with technical means. Consider this: AS X is returned AS Y references it, database object is changed by NCC to remove reference to X AS X is reassigned to someone else AS Y sends an update to it's aut-num: object, restoring the reference to X now what - is this "illegal" because it's "an old reference", or should this be permitted, because it's really referencing to "the new holder of X"? (we can't know, so technical "blocking" of references to X will do the wrong thing in half the cases...) So, speaking as router admin, my preference is to - inform holders of objects with dangling references (admin-c, tech-c) - if nothing changes in, say, two weeks, inform LIR contacts as well - two weeks later, if the object is still referencing stale ASes, change object in DB, and again inform admin-c, tech-c, LIR contact - reassign the no longer referenced AS (speaking for myself and my routers, not speaking as WG chair) Gert Doering -- Operator -- 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripe at opteamax.de Thu Jun 27 10:11:27 2013 From: ripe at opteamax.de (Opteamax GmbH - RIPE-Team) Date: Thu, 27 Jun 2013 10:11:27 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130627075926.GU2706@Space.Net> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> <51CBE10C.6070309@trifle.net> <20130627075926.GU2706@Space.Net> Message-ID: <8c650319-8218-46c0-b415-1b8eaa787903@email.android.com> Gert Doering schrieb: >Hi, > >On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote: >> On 06/27/13 01:52, Andreas Schachtner wrote: >> > Sanity checking upon submitting to the DB could prevent this. >> >> And it's the main problem that we should talk. But not about removing > >> some references to the objects that doesn't exists >> The lack of sanity check for the corresponding fields during database > >> updates - is the root of the problem. > >It's not the *root* of the problem, but just one aspect (when the AS >number >is returned, all references to it are perfectly fine, up to that point) >- >and even then, you can't really solve the whole issue with technical >means. > >Consider this: > >AS X is returned >AS Y references it, database object is changed by NCC to remove >reference to X > >AS X is reassigned to someone else >AS Y sends an update to it's aut-num: object, restoring the reference >to X > >now what - is this "illegal" because it's "an old reference", or should >this be permitted, because it's really referencing to "the new holder >of X"? >(we can't know, so technical "blocking" of references to X will do the >wrong thing in half the cases...) > The sanity check could and should check if the inverse exists. And any import in aut-num X for asn Y that has no export in aut-num Y within 2 days has to be treated as illegal and removed, notifying the holder. And as some people only react when it hurts, I would even charge the removal if it happens more than once ... Also exports/imports as for example seen in aut-num 3320 (from any import any; to any export any) should be treated as illegal! Jens >So, speaking as router admin, my preference is to > > - inform holders of objects with dangling references (admin-c, tech-c) > - if nothing changes in, say, two weeks, inform LIR contacts as well >- two weeks later, if the object is still referencing stale ASes, >change > object in DB, and again inform admin-c, tech-c, LIR contact > > - reassign the no longer referenced AS > >(speaking for myself and my routers, not speaking as WG chair) > >Gert Doering > -- Operator -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel. +49 2224 969500 Email: jo at opteamax.de HRB 23144, AG Montabaur -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Jun 27 10:15:32 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 27 Jun 2013 10:15:32 +0200 Subject: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space In-Reply-To: <7C49C19C69319E4FB1279CA15A84D18B61DBA9E3@SAX20244.bia.abraxas.ch> References: <7C49C19C69319E4FB1279CA15A84D18B61DBA94B@SAX20244.bia.abraxas.ch> <20130626104215.GD2706@Space.Net> <7C49C19C69319E4FB1279CA15A84D18B61DBA9E3@SAX20244.bia.abraxas.ch> Message-ID: <44ECF94F-EF49-4EBB-B946-050186B6C0F6@steffann.nl> Hi Olaf, > Okay, I agree with Gert's point of view. If community doesn't see any problem with guidance request, let's do it. > > It would be nice if Address Policy WG could continue with the idea about removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Are there any plans? Plans: definitely! Time: not enough, looking for volunteers :-) Cheers, Sander From andrey at trifle.net Thu Jun 27 10:53:46 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 11:53:46 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130627075926.GU2706@Space.Net> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> <51CBE10C.6070309@trifle.net> <20130627075926.GU2706@Space.Net> Message-ID: <51CBFD9A.1070700@trifle.net> On 06/27/13 10:59, Gert Doering wrote: > Hi, > > On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote: >> On 06/27/13 01:52, Andreas Schachtner wrote: >>> Sanity checking upon submitting to the DB could prevent this. >> And it's the main problem that we should talk. But not about removing >> some references to the objects that doesn't exists >> The lack of sanity check for the corresponding fields during database >> updates - is the root of the problem. > It's not the *root* of the problem, but just one aspect (when the AS number > is returned, all references to it are perfectly fine, up to that point) - > and even then, you can't really solve the whole issue with technical means. > > Consider this: > > AS X is returned > AS Y references it, database object is changed by NCC to remove reference to X > > AS X is reassigned to someone else > AS Y sends an update to it's aut-num: object, restoring the reference to X > > now what - is this "illegal" because it's "an old reference", or should > this be permitted, because it's really referencing to "the new holder of X"? Reference to any object is not the "old reference" or the "new reference" - it's the "the only one valid reference". Anytime End User that holds AS Y can add reference to AS Y. And it's not the problem of reassigning ASNs: until this information is not checked by RIPE's software (for example - like adding origin field to the route object) - any user will can add reference to any ASN (but for the assigned ASNs only). It's the separate question: how to prevent users to add references to objects that shouldn't be referenced by this object. It may be done by checking cross-references from the referenced and referencing objects for example. But it's not the question to ASN reassignment process > So, speaking as router admin, my preference is to > > - inform holders of objects with dangling references (admin-c, tech-c) > - if nothing changes in, say, two weeks, inform LIR contacts as well > - two weeks later, if the object is still referencing stale ASes, change > object in DB, and again inform admin-c, tech-c, LIR contact > > - reassign the no longer referenced AS And your proposal is inconsistent with your example: the End User still can "restore reference to AS X inside AS Y object description during updating aut-num object" -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From gert at space.net Thu Jun 27 12:22:57 2013 From: gert at space.net (Gert Doering) Date: Thu, 27 Jun 2013 12:22:57 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CBFD9A.1070700@trifle.net> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> <51CBE10C.6070309@trifle.net> <20130627075926.GU2706@Space.Net> <51CBFD9A.1070700@trifle.net> Message-ID: <20130627102257.GV2706@Space.Net> Hi, On Thu, Jun 27, 2013 at 11:53:46AM +0300, Andrey Semenchuk wrote: > > So, speaking as router admin, my preference is to > > > > - inform holders of objects with dangling references (admin-c, tech-c) > > - if nothing changes in, say, two weeks, inform LIR contacts as well > > - two weeks later, if the object is still referencing stale ASes, change > > object in DB, and again inform admin-c, tech-c, LIR contact > > > > - reassign the no longer referenced AS > > And your proposal is inconsistent with your example: the End User still > can "restore reference to AS X inside AS Y object description during > updating aut-num object" Indeed. I want a light-weight process that can be implemented while it's still relevant (aka "we still have 16 bit ASNs to worry about"). The more heavyweight "full database consistency cross-check, including references to AS numbers that are not from the RIPE region(!)" needs to very carefully considered - if we make it too complicated to register policy, people will just stop doing so, and what have we gained then? Gert Doering -- Operator -- 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Thu Jun 27 12:42:35 2013 From: gert at space.net (Gert Doering) Date: Thu, 27 Jun 2013 12:42:35 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CB29E5.8090008@trifle.net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <51CB29E5.8090008@trifle.net> Message-ID: <20130627104235.GW2706@Space.Net> Hi, On Wed, Jun 26, 2013 at 08:50:29PM +0300, Andrey Semenchuk wrote: > I saw no information inside proposal to remove the objects that > referenced to deleted ASN - it's just removing a broken references > inside those objects. So, deleting of the broken references is the way > to provide integrity to RIPE's database - nothing additional. You can't remove the reference to an ASN from a route:/route6: object - you have to remove the whole object. Gert Doering -- Operator -- 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From andrey at trifle.net Thu Jun 27 13:39:26 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 14:39:26 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130627104235.GW2706@Space.Net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <51CB29E5.8090008@trifle.net> <20130627104235.GW2706@Space.Net> Message-ID: <51CC246E.2050603@trifle.net> On 06/27/13 13:42, Gert Doering wrote: > On Wed, Jun 26, 2013 at 08:50:29PM +0300, Andrey Semenchuk wrote: >> I saw no information inside proposal to remove the objects that >> referenced to deleted ASN - it's just removing a broken references >> inside those objects. So, deleting of the broken references is the way >> to provide integrity to RIPE's database - nothing additional. > You can't remove the reference to an ASN from a route:/route6: object - you > have to remove the whole object. let me to correct myself: "I saw no information inside proposal to remove the *resource* objects that referenced to deleted ASN". Any route object is illegal since the ASN does not exists. As it seems to me, there're two solutions: - to delete illegal resource; - to replace reference inside those objects to the placeholder ASN The first solution is more correct RFC1786: ========= The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. ========= RIPE-252: ========= 1.2.16 route ... The "route:" attribute is the address prefix of the route and the "origin:" attribute is the AS number of the AS that originates the route into the interAS routing system. ... ========= No ASN - no route object. -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey at trifle.net Thu Jun 27 13:50:41 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 14:50:41 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <20130627102257.GV2706@Space.Net> References: <6qqpcnpr2gd94kowwo5grw6v.1372287178428@email.android.com> <51CBE10C.6070309@trifle.net> <20130627075926.GU2706@Space.Net> <51CBFD9A.1070700@trifle.net> <20130627102257.GV2706@Space.Net> Message-ID: <51CC2711.1070804@trifle.net> On 06/27/13 13:22, Gert Doering wrote: > Indeed. I want a light-weight process that can be implemented while > it's still relevant (aka "we still have 16 bit ASNs to worry about"). If ASN assigned by RIPE and used by the End User according with RIPE's policy - it's nothing to worry about. If ASN returned to the pool - it's nothing to worry about too: we can't worry about something that does not exists (ASN does not assigned). > The more heavyweight "full database consistency cross-check, including > references to AS numbers that are not from the RIPE region(!)" needs > to very carefully considered - if we make it too complicated to > register policy, people will just stop doing so, and what have we > gained then? And this part of your opinion I fully support - we shouldn't make any complicated solutions for the simple task: If the ASN assigned - the ASN holder may use it. If the ASN does not assigned (or was assigned but was returned to the pool) - any reference that violates this should be deleted. And it's not the RIPE or community problem -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From gert at space.net Thu Jun 27 14:42:17 2013 From: gert at space.net (Gert Doering) Date: Thu, 27 Jun 2013 14:42:17 +0200 Subject: [address-policy-wg] PA/PI unification IPv6 Address Space In-Reply-To: References: <20130626124403.GI2706@Space.Net> Message-ID: <20130627124217.GE2706@Space.Net> Hi, On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote: > > [PA/PI unification proposal] > > > For IPv6, it's still sitting on my lap, and I need to restart the process - > > thanks for the reminder. > > Just let us know if you need volonteers or cheering. Since Sander already mentioned it, I now need to write down what I had in mind :-) The original proposal (text appended below) received quite positive feedback, so I think we want to go ahead with that. What is necessary next is to actually write this up in the form of a RIPE policy document - and since the secondary effects of this change are quite radical, I think it leads to "write a new policy document for the new IPv6 address policy in RIPE, after that change, taking into account most of the questions that have come up" (like: what are the rules for a LIR to receive multiple "blocks of addresses"?). I can't seem to find enough "undisturbed time" to actually get going with this, so my idea was to form a *small* editorial team, maybe 3-5 people, who would work together with Sander, me and Emilio to write this new policy document (you write, we review :) ), and if we all agree that "yes, this is good!" it will be presented as a formal policy proposal to the WG, possibly leading to further tweaks of the text. The group writing this should be people that have had first-hand experience with address requests, customer confusion about PA and PI, with the RIPE policy process - and who have nerves of steel, to actually fight for it in the ensueing arguments on the list... So... volunteers? :-) Gert Doering -- APWG chair ---------------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: - base cost per year per LIR - yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From stolpe at resilans.se Thu Jun 27 14:56:09 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 27 Jun 2013 14:56:09 +0200 (CEST) Subject: [address-policy-wg] PA/PI unification IPv6 Address Space In-Reply-To: <20130627124217.GE2706@Space.Net> References: <20130626124403.GI2706@Space.Net> <20130627124217.GE2706@Space.Net> Message-ID: Hi Gert, I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. Hand up. On Thu, 27 Jun 2013, Gert Doering wrote: > Hi, > > On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote: >>> [PA/PI unification proposal] >> >>> For IPv6, it's still sitting on my lap, and I need to restart the process - >>> thanks for the reminder. >> >> Just let us know if you need volonteers or cheering. > > Since Sander already mentioned it, I now need to write down what I had in > mind :-) > > The original proposal (text appended below) received quite positive feedback, > so I think we want to go ahead with that. > > What is necessary next is to actually write this up in the form of a RIPE > policy document - and since the secondary effects of this change are > quite radical, I think it leads to "write a new policy document for the > new IPv6 address policy in RIPE, after that change, taking into account > most of the questions that have come up" (like: what are the rules for > a LIR to receive multiple "blocks of addresses"?). > > I can't seem to find enough "undisturbed time" to actually get going with > this, so my idea was to form a *small* editorial team, maybe 3-5 people, > who would work together with Sander, me and Emilio to write this new > policy document (you write, we review :) ), and if we all agree that > "yes, this is good!" it will be presented as a formal policy proposal > to the WG, possibly leading to further tweaks of the text. > > The group writing this should be people that have had first-hand experience > with address requests, customer confusion about PA and PI, with the RIPE > policy process - and who have nerves of steel, to actually fight for it > in the ensueing arguments on the list... > > > So... volunteers? :-) > > Gert Doering > -- APWG chair > > ---------------------------------------------------------------------- > Motivation: why? > ---------------- > - PA and PI are just different labels for "IPv6 addresses" > ... but with different strings attached: > - PI must not be used for 3rd party assignments (problem for hosting > providers) > - only single PA allocation for LIRs possible, even if multiple > independent networks exist > - network structure and operation is very different these days than > at the time where the PA/PI distinction was made. The boundaries between > networks, different operators and different services are not as clear > as they used to be... > - the classic distinction > "PA is for ISPs and their access customers" > "PI is for enterprises that do not do ISP-like business" > has been overcome by reality, and there are no longer clear borders between > "ISP", "enterprise" and "end-customer" networks > > - Network addresses are for *numbering network devices*. Limiting what > someone is allowed to do with certain addresses creates confusion. > Constantly having to tweak policy to work around this is the wrong > solution. > > > Goals and Caveats > ----------------- > - encourage IPv6 deployment > - be flexible enough to accommodate both typical and non-typical network- > and business models > - do not encourage assignment of /64 or single addresses to end users > - do not encourage excessive routing table growth > - encourage proper documentation and discourage lying to the RIPE NCC to > wiggle around policy restrictions > > > The Proposal > ------------ > - abandon distinction between PA (allocation) and PI (assignment) > - everything is just "numbers" > - RIPE NCC hands out "block(s) of numbers" to "users of numbers" > - see below for answers on the fine print... > > > Who get's address space? > ------------------------ > - existing model is kept: LIRs as distribution point for address space > - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" > - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 > - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) > > > Amount of space per "block of numbers"? > --------------------------------------- > - /48 (or larger with justification) by default > - /32.../29 (or larger with justification) allowed when planning to > assign to 3rd parties > - multiple "blocks of numbers" to or via a single LIR allowed and expected > to be a frequently seen usage case > > > Allocation from well-known ranges for anything that people might want to > treat specially in their routing policy (former "special case" and PI > policies): > - IXP > - Root DNS > - Anycast DNS > - /33.../48 blocks > > > Cost? > ----- > - determined by AGM, but we can discuss models here and provide > recommendations to AGM and NCC board, e.g.: > - base cost per year per LIR > - yearly recurring cost "per block of numbers", independent of size(!), > reflecting the cost of handling the address space request, documentation, > RIPE database, etc., which increase if you need "many blocks" > > > Multiple blocks per LIR? > ------------------------ > - since there would no longer be any difference between PA and PI, "more > than one block going to a single LIR" would be a typical case - so it > needs to be permitted > - "get any number of blocks that people are asking for" is not likely to > get consensus due to pressure on the routing system > - proposal for compromise: > ``one "block of numbers" per "network"'' > - needs workable definition for "network": > - interconnected network > - operated by the same entity > - operated as a layer 3 network > - be flexible in allowing multiple blocks, but don't *require* anyone > to actually ask for multiple number blocks if they are happy with > using the same address block for multiple networks/sites/... > > - problem cases to keep in mind, leading to this definition > - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure > - single LIRs providing addresses to two independent Layer 3 networks > that are not directly connected - e.g. due to political > (commercial/NREN), legal or geographical reasons > - "classical PI" type connections - end users with independent numbers > - Multiple L3 providers providing address space to a single user must > be allowed (multi-homing, special-purpose networks, etc.) > > -- > 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 (89) 32356-444 USt-IdNr.: DE813185279 > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From Olaf.Sonderegger at abraxas.ch Thu Jun 27 16:32:06 2013 From: Olaf.Sonderegger at abraxas.ch (Sonderegger Olaf ABRAXAS INFORMATIK AG) Date: Thu, 27 Jun 2013 14:32:06 +0000 Subject: [address-policy-wg] PA/PI unification IPv6 Address Space In-Reply-To: References: <20130626124403.GI2706@Space.Net> <20130627124217.GE2706@Space.Net> Message-ID: <7C49C19C69319E4FB1279CA15A84D18B61DBAF92@SAX20244.bia.abraxas.ch> Hi Daniel, Hi Gert, Hi Sander I have same experience level as Daniel, but I will support you as much as I can. Do you have any collaboration platform to write together this policy? Or how do you normally start? Olaf -----Original Message----- From: Daniel Stolpe [mailto:stolpe at resilans.se] Sent: Donnerstag, 27. Juni 2013 14:56 To: Gert Doering Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PA/PI unification IPv6 Address Space Hi Gert, I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. Hand up. On Thu, 27 Jun 2013, Gert Doering wrote: > Hi, > > On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote: >>> [PA/PI unification proposal] >> >>> For IPv6, it's still sitting on my lap, and I need to restart the >>> process - thanks for the reminder. >> >> Just let us know if you need volonteers or cheering. > > Since Sander already mentioned it, I now need to write down what I had > in mind :-) > > The original proposal (text appended below) received quite positive > feedback, so I think we want to go ahead with that. > > What is necessary next is to actually write this up in the form of a > RIPE policy document - and since the secondary effects of this change > are quite radical, I think it leads to "write a new policy document > for the new IPv6 address policy in RIPE, after that change, taking > into account most of the questions that have come up" (like: what are > the rules for a LIR to receive multiple "blocks of addresses"?). > > I can't seem to find enough "undisturbed time" to actually get going > with this, so my idea was to form a *small* editorial team, maybe 3-5 > people, who would work together with Sander, me and Emilio to write > this new policy document (you write, we review :) ), and if we all > agree that "yes, this is good!" it will be presented as a formal > policy proposal to the WG, possibly leading to further tweaks of the text. > > The group writing this should be people that have had first-hand > experience with address requests, customer confusion about PA and PI, > with the RIPE policy process - and who have nerves of steel, to > actually fight for it in the ensueing arguments on the list... > > > So... volunteers? :-) > > Gert Doering > -- APWG chair > > ---------------------------------------------------------------------- > Motivation: why? > ---------------- > - PA and PI are just different labels for "IPv6 addresses" > ... but with different strings attached: > - PI must not be used for 3rd party assignments (problem for hosting > providers) > - only single PA allocation for LIRs possible, even if multiple > independent networks exist > - network structure and operation is very different these days than > at the time where the PA/PI distinction was made. The boundaries > between networks, different operators and different services are not > as clear as they used to be... > - the classic distinction > "PA is for ISPs and their access customers" > "PI is for enterprises that do not do ISP-like business" > has been overcome by reality, and there are no longer clear borders > between "ISP", "enterprise" and "end-customer" networks > > - Network addresses are for *numbering network devices*. Limiting what > someone is allowed to do with certain addresses creates confusion. > Constantly having to tweak policy to work around this is the wrong > solution. > > > Goals and Caveats > ----------------- > - encourage IPv6 deployment > - be flexible enough to accommodate both typical and non-typical > network- and business models > - do not encourage assignment of /64 or single addresses to end users > - do not encourage excessive routing table growth > - encourage proper documentation and discourage lying to the RIPE NCC > to wiggle around policy restrictions > > > The Proposal > ------------ > - abandon distinction between PA (allocation) and PI (assignment) > - everything is just "numbers" > - RIPE NCC hands out "block(s) of numbers" to "users of numbers" > - see below for answers on the fine print... > > > Who get's address space? > ------------------------ > - existing model is kept: LIRs as distribution point for address space > - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" > - or via the LIR to "the entity that wants to use the space and take > responsibility for it" (sponsoring LIR), keeping the contractual > requirements of 2007-01 > - "Direct Assignment Users" members could still be possible, but > "every NCC member is an LIR" would simplify things further (see > "Costs" section) > > > Amount of space per "block of numbers"? > --------------------------------------- > - /48 (or larger with justification) by default > - /32.../29 (or larger with justification) allowed when planning to > assign to 3rd parties > - multiple "blocks of numbers" to or via a single LIR allowed and > expected to be a frequently seen usage case > > > Allocation from well-known ranges for anything that people might want > to treat specially in their routing policy (former "special case" and > PI > policies): > - IXP > - Root DNS > - Anycast DNS > - /33.../48 blocks > > > Cost? > ----- > - determined by AGM, but we can discuss models here and provide > recommendations to AGM and NCC board, e.g.: > - base cost per year per LIR > - yearly recurring cost "per block of numbers", independent of > size(!), reflecting the cost of handling the address space request, > documentation, RIPE database, etc., which increase if you need "many blocks" > > > Multiple blocks per LIR? > ------------------------ > - since there would no longer be any difference between PA and PI, > "more than one block going to a single LIR" would be a typical case - > so it needs to be permitted > - "get any number of blocks that people are asking for" is not likely > to get consensus due to pressure on the routing system > - proposal for compromise: > ``one "block of numbers" per "network"'' > - needs workable definition for "network": > - interconnected network > - operated by the same entity > - operated as a layer 3 network > - be flexible in allowing multiple blocks, but don't *require* anyone > to actually ask for multiple number blocks if they are happy with > using the same address block for multiple networks/sites/... > > - problem cases to keep in mind, leading to this definition > - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure > - single LIRs providing addresses to two independent Layer 3 networks > that are not directly connected - e.g. due to political > (commercial/NREN), legal or geographical reasons > - "classical PI" type connections - end users with independent numbers > - Multiple L3 providers providing address space to a single user must > be allowed (multi-homing, special-purpose networks, etc.) > > -- > 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 (89) 32356-444 USt-IdNr.: DE813185279 > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From andrey at trifle.net Thu Jun 27 17:26:29 2013 From: andrey at trifle.net (Andrey Semenchuk) Date: Thu, 27 Jun 2013 18:26:29 +0300 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <51CC246E.2050603@trifle.net> References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> <51CACE2F.7050406@trifle.net> <51CB29E5.8090008@trifle.net> <20130627104235.GW2706@Space.Net> <51CC246E.2050603@trifle.net> Message-ID: <51CC59A5.3090800@trifle.net> > let me to correct myself: "I saw no information inside proposal to > remove the *resource* objects that > referenced to deleted ASN". Any route object is illegal since the ASN > does not exists. > As it seems to me, there're two solutions: > - to delete illegal resource; Sorry, my fault: to delete illegal object (route, route6, as-set etc). All resourse objects should not be deleted. But may be cleared of references to non-existent ASNs (import/export policy for example) -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net From kurtis at kurtis.pp.se Fri Jun 28 11:38:31 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Fri, 28 Jun 2013 11:38:31 +0200 Subject: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: References: <51C994DD.1040005@ripe.net> <51C9BBA2.8030806@inex.ie> Message-ID: On 25 jun 2013, at 17:51, Randy Bush wrote: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. Seems like a reasonable approach to me. Best regards, - kurtis - From kurtis at kurtis.pp.se Fri Jun 28 11:40:59 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Fri, 28 Jun 2013 11:40:59 +0200 Subject: [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs In-Reply-To: <004801ce72a6$1d32d010$57987030$@a2b-internet.com> References: <51C994DD.1040005@ripe.net> <004801ce72a6$1d32d010$57987030$@a2b-internet.com> Message-ID: <8386C119-F5D9-4A38-A9C1-CFAFE9A8ECBD@kurtis.pp.se> On 26 jun 2013, at 21:48, Erik Bais wrote: > The idea of cleaning the RIPE db is noble and we should do that, however > there are also other locations where those AS numbers are referenced.. ( > PeeringDB or RADB comes to mind..) RADB contains so much garbage that I think best would be for people to stop using it....YMMV > Are we going to provide them with the list of current returned AS numbers to > make sure they can also do their housekeeping ? I think that publishing lists on ASNs in each stage in Randy's proposal for example would be prudent... Best regards, - kurtis -