October 2009 - ncc-services-wg

New RIPE NCC Procedural Document Available
by Andrea Cima 28 Feb '11

28 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [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 Kind regards, Andrea Cima RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpfPukACgkQXOgsmPkFrjNlEwCcDtE364DhQCU0USBoK3kJhord yBgAoMbRsLFCStkXfvEaV6Mtm5b2sfxW =fKC3 -----END PGP SIGNATURE-----

8 11

Independent Resource procedure and implementation
by Daniel Suchy 28 Oct '10

28 Oct '10

Hello, I would like to open discussion related to "Action Required: Contractual Relationship for Independent Resource Assignments" emails, that almost all LIRs received from RIPE NCC in the past. I have some notes from perspective of small LIR (or from perspective of person helping running multiple small LIRs). My first note points to system in general. Although RIPE NCC has many required informations in own existing databases already, it requires additional action from LIR in general. Typical small LIR has one or more PA allocations and exactly _one_ autonomous system registered. In RIPE database, there are records matching allocated PA prefix and ASN (route objects with proper origin AS and related inetnum objects, many ASNs has paired LIRs org: in aut-num object). In addition, RIS service (with history!) can be used for verification of these informations obtained automatically from database. For incomprehensible reason, RIPE NCC doesn't use these informations at all and instead of this abuses ALL LIRs with submiting simple form with exactly one record within it. I thing RIPE RCC has enough resources (financial and human) to do that automatically. My second note points to implementation of this new tool. I discovered, that I'm not able to "new" tool used for confirmation. I'm using PKI login feature and I have one identity paired with more LIRs. Although I'm able login to the LIR portal and modify everything I need with my certificate, I'm _NOT_ able to update informations on "Independent Resources" page. The main reason is, that RIPE NCC created new and separated (!) tool instead of simple integration of new feature/functionality to existing LIR portal. So, instead of reusing existing code used for LIR portal authentication, new outside code was developed for this new tool. And this new code doesn't implement all authentication features from LIR portal. In my point of view, this is quite unprofessional approach of modern application development. Aplications should be multi-layer, allowing easy new feature implementation. I reported this issue to RIPE NCC on friday last week, but first "answer" I received yesterday from RIPE NCC was initiation of audit in one LIR. Just fortuitous event? I don't believe. I have no problems with audit itself, I have all records, but this takes some additional time (and of course, money). Just because I claimed some problems to RIPE NCC staff due to problematic internal _implementation_ of new policy. Ok, I would like to open public discussions about this problem. There are some questions to answer and discuss: * why RIPE NCC just doesn't use informations from RIPE database in case of their availability and verifiability, why abuses small LIRs instead * why aren't RIS data used for automatic obtaining of requested informations, where this can be applicable * why RIPE NCC didn't integrate "confirmation" tool to existing LIR portal and why new outside application with _limited_ functionality was developed instead of reusing of existing code and functionality * what architecture is used for LIR portal in general, can be there easily implemented new features Of course, I understand, that there are large LIRs and some historic mess, where this action may be required due to lack of records in existing databases. But, I think this is NOT a case of LIRs started in past couple of years, where all required data should be available. With regards, Daniel

13 28

IP geolocation services
by Vegard Svanberg 03 Nov '09

03 Nov '09

We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services. A quick web search reveals that this is a pretty common problem. While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs. I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations. Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this). Apologies in advance if this has been discussed before -- I searched the archive, but got no hits. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801

10 17

Re: [ncc-services-wg] IP geolocation services
by Arkley, Patrick 28 Oct '09

28 Oct '09

Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin(a)ripe.net <ncc-services-wg-admin(a)ripe.net> To: Vegard Svanberg <vegard(a)monsternett.no> Cc: ncc-services-wg(a)ripe.net <ncc-services-wg(a)ripe.net> Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote: > We've recently experienced a storm of customer complaints after starting > to use IP addresses from a new allocation/assignment. The IP block was > earlier in use by a German company. The result is that services like > Google and Yahoo assume users are from Germany and presents content > accordingly. Some users have also reported that they are excluded from > certain services. > > A quick web search reveals that this is a pretty common problem. > > While not blaming RIPE or the other RIRs, we believe this problem should > be addressed, and that the initiative has to come from the RIRs. > > I would like to propose that RIPE NCC works together with other RIRs to > see if it's possible to implement procedures/routines to notify > providers and users of IP geolocation services of new, relocated and > deleted allocations. > > Also, one should probably consider if it's a need for a (distributed?) > database with more fine-grained location data than the whois database > currently provides (also, I've been told that licensing issues prohibits > geolocation providers from using the RIR DBs directly, but I've not been > able to verify this). > > Apologies in advance if this has been discussed before -- I searched the > archive, but got no hits. > Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009– huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige

7 13

FW: [ipv6-wg] Publication of default assignment sizes for end-user network ?
by michael.dillon＠bt.com 28 Oct '09

28 Oct '09

You might want to have a look at this idea as a way to kill two birds with one stone. -----Original Message----- From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of michael.dillon(a)bt.com Sent: 28 October 2009 13:38 To: ipv6-wg(a)ripe.net Subject: RE: [ipv6-wg] Publication of default assignment sizes for end-user network ? > Now this does not forbid you to register individual assignments into > the public database, but doing so poses various problems. Not only the > sheer number of assignments can be a problem, but also keeping that > registration up-to-date will have serious impact on your day to day > operations and especially with residential users there might be > privacy issues as well. If we would have a distributed database protocol to extend the RIPE database into the LIRs, then this would not be an issue. I'm thinking of something like DNS. For instance, if I need to look up data on three /48s in fdb8:e914::/32 I would first send a lookup request to RIPE. The RIPE db would tell me that all data for fdb8:e914::/32 is in a server at fdb8:e914::dbdb. I would cache that information, and send my first lookup request to the distributed server. After getting my reply, I would prepare to send the second request for fdb8:e914:c20f::/48, notice that the /32 is already in my cache, and use the cached server instead. This is roughly the way DNS lookups work with the result that the detailed data does not have to be kept in one central location. I would like to see the RIPE db move in the same direction. At the same time, I would like to see the spec opened up a bit so that the distributed server operators would be free to add additional attributes to existing objects, and additional objects so that there is the possibility of using the same distributed lookup mechanism for geographic or language identifications as well. --Michael Dillon

1 0

New rules for reverse domain object creation in the RIPE Database
by Denis Walker 22 Oct '09

22 Oct '09

Dear Colleagues, [Apologies for duplicate emails] A proposal has just been sent to the DNS Working Group (DNS WG) mailing list about additional checks on creating reverse delegation DOMAIN objects. If you wish to comment, please do so on the DNS WG mailing list. This will keep any discussion concentrated in a single thread. Regards, Denis Walker Business Analyst, Database Group RIPE NCC

1 0

Proposal to Remove Routing Requirements from the IPv6 Address Allocation Policy Implemented
by Nathalie Trenaman 08 Oct '09

08 Oct '09

Dear Colleagues, We are pleased to announce that policy proposal 2000-06,"Removing Routing Requirements from the IPv6 Address Allocation Policy", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-06.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-481.html The following FAQ has also been updated to reflect this policy implementation: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Nathalie Trenaman Registration Services RIPE NCC

1 0

RE: RIPE NCC Services Working Group - Draft Agenda - Updated
by Sanghani, Bijal 06 Oct '09

06 Oct '09

Please see below Updated Draft Agenda for the NCC Services Working Group - A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 58 * Finalise agenda B. RIPE NCC Update - Axel Pawlik, RIPE NCC C. Contractual Relationship Requirement for End Users - Andrea Cima, RIPE NCC D. Certification Update, Alex Band, RIPE NCC E. Discussion about inet(6)num and aut-num objects to reference sponsoring LIR - Piotr Strzyzewski F. 2007-01 implementation survey. Discussion - Piotr Strzyzewski G. Recovering resources assigned to non-existing entities - Uwe Manuel Rasmussen I. Registration Data Quality Update - Robert Kisteleki H. Open Microphone Session Z. A.O.B. Regards, Bijal The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

1 0

IPv6 Assignment to RIPE NCC
by Axel Pawlik 02 Oct '09

02 Oct '09

Dear Colleagues, Following the approval of Policy Proposal 2009-02, "Allocating/Assigning Resources to the RIPE NCC", the RIPE NCC requested that an IPv6 PI assignment be assigned to it for RIPE Meetings. The RIPE NCC pool of arbiters decided, based on RIPE Policy Document ripe-476, “Allocating/Assigning Resources to the RIPE NCC", that the request met the criteria for the assignment of PI IPv6. For more information on the RIPE NCC's initial request to the arbiters, and details of the arbiters' decision, see: http://www.ripe.net/info/ncc/ipv6-pi-request-to-arbiters.pdf For more information on the arbiters, see: http://www.ripe.net/membership/arbitration.html Best regards, The Arbitration panel and Axel Pawlik Managing Director RIPE NCC

1 0

RE: RIPE NCC Services Working Group - Draft Agenda - Updated
by Sanghani, Bijal 02 Oct '09

02 Oct '09

Please see below Updated Draft Agenda for the NCC Services Working Group - A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 58 * Finalise agenda B. RIPE NCC Update - Axel Pawlik, RIPE NCC (30 minutes) C. Contractual Relationship Requirement for End Users - Andrea Cima, RIPE NCC (15 minutes) D. Certification Update, Alex Band, RIPE NCC E. Discussion about inet(6)num and aut-num objects to reference sponsoring LIR - Piotr Strzyzewski (10 mins) F. Recovering resources assigned to non-existing entities - Uwe Manuel Rasmussen (10 mins) G. Open Microphone Session Z. A.O.B. Regards, Bijal The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

1 0