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: [ncc-services-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 emadaio at ripe.net Mon Jun 3 15:17:01 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 03 Jun 2013 15:17:01 +0200 Subject: [ncc-services-wg] 2012-08 Review Period extended until 1 July 2013 (Publication of Sponsoring LIR for Independent Number Resources) Message-ID: Dear Colleagues, The Review Period for the proposal 2012-08, "Publication of Sponsoring LIR for Independent Number Resources", has been extended until 1 July 2013. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-08 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Mon Jun 3 16:06:24 2013 From: gert at space.net (Gert Doering) Date: Mon, 3 Jun 2013 16:06:24 +0200 Subject: [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: <20130603140624.GK2504@Space.Net> Hi, On Mon, Jun 03, 2013 at 02:08:46PM +0200, Erik Bais wrote: > 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) Speaking as a router operator, I support this proposal. For services offered by the RIPE NCC, the history and colour of an IP prefix should not make a difference - so "PA", "PI" or "legacy" prefixes should be treated all the same. (If the community decides to abandon RPKI because of whatever reason, fine with me - but as long as the paying members have voted to keep the RPKI system running, it needs to work for all prefixes that the RIPE NCC feels authoritative to state "this person is entitled to decide who gets to route the prefix" - i.e. verified contract holders, LIRs, etc) Gert Doering -- internet 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 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: [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 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: [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 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: [ncc-services-wg] [address-policy-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 tore at fud.no Tue Jun 4 09:28:31 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 04 Jun 2013 09:28:31 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> References: <20130518132453.GA92411@cilantro.c4inet.net> <519A365B.3060304@fud.no> <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> Message-ID: <51AD971F.1020209@fud.no> * Erik Bais >> I've got one question though. What is the rationale for the requirement >> that ?the Internet resources reside within the RIPE NCC service region?? >> I don't see the reason for this. IMHO, any PI/legacy space >> issued/maintained by the RIPE NCC should be eligible for certification >> under this policy, no matter where on (or off!) the planet it's being > used. > > The intention is to provide the services for end-users / organizations > within the RIPE NCC service region. > That the resources itself are used outside the region can't and I think we > shouldn't want to restrict. > > I'll see how to rephrase that before the review. IMHO we should not restrict this to end users / organisations within the RIPE NCC service region, as it is legitimate for organisations located outside of the NCC's service region to hold address space registered in the RIPE NCC's registry. I think the natural scope of this policy would be all resources that are maintained in in the RIPE NCC's registry. So how about simply ?The Internet resources reside within the RIPE NCC registry?? Tore From andreas.larsen at ip-only.se Tue Jun 4 11:06:42 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 4 Jun 2013 11:06:42 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: <51AD971F.1020209@fud.no> Message-ID: I agree with Tore and Erik, enable all resources that are maintained within the region of RIPE not matter what the status of them are so +1. // 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-04 09:28 skrev Tore Anderson : >* Erik Bais > >>> I've got one question though. What is the rationale for the requirement >>> that ?the Internet resources reside within the RIPE NCC service >>>region?? >>> I don't see the reason for this. IMHO, any PI/legacy space >>> issued/maintained by the RIPE NCC should be eligible for certification >>> under this policy, no matter where on (or off!) the planet it's being >> used. >> >> The intention is to provide the services for end-users / organizations >> within the RIPE NCC service region. >> That the resources itself are used outside the region can't and I think >>we >> shouldn't want to restrict. >> >> I'll see how to rephrase that before the review. > >IMHO we should not restrict this to end users / organisations within the >RIPE NCC service region, as it is legitimate for organisations located >outside of the NCC's service region to hold address space registered in >the RIPE NCC's registry. > >I think the natural scope of this policy would be all resources that are >maintained in in the RIPE NCC's registry. > >So how about simply ?The Internet resources reside within the RIPE NCC >registry?? > >Tore > From ebais at a2b-internet.com Tue Jun 4 12:14:28 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 4 Jun 2013 12:14:28 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: <51AD971F.1020209@fud.no> References: <20130518132453.GA92411@cilantro.c4inet.net> <519A365B.3060304@fud.no> <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> <51AD971F.1020209@fud.no> Message-ID: <006d01ce610c$4c813100$e5839300$@a2b-internet.com> Hi Tore, >> I'll see how to rephrase that before the review. > IMHO we should not restrict this to end users / organisations within the > RIPE NCC service region, as it is legitimate for organisations located > outside of the NCC's service region to hold address space registered in > the RIPE NCC's registry. > I think the natural scope of this policy would be all resources that are > maintained in in the RIPE NCC's registry. > So how about simply ?The Internet resources reside within the RIPE NCC > registry?? That sounds usable to me Tore. Regards, Erik Bais From lists-ripe at c4inet.net Tue Jun 4 15:39:28 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 4 Jun 2013 14:39:28 +0100 Subject: [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: <20130603140624.GK2504@Space.Net> References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> <20130603140624.GK2504@Space.Net> Message-ID: <20130604133928.GA77478@cilantro.c4inet.net> On Mon, Jun 03, 2013 at 04:06:24PM +0200, Gert Doering wrote: >For services offered by the RIPE NCC, the history and colour of an IP >prefix should not make a difference - so "PA", "PI" or "legacy" prefixes >should be treated all the same. Logically, if there is no policy for PA space, there should be none for PI/legacy space. >(If the community decides to abandon RPKI because of whatever reason, The community *has* decided to abandon RPKI, at least where policy is concerned. rgds, Sascha Luck From roland at internetpolicyagency.com Thu Jun 6 15:11:35 2013 From: roland at internetpolicyagency.com (Roland Perry) Date: Thu, 6 Jun 2013 14:11:35 +0100 Subject: [ncc-services-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: In message , at 09:57:34 on Mon, 3 Jun 2013, Randy Bush writes >my routers do not know the difference between PI, PA, Legacy, or >whatever. i suspect that no one has routers which differentiate. It might happen one day, if only a subset are present in a database that your router has been programmed to check authentication against, or only a subset are accompanied by a digital signature that becomes "de rigueur" to have. -- Roland Perry From furry13 at gmail.com Thu Jun 6 15:54:44 2013 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 6 Jun 2013 23:54:44 +1000 Subject: [ncc-services-wg] [address-policy-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: On Mon, Jun 3, 2013 at 10:08 PM, 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. I support the proposal. Situation when 'all IP addresses are equal, but some addresses are more equal than others' does not make much sense to me. -- SY, Jen Linkova aka Furry From lists-ripe at c4inet.net Thu Jun 6 16:26:24 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 6 Jun 2013 15:26:24 +0100 Subject: [ncc-services-wg] [address-policy-wg] Resource Certification for non-RIPE NCC Members In-Reply-To: References: <00cb01ce6053$19c0c960$4d425c20$@a2b-internet.com> Message-ID: <20130606142624.GA87935@cilantro.c4inet.net> On Thu, Jun 06, 2013 at 11:54:44PM +1000, Jen Linkova wrote: > >I support the proposal. Situation when 'all IP addresses are equal, >but some addresses are more equal than others' does not make much >sense to me. Right now, there is no policy that allows for *any* resources to be (NCC-) signed. If this proposal passes, there will be a situation where there is a policy for PI/Legacy resources and *no policy* for PA resources. rgds, Sascha Luck 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: [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: [ncc-services-wg] [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: <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 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: [ncc-services-wg] [address-policy-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 ebais at a2b-internet.com Mon Jun 10 11:30:46 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 10 Jun 2013 11:30:46 +0200 Subject: [ncc-services-wg] [policy-announce] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: Message-ID: <009701ce65bd$301c7a00$90556e00$@a2b-internet.com> Hi, First of all, sorry for being a bit late to jump in on the proposal. https://www.ripe.net/ripe/policies/proposals/2012-07/draft I had a question on the procedures, when this proposal is accepted. Is it the intention of the RIPE NCC to go back to ALL legacy resource holders (including those that have signed the 'Legacy Space Agreement' or 'Agreement between Legacy Holder and LIR' ( see the downloads of the templates here : http://www.ripe.net/lir-services/resource-management/legacy-space ) to ask them if they would want to revert their decision and get their original LEGACY status back on their resources under this policy instead of the status: Allocated PA or Assigned PI? The reason why I ask this, as there might be original Legacy space holders who might think that the current proposal would be a better solution (fit) than the current implemented (signed) agreement. I noticed point 10 in the Executive Summary: 10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted. But does that include ALL Legacy resource holders even those that are not registered under a LIR? One of the other (small) points that I had some questions about is point 2 in the Executive summary: 2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests. Why would the RIPE NCC have to decline these requests? I also have a question on the topic A Understanding the policy: This policy proposal is meant to be applied by the RIPE NCC to Registration Services, as regards Legacy Internet Resources. > Legacy Internet Resources ? as defined in this proposal, are any Internet resources obtained prior to (or otherwise outside of) the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries (RIRs). While this definition is not limited to resources in the RIPE Registry, the RIPE NCC does not have authority over Legacy Internet Resources in other registries. If this proposal is accepted, the RIPE NCC will implement it only to Legacy Internet Resources that are currently registered in the RIPE Registry. If there are Legacy Internet Resources currently registered at ARIN for instance and a legitimate holder wants to have their resource registered in the RIPE registry, why would it not be available for those registrations? Regards, Erik Bais From niall.oreilly at ucd.ie Mon Jun 10 12:29:46 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 10 Jun 2013 11:29:46 +0100 Subject: [ncc-services-wg] [policy-announce] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <009701ce65bd$301c7a00$90556e00$@a2b-internet.com> References: <009701ce65bd$301c7a00$90556e00$@a2b-internet.com> Message-ID: On 10 Jun 2013, at 10:30, Erik Bais wrote: > Hi, > > First of all, sorry for being a bit late to jump in on the proposal. > > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > > I had a question on the procedures, when this proposal is accepted. Your questions seem to be based on the RIPE NCC's Impact Assessment, rather than on the actual text of the proposal. Because of this, I think it's better for me to leave it to the NCC to answer them rather than to jump in with reactions based on what I think they may have meant. I will make just one exception, where your question refers to a reaction from the NCC which pointed out a gap in the proposal. > One of the other (small) points that I had some questions about is point 2 > in the Executive summary: > > 2. The RIPE NCC often receives requests from Legacy Resource Holders > wanting their resources to be considered as space allocated by the RIPE NCC. > If this proposal is accepted, the RIPE NCC will have to decline these > requests. > > Why would the RIPE NCC have to decline these requests? As written, v3.0 of proposal 2012-07 didn't provide such an option, simply because the authors hadn't considered it. NCC read this as an obstacle to accepting such a request in future. The draft currently in preparation provides explicitly for this case, so that the obstacle should no longer arise. Thanks for asking, Erik. Niall O'Reilly From sbras at ripe.net Mon Jun 10 13:39:06 2013 From: sbras at ripe.net (Sandra Bras) Date: Mon, 10 Jun 2013 13:39:06 +0200 Subject: [ncc-services-wg] [Training] New E-Learning Videos: Role Object and Abuse-C Set up Message-ID: <834C13C5-FE40-4FD0-9A6E-37D6081C7503@ripe.net> [Apologies for duplicates] Dear colleagues, We are pleased to announce the launch of two new RIPE Database videos as part of our online training. The topics are: - Create a Role Object https://www.ripe.net/lir-services/training/e-learning/ripe-database/contact-information/create-a-role-object - Set up Abuse Contact Information https://www.ripe.net/lir-services/training/e-learning/ripe-database/contact-information/set-up-abuse-contact-information For more videos go to https://www.ripe.net/lir-services/training/e-learning. Stay tuned! We plan to announce more exciting E-Learning news in the coming months. RIPE NCC E-Learning Tutorials are a free service available to everyone. If you have any questions or comments, feel free to contact us at . Happy learning! Sandra Br?s E-Learning Project Manager -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2618 bytes Desc: not available URL: 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: [ncc-services-wg] [address-policy-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 Woeber at CC.UniVie.ac.at Mon Jun 10 15:12:13 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 10 Jun 2013 15:12:13 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: <5.1.1.6.2.20130510163237.0030a8a8@efes.iucc.ac.il> <44243C60-3918-4EE9-878F-D598A81E86E8@ucd.ie> Message-ID: <51B5D0AD.9060809@CC.UniVie.ac.at> Sander Steffann wrote: > Hi Randy, > > >>>>To what benefit would one receive to have the resource considered as >>>>space allocated by RIPE NCC? IMHO, with the *current* set of address transfer provisions, it would open the possibility to transfer (parts of) these addresses. >> Perhaps the RIPE NCC can provide some >>>>examples so we can understand this. >>> >>>+1 >> >>if such a case existed, would they not just become a member? But, to add another littel bit of Internet Archeology info here. I did establish our LIR in early 1993. Back then, there was no concept of PI and PA, yet. What we had was ISP-based LIRs, last-resort-LIRs on a per country basis, and in parallel, other mechanisms to obtain blocks of addresses[1]. Thus, initially, our allocation was "unlabelled" and with the introduction of this attribute, became status: "ALLOCATED UNSPECIFIED". As we were operating this LIR on the procedures of an ISP-based LIR, and thus "PA", eventually we asked/agreed with the NCC to change the status to "ALLOCATED PA" :-) Those were the times... ;-) > If I understand correctly they do become a member and have their legacy address > space re-labeled as PA space. > > NCC: please correct me if I'm wrong! > Sander What I want to achieve with this stuff: back then the world looked a tad different. There were no "service contracts", formal agreements or "terms and conditions" and a full paper trail. In particular for those resources obtained outside the framework of the NCC. IMHO, any attempt to "manage" eligibility for the registration services based on today's strict formalities, is going to give us grief - big time. Wilfried. [1] the only distinction back then (with "cc" as ISO3166 country codes) was the ? RegID: "cc"."isptag" for the ISP-based which later became the LIRs with PA, and ? RegID: "cc".ZZ were the last-resort, which were a precursor of PI stuff 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: [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: <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 natalia.perez at i-systems.es Tue Jun 11 12:00:06 2013 From: natalia.perez at i-systems.es (Natalia Perez Salamanca) Date: Tue, 11 Jun 2013 12:00:06 +0200 Subject: [ncc-services-wg] Ausente de la Oficina Message-ID: <11306111200.AA2786740229@correo.i-systems.es> Estar? fuera de la oficina hasta el pr?ximo dia 17 de Junio de 2013. Si tienen alguna consulta urgente ponganse en contacto con nosotros en el tel?fono 917895800 o mande su mensaje a administracion at i-systems.es. Gracias Un saludo, Natalia Perez Salamanca From maildanrl at gmail.com Wed Jun 12 10:47:52 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Wed, 12 Jun 2013 10:47:52 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: <006d01ce610c$4c813100$e5839300$@a2b-internet.com> References: <20130518132453.GA92411@cilantro.c4inet.net> <519A365B.3060304@fud.no> <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> <51AD971F.1020209@fud.no> <006d01ce610c$4c813100$e5839300$@a2b-internet.com> Message-ID: Sander wrote: > Yes, securing routing is desperately needed. I totally agree! For this reason alone I support any proposal that gives me as PI holder the chance to sign my routes. +1 Tore wrote: > So how about simply ?The Internet resources reside within the RIPE NCC > registry?? I support that too. Tores off-planet argument made me thinking about pictures I've seen from the international space station. Whose region are they in anywhere? They probably change reagions multiple times a day. Best regards Dan -- Dan Luedtke http://www.danrl.de 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: [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: [ncc-services-wg] [address-policy-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 andrea at ripe.net Wed Jun 12 11:11:39 2013 From: andrea at ripe.net (Andrea Cima) Date: Wed, 12 Jun 2013 11:11:39 +0200 Subject: [ncc-services-wg] [policy-announce] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <009701ce65bd$301c7a00$90556e00$@a2b-internet.com> References: <009701ce65bd$301c7a00$90556e00$@a2b-internet.com> Message-ID: <51B83B4B.6090501@ripe.net> Hi Erik, On 6/10/13 11:30 AM, Erik Bais wrote: > Hi, > > First of all, sorry for being a bit late to jump in on the proposal. > > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > > I had a question on the procedures, when this proposal is accepted. > > Is it the intention of the RIPE NCC to go back to ALL legacy resource > holders (including those that have signed the 'Legacy Space Agreement' or > 'Agreement between Legacy Holder and LIR' ( see the downloads of the > templates here : > http://www.ripe.net/lir-services/resource-management/legacy-space ) to ask > them if they would want to revert their decision and get their original > LEGACY status back on their resources under this policy instead of the > status: Allocated PA or Assigned PI? > > The reason why I ask this, as there might be original Legacy space holders > who might think that the current proposal would be a better solution (fit) > than the current implemented (signed) agreement. > > I noticed point 10 in the Executive Summary: > > 10. If the proposal is accepted, the RIPE NCC will have to contact > Legacy Resource Holders that have their resources registered under the > umbrella of an LIR and offer them the contractual options of the accepted > proposal. The RIPE NCC will consider any requests for this since 1992 as > having never been submitted. > > But does that include ALL Legacy resource holders even those that are not > registered under a LIR? If this policy reaches consensus the RIPE NCC will contact legacy resource holders that over time have either: - registered their address space with an LIR; and/or - signed one of the agreements mentioned above in order to inform them that those agreements and registrations will be considered as never having been submitted and offer them the options listed in the accepted policy. Furthermore the RIPE NCC will send an email to the contacts registered in all other legacy resource RIPE Database objects, informing them about the options listed in the accepted policy. > One of the other (small) points that I had some questions about is point 2 > in the Executive summary: > > 2. The RIPE NCC often receives requests from Legacy Resource Holders > wanting their resources to be considered as space allocated by the RIPE NCC. > If this proposal is accepted, the RIPE NCC will have to decline these > requests. > > Why would the RIPE NCC have to decline these requests? I believe that Niall has already addressed this question. > I also have a question on the topic A Understanding the policy: > > This policy proposal is meant to be applied by the RIPE NCC to Registration > Services, as regards Legacy Internet Resources. > > > Legacy Internet Resources ? as defined in this proposal, are > any Internet resources obtained prior to (or otherwise outside of) the > current system of hierarchical distribution (by allocation or assignment) > through the Regional Internet Registries (RIRs). While this definition is > not limited to resources in the RIPE Registry, the RIPE NCC does not have > authority over Legacy Internet Resources in other registries. If this > proposal is accepted, the RIPE NCC will implement it only to Legacy Internet > Resources that are currently registered in the RIPE Registry. > > If there are Legacy Internet Resources currently registered at ARIN for > instance and a legitimate holder wants to have their resource registered in > the RIPE registry, why would it not be available for those registrations? 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. I hope this clarifies. Best regards, Andrea Cima RIPE NCC > Regards, > Erik Bais > > > > > > > From millnert at gmail.com Wed Jun 12 14:02:11 2013 From: millnert at gmail.com (Martin Millnert) Date: Wed, 12 Jun 2013 14:02:11 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: References: <20130518132453.GA92411@cilantro.c4inet.net> <519A365B.3060304@fud.no> <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> <51AD971F.1020209@fud.no> <006d01ce610c$4c813100$e5839300$@a2b-internet.com> Message-ID: Hi, On 12 jun 2013, at 10:47, Dan Luedtke wrote: > Sander wrote: >> Yes, securing routing is desperately needed. > I totally agree! For this reason alone I support any proposal that > gives me as PI holder the chance to sign my routes. > +1 Signing contracts without reading fine print is risky.. > Tore wrote: >> So how about simply ?The Internet resources reside within the RIPE NCC >> registry?? > I support that too. Tores off-planet argument made me thinking about > pictures I've seen from the international space station. Whose region > are they in anywhere? They probably change reagions multiple times a > day. Pretty sure they are using dark space. ;) Near earth communication could just random RIR based on dice or whatever. Geographic place of origin isn't all that important to RIR membership, is it? [1] For deep space communication, IP and especially TCP doesn't work so well. [2] Instead, DTN, with a more purposeful Bundle Protocol is used instead. [3, 4] Guess Vint knows more :) I'd like this to work, because either the good or the bad people should get off this planet. (I'd like to think the good are many more, so perhaps best if the bad ones just leave :) ) Best, Martin [1] http://tools.ietf.org/html/rfc5522 [2] http://en.wikipedia.org/wiki/Interplanetary_Internet [3] http://www.mitre.org/work/tech_papers/2010/09_5229/09_5229.pdf [4] http://tools.ietf.org/html/rfc4838 > > Best regards > > > Dan > > -- > Dan Luedtke > http://www.danrl.de > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurtis at kurtis.pp.se Thu Jun 13 18:44:35 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Thu, 13 Jun 2013 18:44:35 +0200 Subject: [ncc-services-wg] 2013-04 to Review phase Message-ID: <91ED7AB7-CA4C-49D7-9CF7-DF68B476371C@kurtis.pp.se> All, The WG chairs have decided to proceed with moving the 2013-04 proposal to the review phase. Our reasoning for this is 1/ There seems to be broad support for the proposal 2/ The changes flagged by the author for the new version are minimal 3/ We believe that having the RIPE NCC impact analysis available for the proposal will help in the discussions I would like to stress that this step forward in the PDP does not make this proposal more or less likely to become a final policy, but rather it will give us a more complete document to have a discussion around. Last, as for the issue raised by Peter, if members DO believe that acceptance of 2013-04 as a policy in a possible future last-call is dependent on symmetry with PA/other status I would like to bring this to the list. Kurtis & Bijal From fw at deneb.enyo.de Sun Jun 16 18:44:41 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Jun 2013 18:44:41 +0200 Subject: [ncc-services-wg] 2012-08 Review Period extended until 1 July 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: (Emilio Madaio's message of "Mon, 03 Jun 2013 15:17:01 +0200") References: Message-ID: <874ncyngxy.fsf@mid.deneb.enyo.de> * Emilio Madaio: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-08 I support this proposal. The LIR link is one of the few bits that RIPE NCC can actually verify. Will the sponsoring-org: attribute be included in the database dumps on ftp.ripe.net? That information might be helpful in a disaster recovery scenario. From fw at deneb.enyo.de Sun Jun 16 18:37:05 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Jun 2013 18:37:05 +0200 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: (Emilio Madaio's message of "Wed, 08 May 2013 15:19:48 +0200") References: Message-ID: <878v2anham.fsf@mid.deneb.enyo.de> * Emilio Madaio: > https://www.ripe.net/ripe/policies/proposals/2013-04 What does this mean? | The Internet resources reside within the RIPE NCC service region Will the sponsoring LIR for legacy resources be visible in the WHOIS database? 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: [ncc-services-wg] [address-policy-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 hamed at skydsl.ir Mon Jun 17 19:52:58 2013 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Mon, 17 Jun 2013 22:22:58 +0430 Subject: [ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members) In-Reply-To: References: <20130518132453.GA92411@cilantro.c4inet.net> <519A365B.3060304@fud.no> <004301ce5588$f9d74130$ed85c390$@a2b-internet.com> <51AD971F.1020209@fud.no> <006d01ce610c$4c813100$e5839300$@a2b-internet.com> Message-ID: I support. +1 On Wed, Jun 12, 2013 at 1:17 PM, Dan Luedtke wrote: > Sander wrote: > > Yes, securing routing is desperately needed. > I totally agree! For this reason alone I support any proposal that > gives me as PI holder the chance to sign my routes. > +1 > > Tore wrote: > > So how about simply ?The Internet resources reside within the RIPE NCC > > registry?? > I support that too. Tores off-planet argument made me thinking about > pictures I've seen from the international space station. Whose region > are they in anywhere? They probably change reagions multiple times a > day. > > Best regards > > > Dan > > -- > Dan Luedtke > http://www.danrl.de > > -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexb at ripe.net Wed Jun 26 22:06:12 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 26 Jun 2013 22:06:12 +0200 Subject: [ncc-services-wg] RPKI Validator 2.11 with RESTful API Message-ID: Dear colleagues, We just released a new version of the RIPE NCC RPKI Validator with some major new functionality. The application has always been able to determine the RPKI validity state of a BGP announcement, but it was only visible in the UI. Many users have asked us to expose this functionality through an API, so it can be used for scripting and alerting. In addition, operators have expressed that they would like to know the reason of an 'Invalid' BGP announcement: whether it is an origination from unauthorised AS or if it is a more specific announcement than is allowed by the Maximum Length of the ROA. All of this is now available in version 2.11. When you supply a combination of AS and IP prefix, they will be matched against all the Validated ROA Prefixes (VRPs) that are in the cache of the RPKI Validator. The result is returned in JSON format and contains the following information: - The RPKI validity state - The VRPs that caused the state - In case of an 'Invalid' state, the reason So for example, when running this: $ curl http://localhost:8080/api/v1/validity/AS12654/93.175.147.0/24 The response will be: { "validated_route":{ "route":{ "origin_asn":"AS12654", "prefix":"93.175.147.0/24" }, "validity":{ "state":"Invalid", "reason":"as", "description":"At least one VRP Covers the Route Prefix, but no VRP ASN matches the route origin ASN", "VRPs":{ "matched":[], "unmatched_as":[{ "asn":"AS196615", "prefix":"93.175.147.0/24", "max_length":24 }], "unmatched_length":[] } } } Full documentation is available here: https://www.ripe.net/developers/rpki-validator-api You can download the application here: http://www.ripe.net/certification/tools-and-resources Kaia Global Networks offers a testbed where you can try out the functionality on a public instance of the RPKI Validator: http://195.13.63.18:8080/export We look forward to your feedback, to hear how we can improve on this functionality. Kind regards, Alex Band Product Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From training at ripe.net Thu Jun 27 10:03:17 2013 From: training at ripe.net (Training Team) Date: Thu, 27 Jun 2013 10:03:17 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates Message-ID: <51CBF1C5.8070707@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From chrisb at ripe.net Thu Jun 27 15:32:40 2013 From: chrisb at ripe.net (Chris Buckridge) Date: Thu, 27 Jun 2013 15:32:40 +0200 Subject: [ncc-services-wg] RIPE NCC Launches New Initiatives at EuroDIG 2013 References: <8CEA2569-743B-4FAE-8504-67CB2657B17B@ripe.net> Message-ID: <3077E8EA-7320-409F-B41A-287BB4A436D8@ripe.net> Dear colleagues, The RIPE NCC has posted a report on our participation at last week's EuroDIG (European Dialogue on Internet Governance) meeting in Lisbon, including two new initiatives launched by the RIPE NCC at the event: https://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe-ncc-launches-new-initiatives-at-eurodig-2013 Best regards, Chris Buckridge External Relations Officer, RIPE NCC From alexb at ripe.net Thu Jun 27 17:52:17 2013 From: alexb at ripe.net (Alex Band) Date: Thu, 27 Jun 2013 17:52:17 +0200 Subject: [ncc-services-wg] [service] LIR Portal Downtime Due to Network Maintenance, Saturday 29 June Message-ID: <4DCB5CE5-7250-4D1C-9FCD-DD00650D0EF2@ripe.net> Dear colleagues, On Saturday 29 June, from 07:30 UTC to 16:00 UTC, the RIPE NCC is planning network maintenance. During this maintenance, the LIR Portal and services that depend on it, such as the IP Analyser and the Resource Certification (RPKI) management interface, will be unavailable. Other RIPE NCC services are not expected to be affected. We apologise for any inconvenience this may cause. If you have any questions, please contact us at . Kind regards, Alex Band Product Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Fri Jun 28 16:56:51 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Fri, 28 Jun 2013 16:56:51 +0200 Subject: [ncc-services-wg] DB Software - release and deployment improvements Message-ID: <51CDA433.5010901@CC.UniVie.ac.at> Dear DB-WG, NCC-Services and Routing WG Community! Over the recent month or so, a deployment of a new version of the DB-SW, to the production environment, turned out to (potentially) have serious impact on automated router configurations in (an) operator's network(s). The issue was reported to the NCC's DB-WG Group and the specific problem has already been fixed (actually on the same day as reported). Here's the link to the service announcement page: http://www.ripe.net/lir-services/service-announcements/ripe-database-query-output-issue However, as the incident seemes serious enough, a small group of interested people (R?diger, Nigel Titley, folks from the NCC and myself) started to dig a bit deeper, into what was (and is) perceived to be aspects that need review, more transparency and maybe improvement. We plan to look at some aspects, amongste others, like: - better communication regarding upcoming new SW releases - better transparency when and where (TEST DB, Production DB,...) new software will be deployed - version control and documentation But the most important thing is an improved and more transparent process to deploy new software versions *as soon as possible*! Then we can take it from there... While this message is also sent to the NCC Services and Routing WG, fyi, I'd like to suggest to have follow-up comments and discussion on the DB-WG List! Looking forward to fruitful discussions, best regards, Wilfried From jahlen at ripe.net Fri Jun 28 21:14:00 2013 From: jahlen at ripe.net (=?iso-8859-1?Q?Johan_=C5hl=E9n?=) Date: Fri, 28 Jun 2013 21:14:00 +0200 Subject: [ncc-services-wg] New Procedure for RIPE Database Software Releases Message-ID: Dear colleagues, We have recently received valuable input on how we can improve our release procedures for the RIPE Database software. In order to further reinforce our processes, we have defined a new procedure together with the Database Working Group (WG) Chairs that will address the concerns that have been raised about the stability of the Database software by the community. The purpose of the new procedure is to give you notice of what the next release will contain and how it might affect you as a user. No matter what the impact of a new feature is, an announcement will always precede the deployment to production and you will be given sufficient time to test your software. The procedure is not too far from how we have been working up until now, but will be more strictly defined and will hopefully eliminate any surprises. We propose to proceed as follows: - We will move to a four to six week release cycle for the Database software - There will be no more than three new features per release - Each new release will be announced to the WG mailing list at least two weeks before we deploy to production - In the event that we are required to deviate from what was stated in the announcement, we will announce this to the WG mailing list - The new release will be available in Test Database at least two weeks before we deploy to production - We will announce to the WG mailing list when we have successfully completed deployments to Test Database - We will announce to the WG mailing list when we have successfully completed deployments to Production Database - In the special case of required emergency fixes, we will announce this to the WG mailing list as well as the website as soon as possible - We will make a follow-up announcement to the WG mailing list and the website as soon as a fixed version has been deployed - These two emergency announcements can be combined for security reasons, or if the problem is solved in less than 30 minutes For the initial release announcements, the following template will be used: Release number Expected date of deployment to Test Database Expected date of deployment to Production Database New features Impact on existing functionality Operational improvements Impact on existing functionality Fixed bugs Impact on existing functionality Expected upcoming features for next release We hope that you will find this procedure beneficial and with your consent we would like to move ahead with it effective immediately. We also intend to publish this procedure to the website together with a roadmap of what we expect that the upcoming releases will contain. Kind regards, Johan ?hl?n Assistant Manager Database RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2616 bytes Desc: not available URL: