draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
This is the draft minutes of the RIPE-23, Jan.96, DB-WG meeting. Better late than never :-( Apologies for the excessive delay. Many thanks to Kurt Kayser from ECRC Munich, for taking notes - all the typos are mine... In order to make the minutes more consistent, the sequence of the discussion is not accurately preserved for all aspects. Any additions, clarifications appreciated! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Kurt Kayser, ECRC, volunteered to take notes. The WG meeting was split into two sessions - part 1 to deal with currnt topic, problems and ideas - part 2 the more traditional stuff The proposed WG-agenda was accepted. 1. Databases and registries B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB. [ A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources. ] From the user's point of view it would be very convenient to send updates to a "local" database and have the software forward the message(s) to the appropriate database(s) according to the source: attribute. Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC. While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay. Other problems identified: - uniqueness of names / keys across different databases - lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being. - quality control on information, . like duplicate entries alert, . automatic handle assignment, . semantics for more than one person object for a given individual . Registry ID information is maintained manually, this might change by building links to objects in the public database. 2. User interface(s) - access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that supports logical AND and OR of keys. - whois "help" gives on-line documentation hypertext version being considered - An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC. - RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL-FROM only - proposal: put a pointer to whois "help" into ripe-104++ 3. Authorization and Security DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. Th Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities? In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a devlopment project with additional resources. 4. DB-SW report David Kessens offered the traditional database software report. The slides can be obtained from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz Another set of slides for the In-Addr-Check handling is available from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz - beta version V1.1 that allows (close to) real-time mirroring is available. At the time of writing these minutes (4-MAR-1996) the distribution is at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz - requests to run a mirror copy are to be sent to ripe-dbm@ripe.net - other changes include . support for the BSD DB package . better security for "network updates" . less memory consumption In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long-term consistency (because the sequntially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted. stored: <NEW | UPD> <Date> <Time> <Serial> Inclusion of the authorisation method used and the source of the update was then asked for. DFK is going to circulate a detailed proposal. In general the NCC proposes to use a keyword based mechanism on the subject: line of DB update messages to request special processing. This should eventually obsolete the multiple e-mail addresses, like auto-assign@ripe.net, which are not widely known and their use is not always properly enforced. 5. Hierarchical authorization Implementation of hierarchical authorization is initially planned for . domain name space . IP-Address-Ranges for registries . origin AS for routes Moving the description of the hierarchy and the transactions allowed at a particular level to a maintainer object was preferred over an alternate method of using a scope: attribute. 6. Handles, Object review Eventually the assignment of NIC-Handles (more precisely: RIPE handles) is being implemented. David shall circulate a propsal about the logic and the semantics to the mailing list. Reverse lookup (for person objects, at least) is being worked on. The country: attribute is being redefined to allow multiple lines with multiple values, to better reflect the real scope of an entity (like address blocks from a regional registry, AS numbers, etc.) The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency preocedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list. The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list. url: it was agreed to add a new (optional) attribute to all objects to allow for inclusion of URLs. The details to be worked out after some more tests. Format could either be plain HTML or general URI syntax. 7. Input from other WGs Already covered (see inet-rtr: for Mbone) 8. AOB None. Meeting closed. ________________________________________________________________________________ List of new actions: Daniel Karrenberg: To circulate a detailed proposal for the stored: attribute. David Kessens: To circulate a detailed proposal for the automatic handle assignement. Wilfried Woeber, Michael H. Behringer: To initiated discussion on the mailing list about the need and possible format for a role: or noc: object. Wilfried Woeber: To initiated discussion on the mailing list about the extension of the inet-rtr: object. WW, 4.3.96.
Dear Kurt, Wilfried, Thanks for producing the minutes. I have a minor note:
Wilfried Woeber, UniVie/ACOnet writes :
- other changes include . support for the BSD DB package . better security for "network updates"
I think you mixed up (or I was not clear in my presentation) two points: - We have now implemented a password controlled mechanism to overrule all security mechanisms (For adding maintainers and the like). We previously used a 'security by obscurity' mechanism. - 'Network updates' are now fully supported by the RIPE database software. Fully supported means here: If your IP address is in our access list. This mechanism is a very fast and efficient update mechanism and so far only intended for use by the registry itself. We could decide to make this mechanism available for everybody by adding a accesslist protection to the maintainer object but that will only work for objects that are protected by maintainers. We currently have the feeling that this mechanism is not providing enough data for our logfiles to track down problems... (Note: not all objects are protected by maintainers and can thus be updated by anybody *without* providing us with some useful information in our log files) [ Personal opinion mode - ON ] We probably need another authentication mechanism to make this secure enough, the mechanism is just too powerful for the old authentication methods. [ Personal opinion mode - OFF] Kind regards, David K.
[...]
The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency preocedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list. [...]
List of new actions:
[...]
Wilfried Woeber, Michael H. Behringer: To initiated discussion on the mailing list about the need and possible format for a role: or noc: object.
[...] Right, here we go:
From my perspective: I do not really *need* the role object. If this object will not be implemented, we will find some sort of a workaround by using comments in a person object. Then we would define a person "XY-NOC" for example, address and such is obvious, and the additional information we need will be put into the comment fields, using our own sub-definition, ie, we would put essentially the same thing I proposed into the comments, and only the parser would need to be different. Not nice - but it does the job.
The reason why I am pursuing this here though is that I think that the role object is really missing in the DB. And I get back to the same old example: When someone is leaving a company, and the route/AS/other objects containing this person are not updated, it looks like the AS/route/other is maintained by someone from a different organisation. And you have to make changes in all objects that refer to this person. I still maintain: An AS/route/other object is *not* maintained by persons, but for example by a NOC. The DB should reflect that, and give the possibility to get the level of abstraction right. For that you need this role object. It is just a clean solution. Okay, if others think this is too much effort, no problem with me. For the thing we want to do we have a dirty hack. I just thought it is worthwhile trying to pursue a "clean" solution first, before doing the hack. Michael
Dear all, regarding the discussion of a "NOC" object:
Message-Id: <9603081902.AA08048@ncc.ripe.net> Subject: Re: draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam To: woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 8 Mar 1996 19:01:44 +0000 (GMT) Cc: db-wg@ripe.net, woeber@cc.univie.ac.at, ncc@ripe.net From: Michael Behringer <M.H.Behringer@dante.org.uk>
[...]
The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. [...]
From my perspective: I do not really *need* the role object. If this object will not be implemented, we will find some sort of a workaround by using comments in a person object. Then we would define a person "XY-NOC" for example, address and such is obvious, and the additional information we need will be put into the comment fields, using our own sub-definition, ie, we would put essentially the same thing I proposed into the comments, and only the parser would need to be different. Not nice - but it does the job.
The reason why I am pursuing this here though is that I think that the role object is really missing in the DB. And I get back to the same old example: When someone is leaving a company, and the route/AS/other objects containing this person are not updated, it looks like the AS/route/other is maintained by someone from a different organisation. And you have to make changes in all objects that refer to this person.
From my daily experience I can only follow Michael - a NOC-object (or similar) would be extremely handy. I have some overview of data regarding contacts from our networks: we generate an internal mailing list from the contact information and see pretty well from the "undeliveries" how many are valid. The weekly rate of changes is around 1-2%. These changes are * Some of the persons just change their mail addresses but stay with their organization. Most of these can be handled because we urge people to use mail addresses like "user@organization.country", excluding hosts, if they insist on using personal mail addresses * Most of the invalid addresses are caused by people leaving their organi- zation. We urge organizations to use local mail fanouts like "group@org.cy" (we handle these locally and not via the RIPE database) instead of personal mail addresses. These are normally reachable but we do not know if the persons are still valid contacts - however, we DO have a valid contact mail address. * Very difficult to handle are persons who insist on using a personal mail address. Quite often we find that they take a new job in another organi- zation but keep their original account and mail address (sometimes for years) I estimate that the contact information is not uptodate for at least 10% of the networks. Most of the changes we do on the RIPE database is updating person information. Therefore, I think it is a very good idea to have a Role or NOC object. This does not mean that person objects are less important than before. But having this new object makes the data more consistent and uptodate. I also think that the implementation is not overly difficult - the Role or NOC object shares many components with the maintainer object. Regards Joachim Schmitz _____________________________________________________________________________ For any problem reports regarding DFN-IP, please send your e-mail to >>>>>> noc@noc.dfn.de <<<<<< DFN Network Operation Center Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6787626 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager more info: finger help@noc.dfn.de _____________________________________________________________________________
Wilfried Woeber (woeber@cc.univie.ac.at) on March 4:
The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list.
RA is also considering extending this object for more general RS peerings. Our peers need to tell us whether we should turn on route flap dampening, as transparency, etc. We are thinking of using the rpsl dictionary to make this process extensible. In other words, one would define all allowable keywords (rpsl attributes and access methods) in the dictionary, and then refer to them on the definition of the inet-rtr objects. Later if another keywords is needed, one would simply modify the dictionary. If anyone is interested in the current dictionary work, there are some transparencies under: ftp.isi.edu:rps/la-ietf/dictionary.ps.gz Comments and suggestions are welcome. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz
participants (5)
-
Cengiz Alaettinoglu -
David.Kessens＠ripe.net -
Michael Behringer -
Schmitz＠RUS.Uni-Stuttgart.DE -
Wilfried Woeber, UniVie/ACOnet