April 2015 - db-wg - mailman.ripe.net

Proposal: make phone number optional in person objects
by Shane Kerr 17 Apr '15

17 Apr '15

All, Piotr's set of proposed improvements to the RIPE database has inspired me! Proposal: Make the phone number optional in person objects. Motivation: For ages the "phone" attribute has been mandatory in person objects (since 1995 with document RIPE 49 at least). But I don't see any reason that this should be mandatory. Many people prefer to be contacted via e-mail or some other method. Oddly, "phone" is optional on role objects, which would seem to be the ideal place for help desks and the like. (I am NOT proposing that we change this.) Cheers, -- Shane

3 4

Proposal to cleanup some hack's with status values
by Piotr Strzyzewski 17 Apr '15

17 Apr '15

Dear DB-WG Members Proposal: I propose to introduce some new status lines for INET(6)NUM objects to cleanup some hacks. Problem description: Right now we have at least four category of hacks in the status lines: 1. ::/0 inet6num: ::/0 netname: IANA-BLK (...) status: ALLOCATED-BY-RIR remarks: This network in not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks. (...) 2. 0/0 inetnum: 0.0.0.0 - 255.255.255.255 (...) status: ALLOCATED UNSPECIFIED (...) 3. IPv6 allocations made by IANA to RIPE NCC inet6num: 2001:600::/23 (this is just an example) (...) status: ALLOCATED-BY-RIR # This block was actually allocated by the IANA (...) 4. IPv4 allocations made by IANA to RIPE NCC inetnum: 185.0.0.0 - 185.255.255.255 (this is just an example) (...) status: ALLOCATED UNSPECIFIED (...) Hacks no 1 and 3 looks easy. Those are definately not ALLOCATED-BY-RIR. So I propose to introduce two new status values: IPV6 for ::/0 and ALLOCATED-BY-IANA for IANA IPv6 allocations. Hacks no 2 and 4 are bit tricky. According to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region": "ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR or RIR. Assignments may be PA or PI. This status is intended to document past allocations (...)" It is quite obvious that 0/0 is not "past allocation". So I propose to introduce new status value: IPV4 for 0/0. Moreover, it looks like "ALLOCATED UNSPECIFIED" has been overused also. For example 185/8 has been allocated to RIPE NCC on 2011-02-08. This was done after many of the previous versions of the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" which include quoted definition have been published. So I propose to introduce new status value ALLOCATED IANA for such cases. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed with AP-WG and IPv6-WG. 2. There are two more hacks which could be discussed: IETF reserved blocks and legacy allocations under various RIR administration. Looking for your comments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment
by * IP - Detal 10 Apr '15

10 Apr '15

Dear Colleagues from RIPE NCC, Thank you for information. <http://www.google.pl/url?source=transpromo&rs=rssf&q=//translate.google.com…> In relation to the following e-mail we have a question. We are one of the largest ISP in Poland (we have a huge number of object registered in ripe database). We do not understand how we would add so many attributes "last-modified:" and "created:" to tens of thousands our records registered in ripe database? It takes a long time and we are obliged to modify it to the end of July 2015. The "created" and "last-modified" fields can be automatically generated to new records, but how to updated the already registered objects without manual input ? We are waiting to your reply. Kind regards, Ewa Hilmantel - Debska pl.tpsa ________________________________ From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Thursday, April 02, 2015 5:15 PM To: ncc-announce(a)ripe.net Subject: [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment Dear colleagues, The RIPE Database Working Group has asked the RIPE NCC to replace the "changed:" attribute in the RIPE Database with "created:" and "last-modified:". We want to inform the wider community, in case you have any feedback you would like to share with the Database WG. Following discussions at RIPE 69, we met with the WG chairs and finalised an implementation plan consisting of three phases: 1) Introduce the new attributes "created:" and "last-modified:" 2) Make the "changed:" attribute optional 3) Deprecate the "changed:" attribute Details of this implementation plan can be found here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… We recently informed the Database WG that Phase 1 of this implementation had been deployed to the Release Candidate environment. We are planning to deploy this to the production environment on 28 April: <https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html>https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html If you have any questions or comments, please raise them on the RIPE Database WG mailing list at <db-wg(a)ripe.net<mailto:db-wg@ripe.net>>. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

2 1

RIPE-NCC-LEGACY-MNT
by Hank Nussbacher 07 Apr '15

07 Apr '15

Not sure which list is appropriate so please reply only to the list that people point out as the one which should handle the following issue: I have modified a number of objects to be now LEGACY objects. inet-nums and aut-nums. When the object is processed and converted into a LEGACY object, RIPE auto-adds the following line to each object: mnt-by: RIPE-NCC-LEGACY-MNT This is documented here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 Policy 2012-07: Legacy holder organisations cannot change their organisation name in their org object if it is referenced by an INETNUM or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. I then noticed I needed to delete some import and export lines on my aut-num policy. No can do any more. I now get the error: Authorisation for [aut-num] AS378 failed using "mnt-by:" not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT So this now means *every* change to any legacy IP block or ASN has to go via RIPE. But I have been unable to find how to go about informing RIPE that I need to make an object modification. Any pointers would be helpful. Regards, Hank

2 2