From BECHA at ripe.net Wed Jul 4 17:07:15 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 04 Jul 2012 17:07:15 +0200 Subject: [ncc-services-wg] Short update on TTM service Message-ID: <4FF45C23.2010902@ripe.net> Dear colleagues, We received a lot of feedback from the community after we announced our proposal to discontinue TTM at RIPE 64. After reviewing the RIPE community's feedback and reevaluating our own planning, we are pleased to announce that we will continue supporting TTM until sometime in 2013. As presented during the MAT Working Group and RIPE NCC Services Working Group sessions at RIPE 64, we plan to implement RIPE Atlas Anchors and to migrate DNSMON functionality to RIPE Atlas. We will do this in parallel to the current TTM infrastructure in order to give the RIPE community enough time to build confidence in and test the new infrastructure. We will give you more details about transition in early September and look forward to discussing our proposed plans with you at RIPE 65 in Amsterdam. If you are a TTM host you have received a more detailed version of this email, if this is not the case then please contact with me and I would be more than happy to provide further information for you. I wish you relaxed summer holidays. Kind regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder +31205354444 for Measurement Tools RIPE NCC http://ripe.net From training at ripe.net Thu Jul 5 09:48:58 2012 From: training at ripe.net (Training Mailbox) Date: Thu, 05 Jul 2012 09:48:58 +0200 Subject: [ncc-services-wg] RIPE NCC Webinars - new dates In-Reply-To: <4FF43809.8080506@ripe.net> References: <4FF43809.8080506@ripe.net> Message-ID: <4FF546EA.8000703@ripe.net> [Apologies for duplicate emails] Dear colleagues, We're pleased to announce that we've added new RIPE NCC Webinar dates for RIPE NCC members. The RIPE NCC Webinars are live, one-hour online training courses that allow participants to interact with our trainers without leaving their desks. We focus on the topics and issues most important to RIPE NCC members. Register now at: 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 brian.nisbet at heanet.ie Thu Jul 5 15:08:52 2012 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 05 Jul 2012 14:08:52 +0100 Subject: [ncc-services-wg] [mat-wg] Short update on TTM service In-Reply-To: <4FF45C23.2010902@ripe.net> References: <4FF45C23.2010902@ripe.net> Message-ID: <4FF591E4.6080308@heanet.ie> Vesna, "Vesna Manojlovic" wrote the following on 04/07/2012 16:07: > Dear colleagues, > > We received a lot of feedback from the community after we announced our > proposal to discontinue TTM at RIPE 64. After reviewing the RIPE > community's feedback and reevaluating our own planning, we are pleased > to announce that we will continue supporting TTM until sometime in 2013. I think this is to be welcomed. As I mentioned at RIPE 64 I cannot argue with the basic idea of shutting down TTM, but revised timelines would seem to be an excellent idea given the feedback and the questions raised after the last announcement. > As presented during the MAT Working Group and RIPE NCC Services Working > Group sessions at RIPE 64, we plan to implement RIPE Atlas Anchors and > to migrate DNSMON functionality to RIPE Atlas. We will do this in > parallel to the current TTM infrastructure in order to give the RIPE > community enough time to build confidence in and test the new > infrastructure. Again, a good move. While I'm not a DNSMON user myself, I think this was one of the biggest issues with the previous plan. > We will give you more details about transition in early September and > look forward to discussing our proposed plans with you at RIPE 65 in > Amsterdam. Indeed, I think that a proposed plan and discussion is greatly to be preferred over the previous fait accompli. HEAnet are very happy to continue to be a TTM host until such times as the alternative is in place and the project is shut down in an agreed and structured manner. Thanks, Brian. From andrea at ripe.net Mon Jul 9 15:24:31 2012 From: andrea at ripe.net (Andrea Cima) Date: Mon, 09 Jul 2012 15:24:31 +0200 Subject: [ncc-services-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC Message-ID: <4FFADB8F.7040709@ripe.net> Dear colleagues, The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has been published. The document is available at: https://www.ripe.net/ripe/docs/ripe-555/ This RIPE Document updates ripe-510 and now points to the extended delegated statistics containing the full list of resources that the RIPE NCC manages. The document also reflects the fact that the RIPE NCC needs to be able to issue blocks of any size from any /8, so the document was updated accordingly. Best regards, Andrea Cima Registration Services Manager RIPE NCC From gall at switch.ch Tue Jul 10 10:46:01 2012 From: gall at switch.ch (Alexander Gall) Date: Tue, 10 Jul 2012 10:46:01 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <4FFADB8F.7040709@ripe.net> References: <4FFADB8F.7040709@ripe.net> Message-ID: <20475.60361.476285.923710@switch.ch> On Mon, 09 Jul 2012 15:24:31 +0200, Andrea Cima said: > Dear colleagues, > The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has > been published. The document is available at: > https://www.ripe.net/ripe/docs/ripe-555/ > This RIPE Document updates ripe-510 and now points to the extended > delegated statistics containing the full list of resources that the RIPE > NCC manages. > The document also reflects the fact that the RIPE NCC needs to be able > to issue blocks of any size from any /8, so the document was updated > accordingly. Am I the only one who is confused by this document? I don't care much about IPv4, but this scares me: The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48. At the same time, this text from RIPE-510, Section 4 has been removed Network operators taking routing decisions based on prefix length are requested and encouraged to route at least blocks of sizes corresponding to the longest prefix and larger. If this means what I naively think it does, I'd have missed the entire discussion about what I would perceive as a fundamental change in policy. So, I guess I'm just thoroughly confused. Can somebody help me understand what exactly RIPE-555 means? -- Alex From andrea at ripe.net Tue Jul 10 13:37:43 2012 From: andrea at ripe.net (Andrea Cima) Date: Tue, 10 Jul 2012 13:37:43 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <20475.60361.476285.923710@switch.ch> References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> Message-ID: <4FFC1407.2070204@ripe.net> Dear Alexander, On 7/10/12 10:46 AM, Alexander Gall wrote: > On Mon, 09 Jul 2012 15:24:31 +0200, Andrea Cima said: > >> Dear colleagues, >> The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has >> been published. The document is available at: >> https://www.ripe.net/ripe/docs/ripe-555/ >> This RIPE Document updates ripe-510 and now points to the extended >> delegated statistics containing the full list of resources that the RIPE >> NCC manages. >> The document also reflects the fact that the RIPE NCC needs to be able >> to issue blocks of any size from any /8, so the document was updated >> accordingly. > Am I the only one who is confused by this document? I don't care much > about IPv4, but this scares me: > > The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48. A /48 is the minimum assignment size for IPv6 PI and IXP assignments. Please see: http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments http://www.ripe.net/ripe/docs/ripe-451 > At the same time, this text from RIPE-510, Section 4 has been removed > > Network operators taking routing decisions based on prefix length > are requested and encouraged to route at least blocks of sizes > corresponding to the longest prefix and larger. > > If this means what I naively think it does, I'd have missed the entire > discussion about what I would perceive as a fundamental change in > policy. RIPE 555 is not a RIPE Policy document but a RIPE NCC organisational document. The scope of this document is to list the address space managed by the RIPE NCC. > So, I guess I'm just thoroughly confused. Can somebody help > me understand what exactly RIPE-555 means? > I apologise if I have not been clear about the changes. I will try to clarify further. RIPE 510 listed only the /8s allocated to the RIPE NCC by IANA. With RIPE 555, our aim is to provide the full and current list of all address space managed by the RIPE NCC, therefore increasing the quality of the data provided. Please also note that not all blocks allocated to the RIPE NCC from IANA in the past are still fully managed by the RIPE NCC. Some IP address space was transferred to AFRINIC, for example. For this reason, we removed the static list and refer to the extended FTP stats, which contain accurate and up-to-date information. This is also the reason why the route sets for these /8s in the RIPE Database (see section 1 of RIPE 510) will be removed. I hope this clarifies. If not, please don't hesitate to contact me. Best regards, Andrea Cima RIPE NCC From gall at switch.ch Tue Jul 10 17:29:59 2012 From: gall at switch.ch (Alexander Gall) Date: Tue, 10 Jul 2012 17:29:59 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <4FFC1407.2070204@ripe.net> References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> <4FFC1407.2070204@ripe.net> Message-ID: <20476.19063.651745.927381@switch.ch> Hello Andrea Thanks for the quick feedback. Please see my comments inline. On Tue, 10 Jul 2012 13:37:43 +0200, Andrea Cima said: > Dear Alexander, > On 7/10/12 10:46 AM, Alexander Gall wrote: >> On Mon, 09 Jul 2012 15:24:31 +0200, Andrea Cima said: >> >>> Dear colleagues, >>> The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has >>> been published. The document is available at: >>> https://www.ripe.net/ripe/docs/ripe-555/ >>> This RIPE Document updates ripe-510 and now points to the extended >>> delegated statistics containing the full list of resources that the RIPE >>> NCC manages. >>> The document also reflects the fact that the RIPE NCC needs to be able >>> to issue blocks of any size from any /8, so the document was updated >>> accordingly. >> Am I the only one who is confused by this document? I don't care much >> about IPv4, but this scares me: >> >> The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48. > A /48 is the minimum assignment size for IPv6 PI and IXP assignments. > Please see: > http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments > http://www.ripe.net/ripe/docs/ripe-451 Ok. I try to explain below why the current formulation can appear to be misleading for some people that used RIPE-510 for a particular purpose. >> At the same time, this text from RIPE-510, Section 4 has been removed >> >> Network operators taking routing decisions based on prefix length >> are requested and encouraged to route at least blocks of sizes >> corresponding to the longest prefix and larger. >> >> If this means what I naively think it does, I'd have missed the entire >> discussion about what I would perceive as a fundamental change in >> policy. > RIPE 555 is not a RIPE Policy document but a RIPE NCC organisational > document. The scope of this document is to list the address space > managed by the RIPE NCC. You may underestimate the relevance of this document for operators :) Either that or I overestimate it. >> So, I guess I'm just thoroughly confused. Can somebody help >> me understand what exactly RIPE-555 means? >> > I apologise if I have not been clear about the changes. I will try to > clarify further. > RIPE 510 listed only the /8s allocated to the RIPE NCC by IANA. With > RIPE 555, our aim is to provide the full and current list of all address > space managed by the RIPE NCC, therefore increasing the quality of the > data provided. That's much appreciated. However, this list is missing a piece of information that some people have been using for many years to generate "martian/bogon"-type route filters. From the old "longest prefix per block" list (and there is, or at least used to be such a list for every RIR), these people (like us) generate filters for BGP that deny all longer prefixes in such a range. I don't see how we can infer this information from the file. For example, how do we know exactly which IPv6 block has been set aside for IXP assignments in order to allow more specific prefixes in it? Even if this information is available from somwhere (though I wouldn't know where), it would be useful to have a single place where this is recorded (and this place used to be RIPE-510 and its predecessors). Section 4 also has tremendous potential for misunderstandings, given the meaning of "longest prefix" in RIPE-510, which differs substantially from that of the /29 and /48 mentioned in RIPE-555. Regards, -- Alex From pk at DENIC.DE Wed Jul 11 19:09:18 2012 From: pk at DENIC.DE (Peter Koch) Date: Wed, 11 Jul 2012 19:09:18 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <20475.60361.476285.923710@switch.ch> References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> Message-ID: <20120711170918.GU24669@x28.adm.denic.de> Alex, > At the same time, this text from RIPE-510, Section 4 has been removed > > Network operators taking routing decisions based on prefix length > are requested and encouraged to route at least blocks of sizes > corresponding to the longest prefix and larger. > > If this means what I naively think it does, I'd have missed the entire > discussion about what I would perceive as a fundamental change in > policy. So, I guess I'm just thoroughly confused. Can somebody help > me understand what exactly RIPE-555 means? I share your confusion to the extent that I'd say 555 is not self contained. E.g., mentioning "longest" in the headline to continue with "smallest" in the text is, while strictly applicable, misleading ... > 4. Longest Prefix Tables > > The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29. > The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48. ... as is the sole focus on assignments, isn't it? -Peter From andrea at ripe.net Thu Jul 12 15:35:11 2012 From: andrea at ripe.net (Andrea Cima) Date: Thu, 12 Jul 2012 15:35:11 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <20476.19063.651745.927381@switch.ch> References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> <4FFC1407.2070204@ripe.net> <20476.19063.651745.927381@switch.ch> Message-ID: <4FFED28F.3010407@ripe.net> [Copied ipv6-ops and v6ops mailing lists due to ongoing discussions about the same subject] Hi Alexander, On 7/10/12 5:29 PM, Alexander Gall wrote: > That's much appreciated. However, this list is missing a piece of > information that some people have been using for many years to > generate "martian/bogon"-type route filters. From the old "longest > prefix per block" list (and there is, or at least used to be such a > list for every RIR), these people (like us) generate filters for BGP > that deny all longer prefixes in such a range. I don't see how we can > infer this information from the file. For example, how do we know > exactly which IPv6 block has been set aside for IXP assignments in > order to allow more specific prefixes in it? Even if this information > is available from somwhere (though I wouldn't know where), it would be > useful to have a single place where this is recorded (and this place > used to be RIPE-510 and its predecessors). Both of IPv4 and IPv6 policies allow de-aggregation of allocations now. The requirement to announce an IPv6 allocation as one prefix only was removed from the policy in year 2009, please see: https://www.ripe.net/ripe/policies/proposals/2009-06 IPv6 Address Policy requires that IPv6 PI assignments are made from a separate address block. This is described in RIPE 555. There is no such requirement in the policies for IPv6 IXP or TLD anycast. Root server assignments are all /32 and thus presumably not the subject of any filtering (Sascha, I hope this answers your question as well). This document has been updated frequently in the past due to changes in policies and address assignment and allocation strategies, while at the same time not offering a very detailed view of the address space managed by the RIPE NCC. This version of the document is expected to change much less frequently while any loss of detailed information would be compensated by the published extended delegated statistics. We understand however that you may want to filter based on prefix lengths. The single data source for this is extended FTP stats we started publishing at ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest There you can see exactly which blocks were issued. As explained above, the changes made to RIPE 510 have the aim to increase the quality of the data provided to operators. If however there is a strong feeling in the community to include additional information in RIPE 555, we will do so. In this case however it would be better if we could collect the feedback through a single mailing list. Therefore I would suggest the NCC Services Mailing List. Best regards, Andrea Cima RIPE NCC > Section 4 also has tremendous potential for misunderstandings, given > the meaning of "longest prefix" in RIPE-510, which differs > substantially from that of the /29 and /48 mentioned in RIPE-555. > > Regards, From alexb at ripe.net Thu Jul 12 16:14:02 2012 From: alexb at ripe.net (Alex Band) Date: Thu, 12 Jul 2012 16:14:02 +0200 Subject: [ncc-services-wg] Using API Keys To Access (Private) LIR Portal Data Locally Message-ID: <9283CC46-C77E-45C7-90A2-E586F8699BB4@ripe.net> Dear colleagues, There have been many requests from the membership to provide a way to access private LIR data that is not locked into the LIR Portal web interface. This is especially relevant for larger LIRs who have to manage a large amount of IP address space. In order to offer our members better local access to our tools and data sets, it is now possible to create API access keys in the LIR Portal. The keys can be used to grant applications and scripts access to your (private) LIR data. The information will be fetched securely over HTTPS and can be used in your IP address management tools, for example. You can read more about it in this article on RIPE Labs: https://labs.ripe.net/Members/AlexBand/lir-portal-api-keys We hope you appreciate this functionality and look forward to your feedback. Kind regards, Alex Band Product Manager RIPE NCC From noreply at ripe.net Mon Jul 16 13:18:58 2012 From: noreply at ripe.net (Axel Pawlik) Date: Mon, 16 Jul 2012 13:18:58 +0200 Subject: [ncc-services-wg] =?windows-1252?q?Transfer_of_Internet_Number_Re?= =?windows-1252?q?source_Records_and_Change_of_a_Member=92s_Official_Legal?= =?windows-1252?q?_Name_-_Draft_Document?= Message-ID: <5003F8A2.60808@ripe.net> Dear colleagues, The RIPE NCC has created a draft procedural document, ?Transfer of Internet Number Resource Records and Change of a Member?s Official Legal Name?. A PDF of the document is available at: http://www.ripe.net/lir-services/ncc/legal/Transferofrecords_namechange.v2012.pdf The draft document refers to the current procedures the RIPE NCC follows in order to maintain an accurate registry in the case of changes regarding: - The Internet number resource records that are registered to a person; or - The official name of the person holding a registration of Internet number resources The procedures were originally discussed at the RIPE 62 Meeting in Amsterdam. The text of this document is intended to replace relevant sections of ripe-515, ?Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR?. The original RIPE Document is available at: https://www.ripe.net/ripe/docs/ripe-515 The RIPE NCC would like to receive feedback on this draft document from its members and the RIPE community. Based on this feedback, the RIPE NCC Executive Board will decide on a final version of the document. If you would like to give feedback on the document, please email the RIPE NCC Services Working Group mailing list at . Kind regards, Axel Pawlik Managing Director RIPE NCC From he at uninett.no Wed Jul 18 15:36:52 2012 From: he at uninett.no (Havard Eidnes) Date: Wed, 18 Jul 2012 15:36:52 +0200 (CEST) Subject: [ncc-services-wg] Destruction of trust Message-ID: <20120718.153652.263918473.he@uninett.no> Hi, as you may be aware, the RIPE NCC is currently engaged in an activity to establish contact with legacy address space holders, and among other things to set up a contractual relationship between the RIPE NCC and the legacy resource holders. However, it is my opinion that the current RIPE NCC actions with legacy resource holders is destroying some of the valuable trust they have built in the community over the years. It has been said that "the RIPE NCC does what the members tell them to do". That does however not appear to be the case for this action, where the RIPE NCC appears to act in a policy-free zone, simply on executive decision. Despite the RIPE NCCs knowledge that work is ongoing to formulate a policy for this area, they are barging ahead, possibly in an attempt to establish a fait accompli. The message sent to the legacy resource holders does not mention the option which would probably be most preferable to at least most of our customers, namely registering the resources via the LIR at their service provider. One could suspect the RIPE NCC has self-interest in driving up the number of LIRs, to increase the number of paying customers of the RIPE NCC. Some of the documents about the approach with legacy resource holders has mentioned a "stick and carrot" approach. I'll claim that the stick is needlessly sharp and the carrot reeks of decomposition. Explanation: * The stick is primarily the "we cannot guarantee in-addr.arpa name service". Without it, a user will in practice be unable to operate mail servers within the affected address space, which would be a severe blow to those who still actively use their address space. The freezing of the registry data is an inconvenience which will ensure that the accuracy of the data whittles over time, an action initiated by the RIPE NCC no less... Many legacy resource holders have not updated their records in a long time already (many didn't have an actual need to do so), so while inconvenient, it's not as strong a stick as the threat of removal of the in-addr.arpa delegation. It should however be noted that the whittling of the registration data over time also is detrimental for the RIPE community at large, not only for the address space holder. * What's the carrot? Only the removal of the stick from above? What makes the carrot particularly rotten is several things: * The open-ended and unliateral application of "all relevant RIPE NCC policies and procedures". The fear would be "we will mire you or your LIR (or both) down in pointless address policy work to document ancient history, and have the RIPE NCC verify (or deny, as the case may be) all assignments done over time" (applicable where address space has been used in PA-fashion). ...or for PI-style assignments, the assignment itself might be challenged. * The highly uncertain status of the charging scheme in the longer term for the legacy resource holders, where the initial proposal to modify today's model had, with no discussion, abolished the "age based discount", and where current discussion is rampant with "payment per IP address" schemes. The fear is that the RIPE NCC will gouge the legacy resource holders either directly or indirectly, "motivating" them to hand back the resource. * The lack of recognition that these addresses were assigned under a different policy. Anecdotal evidence suggests that at one time you would be handed a class-B instead of 4 class-Cs because there was fear of growth of the routing table. Does the RIPE NCC now want to challenge the assignments? In sum, this makes the RIPE NCC appear more as an extorting bully rather than an agent who has the accuracy of the address register as its foremost priority, and this destroys some of the valuable trust they have built in the community over the years. Regards, - H?vard From hank at efes.iucc.ac.il Wed Jul 18 19:16:52 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 18 Jul 2012 20:16:52 +0300 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <20120718.153652.263918473.he@uninett.no> Message-ID: <5.1.1.6.2.20120718201118.01f0acc0@efes.iucc.ac.il> At 15:36 18/07/2012 +0200, Havard Eidnes wrote: >Hi, > >as you may be aware, the RIPE NCC is currently engaged in an >activity to establish contact with legacy address space holders, >and among other things to set up a contractual relationship >between the RIPE NCC and the legacy resource holders. > >However, it is my opinion that the current RIPE NCC actions with >legacy resource holders is destroying some of the valuable trust >they have built in the community over the years. > >It has been said that "the RIPE NCC does what the members tell >them to do". That does however not appear to be the case for >this action, where the RIPE NCC appears to act in a policy-free >zone, simply on executive decision. Despite the RIPE NCCs >knowledge that work is ongoing to formulate a policy for this >area, they are barging ahead, possibly in an attempt to establish >a fait accompli. It is indeed a shame that the RIPE NCC is plowing ahead without a mandate from the membership to be doing this. It is indeed a shame that the hundreds of legacy IP holders now view the RIPE NCC in a totally different light then they did previously. I do not quite understand the urgency the RIPE NCC sees in forging ahead quickly rather than taking the time to discuss the matter in a calm and non-pressured environment. I am indeed clueless as to why they are doing this. -Hank >The message sent to the legacy resource holders does not mention >the option which would probably be most preferable to at least >most of our customers, namely registering the resources via the >LIR at their service provider. One could suspect the RIPE NCC >has self-interest in driving up the number of LIRs, to increase >the number of paying customers of the RIPE NCC. > >Some of the documents about the approach with legacy resource >holders has mentioned a "stick and carrot" approach. I'll claim >that the stick is needlessly sharp and the carrot reeks of >decomposition. Explanation: > > * The stick is primarily the "we cannot guarantee in-addr.arpa > name service". Without it, a user will in practice be unable > to operate mail servers within the affected address space, > which would be a severe blow to those who still actively use > their address space. > > The freezing of the registry data is an inconvenience which > will ensure that the accuracy of the data whittles over time, > an action initiated by the RIPE NCC no less... Many legacy > resource holders have not updated their records in a long time > already (many didn't have an actual need to do so), so while > inconvenient, it's not as strong a stick as the threat of > removal of the in-addr.arpa delegation. It should however be > noted that the whittling of the registration data over time > also is detrimental for the RIPE community at large, not only > for the address space holder. > > * What's the carrot? Only the removal of the stick from above? > What makes the carrot particularly rotten is several things: > > * The open-ended and unliateral application of "all relevant > RIPE NCC policies and procedures". The fear would be "we > will mire you or your LIR (or both) down in pointless > address policy work to document ancient history, and have > the RIPE NCC verify (or deny, as the case may be) all > assignments done over time" (applicable where address space > has been used in PA-fashion). > ...or for PI-style assignments, the assignment itself might > be challenged. > * The highly uncertain status of the charging scheme in the > longer term for the legacy resource holders, where the > initial proposal to modify today's model had, with no > discussion, abolished the "age based discount", and where > current discussion is rampant with "payment per IP address" > schemes. The fear is that the RIPE NCC will gouge the > legacy resource holders either directly or indirectly, > "motivating" them to hand back the resource. > * The lack of recognition that these addresses were assigned > under a different policy. Anecdotal evidence suggests that > at one time you would be handed a class-B instead of 4 > class-Cs because there was fear of growth of the routing > table. Does the RIPE NCC now want to challenge the > assignments? > >In sum, this makes the RIPE NCC appear more as an extorting bully >rather than an agent who has the accuracy of the address register >as its foremost priority, and this destroys some of the valuable >trust they have built in the community over the years. > > >Regards, > >- H?vard From nigel at titley.com Wed Jul 18 21:41:45 2012 From: nigel at titley.com (Nigel Titley) Date: Wed, 18 Jul 2012 20:41:45 +0100 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <20120718.153652.263918473.he@uninett.no> References: <20120718.153652.263918473.he@uninett.no> Message-ID: <50071179.8020903@titley.com> (excuse the top posting, but I wanted to keep the whole of Havard's email in the thread as it makes some interesting points) Dear Havard, I'm sorry to see that you believe there has been an erosion of trust between yourself and the RIPE NCC. This is certain not the intent. I would just like to make some points on the legacy address space issues you raise below that I hope will help clarify matters. Note that it is not mandatory to register legacy address space. It's completely optional for legacy address space holders to: a. Become a RIPE NCC member; or b. Register their resources with a sponsoring LIR; or c. Remain as they are While the option for a legacy address space holder to become a member of the RIPE NCC is available, the RIPE NCC actively encourages legacy address space holders to register their address space with a sponsoring LIR. As noted in the RIPE NCC's Activity Plan for 2012, "The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992." For legacy address space holders who do wish to become RIPE NCC members, the sign-up fee and the membership fee for the coming year is waived. The document you refer to mentioning the "carrot and stick" approach is the Report of the RIPE NCC Charging Scheme Task Force. This task force was made up of RIPE NCC members, RIPE NCC Executive Board members and representatives from the RIPE NCC. The report only makes recommendations to the RIPE NCC Executive Board regarding a proposed Charging Scheme model. To give you some information on the work carried out by the RIPE NCC so far, the Registration Services Department has contacted 145 existing LIRs who hold legacy resources. The responses from those LIRs can be broken down as follows: - 63 LIRs added the address space under their LIR's registration - 24 LIRs said that they were not interested because of the lack of RIPE Policies - 2 returned unused legacy address space - 56 did not reply to the original email or reminder emails A total of 8,513,280 IP addresses were added to the LIRs' registration during this phase of the project. The RIPE NCC recently started to contact legacy address space holders who are not LIRs. All of the information on the RIPE NCC's activities regarding legacy address space are available at: http://www.ripe.net/lir-services/resource-management/legacy-space Best regards, Nigel Chairman RIPE NCC Board On 18/07/2012 14:36, Havard Eidnes wrote: > Hi, > > as you may be aware, the RIPE NCC is currently engaged in an > activity to establish contact with legacy address space holders, > and among other things to set up a contractual relationship > between the RIPE NCC and the legacy resource holders. > > However, it is my opinion that the current RIPE NCC actions with > legacy resource holders is destroying some of the valuable trust > they have built in the community over the years. > > It has been said that "the RIPE NCC does what the members tell > them to do". That does however not appear to be the case for > this action, where the RIPE NCC appears to act in a policy-free > zone, simply on executive decision. Despite the RIPE NCCs > knowledge that work is ongoing to formulate a policy for this > area, they are barging ahead, possibly in an attempt to establish > a fait accompli. > > The message sent to the legacy resource holders does not mention > the option which would probably be most preferable to at least > most of our customers, namely registering the resources via the > LIR at their service provider. One could suspect the RIPE NCC > has self-interest in driving up the number of LIRs, to increase > the number of paying customers of the RIPE NCC. > > Some of the documents about the approach with legacy resource > holders has mentioned a "stick and carrot" approach. I'll claim > that the stick is needlessly sharp and the carrot reeks of > decomposition. Explanation: > > * The stick is primarily the "we cannot guarantee in-addr.arpa > name service". Without it, a user will in practice be unable > to operate mail servers within the affected address space, > which would be a severe blow to those who still actively use > their address space. > > The freezing of the registry data is an inconvenience which > will ensure that the accuracy of the data whittles over time, > an action initiated by the RIPE NCC no less... Many legacy > resource holders have not updated their records in a long time > already (many didn't have an actual need to do so), so while > inconvenient, it's not as strong a stick as the threat of > removal of the in-addr.arpa delegation. It should however be > noted that the whittling of the registration data over time > also is detrimental for the RIPE community at large, not only > for the address space holder. > > * What's the carrot? Only the removal of the stick from above? > What makes the carrot particularly rotten is several things: > > * The open-ended and unliateral application of "all relevant > RIPE NCC policies and procedures". The fear would be "we > will mire you or your LIR (or both) down in pointless > address policy work to document ancient history, and have > the RIPE NCC verify (or deny, as the case may be) all > assignments done over time" (applicable where address space > has been used in PA-fashion). > ...or for PI-style assignments, the assignment itself might > be challenged. > * The highly uncertain status of the charging scheme in the > longer term for the legacy resource holders, where the > initial proposal to modify today's model had, with no > discussion, abolished the "age based discount", and where > current discussion is rampant with "payment per IP address" > schemes. The fear is that the RIPE NCC will gouge the > legacy resource holders either directly or indirectly, > "motivating" them to hand back the resource. > * The lack of recognition that these addresses were assigned > under a different policy. Anecdotal evidence suggests that > at one time you would be handed a class-B instead of 4 > class-Cs because there was fear of growth of the routing > table. Does the RIPE NCC now want to challenge the > assignments? > > In sum, this makes the RIPE NCC appear more as an extorting bully > rather than an agent who has the accuracy of the address register > as its foremost priority, and this destroys some of the valuable > trust they have built in the community over the years. > > > Regards, > > - H?vard > From ms at man-da.de Thu Jul 19 10:49:49 2012 From: ms at man-da.de (Marcus Stoegbauer) Date: Thu, 19 Jul 2012 10:49:49 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <50071179.8020903@titley.com> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> Message-ID: Dear Nigel, On 18.07.2012, at 21:41, Nigel Titley wrote: > Note that it is not mandatory to register legacy address > space. It's completely optional for legacy address space holders to: > > a. Become a RIPE NCC member; or > b. Register their resources with a sponsoring LIR; or > c. Remain as they are > > While the option for a legacy address space holder to become a member of > the RIPE NCC is available, the RIPE NCC actively encourages legacy > address space holders to register their address space with a sponsoring LIR. > that is correct for information published on the webpages, unfortunately it is not the case for the mails the RIPE NCC sent out to holders of legacy space for Phase 3. According to those mails the only two options for the legacy space holders are to become a member and make the world a better place, or not to become a member and have the registry and reverse DNS data for their legacy space frozen. The people participating in RIPE know about the option of a sponsoring LIR obviously, but my best guess is that for most legacy space holders this mail will be the first contact with the RIPE NCC they ever had. Although there is a link to http://www.ripe.net/lir-services/resource-management/legacy-space in this mail, the wording for a first contact mail is a bit strange and almost threatening for my taste. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Mornewegstr. 30 Fax: +49 6151 16-3050 64293 Darmstadt, Germany e-mail: ms at man-da.de Gesch?ftsf?hrer Marcus St?gbauer AG Darmstadt, HRB 94 84 From nigel at titley.com Thu Jul 19 12:15:30 2012 From: nigel at titley.com (Nigel Titley) Date: Thu, 19 Jul 2012 11:15:30 +0100 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> Message-ID: <5007DE42.5020402@titley.com> On 19/07/2012 09:49, Marcus Stoegbauer wrote: > Dear Nigel, > > On 18.07.2012, at 21:41, Nigel Titley wrote: > >> Note that it is not mandatory to register legacy address >> space. It's completely optional for legacy address space holders to: >> >> a. Become a RIPE NCC member; or >> b. Register their resources with a sponsoring LIR; or >> c. Remain as they are >> >> While the option for a legacy address space holder to become a member of >> the RIPE NCC is available, the RIPE NCC actively encourages legacy >> address space holders to register their address space with a sponsoring LIR. >> > that is correct for information published on the webpages, unfortunately it is not the case for the mails the RIPE NCC sent out to holders of legacy space for Phase 3. According to those mails the only two options for the legacy space holders are to become a member and make the world a better place, or not to become a member and have the registry and reverse DNS data for their legacy space frozen. > > The people participating in RIPE know about the option of a sponsoring LIR obviously, but my best guess is that for most legacy space holders this mail will be the first contact with the RIPE NCC they ever had. Although there is a link to http://www.ripe.net/lir-services/resource-management/legacy-space in this mail, the wording for a first contact mail is a bit strange and almost threatening for my taste. > Marcus, Give me a couple of days to chase this up with the RIPE NCC. The last thing I want to do is for legacy holders to feel threatened or intimidated. Nigel From he at uninett.no Thu Jul 19 14:53:12 2012 From: he at uninett.no (Havard Eidnes) Date: Thu, 19 Jul 2012 14:53:12 +0200 (CEST) Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <50071179.8020903@titley.com> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> Message-ID: <20120719.145312.391903756.he@uninett.no> > Note that it is not mandatory to register legacy address > space. It's completely optional for legacy address space holders to: > > a. Become a RIPE NCC member; or > b. Register their resources with a sponsoring LIR; or > c. Remain as they are > > While the option for a legacy address space holder to become a > member of the RIPE NCC is available, the RIPE NCC actively > encourages legacy address space holders to register their > address space with a sponsoring LIR. You know that, and I do too, but I suspect that most legacy holders, especially those who are not LIRs already, don't. The letter the RIPE NCC is currently sending as the first contact with the legacy space holders only explicitly mentions options a) and c) above. In reality, if some legacy space is in use, option c) above isn't an option, given the very thinly veiled threat of removal of the in-addr.arpa DNS delegation. So for these holders, it means there is a certain element of coercion involved pushing towards either option a) or b) above. If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC. Therefore, this seems to be a unilateral land grab in the policy area by the RIPE NCC. I'm surprised noone appears to see the inherent danger in such an action. > To give you some information on the work carried out by the RIPE NCC > so far, the Registration Services Department has contacted 145 > existing LIRs who hold legacy resources. The responses from those > LIRs can be broken down as follows: > > - 63 LIRs added the address space under their LIR's registration > - 24 LIRs said that they were not interested because of the lack of > RIPE Policies > - 2 returned unused legacy address space > - 56 did not reply to the original email or reminder emails > > A total of 8,513,280 IP addresses were added to the LIRs' registration > during this phase of the project. This shows that the process of establishing a fait accompli is progressing. Of course many will have budged under the pressure imposed by the RIPE NCC. I'm somewhat encouraged that despite this, quite a few LIRs appear to in effect have said "develop a public policy first, and we'll (re-)consider it". Regards, - H?vard From sander at steffann.nl Thu Jul 19 16:11:42 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 19 Jul 2012 16:11:42 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <20120719.145312.391903756.he@uninett.no> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> Message-ID: <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> Hi, Giving some background information related to address policy: > If I've understood correctly, both option a) and b) above involve in > effect abolishment of historical grants and contractual submission > to all current and future RIR address policies and procedures which > are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting > what is relevant. No grandfather clauses, acknowledgement of > historical rights or explicit limitations anywhere in sight, and no > option to amend the template contract imposed by the RIPE NCC. The template is defined in RIPE-452: > --- > The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include: > > ? Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date > ? Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database > ? Notice that none of the provider independent resources may be sub-assigned to a third party > ? Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources > ? A clear statement that the resources will return by default to the RIPE NCC if > ? The resource holder cannot be contacted > ? The annual fee to the LIR is not paid > ? A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time > --- The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that. The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract. The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space.... The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract. But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically. - Sander From noreply at ripe.net Thu Jul 19 17:03:22 2012 From: noreply at ripe.net (Andrew de la Haye) Date: Thu, 19 Jul 2012 17:03:22 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> Message-ID: <500821BA.4030101@ripe.net> Dear colleagues, In Phase 3 of its legacy space project, the RIPE NCC is sending emails to contact legacy address space holders who are not RIPE NCC members and who hold a /16 or more. In the emails we are sending, all three options, including the option to register legacy address space with a sponsoring LIR, are presented to the organisations. However, in the case of contact with three organisations, an email was mistakenly sent that did not mention the option to use a sponsoring LIR. We regret this mistake and apologise sincerely for the confusion and any distress this might have caused. We are contacting the organisations concerned to ensure that the correct message is delivered and that they are aware of all options available to them. The RIPE NCC understands that "freezing" registry entries would be counterproductive and would not help its goal of ensuring registry correctness. The RIPE NCC has no intention of freezing registry entries for legacy resource holders. Also, the RIPE NCC would like to assure legacy address space holders that it has no intention of withdrawing reverse DNS services for legacy address space holders. The certification of address space, however, is available only to RIPE NCC members. Thank you for raising the issue and for giving us the opportunity to clarify these matters. As Marcus has pointed out, the information concerning the project is available on our legacy webpages: http://www.ripe.net/lir-services/resource-management/legacy-space We will update the documentation concerning the project in the coming days to accurately reflect the situation. Again, we apologise for the error and ask that you contact us at if you have any questions or concerns. Or let us know via discussion on the list. Best regards, Andrew de la Haye Chief Operations Officer RIPE NCC On 7/19/12 4:11 PM, Sander Steffann wrote: > Hi, > > Giving some background information related to address policy: > >> If I've understood correctly, both option a) and b) above involve in >> effect abolishment of historical grants and contractual submission >> to all current and future RIR address policies and procedures which >> are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting >> what is relevant. No grandfather clauses, acknowledgement of >> historical rights or explicit limitations anywhere in sight, and no >> option to amend the template contract imposed by the RIPE NCC. > > The template is defined in RIPE-452: > >> --- >> The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include: >> >> ? Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date >> ? Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database >> ? Notice that none of the provider independent resources may be sub-assigned to a third party >> ? Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources >> ? A clear statement that the resources will return by default to the RIPE NCC if >> ? The resource holder cannot be contacted >> ? The annual fee to the LIR is not paid >> ? A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time >> --- > > The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that. > > The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract. > > The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space.... > > The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract. > > But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." > > So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically. > > - Sander > > From hank at efes.iucc.ac.il Thu Jul 19 17:32:37 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 19 Jul 2012 18:32:37 +0300 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> References: <20120719.145312.391903756.he@uninett.no> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> Message-ID: <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> At 16:11 19/07/2012 +0200, Sander Steffann wrote: >So, following the acceptance of 2007-01 by the community: if the RIPE NCC >requires legacy holders to sign such a contract (contract with sponsoring >LIR) they are doing something which directly contradicts an accepted RIPE >policy... If any legacy holder already signed such a contract I strongly >feel that they should either be given the option to void the contract, or >the contract should be declared void automatically. > >- Sander What shocked me when I got the attached template was how the English was not grammatically correct and how unwilling the NCC was willing to make any change to the template. Just taking section II: II. The LIR made an appropriate control to the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. I had suggested the more correct form of: II. The LIR has established the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. but was turned down (as well as the 4 other changes I suggested to sections 2+3). This template was never brought to the membership, but is presented as a "done deal" that every legacy holder has to sign. I call it NCC out of control. -Hank -------------- next part -------------- A non-text attachment was scrubbed... Name: Template Agreement - Legacy holder and LIR.doc Type: application/msword Size: 26624 bytes Desc: not available URL: From Rogier.Spoor at SURFnet.nl Thu Jul 19 17:39:43 2012 From: Rogier.Spoor at SURFnet.nl (Rogier Spoor) Date: Thu, 19 Jul 2012 17:39:43 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <500821BA.4030101@ripe.net> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> Message-ID: <50082A3F.8060701@SURFnet.nl> Dear Andrew, Thank you for explaining that apparently there is a communication issue. Sander Steffann raised an important issue in his email: -- But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." -- Unfortunately you haven't responded to this issue yet. Can you please elaborate on this issue? regards, Rogier On 7/19/12 5:03 PM, Andrew de la Haye wrote: > Dear colleagues, > > In Phase 3 of its legacy space project, the RIPE NCC is sending emails > to contact legacy address space holders who are not RIPE NCC members and > who hold a /16 or more. > > In the emails we are sending, all three options, including the option to > register legacy address space with a sponsoring LIR, are presented to > the organisations. However, in the case of contact with three > organisations, an email was mistakenly sent that did not mention the > option to use a sponsoring LIR. > > We regret this mistake and apologise sincerely for the confusion and any > distress this might have caused. > > We are contacting the organisations concerned to ensure that the correct > message is delivered and that they are aware of all options available to > them. > > The RIPE NCC understands that "freezing" registry entries would be > counterproductive and would not help its goal of ensuring registry > correctness. The RIPE NCC has no intention of freezing registry entries > for legacy resource holders. > > Also, the RIPE NCC would like to assure legacy address space holders > that it has no intention of withdrawing reverse DNS services for legacy > address space holders. > > The certification of address space, however, is available only to RIPE > NCC members. > > Thank you for raising the issue and for giving us the opportunity to > clarify these matters. As Marcus has pointed out, the information > concerning the project is available on our legacy webpages: > http://www.ripe.net/lir-services/resource-management/legacy-space > > We will update the documentation concerning the project in the coming > days to accurately reflect the situation. > > Again, we apologise for the error and ask that you contact us at > if you have any questions or concerns. Or let us know > via discussion on the list. > > Best regards, > > Andrew de la Haye > Chief Operations Officer > RIPE NCC > > On 7/19/12 4:11 PM, Sander Steffann wrote: >> Hi, >> >> Giving some background information related to address policy: >> >>> If I've understood correctly, both option a) and b) above involve in >>> effect abolishment of historical grants and contractual submission >>> to all current and future RIR address policies and procedures which >>> are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting >>> what is relevant. No grandfather clauses, acknowledgement of >>> historical rights or explicit limitations anywhere in sight, and no >>> option to amend the template contract imposed by the RIPE NCC. >> >> The template is defined in RIPE-452: >> >>> --- >>> The details of any such contracts are outside the scope of this >>> document. However, at the minimum, all contracts should include: >>> >>> ? Notice that the LIR is responsible for liaising with the resource >>> holder to keep registration records up-to-date >>> ? Notice that the resource holder is obliged to provide up-to-date >>> registration data to the LIR and that some or all of this >>> registration data will be published in the RIPE WHOIS Database >>> ? Notice that none of the provider independent resources may be >>> sub-assigned to a third party >>> ? Notice that the resource holder is obliged to pay an annual fee to >>> the LIR for the resources >>> ? A clear statement that the resources will return by default to the >>> RIPE NCC if >>> ? The resource holder cannot be contacted >>> ? The annual fee to the LIR is not paid >>> ? A clear statement that the use of resources is subject to RIPE >>> policies as published on the RIPE web site and which may be amended >>> from time to time >>> --- >> >> The first two requirements are what is important according to the >> activity plan ("The goal of these activities will be to bring ERX and >> legacy space registration records up to the same standards of accuracy >> as address space distributed by the RIPE NCC since 1992."), and I >> don't think anybody objects to that. >> >> The next point about sub-assignments is a problem. Current legacy >> holders don't have any restrictions on what they can or can not do >> with their address space. This would suddenly limit what legacy >> holders are allowed to do, and possibly even make their existing >> network setup break the contract. >> >> The next two points about paying the bills and the addresses returning >> to the RIPE NCC if the bills are not paid also change the rights of >> the legacy holder. When they don't sign the contract their records in >> the database are frozen and the RIPE NCC "cannot guarantee the >> continuation of reverse DNS". If they sign the contract and then not >> pay the bill they lose all rights to the address space.... >> >> The last point is the most obvious problem for legacy holders. Now the >> legacy holder is subject to no policy at all, and after signing such a >> contract they are suddenly subject to all current and future RIPE >> policies. I fully understand that legacy holders don't want to sign >> such a contract. >> >> But more importantly: RIPE-452 is a result of policy proposal 2007-01, >> and that proposal explicitly excluded ERX resource holders from being >> required to sign such a contract. Quoting from 2007-01 >> (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This >> proposal does not cover number resources marked in the RIPE database >> as Early Registration (ERX) or NOT-SET. It also does not cover number >> resources listed in the RIPE database which were assigned by InterNIC >> or assigned or allocated by other Regional Internet Registries." >> >> So, following the acceptance of 2007-01 by the community: if the RIPE >> NCC requires legacy holders to sign such a contract (contract with >> sponsoring LIR) they are doing something which directly contradicts an >> accepted RIPE policy... If any legacy holder already signed such a >> contract I strongly feel that they should either be given the option >> to void the contract, or the contract should be declared void >> automatically. >> >> - Sander >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4410 bytes Desc: S/MIME Cryptographic Signature URL: From sander at steffann.nl Thu Jul 19 17:51:05 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 19 Jul 2012 17:51:05 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> References: <20120719.145312.391903756.he@uninett.no> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> Message-ID: Hi, > What shocked me when I got the attached template was how the English was not grammatically correct and how unwilling the NCC was willing to make any change to the template. > > Just taking section II: > II. The LIR made an appropriate control to the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. > > I had suggested the more correct form of: > II. The LIR has established the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. > > but was turned down (as well as the 4 other changes I suggested to sections 2+3). This is a different template than the one from RIPE-452. Are there multiple EndUser<->LIR contract templates in use? > This template was never brought to the membership, but is presented as a "done deal" that every legacy holder has to sign. Yes, I can't remember any policy proposal that specified these requirements. Where do they come from? Thanks, Sander From Niall.oReilly at ucd.ie Thu Jul 19 17:53:54 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 19 Jul 2012 16:53:54 +0100 Subject: [ncc-services-wg] Lessons to be learned (was: Destruction of trust) In-Reply-To: <500821BA.4030101@ripe.net> References: <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <07EAA2B9-614A-4BB9-A6A0-55BA386D5EFE@steffann.nl> <500821BA.4030101@ripe.net> Message-ID: <57297A60-988C-4ADE-A52E-D0E6D3EB1DE8@ucd.ie> On 19 Jul 2012, at 16:03, Andrew de la Haye wrote: > We regret this mistake and apologise sincerely for the confusion and any distress this might have caused. [and more: see archive] Better late than never. Among others, I have been trying to draw attention to the problem behind this since Vienna, privately ands publicly, including in sldes I presented at Ljubljana. Something seems to be seriously broken in the NCC's radar. I'm very glad to see what seems to be a change of course at last. I look forward to seeing indications of the appropriate lessons being learned. Best regards Niall PS. "Reply-To: noreply at ripe.net" is inappropriate -- almost always, but especially now. /N From hank at efes.iucc.ac.il Thu Jul 19 18:05:27 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 19 Jul 2012 19:05:27 +0300 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: References: <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> <20120719.145312.391903756.he@uninett.no> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20120719190412.052b9170@efes.iucc.ac.il> At 17:51 19/07/2012 +0200, Sander Steffann wrote: >Hi, > > > What shocked me when I got the attached template was how the English > was not grammatically correct and how unwilling the NCC was willing to > make any change to the template. > > > > Just taking section II: > > II. The LIR made an appropriate control to the correctness of the > information provided by the Legacy Resource Holder and wishes to register > the Legacy Resources on their LIR account on behalf of the Legacy > Resource Holder. > > > > I had suggested the more correct form of: > > II. The LIR has established the correctness of the information provided > by the Legacy Resource Holder and wishes to register the Legacy Resources > on their LIR account on behalf of the Legacy Resource Holder. > > > > but was turned down (as well as the 4 other changes I suggested to > sections 2+3). > >This is a different template than the one from RIPE-452. Are there >multiple EndUser<->LIR contract templates in use? You can download it youself from: http://www.ripe.net/lir-services/resource-management/legacy-space/template-agreement-between-legacy-holder-and-lir > > This template was never brought to the membership, but is presented as > a "done deal" that every legacy holder has to sign. > >Yes, I can't remember any policy proposal that specified these >requirements. Where do they come from? From the RIPE site as listed above. -Hank >Thanks, >Sander From sander at steffann.nl Thu Jul 19 20:01:28 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 19 Jul 2012 20:01:28 +0200 Subject: [ncc-services-wg] Destruction of trust In-Reply-To: <5.1.1.6.2.20120719190412.052b9170@efes.iucc.ac.il> References: <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> <20120719.145312.391903756.he@uninett.no> <20120718.153652.263918473.he@uninett.no> <50071179.8020903@titley.com> <20120719.145312.391903756.he@uninett.no> <5.1.1.6.2.20120719182438.052ab6c8@efes.iucc.ac.il> <5.1.1.6.2.20120719190412.052b9170@efes.iucc.ac.il> Message-ID: <3C6819F0-8DE6-4316-A5BB-7CB613C492CD@steffann.nl> >> Yes, I can't remember any policy proposal that specified these requirements. Where do they come from? > > From the RIPE site as listed above. I meant 'Who wrote them?'. Does it come from a policy proposal, or is it written by the NCC itself? - Sander From BECHA at ripe.net Fri Jul 20 17:27:56 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 20 Jul 2012 17:27:56 +0200 Subject: [ncc-services-wg] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC In-Reply-To: <20476.19063.651745.927381@switch.ch> References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> <4FFC1407.2070204@ripe.net> <20476.19063.651745.927381@switch.ch> Message-ID: <500978FC.70801@ripe.net> Dear Alexander, all, On 7/10/12 5:29 PM, Alexander Gall wrote: > You may underestimate the relevance of this document for operators :) After considering the operators feedback about RIPE-510 & RIPE555, RIPEstat developers have created another visual interpretation of RIR "delegations" data: an interactive widget in which you can query for any address space prefix (0/0, 2000::/3 or 5/8, for example) and receive a prefix size distribution as an output: https://stat.ripe.net/widget/rir-prefix-size-distribution You can use the resulting output to determine a cutting-off point for the filtering based on the minimum allocation size: for example, if the 213/8 block has only XX % prefixes smaller then /24, you might decide that it is safe to not accept those prefixes. Or you can go for the /25 or /23 instead. A data call API is also available for the scripting and creating your own favorite filters. We are interested in your feedback: - do you find this useful? - how can we improve it, so that it suits your needs even better? We already have multiple ideas for the additional features in the next release of the widget, but we are very much looking forward to hear from you and make a new widget or improve this one based on your needs! More information is available in the RIPE Labs article: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Regards, Vesna -- Vesna Manojlovic BECHA at ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net From axel at ripe.net Mon Jul 23 16:02:19 2012 From: axel at ripe.net (Axel Pawlik) Date: Mon, 23 Jul 2012 16:02:19 +0200 Subject: [ncc-services-wg] Due Diligence for the Quality of the RIPE NCC Registration Data Message-ID: <500D596B.9070300@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC procedural document, "Due Diligence for the Quality of the RIPE NCC Registration Data", has been published. The document is available at: https://www.ripe.net/ripe/docs/due-diligence The RIPE NCC has a mandate from the RIPE community to keep an up-to-date and correct Internet number resource registry. In order to comply with this mandate, the RIPE NCC performs due diligence on organisations the RIPE NCC registers Internet number resource for. This document outlines the minimum information and documentation the RIPE NCC requires to make sure that the registration data is valid and up-to-date. Regards, Axel Pawlik Managing Director RIPE NCC From shane at time-travellers.org Mon Jul 30 13:18:22 2012 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 30 Jul 2012 13:18:22 +0200 Subject: [ncc-services-wg] Classification of services as member-only, public, or something else Message-ID: <20120730131822.6f554bb6@shane-desktop> All, This announcement appeared on the IPv6 working group mailing list a few weeks back: -------------------------------------------------------------------- Date: Tue, 17 Jul 2012 14:28:37 +0200 As announced in earlier, it is possible for RIPE NCC members to do IPv6-traceroutes from all RIPE Atlas probes to IPv6 destinations. In this new article on RIPE Labs we present a first experimental analysis and a prototype visualisation of the traceroute results: https://labs.ripe.net/Members/emileaben/visualise-your-ipv6-connectivity-using-ripe-atlas -------------------------------------------------------------------- I'm interested in IPv6, but have no way to access this service since I do not work for an LIR. (To be fair, I might be able to get access by talking to the correct people at the RIPE NCC, but in general this is a closed service.) In the past, I felt like RIPE NCC services tended to be public, unless they were naturally member-oriented. However with this service, I don't see any particular connection with members... except for the fact that they pay for it of course! (An additional minor detail here is that the information comes from RIPE Atlas probes, which do not only sit in LIR networks.) What do other participants in the NCC services working group think about the RIPE NCC providing member-only services? Should there be guidelines about this, or is this something that the RIPE NCC and their members should decide on a case-by-case basis? Cheers, -- Shane From jim at rfc1035.com Mon Jul 30 15:15:37 2012 From: jim at rfc1035.com (Jim Reid) Date: Mon, 30 Jul 2012 14:15:37 +0100 Subject: [ncc-services-wg] Classification of services as member-only, public, or something else In-Reply-To: <20120730131822.6f554bb6@shane-desktop> References: <20120730131822.6f554bb6@shane-desktop> Message-ID: On 30 Jul 2012, at 12:18, Shane Kerr wrote: > What do other participants in the NCC services working group think > about the RIPE NCC providing member-only services? Should there be > guidelines about this, or is this something that the RIPE NCC and > their > members should decide on a case-by-case basis? IMO, there is no easy answer to this Shane. Though I suppose if the NCC membership require (scrutiny of?) specific member-only services, the mechanism for that could be through the General Meetings and/or board elections. The fundamental problem probably has no solution though. RIPE policy is made by an open community which by definition includes those who are not NCC members. Yet the membership pay for those policies to be implemented by the NCC. Those well-intentioned policies can sometimes have unforseen consequences, so regular reviews and impact assessments are needed. This is beginning to happen I think, though it could be made a bit clearer and perhaps be formalised somehow. The difficulty is knowing where the boundaries lie between implementation/operational aspects -- which are probably for the membership and/or NCC management to decide -- and policy considerations which would be for the RIPE community. Personally, I would not make too much of a distinction between NCC services which are member only (apart from co-ordination of numbering resources obviously) and those which are for a wider audience. The trick will be figuring out how to oversee those services: watching out for mission creep, giving NCC staff flexibility (they can't be expected to consult with everyone about everything), NCC services competing with those offered by its members, distorting an emerging market, exit strategies, cost/benefit analysis, etc. This will be a difficult balancing act and I doubt a "one size fits all" approach is viable or even desirable. So to answer your question, I'd say yes. There should be some general guidelines about this which allow things to be decided (handwave, handwave!) on a case-by-case basis. By whom? Disclaimer: Since I don't represent an LIR, anything I have to say about member-only services can be ignored. :-)