January 2010 - 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

32-bit AS Number status?
by Shane Kerr 01 Feb '10

01 Feb '10

All, I noticed that the proposed updated AS Number policy was sent to the address-policy-wg recently. There is a timeline for 32-bit AS Number in both the old and new versions, which says: "From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool." I'm not sure exactly what this means, but I think it is supposed to mean that people get 32-bit AS Numbers now. Did this happen? If it didn't, why not? Do we need to change "2010" to "2011"? Is it ever going to happen? If it did, was there any effect? I mean both from humans (angry LIRs, peasants marching on the castle with torches, riots in the streets), or on the Intertubes (ugly routing artifacts, mass reboots of boxes with old firmware, monitoring systems gone wild)? Just wondering. :) -- Shane

4 4

Reverse DNS Outage Announcement
by Sjoerd Oostdijck 22 Jan '10

22 Jan '10

[Apologies for duplicates] Dear Colleagues, At 13:50 on Thursday, 21 January, an error was introduced into the RIPE NCC's reverse DNS provisioning system. This caused reverse DNS delegations to stop working for allocations in the following range: 77.0.0.0 to 77.220.7.255 This error was triggered by an internal cleanup of our Early Registration Transfer (ERX) DNS delegations, which was being conducted as part of the RIPE NCC's Registration Data Quality (RDQ) project. The reverse DNS provisioning system was corrected again on 22 January at 09:50 (UTC). However, due to negative caching in DNS resolvers, the problem may have remained visible for a further two hours. The RIPE NCC is currently revising the reverse DNS provisioning system to prevent errors such as this occurring in future. If you have any questions or comments, please send an email to <ncc(a)ripe.net>. Regards, Sjoerd Oostdijck DNS Services Group, RIPE NCC

1 0

2009-03 "Run-out fairly" implemented
by Xavier Le Bris 21 Jan '10

21 Jan '10

[Apologies for duplicate e-mails.] Dear Colleagues, We are pleased to announce that the policy described in proposal 2009-03,"Run Out Fairly", has been implemented. Requests for IPv4 address space received on or after Friday, 22 January will be evaluated by the RIPE NCC Registration Services Department under the new policy. Full text of the policy proposal can be found at: http://ripe.net/ripe/policies/proposals/2009-03.html The following RIPE documents have been updated to reflect this policy implementation: http://www.ripe.net/ripe/docs/ripe-488.html http://www.ripe.net/ripe/docs/ripe-489.html http://www.ripe.net/ripe/docs/ripe-490.html http://www.ripe.net/ripe/docs/ripe-491.html Regards, Xavier Le Bris Registration Services

1 0