- db-wg - mailman.ripe.net

[Internet-Drafts@ietf.org: [Ietf-not43] I-D ACTION:draft-ietf-crisp-iris-areg-01.txt]
by Stephane Bortzmeyer 08 Nov '02

08 Nov '02

1 0

Webupdates Release
by Can Bican 07 Nov '02

07 Nov '02

Dear Colleagues, Web based graphical user interface for updating the RIPE database, is released, and accessible from the following urls: For updating RIPE database: http://www.ripe.net/webupdates or https://www.ripe.net/webupdates For updating RIPE TEST database: http://www.ripe.net/webupdates-test or https://www.ripe.net/webupdates-test Webupdates provides a web based graphical user interface, with the functionality for: * Adding/deleting/editing objects, * Adding/deleting/changing the order of attributes in an object, * Providing password based authentication for updating. Since the latest prototype, the following improvements have been introduced: * A help page for using the interface has been added. * source: fields of new objects are now prefilled. * It is now possible to add new fields more easily via the '+' icon. * It is now possible to manipulate multi-line fields. * There are now links for querying the database and the copyright information. Your feedback is important to us. Please send any comments, suggestions, questions and criticisms to dbtools(a)ripe.net . We also provide help via e-mail through working hours. You can communicate your problems and questions about the service to ripe-dbm(a)ripe.net . Regards, -- Can Bican Database Software Engineer RIPE NCC

1 0

Major power outage in Amsterdam
by Andrei Robachevsky 07 Nov '02

07 Nov '02

Dear Colleagues, Due to some explosion/fire in a power sub-system a large part of Amsterdam lost power last night around 21:30 UTC, 7 November. This influenced the AMS-IX sites at SARA and NIKHEF. This also caused an outage for some of our external services, mainly ns.ripe.net and whois.ripe.net. We apologise for the inconvenience this might have caused. Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

1 0

Hierarchical authorisation failed, request forwarded to maintaine r ???
by Harald.Singer＠tesion.de 05 Nov '02

05 Nov '02

Hello, i have the problem to create a route-object for a customer of me. The customer will transfer his PI-Network (192.109.176.0/24, I´m CNSPLUS-MNT) from another ISP into my AS. And of course a mnt-routes:CNSPLUS-MNT exists. I need to create the new route-object, but i get the error: "Hierarchical authorisation failed, request forwarded to maintainer." I think I should be able to create such an object without assistance from another ISP. - As the ISP and I are using Crypt-PW I don´t want to send a mail with my password to this ISP (like the proposal from Daniel in this WG). - Some time ago i was able to create such objects without any assistance, what was the reason to change this behaviour? - The discussion some weeks ago doesn´t have any hints for a solution, or i missed it. - Do you have any proposal to create the object? Regards Harald -- Harald Singer Telefon: +49 (0)711/2021-847 tesion )) Telekommunikation Telefax: +49 (0)711/2021-93-847 Systemingenieur / CCIE #7326 Mobil: +49 (0)178/2021-847 Kriegsbergstrasse 11 Mail: harald.singer(a)tesion.de D-70174 Stuttgart Web: http://www.tesion.de

4 6

Hierarchical authorisation failed, request forwarded to maintaine r ???
by Marcus.Ruchti＠colt.de 05 Nov '02

05 Nov '02

Hi all, can somebody tell me why this update failed? inet-num maintainer is NONE and AS maintainer is ours ! This is an ARIN /16 network, but the /22 part of it is announced in the RIPE region.. thanks for your help!! Marcus Ruchti New FAILED: [route] 143.58.120.0/22 Hierarchical authorisation failed, request forwarded to maintainer. route: 143.58.120.0/22 descr: MAYER, BROWN, ROWE & MAW GAEDERTZ descr: ***routed per request*** origin: AS8220 mnt-by: DE-COLT-MNT changed: markb(a)de.colt.net 20020813 source: RIPE inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: NL admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT changed: bitbucket(a)ripe.net 20010529 changed: bitbucket(a)ripe.net 20020625 source: RIPE route: 143.58.120.0/22 descr: MBRG-FFM origin: AS3320 mnt-by: DTAG-RR changed: mbt(a)nic.dtag.de 20020619 source: RIPE route: 143.58.120.0/23 descr: MBRG-FFM origin: AS8354 notify: info(a)twinwave.net mnt-by: TWINWAVE-MNT changed: g.cipollone(a)twinwave.net 20020417 source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. e-mail: bitbucket(a)ripe.net admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT changed: bitbucket(a)ripe.net 20010411 source: RIPE Marcus Ruchti Internet Systemingenieur mailto:marcus.ruchti@colt.de COLT TELECOM GmbH Herriotstr. 4 D-60528 Frankfurt Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350

5 10

RE: Hierarchical authorisation failed, request forwarded to maint aine r ???
by Koepp, Karsten 05 Nov '02

05 Nov '02

Hi Harald, The database checks for matching and less specific routes first. If such a route exists (that's the case here), mnt-routes is required in this route object. And the mntners in the inetnum are being ignored. There was a lenghty discussion about the reasons of this procedure. I don't find that appropriate but maybe others can summarize why not to check the inetnum first. The outcome for me is, that whenever you want to give mnt-routes to somebody else, only do it in a route with your own AS as origin, but that's not applicable for PI. Regards Karsten > -----Original Message----- > From: Harald.Singer(a)tesion.de [mailto:Harald.Singer@tesion.de] > Sent: Monday, November 04, 2002 5:59 PM > To: db-wg(a)ripe.net > Subject: Hierarchical authorisation failed, request forwarded to > maintaine r ??? > > > Hello, > > i have the problem to create a route-object for a customer of me. The > customer will transfer his PI-Network (192.109.176.0/24, I´m > CNSPLUS-MNT) > from another ISP into my AS. And of course a > mnt-routes:CNSPLUS-MNT exists. > I need to create the new route-object, but i get the error: > "Hierarchical > authorisation failed, request forwarded to maintainer." I > think I should be > able to create such an object without assistance from another ISP. > > - As the ISP and I are using Crypt-PW I don´t want to send a > mail with my > password to this ISP (like the proposal from Daniel in this WG). > > - Some time ago i was able to create such objects without any > assistance, > what was the reason to change this behaviour? > > - The discussion some weeks ago doesn´t have any hints for a > solution, or i > missed it. > > - Do you have any proposal to create the object? > > Regards > > Harald > > -- > Harald Singer Telefon: +49 (0)711/2021-847 > tesion )) Telekommunikation Telefax: +49 (0)711/2021-93-847 > Systemingenieur / CCIE #7326 Mobil: +49 (0)178/2021-847 > Kriegsbergstrasse 11 Mail: harald.singer(a)tesion.de > D-70174 Stuttgart Web: http://www.tesion.de >

1 0

IRT object and authentication schemes
by Havard Eidnes 31 Oct '02

31 Oct '02

Hi, someone's prodded me wrt. the IRT object registration. This finally made me take a closer look at the available documentation defining this object type. I have one question (well, I may have more, but this one is the most important one, I think): In section 5 of http://www.ripe.net/ripe/docs/irt-object.html I find the following text: When adding a reference to an irt object the update of an inet[6]num should pass the following authorisation checks: * from the irt object itself as specified in one of the "auth:" attribute * from any of the mntner objects that protect the inet[6]num object (i.e. referenced using "mnt-by:" attribute). Is there a logical AND between these two items? (I think there is, but it really ought to be said explicitly, and the "should pass" phrase should be replaced by "must pass both of".) This is pretty crucial when evaluating what should be registered in the IRT object, as unwise choices (no overlap between irt auth: and mntnr auth:) on this front will at best make it very cumbersome to add IRT references to inetnum / inet6num objects, requiring nested signatures (I wonder, does the RIPE DB support that?). Oh, yes, I also think the IRT definition document needs to say a few words about what specific roles the admin-c and tech-c of an IRT object is supposed to fill. Regards, - Håvard

2 1

Summary of ERX-TF discussion
by leo vegoda 29 Oct '02

29 Oct '02

Dear Colleagues, As promised, here is a summary of the short discussion had on the <erx-tf(a)ripe.net> mailing list over the last few weeks. There have been about 15 messages in total. On 10 October we published the RIPE NCC's proposed ERX process for IPv4 to the Task Force. There were two technical queries: a request for confirmation that all contacts in both databases be e-mailed. Also, there was a request for confirmation on how reverse delegations would be handled. Substantive issues included a question on how early registrations would be handled from a policy point of view. The RIPE NCC confirmed that in the past, the majority of registrants have agreed to meet the current policy requirements for registration. However, we also noted that previous registrations have tended to be done for organisations who place a value on registration data. It was argued that the policy issues were less important than the accuracy of the registration data transferred/updated. No other issues on the transfer process were raised. It appears that the Task Force is happy with the proposed transfer process. As such, we would like to publish the proposed process in the next few days. Regards, -- leo vegoda RIPE NCC Registration Services

1 0

Improved Query Processing on RIPE Database Serve
by RIPE Database Administration 24 Oct '02

24 Oct '02

[ Apologies for multiple copies. ] Colleagues, Whois query processing for the RIPE Database Server has been revised to be more consistent and helpful to users. In the past, the server would make a number of changes to the user query without telling the user, for example removing characters that it did not understand or truncating the query. The new implementation will perform exactly the query the user requested, if possible, and give errors when not. Warnings are now returned where appropriate. A full description of the changes may be found here: http://www.ripe.net/db/whois-query-2002.html In general, all correct queries will provide exactly the same results as on the previous version of the server. If you have any questions please send them to <ripe-dbm(a)ripe.net>. Suggestions may be sent to <ripe-dbm(a)ripe.net>, or discussed on the RIPE Database working group mailing list, details of which may be found here: http://www.ripe.net/ripe/wg/db/index.html -- Shane Kerr RIPE NCC

1 0

[Ted.Hardie@nominum.com: [Ietf-not43] Working Group Last Call: draft-ietf-crisp-requirements-01.txt]
by Stephane Bortzmeyer 16 Oct '02

16 Oct '02

This is also for address registries like RIPE-NCC so I believe everybody should read this post-whois document and comment before the Atlanta meeting.

1 0