May 1997 - db-wg - mailman.ripe.net

New Document available: RIPE-157
by RIPE NCC Document Annoucement Service 30 May '97

30 May '97

New/Revised RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-157 Title: RIPE NCC Database Documentation Author: A. M. R. Magee Date: 29 May 1997 Format: PS=1145210 TXT=187252 Obsoletes: ripe-153 Ref: ripe-153 Title: RIPE NCC Database Documentation Author: A. M. R. Magee Date: 28 Jan 1997 Format: PS=788674 TXT=137793 Obsoletes: Version 1.2 of the document. Obsoleted by: ripe-157 Short content description ------------------------- This is an updated version of ripe-153. It includes information on the new whois -v feature, the new output from whois -t, hierarchical authorisation of the creation of inetnum objects, mirroring the RIPE Database, appendixes containing descriptions of the attributes and the objects. Comments to <ripe-dbm(a)ripe.net>. Accessing the RIPE document store --------------------------------- You can access the RIPE document store via the World Wide Web; RIPE-157 is available from the WWW at the following URL: http://www.ripe.net/docs/ripe-157.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The full filenames of the new documents on the FTP-server are: ripe/docs/ripe-157.ps for the PostScript version ripe/docs/ripe-157.txt for the plain text version Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to <mail-server(a)ripe.net> with "send HELP" in the body text. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

RIPE 27 Database Workshop Slides.
by RIPE Database Administration 29 May '97

29 May '97

Dear Colleagues, The slides of the Database Workshop which was run at RIPE 27 are available at: <http://www.ripe.net/meetings/ripe/ripe-27/pres/db> <ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-magee-db-workshop.ps.…> If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

New Database Document
by RIPE Database Administration 22 May '97

22 May '97

Dear Colleagues, The Database Document, ripe-153, is obsolete. It is superceded by ripe-157, available at: <http://www.ripe.net/db/doc.html> <ftp://ftp.ripe.net/ripe/docs/ripe-157.ps> <ftp://ftp.ripe.net/ripe/docs/ripe-157.txt> Help on using whois is available by doing whois HELP Help on creating, updating and deleting objects is available by sending mail to <auto-dbm(a)ripe.net> with HELP in the Subject line. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

subscribe db-wg
by Dieterle 21 May '97

21 May '97

subscribe db-wg

1 0

(rough) draft agenda for DB-WG mtg. during RIPE 27
by Wilfried Woeber, UniVie/ACOnet 17 May '97

17 May '97

Dear all! This is the initial, and still very rough, draft of a proposed agenda for the RIPE DB-WG Meeting, currently scheduled for Tue, May 22. Due to the fact that the workload here at home is extremely high at the moment, and that we only got a 60min slot assigned, I have to be considerably less ambitious this time. Please bear with me. Here you go... See you in Dublin, Wilfried. ~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-27, May 1997, Dublin 1st Draft, May. 17, 1997 A. Administrative stuff (W.Woeber, chair) 10min - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions B. New functionality, proposals, reports 30min - Database Referral mechanism (Q: rhois compatibility ?) - Database consistency - Security and Authentication (if time permits) B. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) 10min - operational changes (handles mandatory) - new functionality implemented and bugs fixed - documentation (current status, progress) - feedback from the users (DB WS usefulness?) G. General input from other WGs 10min - Hier. Authorisation and Notification in the RR (Routing WG) Z. AOB WW, 17-MAY-1997 21:22:05 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

whois -v option.
by RIPE Database Administration 16 May '97

16 May '97

Dear Colleagues, A new feature is available in the RIPE Database; "whois -v". This option displays detailed information of any type of object that is accepted by the RIPE database. Each attribute of the object is briefly described, as is the object itself. A more detailed template of the object is also given. A full list of objects is available by typing "all" after the "-v" option. The new, detailed template only is available using "whois -t". A full list of objects may be obtained by typing "all" after the "-t" option. The new template lists each of the attributes of an object together with a list of flags. Flags are enclosed in square brackets and separated within the list by white space. The flags are ... [mandatory] - An object MUST NOT contain zero instances of this attribute. [optional] - An object MAY contain zero instances of this attribute. [single] - An object MUST NOT contain more than one instance of this attribute. [multiple] - An object MAY contain more than one instance of this attribute. [look-up key] - Attribute is indexed. [inverse key] - Attribute is in the 'reverse' index. (use -i) [primary key] - Attribute is (part of) the primary key. [primary/look-up key] - Attribute is both indexed and is (part of) the primary key. The "-t" option does not display a list of obsolete attributes, as before. The "-v" option must be used. Example: [an-lar]$ whois -h whois.ripe.net -t person person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [look-up key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] To use "whois -v", you will need a new whois client. The new version of the whois client is available at <ftp://ftp.ripe.net/tools/ripe-whois-tools-2.1.tar.gz> If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

3 2

whois -v option.
by RIPE Database Administration 16 May '97

16 May '97

Dear Colleagues, A new version of the C client for whois is available at ftp://ftp.ripe.net/tools/ripe-whois-tools-2.2.tar.gz Thanks to Steven Bakker for the patch. However, the problem appears to be system dependent as I never had a core dump with "whois -t xyz" or "whois -v abc". If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Hierarchical Authorisation in the RR
by Carol Orange 15 May '97

15 May '97

Hi again, Here is another brief proposal for your perusal. This time for an implementation of hierarchical authorization in the Routing Registry. The mechanism described below will implement a hierarchy in the RR for which I believe there is consensus. The ideas in the proposal below were sifted from discussions which took place on the <routing-wg(a)ripe.net> mailing list and in the Routing WG meetings at RIPE-25 and RIPE-26. Please review this if you have time. We are hoping to have a go ahead on this from the Routing and Database WG's at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC -------------------------------------------------------------------- Hierarchical Authorisation in the RR Proposal for an Implementation Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. Whereas extensive discussion took place on the extent to which authority can be established in the RR, there was clear agreement that the maintainer of an AS should have authority over what routes are announced with a given aut-num in the "origin:" attribute. In the following, we specify an implementation to support the authority of "aut-num:" maintainers to determine who can announce routes under their AS. The mechanism can be extended as the need arises and consensus on other forms of authorization is achieved. For more information on the discussions leading up to this proposal, see: http://www.ripe.net/wg/routing/haro-d.html. Implementation -------------- If you (or your organization) manages an AS, then you should have authority over the routes announced in your AS. This can be implemented if we: a) add a "mnt-lower:" attribute to the aut-num object b) allow routes to be announced with a given "origin:" by those given authority as defined in the mntner object specified in the "mnt-lower:" attribute of the aut-num object. Example ------- If we add a "mnt-lower:" attribute to the aut-num object of the RIPE NCC, then only those who know what peEw8Gb4xBNqI encrypts can add and remove routes originating in AS3333. ---- aut-num: AS3333 ... mnt-lower: AS3333-MNT ... ---- mntner: AS3333-MNT descr: RIPE-NCC Maintainer ... auth: CRYPT-PW peEw8Gb4xBNqI ... ---- route: 193.0.0.0/23 descr: RIPE-NCC origin: AS3333 ... Summary ------- Other forms of hierarchical authorization and notification can be implemented in the future if a well defined hierarchy can achieve consensus. To provide some initial functionality which may meet the needs of many RR users, we propose to implement the above in the short term.

2 2

Re: whois -v option.
by Steven Bakker 15 May '97

15 May '97

==> From: RIPE Database Administration <ripe-dbm(a)ripe.net> ==> Thu, 15 May 1997 13:02:17 +0200 > To use "whois -v", you will need a new whois client. The new > version of the whois client is available at > > <ftp://ftp.ripe.net/tools/ripe-whois-tools-2.1.tar.gz> And it still goes "boom" when you try to use "whois -v" or "whois -t": kappa-~ & whois -v netnum zsh: 5855 segmentation fault (core dumped) whois -v netnum I have a patch for it (incidentally identical to the one I sent in last September ;-), which I'll attach below. It's basically a tiny error in the argc/argv handling. Cheers, Steven

2 1

X-Notification in the RR
by Carol Orange 15 May '97

15 May '97

Hi all, The following is a proposal for a cross notification mechanism in the Routing Registry. I post it for your perusal and hope to discuss it during the Routing WG meeting in Dublin. The initial suggestion was made by Daniel Karrenberg at the Routing WG meeting in January, and discussions with Joachim Schmitz and Wilfried Woeber have helped me work it into the following proposal. Such a mechanism was given a high priority by those who participated in the recent RIPE Database priority survey, so we are hoping to reach consensus on this at or shortly after RIPE-27. Greetings, Carol Orange RIPE NCC ---------------------------------------------------------------------- Cross Notification in the Routing Registry A Proposal Carol Orange, May 1997 At the January meeting of the Routing WG in Amsterdam, various possible hierarchies for authorization in the Routing Registry (RR) were considered. During the discussion, a suggestion was made that "hierarchical notification" would be useful even in cases where authority is not well defined. This suggestion enjoys strong support of both the Routing WG and the Database WG. In the following, we propose a simple cross notification mechanism which will allow routing registry users to be notified of overlapping route announcements in the RR. Route Announcement Notifications in the RR ------------------------------------------ Suppose you announce a route in your address space covering some /24. It may be useful when you make the announcement, to know that the /24 has already been announced in another AS. Likewise, should the user of that address space later decide to become multi-homed, it may be interesting to know that as well. Moreover, overlapping routes are often unintentionally announced in a single AS. In all of these cases, it would be useful to get a notification from the RR. Consider the route object: route: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] origin: [mandatory] [single] [primary key] hole: [optional] [multiple] [ ] withdrawn: [optional] [single] [ ] comm-list: [optional] [multiple] [ ] advisory: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Suppose we add a new field called "x-notify:" (cross-notify) which a) can contain either + a NIC-handle pointing to a person or role object, the email address of which will get the notification; or + a mntner ID pointing to the maintainer who will be notified b) is optional The contact in "x-notify:" will receive an e-mail whenever + a route is announced with overlapping address space + the address range in the route being added (with the "x-notify:" attribute) overlaps any address space currently announced in the RR. Issues ------ Does this cross notification satisfy the needs of network operators? Due to the global nature of the RR, some effort will be involved to provide notifications in a timely manner. What is an acceptable upper bound for cross notifications to be sent out? Using a NIC-handle or mntner for notification is different than the traditional e-mail address. However, it simplifies data maintenance for users significantly.

1 0