From noreply at ripe.net Wed Jun 2 17:01:05 2010 From: noreply at ripe.net (Paul Rendek) Date: Wed, 2 Jun 2010 17:01:05 +0200 Subject: [ncc-services-wg] 2010 IPv6 Deployment Monitoring Survey Now Underway Message-ID: <2E928667-2277-42E3-8CB8-EBC154DB061D@ripe.net> [Apologies for duplicates] Dear Colleagues, As announced at RIPE 60 in Prague, GNKS Consult and TNO are working with the RIPE NCC to repeat the 2009 survey on the current and future use of IPv6 throughout the RIPE NCC service region. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of the RIPE community to participate: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The purpose of the survey is to better understand where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. As it is mostly the same as the survey carried out in 2009, comparison of progress will be possible. In addition, RIPE community participation will contribute to a better understanding of the global situation, as APNIC, AfriNIC and LACNIC will also send out the request to participate to their communities. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. The survey will close on 1 July 2010. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From training at ripe.net Thu Jun 3 17:15:39 2010 From: training at ripe.net (Training) Date: Thu, 03 Jun 2010 17:15:39 +0200 Subject: [ncc-services-wg] Announcement: RIPE NCC Training Courses In-Reply-To: <4BD6A718.8010808@ripe.net> References: <4BD6A718.8010808@ripe.net> Message-ID: <4C07C71B.7060709@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From kurtis at kurtis.pp.se Sun Jun 6 20:48:14 2010 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Sun, 6 Jun 2010 20:48:14 +0200 Subject: [ncc-services-wg] RIPE NCC Services WG (draft) Minutes - RIPE 60 References: Message-ID: <1E2A66C7-471C-4C36-8045-24EBAF8343F8@kurtis.pp.se> All, please find the minutes from the NCC Services WG at RIPE60. If you have any comments or changes, please let me know. Best regards, - kurtis - Begin forwarded message: > > --------------------------------------- > > Minutes from RIPE 60 > > RIPE Meeting: 60 > Working Group: RIPE NCC > Status: Draft > Revision Number: 1 > > RIPE 60 NCC Services Working Group > Prague, 5 May 2010, 16:00 ? 17:30 > Chair: Kurtis Lindquist > > A. Administrative Matters > > ? Welcome > Kurtis Lindquist welcomed the attendees and began the session at 16:00 local time. > > ? Approval of Minutes from RIPE 59 > > Minutes from RIPE59 approved without objections. > > B. Report from RIPE NCC > > Axel Pawlik from the RIPE NCC gave a report on the RIPE NCC. The presentation is available at: > http://www.ripe.net/ripe/meetings/ripe-60/uploads/presentations/Wednesday/NCC%20Services%20WG/Pawlik-Update_from_the_RIPE_NCC.hkOj.pps > > There were no questions. > > C. RIPE Labs Update > > Mirjam Kuehne from the RIPE NCC gave an update on RIPE Labs. The presentation is available at: > http://www.ripe.net/ripe/meetings/ripe-60/uploads/presentations/Wednesday/NCC%20Services%20WG/K_hne-RIPE_Labs.Ekd0.pdf > > There were no questions. > > D. Update on the 2007-1 Project > > Arne Kiessling from the RIPE NCC gave an update on 2007-01. The presentation is available at: > http://www.ripe.net/ripe/meetings/ripe-60/uploads/presentations/Wednesday/NCC%20Services%20WG/Kiessling-Update_on_the_2007-01_Policy_Implementation_.TiOJ.pps > > Piotr Strzyzewski commented that there are some resources where you can't contact the end user. He asked if Arne used the BGP table to find out how many one could reclaim. > > Arne said not yet. He added that they know there are some that can be reclaimed, but there might be reasons why they are not announcing their prefix. > > Piotr commented that there might be some that he could reclaim. > > Arne responded that they do check the use when they receive the documents. He said that in Phase 3, they would have to ask the end-user and take this into account. > > Kurtis asked that if users were now with another LIR, if they could sign a contract with a new one? > > Arne said yes, that the new LIR could submit the documentation to the RIPE NCC and they would process it. He added that if someone hadn?t yet submitted documentation, that they could also send an email. > > Kurtis asked if the email should be sent to the hostmaster. > > Arne confirmed ?yes?, to hostmaster at ripe.net or enduser-contract at ripe.net preferably. > > Kurtis then asked if Arne had said that they had decided on a time-out when they stop reaching an end-user. > > Arne answered that this was for when they?ve tried to contact everyone, admin-c, upstream, etc., but it still needed to be decided what to do then. He asked for input. > > Kurtis replied that, in his opinion, there is only a reasonable level of attempts to find these people. After time X, RIPE NCC should simply publish all the resources and then reclaim the resources in a month or so. He then confirmed that the RIPE NCC would be writing up a proposal, and that if they start in September, which means it?ll be before the next RIPE meeting and that it would have to be discussed on the mailing list. > > Arne confirmed that there would be communication on the mailing list. > > Rudiger Volk asked that the proposals for the final decision were at RIPE 61. > > Arne confirmed that would be the case. > > Kurtis asked if it could be documented in August. > > Arne replied that August was the planned start date and that a test-run would happen in the summer where they would contact a certain number of end-users and see what kind of response they?d get. > > Wilfried Woeber asked about orphaned resources. He said he worked through a short list of resources and that there were quite a few he marked as ?not my end user', as they had since become an LIR. He asked about having a place in the LIR Portal where they could go and mark that kind of resources as 'this registry is the proper one to contact for this resource'? > > Arne agreed that it was a good idea and said they?d look into it. > > Kurtis mentioned that this was posted on the list but that there was a reason not to implement it. > > E. Small But Interesting Things > > Robert Kisteleki from the RIPE NCC gave an update from the Science Group. The presentation is available at: > http://www.ripe.net/ripe/meetings/ripe-60/uploads/presentations/Wednesday/NCC%20Services%20WG/Kisteleki-Small_but_interesting_things.c7sO.pdf > > There were no questions. > > G. Open Microphone Session > > No one came forward. > > Z. A.O.B. > > There were no more questions. > > Kurtis closed the session. Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From denis at ripe.net Tue Jun 8 12:37:21 2010 From: denis at ripe.net (Denis Walker) Date: Tue, 08 Jun 2010 12:37:21 +0200 Subject: [ncc-services-wg] "referral-by:" attribute Message-ID: <4C0E1D61.3080206@ripe.net> Dear Colleagues As a first step to clearing up long standing issues that cause confusion in using the RIPE Database, we would like to propose making the "referral-by:" attribute optional in maintainer objects. Historically maintainers were strictly controlled and users had to apply to the RIPE Database administrators to get one. This was created and "referral-by:" referenced ripe-dbm-mnt. The RFC for RPSS allowed for maintainers to be able to create other maintainers in this controlled world. The "referral-by:" attribute was intended to be an audit trail back to the root maintainer creation. This was never implemented in the RIPE Database software. Since the strict control was relaxed, we have always advised that "referral-by:" references itself. It is a redundant attribute that confuses new users. When we set up AfriNIC, they asked us to drop this attribute completely. If we make it optional now, although it is still in the RPSL definition, it can be completely ignored. Does anyone have any strong views on this either way? Regards Denis Walker Business Analyst RIPE NCC Database Group From ppalse at ripe.net Tue Jun 8 14:15:10 2010 From: ppalse at ripe.net (Paul Palse) Date: Tue, 8 Jun 2010 14:15:10 +0200 Subject: [ncc-services-wg] RIPE Database Bulk Access Service to be Cancelled as of 6 July 2010 Message-ID: <93BE1697-9B08-49D3-A6BA-05A482525315@ripe.net> [Apologies for duplicates] Dear Colleagues, We regret to inform you that due to European data protection laws, the RIPE NCC is now unable to provide the RIPE Database Bulk Access service. The Bulk Access service will be discontinued on 6 July 2010 and all contracts relating to it will be cancelled as of this date. All services provided by the RIPE NCC must abide by the restrictions imposed by data protection regulation. Due to the level of access to personal data in the RIPE Database provided to Bulk Access service users, we are no longer able to legally offer this service. For more information about personal data in the RIPE Database, please seethe RIPE Data Protection Task Force homepage at: http://www.ripe.net/ripe/tf/dp/index.html The Near Real Time Mirroring (NRTM) service offers similar functionality to the Bulk Access service but does not contain personal data. For more information about this and instructions on how to sign up for this service, please see: http://www.ripe.net/db/support/about-nrtm.html If you have any questions about the RIPE Database, the Bulk Access service or the NRTM service, please contact ripe-dbm at ripe.net. Kind regards, Paul Palse -- Database Group Manager at RIPE NCC http://www.ripe.net/info/ncc/contact.html From shane at time-travellers.org Tue Jun 8 14:54:48 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 08 Jun 2010 14:54:48 +0200 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <4C0E1D61.3080206@ripe.net> References: <4C0E1D61.3080206@ripe.net> Message-ID: <1276001688.30222.365.camel@shane-asus-laptop> Denis, On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: > If we make it optional now, although it is still in the RPSL definition, > it can be completely ignored. Does anyone have any strong views on this > either way? I'd actually suggest going further, and getting rid of it completely. I think the change could be done so that "referral-by:" attributes would be automatically removed when an addition or update was made, so that people don't have to change their software when creating maintainer objects. In theory this warning could be converted to an error at some point in the future, but I don't think it would actually ever be necessary. -- Shane From leo.vegoda at icann.org Tue Jun 8 15:11:28 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 8 Jun 2010 06:11:28 -0700 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <1276001688.30222.365.camel@shane-asus-laptop> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> Message-ID: <56B606BF-DA23-44BA-921F-9E9560B64D80@icann.org> On Jun 8, 2010, at 5:54 AM, Shane Kerr wrote: > On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: >> If we make it optional now, although it is still in the RPSL definition, >> it can be completely ignored. Does anyone have any strong views on this >> either way? > > I'd actually suggest going further, and getting rid of it completely. > > I think the change could be done so that "referral-by:" attributes would > be automatically removed when an addition or update was made, so that > people don't have to change their software when creating maintainer > objects. In theory this warning could be converted to an error at some > point in the future, but I don't think it would actually ever be > necessary. I agree with Shane. Let's clean up after ourselves. Regards, Leo From Piotr.Strzyzewski at polsl.pl Tue Jun 8 15:22:54 2010 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 8 Jun 2010 15:22:54 +0200 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <1276001688.30222.365.camel@shane-asus-laptop> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> Message-ID: <20100608132254.GL28429@hydra.ck.polsl.pl> On Tue, Jun 08, 2010 at 02:54:48PM +0200, Shane Kerr wrote: > On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: > > If we make it optional now, although it is still in the RPSL definition, > > it can be completely ignored. Does anyone have any strong views on this > > either way? > > I'd actually suggest going further, and getting rid of it completely. > > I think the change could be done so that "referral-by:" attributes would > be automatically removed when an addition or update was made, so that > people don't have to change their software when creating maintainer > objects. In theory this warning could be converted to an error at some > point in the future, but I don't think it would actually ever be > necessary. I agree with that point of view. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From Woeber at CC.UniVie.ac.at Tue Jun 8 16:55:45 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 08 Jun 2010 14:55:45 +0000 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <1276001688.30222.365.camel@shane-asus-laptop> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> Message-ID: <4C0E59F1.4070201@CC.UniVie.ac.at> Shane Kerr wrote: > Denis, > > On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: > >>If we make it optional now, although it is still in the RPSL definition, >>it can be completely ignored. Does anyone have any strong views on this >>either way? > > > I'd actually suggest going further, and getting rid of it completely. If it doesn't dere a purpose any longer, yes, I agree. > I think the change could be done so that "referral-by:" attributes would > be automatically removed when an addition or update was made, so that > people don't have to change their software when creating maintainer > objects. In theory this warning could be converted to an error at some > point in the future, but I don't think it would actually ever be > necessary. But I don't beliee in messing around with the users' input and (more or less silently) throwing away part of their submitted data. > -- > Shane IIRC, the "usual" approach was to deal with such a change in phases, like issue a warning for a while, then refuse an update if it violates the acceptable schema, and eventually cleaning up old objects that haven't been touched for a looong time. I'm sure the DB guys can refresh our memory regarding the specifics. Wilfried. From denis at ripe.net Tue Jun 8 17:19:00 2010 From: denis at ripe.net (Denis Walker) Date: Tue, 08 Jun 2010 17:19:00 +0200 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <4C0E59F1.4070201@CC.UniVie.ac.at> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> <4C0E59F1.4070201@CC.UniVie.ac.at> Message-ID: <4C0E5F64.6000307@ripe.net> Wilfried Woeber, UniVie/ACOnet wrote: > Shane Kerr wrote: > > >> Denis, >> >> On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: >> >> >>> If we make it optional now, although it is still in the RPSL definition, >>> it can be completely ignored. Does anyone have any strong views on this >>> either way? >>> >> I'd actually suggest going further, and getting rid of it completely. >> > > If it doesn't dere a purpose any longer, yes, I agree. > It never served any purpose as no code was ever written to check this audit trail. > >> I think the change could be done so that "referral-by:" attributes would >> be automatically removed when an addition or update was made, so that >> people don't have to change their software when creating maintainer >> objects. In theory this warning could be converted to an error at some >> point in the future, but I don't think it would actually ever be >> necessary. >> > > But I don't beliee in messing around with the users' input and (more or > less silently) throwing away part of their submitted data. > > >> -- >> Shane >> > > IIRC, the "usual" approach was to deal with such a change in phases, like > issue a warning for a while, then refuse an update if it violates the > acceptable schema, and eventually cleaning up old objects that haven't been > touched for a looong time. > > I'm sure the DB guys can refresh our memory regarding the specifics. > I would suggest a first phase to make it optional. Then users can stop including this attribute and, in their own time, adjust any scripts they have for generating MNTNER objects and slowly remove them from their existing maintainers. We could also include a Warning message whenever this attribute is included to say it will be deprecated soon. Then after some time, deprecate the attribute, change the syntax rules and do a bulk cleanup to remove these attributes from any old maintainers. Regards Denis Walker Business Analyst RIPE NCC Database Group > Wilfried. > > From andy at nosignal.org Wed Jun 9 10:56:21 2010 From: andy at nosignal.org (Andy Davidson) Date: Wed, 9 Jun 2010 09:56:21 +0100 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <4C0E59F1.4070201@CC.UniVie.ac.at> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> <4C0E59F1.4070201@CC.UniVie.ac.at> Message-ID: <5FC880CF-A9A8-4208-AB03-CE3D46A0771F@nosignal.org> On 8 Jun 2010, at 15:55, Wilfried Woeber, UniVie/ACOnet wrote: > Shane Kerr wrote: >> On Tue, 2010-06-08 at 12:37 +0200, Denis Walker wrote: >>> If we make it optional now, although it is still in the RPSL definition, >>> it can be completely ignored. Does anyone have any strong views on this >>> either way? >> I'd actually suggest going further, and getting rid of it completely. > If it doesn't dere a purpose any longer, yes, I agree. I agree, let's do this. [...] > IIRC, the "usual" approach was to deal with such a change in phases, like > issue a warning for a while, then refuse an update if it violates the > acceptable schema, and eventually cleaning up old objects that haven't been > touched for a looong time. > > I'm sure the DB guys can refresh our memory regarding the specifics. This sounds like the way forward with regards to implementation too. Andy From shane at time-travellers.org Wed Jun 9 11:21:54 2010 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 09 Jun 2010 11:21:54 +0200 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <4C0E59F1.4070201@CC.UniVie.ac.at> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> <4C0E59F1.4070201@CC.UniVie.ac.at> Message-ID: <1276075314.30222.634.camel@shane-asus-laptop> Wilfried, On Tue, 2010-06-08 at 14:55 +0000, Wilfried Woeber, UniVie/ACOnet wrote: > >>If we make it optional now, although it is still in the RPSL definition, > >>it can be completely ignored. Does anyone have any strong views on this > >>either way? > > > > I'd actually suggest going further, and getting rid of it completely. > > If it doesn't dere a purpose any longer, yes, I agree. Yay! We agree! > > I think the change could be done so that "referral-by:" attributes would > > be automatically removed when an addition or update was made, so that > > people don't have to change their software when creating maintainer > > objects. In theory this warning could be converted to an error at some > > point in the future, but I don't think it would actually ever be > > necessary. > > But I don't beliee in messing around with the users' input and (more or > less silently) throwing away part of their submitted data. Boo! We disagree! ;) In principle your view makes sense, but if we think about what is actually happening for the user, I tend to disagree. We can either have the following: 1. User submits a modification to the database 2. Database rejects the update and explains exactly how to fix it 3. User fixes the update 4. User re-submits the update 5. Database performs the update Or: 1. User submits a modification to the database 2. Database fixes the update 3. Database performs the (modified) update We're not talking about a substantive change - we're talking about a trivial modification that can be done completely correctly by a machine every time. I consider this somewhat akin to what happens now when you put a trailing dot on the end of a Whois query: shane at shane-asus-laptop:~$ whois -h whois.ripe.net 193.in-addr.arpa. ... %WARNING:906: trailing dot in domain query % % The key has been changed to "193.IN-ADDR.ARPA" for lookup. This is another case where we know what the user wants, make a trivial change to their input, and execute the correct command for them. We also tell the user, so they know exactly what is going on, and can change future input as necessary. I think this is a good model to follow. (Full disclosure: I think I wrote the warning in the lookup code.) > IIRC, the "usual" approach was to deal with such a change in phases, like > issue a warning for a while, then refuse an update if it violates the > acceptable schema, and eventually cleaning up old objects that haven't been > touched for a looong time. For reasons above, I prefer to avoid a phased introduction with warning followed by rejection. It adds burden to the RIPE NCC and to database users, with less benefit than just Doing the Right Thing. -- Shane From denis at ripe.net Wed Jun 9 11:55:55 2010 From: denis at ripe.net (Denis Walker) Date: Wed, 09 Jun 2010 11:55:55 +0200 Subject: [ncc-services-wg] Re: [db-wg] "referral-by:" attribute In-Reply-To: <1276075314.30222.634.camel@shane-asus-laptop> References: <4C0E1D61.3080206@ripe.net> <1276001688.30222.365.camel@shane-asus-laptop> <4C0E59F1.4070201@CC.UniVie.ac.at> <1276075314.30222.634.camel@shane-asus-laptop> Message-ID: <4C0F652B.6080600@ripe.net> Hi Shane I tend to disagree with you on this Shane. In principle I like the idea of software correcting 'obvious' mistakes. But how do we define 'obvious' and do we do this forever because no one learns from 'always corrected' mistakes? We implemented code to remove the trailing dot on rDNS objects about 5 yaers ago. We are still receiving objects today with trailing dots. Because we diligently do this for users no one bothers to fix their scripts to submit valid input. Yes we can do this again and again and again...with more fixes on this and that and the other. We will end up writing lots of functions to fix many variations and what we end up putting in the database will only vaguely match the user input. With the trailing dot we do know what the user wants. If we start adding more and more of these fixes will we really know what the user wants? Or is it better at some point to reject it and ask the user to fix it? In this case we are removing an attribute that has never been used and still confuses people. In 5 years time we don't want users to still be submitting data that they do not understand simply because we allow it and 'fix' it for them. Your analysis of the user experience is not quite right. In the first phase we have two options to make life easy for the user. Either we make the attribute optional and warn users if they use it, telling them it will be deprecated soon. Or we 'fix' it by removing the attribute and warn the user we fixed it. BUT we put a time limit on this phase. After that phase we would reject updates containing this attribute. regards denis Shane Kerr wrote: > Wilfried, > > On Tue, 2010-06-08 at 14:55 +0000, Wilfried Woeber, UniVie/ACOnet wrote: > >>>> If we make it optional now, although it is still in the RPSL definition, >>>> it can be completely ignored. Does anyone have any strong views on this >>>> either way? >>>> >>> I'd actually suggest going further, and getting rid of it completely. >>> >> If it doesn't dere a purpose any longer, yes, I agree. >> > > Yay! We agree! > > >>> I think the change could be done so that "referral-by:" attributes would >>> be automatically removed when an addition or update was made, so that >>> people don't have to change their software when creating maintainer >>> objects. In theory this warning could be converted to an error at some >>> point in the future, but I don't think it would actually ever be >>> necessary. >>> >> But I don't beliee in messing around with the users' input and (more or >> less silently) throwing away part of their submitted data. >> > > Boo! We disagree! ;) > > In principle your view makes sense, but if we think about what is > actually happening for the user, I tend to disagree. > > We can either have the following: > > 1. User submits a modification to the database > 2. Database rejects the update and explains exactly how to fix it > 3. User fixes the update > 4. User re-submits the update > 5. Database performs the update > > Or: > > 1. User submits a modification to the database > 2. Database fixes the update > 3. Database performs the (modified) update > > We're not talking about a substantive change - we're talking about a > trivial modification that can be done completely correctly by a machine > every time. > > > I consider this somewhat akin to what happens now when you put a > trailing dot on the end of a Whois query: > > shane at shane-asus-laptop:~$ whois -h whois.ripe.net 193.in-addr.arpa. > ... > %WARNING:906: trailing dot in domain query > % > % The key has been changed to "193.IN-ADDR.ARPA" for lookup. > > This is another case where we know what the user wants, make a trivial > change to their input, and execute the correct command for them. > > We also tell the user, so they know exactly what is going on, and can > change future input as necessary. I think this is a good model to > follow. (Full disclosure: I think I wrote the warning in the lookup > code.) > > > >> IIRC, the "usual" approach was to deal with such a change in phases, like >> issue a warning for a while, then refuse an update if it violates the >> acceptable schema, and eventually cleaning up old objects that haven't been >> touched for a looong time. >> > > For reasons above, I prefer to avoid a phased introduction with warning > followed by rejection. It adds burden to the RIPE NCC and to database > users, with less benefit than just Doing the Right Thing. > > -- > Shane > > > From noreply at ripe.net Thu Jun 17 11:39:45 2010 From: noreply at ripe.net (Paul Rendek) Date: Thu, 17 Jun 2010 11:39:45 +0200 Subject: [ncc-services-wg] Reminder: Global IPv6 Deployment Monitoring Survey References: <4C191AE0.9020406@ripe.net> Message-ID: [Apologies for duplicates] Dear Colleagues, This is a reminder to participate in the 2010 Global IPv6 Deployment Monitoring Survey being conducted by GNKS Consult and TNO, in collaboration with the RIPE NCC. The survey is now available at: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The survey will close on 1 July 2010. All five Regional Internet Registries have committed to soliciting participation in this survey in order to compile the most complete global IPv6 deployment data possible. The goal of the survey is to gain a better understanding of where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. Any questions concerning the survey itself should be addressed to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From agoston at ripe.net Thu Jun 17 12:37:37 2010 From: agoston at ripe.net (Agoston Horvath) Date: Thu, 17 Jun 2010 12:37:37 +0200 Subject: [ncc-services-wg] Maintenance of RIPE Database updates Message-ID: <4C19FAF1.8020801@ripe.net> [Apologies for multiple emails] Dear colleagues, As part of the continued efforts to improve its services, the RIPE NCC is migrating the RIPE Database updates service to a more advanced infrastructure. For the migration, we need to disable all updates to the RIPE Database. On 21 June 2010, between 07:00 and 08:00 (UTC), you may experience outages with the RIPE Database update services. Updates sent via syncupdates will be rejected. Updates sent via mail will be queued and processed after the migration. Other services relying on RIPE Database updates will show problems. For example, webupdates will not work and the LIR Portal will not be able to update objects. RIPE Database Queries, NRTM and any service that does not rely on RIPE Database updates will continue working without interruption. This migration is at the infrastructure level of the service. There should be no visible change to the service for users after the migration is complete. Apologies for any inconvenience this may cause. Kind regards, Agoston Horvath Database Group RIPE NCC From denis at ripe.net Tue Jun 22 17:37:54 2010 From: denis at ripe.net (Denis Walker) Date: Tue, 22 Jun 2010 17:37:54 +0200 Subject: [ncc-services-wg] Problem with RIPE Database Daily Split Files Message-ID: <4C20D8D2.1090509@ripe.net> [Apologies for duplicate emails] Dear Colleagues Over the weekend there was a problem with the generation of the RIPE Database daily split files. These are the files available on the FTP site with a text dump of operational data split by object type. If you downloaded these files with a datestamp for Sunday 20 June 2010, some of the files are truncated and do not contain the full data set. Please do not use this data. You need to download the files again with the full contents. If you download this data daily, any processing you do on the contents may have errors resulting from the data downloaded on Sunday. The RIPE NCC will improve the sanity checks on these files to prevent such events happening in future. Apologies for any inconvenience this may have caused. Regards Denis Walker Business Analyst RIPE NCC Database Group From ppalse at ripe.net Wed Jun 23 15:57:59 2010 From: ppalse at ripe.net (Paul Palse) Date: Wed, 23 Jun 2010 15:57:59 +0200 Subject: [ncc-services-wg] Changes to the RIPE Database Bulk Access Service: Further Information In-Reply-To: <93BE1697-9B08-49D3-A6BA-05A482525315@ripe.net> References: <93BE1697-9B08-49D3-A6BA-05A482525315@ripe.net> Message-ID: <047FEF2C-82A1-4AE9-853A-BF92215627A3@ripe.net> [Apologies for duplicate emails] Dear Colleagues, We recently announced the cancellation of the RIPE Database Bulk Access service as of 6 July 2010. Based on the feedback we have received so far I want to give you some additional information about what will actually change after this date. Daily Database Snapshots WITHOUT Personal Data The RIPE NCC provides daily snapshots of the RIPE Database operational data in the form of text files, split by object type. These files can be downloaded from our public FTP site. As these files do not contain personal data, will continue to offer these files on the public FTP site. Daily Database Snapshots WITH Personal Data Additional snapshots with personal data are currently available to organisations that have a contract with the RIPE NCC. These files will no longer be made available after 6 July. The Near Real Time Mirroring (NRTM) Service This service allows a remote site to receive a stream of data containing updates to operational data in near real time. This service doesn't include personal data, so the RIPE NCC will continue to provide this service to organisations who have a contract with the RIPE NCC. For more information about the NRTM service and how to sign up for the service, please see: http://www.ripe.net/db/support/about-nrtm.html I hope this has clarifies the situation. If you have any further questions or comments, please contact . Kind regards, Paul Palse -- Database Group Manager at RIPE NCC http://www.ripe.net/info/ncc/contact.html From denis at ripe.net Thu Jun 24 16:47:15 2010 From: denis at ripe.net (Denis Walker) Date: Thu, 24 Jun 2010 16:47:15 +0200 Subject: [ncc-services-wg] RIPE Database Update - Service Outage Report Message-ID: <4C236FF3.60006@ripe.net> Apologies for duplicate emails Dear colleagues, Between 22:06 and 23:21 hours (UTC) on 23 June 2010, there was an interruption to the RIPE Database Update service. The failure was in the back end of the update server. During this period, the RIPE Database Update front-end software was still running and processing updates. The back-end server failed all these updates. Users received acknowledgements for these updates showing that an internal software error had occurred. This affected all updates in this period from webupdates, syncupdates and by email. It also affected any updates attempted through the LIR Portal. If you submitted any updates during this period, please check the acknowledgement and re-submit the update if necessary. We apologise for any inconvenience this might have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group From training at ripe.net Thu Jun 24 16:41:37 2010 From: training at ripe.net (Training) Date: Thu, 24 Jun 2010 16:41:37 +0200 Subject: [ncc-services-wg] Announcement: RIPE NCC Training Courses Message-ID: <4C236EA1.7030503@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From training at ripe.net Mon Jun 28 16:58:31 2010 From: training at ripe.net (Training) Date: Mon, 28 Jun 2010 16:58:31 +0200 Subject: [ncc-services-wg] Announcement: RIPE NCC Training Courses Message-ID: <4C28B897.3070607@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From hank at efes.iucc.ac.il Mon Jun 28 17:10:01 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 28 Jun 2010 18:10:01 +0300 Subject: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <4A5F3EE9.1070603@ripe.net> Message-ID: <5.1.0.14.2.20100628175858.08875d30@efes.iucc.ac.il> At 16:53 16/07/2009 +0200, Andrea Cima wrote: >[Apologies for duplicate emails] > >Dear Colleagues, > >The RIPE NCC has published a new RIPE NCC procedural document: >ripe-475, "Independent Internet Number Resources ? Contractual >Relationship Changes between sponsoring LIR and End User" > >This document describes the steps to be taken when there are changes in >the contractual relationship between the End User of independent >Internet number resources and the sponsoring Local Internet Registry >(LIR). It also describes the scenarios in which the RIPE NCC may >de-register independent Internet number resources and what happens to >those resources once they are de-registered. > >The new document is available at: >http://www.ripe.net/ripe/docs/ripe-475.html I'd like to once again raise this issue which I did a year ago and did not get sufficient answers. Here are two scenerios that are happening: - scenerio 1: I have marked a resource as "not my end user", yet RIPE responds as follows when I request that they move the resource from my LIR to the new sponsoring LIR: "We haven't received any documentation yet. Please inform the End User of ASxxxxx to ask from their new LIR to submit the transfer request in a new ticket in enduser-contract at ripe.net." I think after a year and about a dozen emails to the old user and the new sponsoring LIR I have gone beyond my responsibility on this matter. What does RIPE intend to do with those resources that the new sponsoring LIR or the end user just can't be bothered to do the registration change? If I mark a resource as "not my end user", why are they asking "please inform the end user..." - scenerio 2: I have marked a resource as "not my end user" and have heard from the end user that they have walked away from the resource. I have requested that RIPE delete this resource yet the answer I get from RIPE is "We did not receive any reply from the End User, so we can not return ASxxxx to the free pool without their confirmation. We will send another reminder to the End User." The end user will never respond since they no longer exist or don't care to respond. At what point will RIPE reclaim the resource? I think there should be clear written procedures for these cases. Regards, Hank From sergey at devnull.ru Mon Jun 28 17:53:40 2010 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 28 Jun 2010 17:53:40 +0200 Subject: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <5.1.0.14.2.20100628175858.08875d30@efes.iucc.ac.il> References: <4A5F3EE9.1070603@ripe.net> <5.1.0.14.2.20100628175858.08875d30@efes.iucc.ac.il> Message-ID: <201842061.20100628175340@devnull.ru> Hi Hank, it seems that you can make a proposal because there is no clear procedure for such scenarios. At the moment I can not see what resources were marked as my end user or not, due to disabled functionality of LIR portal. -- Sergey Monday, June 28, 2010, 5:10:01 PM, you wrote: HN> At 16:53 16/07/2009 +0200, Andrea Cima wrote: >>[Apologies for duplicate emails] >> >>Dear Colleagues, >> >>The RIPE NCC has published a new RIPE NCC procedural document: >>ripe-475, "Independent Internet Number Resources ? Contractual >>Relationship Changes between sponsoring LIR and End User" >> >>This document describes the steps to be taken when there are changes in >>the contractual relationship between the End User of independent >>Internet number resources and the sponsoring Local Internet Registry >>(LIR). It also describes the scenarios in which the RIPE NCC may >>de-register independent Internet number resources and what happens to >>those resources once they are de-registered. >> >>The new document is available at: >>http://www.ripe.net/ripe/docs/ripe-475.html HN> I'd like to once again raise this issue which I did a year ago and did not HN> get sufficient answers. Here are two scenerios that are happening: HN> - scenerio 1: I have marked a resource as "not my end user", yet RIPE HN> responds as follows when I request that they move the resource from my LIR HN> to the new sponsoring LIR: HN> "We haven't received any documentation yet. HN> Please inform the End User of ASxxxxx to ask from their new LIR to HN> submit the transfer request in a new ticket in HN> enduser-contract at ripe.net." HN> I think after a year and about a dozen emails to the old user and the new HN> sponsoring LIR I have gone beyond my responsibility on this matter. What HN> does RIPE intend to do with those resources that the new sponsoring LIR or HN> the end user just can't be bothered to do the registration change? If I HN> mark a resource as "not my end user", why are they asking "please inform HN> the end user..." HN> - scenerio 2: I have marked a resource as "not my end user" and have heard HN> from the end user that they have walked away from the resource. I have HN> requested that RIPE delete this resource yet the answer I get from RIPE is HN> "We did not receive any reply from the End User, so we HN> can not return ASxxxx to the free pool without their confirmation. HN> We will send another reminder to the End User." HN> The end user will never respond since they no longer exist or don't care to HN> respond. At what point will RIPE reclaim the resource? HN> I think there should be clear written procedures for these cases. HN> Regards, HN> Hank From noreply at ripe.net Tue Jun 29 15:26:19 2010 From: noreply at ripe.net (Paul Rendek) Date: Tue, 29 Jun 2010 15:26:19 +0200 Subject: [ncc-services-wg] Last call to participate: 2010 Global IPv6 Deployment Monitoring Survey Message-ID: <4C29F47B.3010301@ripe.net> [Apologies for duplicates] Dear Colleagues, This is a last-call reminder to participate in the 2010 Global IPv6 Deployment Monitoring Survey, conducted by GNKS Consult and TNO in collaboration with the RIPE NCC. The survey is available at: http://www.surveymonkey.com/s/IPv6deploymentmonitoring2010 The deadline to complete the survey is this Thursday, 1 July 2010. All five Regional Internet Registries have committed to soliciting participation in this survey in order to compile the most complete global IPv6 deployment data possible. The goal of the survey is to gain a better understanding of where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 61, which will be held 15-19 November in Rome, Italy. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. Any questions concerning the survey itself should be addressed to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From arne at ripe.net Tue Jun 29 18:00:44 2010 From: arne at ripe.net (Arne Kiessling) Date: Tue, 29 Jun 2010 18:00:44 +0200 Subject: [ncc-services-wg] New RIPE NCC Procedural Document Available In-Reply-To: <5.1.0.14.2.20100628175858.08875d30@efes.iucc.ac.il> References: <5.1.0.14.2.20100628175858.08875d30@efes.iucc.ac.il> Message-ID: <4C2A18AC.1050007@ripe.net> Dear Hank, Thanks for your email. In answer to your first scenario: In order to move an independent Internet resource assigned to an End User to another sponsoring LIR, the new sponsoring LIR must submit an End User Assignment Agreement and the registration documents of the End User's organisation. This ensures that the new sponsoring LIR and the end user are aware of the changes. This is described in procedure document ripe-475 (http://www.ripe.net/ripe/docs/ripe-475.html), 3.1 (Transfer between Sponsoring LIRs). We are aware that this document also states that such requests "must come from either the current or the new sponsoring LIR". However, the old sponsoring LIR only needs to confirm that they agree with these changes. Having a resource marked as "Not My End User" is seen as a confirmation in this case. The RIPE NCC will inform both the former and new sponsoring LIR when the requested updates have been processed. Because the End Users know with which LIR they will sign an agreement, the best option is to have the new sponsoring LIR contact the RIPE NCC and provide the necessary documentation. End Users who are not going to sign an agreement with the current sponsoring LIR are responsible finding a new sponsoring LIR and signing an agreement with that LIR. The new sponsoring LIR then needs to provide the required documents to the RIPE NCC who will evaluate the documentation, approve it and move the resource to the new sponsoring LIR. Resources for which no documentation was submitted at the end of Phase 2 will become part of Phase 3 of the policy implementation where the RIPE NCC will contact the resource holders directly. In answer to your second scenario: If you've marked a resource as "Not my End User" after communicating to the resource holder and informing them that they will need to sign an agreement with a sponsoring LIR of their choice, there is nothing else you have to do. Regarding the resources which are no longer in use, please note that confirmation from the resource holder that they agree to release the resource is still required, especially if it turns out that the resources are actually still in use. Additionally, there might be other reasons why a PI prefix is not visible in the global routing table. If there is no reply from the end user after a certain period of time (90 days), the resources are de-registered. This is described in procedure document ripe-475, 4 (De-registering of Independent Internet Number Resources). As per community feedback received during the recent 2007-01 update presentation at RIPE 60, the RIPE NCC will draft a procedure for Phase 3 of the policy implementation and send it to the RIPE NCC Services Working Group Mailing List before starting the Phase 3 implementation. I hope that this has clarified the matter. Please let me know if you have any further questions. Kind regards, Arne Kiessling IP Resource Analyst RIPE NCC Hank Nussbacher wrote: > At 16:53 16/07/2009 +0200, Andrea Cima wrote: > >> [Apologies for duplicate emails] >> >> Dear Colleagues, >> >> The RIPE NCC has published a new RIPE NCC procedural document: >> ripe-475, "Independent Internet Number Resources ? Contractual >> Relationship Changes between sponsoring LIR and End User" >> >> This document describes the steps to be taken when there are changes in >> the contractual relationship between the End User of independent >> Internet number resources and the sponsoring Local Internet Registry >> (LIR). It also describes the scenarios in which the RIPE NCC may >> de-register independent Internet number resources and what happens to >> those resources once they are de-registered. >> >> The new document is available at: >> http://www.ripe.net/ripe/docs/ripe-475.html > > I'd like to once again raise this issue which I did a year ago and did > not get sufficient answers. Here are two scenerios that are happening: > > - scenerio 1: I have marked a resource as "not my end user", yet RIPE > responds as follows when I request that they move the resource from my > LIR to the new sponsoring LIR: > "We haven't received any documentation yet. > Please inform the End User of ASxxxxx to ask from their new LIR to > submit the transfer request in a new ticket in > enduser-contract at ripe.net." > I think after a year and about a dozen emails to the old user and the > new sponsoring LIR I have gone beyond my responsibility on this matter. > What does RIPE intend to do with those resources that the new sponsoring > LIR or the end user just can't be bothered to do the registration > change? If I mark a resource as "not my end user", why are they asking > "please inform the end user..." > > - scenerio 2: I have marked a resource as "not my end user" and have > heard from the end user that they have walked away from the resource. I > have requested that RIPE delete this resource yet the answer I get from > RIPE is > "We did not receive any reply from the End User, so we > can not return ASxxxx to the free pool without their confirmation. > We will send another reminder to the End User." > The end user will never respond since they no longer exist or don't care > to respond. At what point will RIPE reclaim the resource? > > I think there should be clear written procedures for these cases. > > Regards, > Hank >