- db-wg - mailman.ripe.net

new bug fix release of prtraceroute
by David.Kessens＠ripe.net 28 Mar '96

28 Mar '96

Hi all, After getting tired of the requests why prtraceroute didn't do what people hoped it should do, I fixed some of the bugs... (and found some new ones). It's highly recommended to upgrade since this release also does a better job in skipping funny modern objects that caused the impression that the whole Internet was in AS1800... and yes the software runs with perl5 now. The code is available from: ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta4.tar.gz If you have any further questions, please don't hesitate to contact me again, Kind regards, David Kessens ---- New in 2.0 BETA 4 1. new quad2int routine due to perl5 problems with bit shifts and some other minor perl5 fixes This version is supposed to work with perl5 now Note that the other PRIDE tools don't!!!! 2. removed hardcoded SOCKSTREAM (for Solaris) and port value 3. The tool skips now route objects with origin=AS0 4. The tool skips now route objects with prefix 'x.x.x.x/0-5' 5. The inet-rtr lookup works again (did nobody notice that the RIPE whois server doesn't support use of two '-T' options...) 6. More robust code for interfacing with different versions of traceroute. Note that more robust doesn't mean good code, there is still some work left... 7. The AS macro expansion didn't work with AS lists that contained other AS macros 8. The policy evaluator had a bug which has been worked around. ------

1 0

update: minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 21 Mar '96

21 Mar '96

This is the updated minutes of the RIPE-23, Jan.96, DB-WG meeting. Corrections submitted by David Kessens wrt "network updates" and "security" have been included. Best regards, 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(a)ripe.net - other changes include . support for the BSD DB package . a password controlled mechanism to overrule normal security mechanisms (e.g. for adding maintainers and the like) . "network updates" are now fully supported by the RIPE-DB SW. Fully supported means: "If your address is in the RIPE-DB access list" However, this is a very powerful method and currently does not provide enough data for the logs to track down problems. For further study, before being made available to the community at large. . 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(a)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, 21.3.96

1 0

RE: polling for ripe dbase software changes (fwd)
by Wilfried Woeber, UniVie/ACOnet 19 Mar '96

19 Mar '96

Hi Cengiz, hi David! >We would like to hear the opinion (positive or negative) of the RIPE >database working group on the following proposals *before* changes are >made to any of the RIPE database implementations. We might want to >discuss things at the RIPE database working group session at the next >RIPE meeting in Berlin. Well, before I can develop an opinion, I'd be interested in the motivation and/or expected benefits for the proposed modifications. My first *feeling* (note, nothing more than a feeling!) is that things that belong to an external representation and a user interface should not be part of the data stored in some database. Another aspect might be multi-language support. Of coure, you can translate the syntactic sugar into syntactic salt :-) BTW, my feeling (again) with regard to the continuation stuff is that it might make sense to improve things. As it stands right now, it is not really simple to comprehend (for humans). Give me more input, then I can make up my mind. Best regards, Wilfried.

2 1

polling for ripe dbase software changes (fwd)
by David.Kessens＠ripe.net 19 Mar '96

19 Mar '96

Dear all, We would like to hear the opinion (positive or negative) of the RIPE database working group on the following proposals *before* changes are made to any of the RIPE database implementations. We might want to discuss things at the RIPE database working group session at the next RIPE meeting in Berlin. Kind regards, David Kessens RIPE NCC ---- > Cengiz Alaettinoglu writes : > From owner-rr-impl Wed Mar 13 20:11:16 1996 > Date: Wed, 13 Mar 1996 11:12:08 -0800 > Posted-Date: Wed, 13 Mar 1996 11:12:08 -0800 > Message-Id: <199603131912.AA16151(a)cat.isi.edu> > From: Cengiz Alaettinoglu <cengiz(a)ISI.EDU> > To: rr-impl(a)ripe.net > Subject: polling for ripe dbase software changes > X-Organisation: USC / Information Sciences Institute > X-Phone: +1 (310) 822 1511 x219 > X-Fax: +1 (310) 823 6714 > > > Hi folks, > > RA is considering: > 1) for db-update to bounce back objects which uses ripe-181 style > line continuations as error. > 2) making the sugar words mandatory on as-in/out, i.e. from to > announce accept. > 3) not deleting these sugar words from the objects while storing them > into the database file (and not reinserting them on whois). > > We would like to know, if there is a strong opinion against > this. Particularly, we would like to know if things would break in > your site if we did this. > > Thanks. > > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California > http://www.isi.edu/~cengiz

2 1

draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 11 Mar '96

11 Mar '96

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(a)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(a)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.

5 4

Re: Internet Draft Submission (fwd)
by Gabor Kiss 23 Feb '96

23 Feb '96

> > George Eddy writes : > >From eddy(a)ISI.EDU Thu Feb 22 22:12:26 1996 > Date: Thu, 22 Feb 96 13:07:22 PST > Posted-Date: Thu, 22 Feb 96 13:07:22 PST > Message-Id: <9602222107.AA16189(a)kit.isi.edu> > From: George Eddy <eddy(a)ISI.EDU> > To: rps(a)ISI.EDU > Subject: Internet Draft Submission > Geographic Location Extension to Ripe-181 > 3.2 Direct and Indirect Location > > This method proposes the addition of a ``location'' attribute to the > aut-num as in 3.1. This attribute could directly hold the LocString, or > the name of a ``location'' object. The location object could be defined > as: > > location: [mandatory] [single] > loc-string: [mandatory] [single] > descr: [optional] [multiple] > notify: [optional] [multiple] > mnt-by: [optional] [multiple] > changed: [mandatory] [multiple] > source: [mandatory] [single] > > Using the example in section 3.1, we would have the following: > > aut-num: AS8800 > location: IrvineCA > ... > > and the object ``IrvineCA'' would be: > > location: IrvineCA > loc-string: 33 40 10n 117 49 20w 10m > descr: Example location object in Irvine, CA. > notify: eddy(a)isi.edu > mnt-by: MAINT-EXAMPLE > changed: eddy(a)isi.edu 960220 > source: EXAMPLE > > The loc-name could be any string desired by the creator. Dear Eddy, Can two or more AS-es share the same location object? How to coordinate the loc-name assignments. In Europe tipically there are more then one AS within the same city. They will race for the simple name of the city. Just like for domain names. :-/ Maybe the RIPE predefine location objects for the main cities. Regards Gabor

2 1

Internet Draft Submission (fwd)
by David.Kessens＠ripe.net 23 Feb '96

23 Feb '96

> George Eddy writes :

2 1

Internet Draft Submission
by George Eddy 22 Feb '96

22 Feb '96

Internet Draft Rusty Eddy Expires August 27, 1996 USC/ISI draft-ietf-rps-location-00.txt February, 1996 Geographic Location Extension to Ripe-181 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Introduction This document describes two proposals for specifying geographic location of a database objects such as an Autonomous System (AS). This information could be used by mapping tools that provide geographic maps of the Internet topology. Two alternatives are documented here, the first proposal uses a new attribute added to a database object. The attribute provides longitude, latitude and size information. The second method also uses a new location attribute added to the database object, this new attribute contains the name of a location object that we propose. The two methods describe direct and indirect location information respectively. 2. Format of Location String The format of the geographic ``location string'' or LocString will be a single string consisting of the latitude, longitude and optionally the size. The latitude and longitude are each represented by one to three integers corresponding to degrees, minutes and seconds, with a direction appended to the final integers of the latitude and longitude. If minutes and/or seconds are not provided values of 0 will be assumed and size will default to 0, a point. The directions are north, south, east and west. Rusty Eddy Expires August 27, 1996 [Page 1] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 For example, the LocString for Irvine, California is: 33 40 10n 117 49 20w 10m Representing 33 degrees, 40 minutes and 10 seconds north latitude, and 117 degrees, 49 minutes and 20 seconds west longitude with a 10 meter encompassing circle. Informally the LocString would be of the form: "LA [MM [SS]](n|s) LO [MM [SS]](e|w) [SIm]" Where, LA and LO are integers representing the degrees latitude and longitude, respectively. MM is an integer representing the number of minutes. SS is an integer representing the number of seconds. The characters 'n', 's', 'e', 'w' and 'm' are literals corresponding to north, south, east, west and meters, respectively. 3. Proposals for AS Geographic Location The following proposals are similar, the first suggests a new attribute to the Ripe-181[1] aut-num object, the second also suggests new aut-num attribute and a new ``location'' object. The following examples use the aut-num object, however, they may be equally applied to the as-macro, inet-rtr or route objects as well. Attributing locations to these other database objects would provide the geographic topology internal to an AS, which may represent reality more accurately. 3.1 Direct Location This method proposes a new aut-num attribute, ``location''. This attribute is a single, optional attribute: aut-num: [mandatory] [single] ... location: [optional] [single] The ``location'' attribute will contain a LocString. For example, say AS8800 is an ISP in Irvine, California, it's aut-num could contain the following: aut-num: AS8800 location: 33 40 10n 117 49 20w ... 3.2 Direct and Indirect Location This method proposes the addition of a ``location'' attribute to the aut-num as in 3.1. This attribute could directly hold the LocString, or Rusty Eddy Expires August 27, 1996 [Page 2] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 the name of a ``location'' object. The location object could be defined as: location: [mandatory] [single] loc-string: [mandatory] [single] descr: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Using the example in section 3.1, we would have the following: aut-num: AS8800 location: IrvineCA ... and the object ``IrvineCA'' would be: location: IrvineCA loc-string: 33 40 10n 117 49 20w 10m descr: Example location object in Irvine, CA. notify: eddy(a)isi.edu mnt-by: MAINT-EXAMPLE changed: eddy(a)isi.edu 960220 source: EXAMPLE The loc-name could be any string desired by the creator. 4. Problems One obvious problem with using geographic layout inherent to networks, is that they often span large geographic areas, this is true of many ISPs. When attributing a location to an AS, one must pick a single location to be representative of the AS. The internal topology of an AS may be mapped geographically when a location attribute has been added to the inet-rtr or route objects. 5. Conclusion The motivation for providing geographic locations was prompted by the development of the Internet Routing Registry (IRR) visualization tool (IRRv) as a possible method for topological layout. Methods for obtaining the LocString are beyond the scope of this document, however, it should be noted that RFC 1876[2] specifies a means for containing location information in Domain Name System. Also worth noting is a ``Geographic Nameserver'' at http://www.mit.edu:8001/geo, that derives its information from the Geographic Nameserver database on martini.eecs.umich.edu. Rusty Eddy Expires August 27, 1996 [Page 3] Internet Draft Geographic Location Extension to Ripe-181 February, 1996 Work in this area will proceed if the community finds this feature useful. 6. Thanks Although we have never spoke, I would like to thank, Juergen Schoenwaelder (schoenw(a)ibr.cs.tu-bs.de) for the development of scotty/tkined, which IRRv is based on and the example geographic layout script. Thanks also to Cengiz Alaettinoglu for suggestions that led to these proposals. [1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. [2] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson. A Means for Expressing Location Information in the Domain Name System, RFC 1876, January 1996. Author's Present Address Rusty Eddy Information Sciences Institute University of Southern California Marina del Rey, CA 90292 e-mail: eddy(a)isi.edu

1 0

Re: draft NOC/role object proposal
by M.H.Behringer＠dante.org.uk 26 Jan '96

26 Jan '96

David, Thanks for starting the discussion on this. I have some input to this, see below. Unfortunately I won't be able to come to the RIPE WG-sessions, but Steven Bakker will be there. At 5:17 pm 26/1/1996, David.Kessens(a)ripe.net wrote: >Dear all, > >We have the creation of NOC/role object as one of the action points for >the RIPE NCC. However, after consulting numerous people we seemed to have >agreed upon something where we don't have any specification for ;-(. >Therefore, I am now doing a proposal for how the object could look like. >Note that this proposal is a real draft due to my personal ignorance of >your real needs in this area and the time that went by when we last >discussed the contents of this object for the last time... > > >Problem description: > >We see more and more person objects in the database that are apparently >not persons but referrals to help desks or ISP NOCs. The problem with the >usage of person objects for this matter is that the person object isn't >really designed for this and that in certain cases we require certain >objects to point to real persons for accountability reasons. Usage of >non-persons in person objects undermines therefore the usability of the >RIPE database. However, it is quite obvious that there is a need for such >an object, especially for larger organizations. > > >Proposal: > > >Since the object will be derived from the 'person:' object I will only >describe *all* the differences between the 'person:' object and the >'role:' object. > > >Attributes that are not used: > > >person: - for obvious reasons >nic-hdl: - a NIC handle is by definition assigned to persons and not > to organizations. Since we don't expect too many people > using this object it seems reasonable that we don't use a > number as a unique identifier. If we will need it in the > future we can add it. > > >Additional attributes: > >role: - the name of the object itself > >admin-c: - as in 'mntner' objects >tech-c: - as in 'mntner' objects > > We could decide to leave the 'tech-c:' out, since what's > the point in having a technical contact for a > administrative object only anyway ? I think we should not distinguish. A "person:" attribute would do, I think (however you call it, eg tech-c; the point is: *one* such object). Besides, this is mainly for NOCs and such (at least this is what we would use it for), so it would be technical people on it anyway only. But I think we need more attributes. Basically the role object needs to reflect what you need to know about something like a NOC: Who's in it (as you say), how to contact (might be derived from the other attributes), but also: What are the out-of-hours procedures. There are several possible ways to include that. I would propose something like: role: [mandatory] [single] address: [mandatory] [multiple] (as in person) phone: [mandatory] [multiple] ( " ) fax-no: [optional] [multiple] ( " ) e-mail: [optional] [multiple] ( " ) trouble: [optional] [multiple] (this is needed for trouble contact) (see below) person: [mandatory] [multiple] (this should be handles, obviously) (I see you used tech-c for this purpose, that is basically the same) remarks: [optional] [multiple] (as in person) notify: [optional] [multiple] ( " ) mnt-by: [optional] [multiple] ( " ) changed: [mandatory] [multiple] ( " ) source: [mandatory] [single] ( " ) What was actually the difference between notify and mnt-by? Do we need both? If feel quite strongly that we need something where you can specify the procedure to get in touch with the "role". This could be for example: trouble: Working days 0900-1700 CET: phone: xxx trouble: Working days 0900-1700 CET: e-mail: xxx trouble: Working days 0900-1700 CET: fax: xxx trouble: other times: phone: xxx trouble: other times: pager: xxx trouble: other times: mobile phone: xxx trouble: if all fails: phone: xxx trouble: NOTE: Please always try the phone before paging us! ... and so on. I don't think it is adviseable to be too precise in the specification, as there are certainly folks out there who want to put in notes like above. Thus one attribute like this "trouble" with free content would do. The reason why I think we still need such an attribute: We would like to be able to automatically derive contact procedures from the RIPE DB, to use it as a list. Of course we can also put it in the remarks, but I think one of the reasons for this object is to have this sort of attribute. > > >How to reference the 'role:' object from an object: > > >Here we can opt for two different solutions: > >1) We can allow people to use the 'role:' object in tech-c/zone-c > attributes (not in admin-c, this one can only point to a human due to > our current assignment criteria) > >2) Use a special attribute. The attribute will be an optional, single > line attribute for all objects that currently have an > 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC > object if desired. Note that this can cause undesired loops...): > > Example: > > preferred-contact: > > Please advise on better and shorter names, but that makes clear that > it is intended that a customer first checks with NOC/role object > people. I strongly feel that we should go away from specifying individuals in the other objects such as "route" or "as-num". But obviously not everybody will do that. Therefore I would suggest to use the tech-c: attribute for that. It makes perfect sense to say "tech-c: DFN-NOC" for example. Admin can stay, I don't have a strong view on that. The special attribute you propose in 2) makes it only more complicated, and it doesn't actually give us anything, does it? Hopefully people will not do something like specifying persons *and* a role as tech-c's in one object, but it shouldn't create problems either, you only might get a person twice as output. > > >How does the lookup work: > >The RIPE database can be configured for objects that have references to >other objects in such a way that it will also show the referenced objects >when querying an object with referenced other objects. Since the NOC >object itself can have references to persons/roles, it seems best to do >such a recursive lookup only one level deep whenever we find a NOC/person >object referenced. > >Examples: > >$ whois 193/8 > > inetnum: 193.0.0.0 > admin-c: DK13-RIPE > tech-c: RIPE-NOC > [...] > > person: David Kessens > nic-hdl: DK13-RIPE > [...] > > role: RIPE-NOC > tech-c: DK58 > [...] > >and > >$ whois RIPE-NOC > > role: RIPE-NOC > tech-c: DK58 > [...] > > person: Daniel Karrenberg > nic-hdl: DK58 > [...] Agree. Looks fine. Basically with the role object the goal is to get away from individuals, so the one-level limited recursion makes perfect sense, imo. > > >We hope that this draft is useful enough for you all to let us define a >sound proposal for the NOC/role object. Please make as many >amendments/added features as you want and that you think is needed for >the object, > >Kind regards, > >David Kessens >RIPE NCC What do others think? Michael

1 0

draft NOC/role object proposal
by David.Kessens＠ripe.net 26 Jan '96

26 Jan '96

Dear all, We have the creation of NOC/role object as one of the action points for the RIPE NCC. However, after consulting numerous people we seemed to have agreed upon something where we don't have any specification for ;-(. Therefore, I am now doing a proposal for how the object could look like. Note that this proposal is a real draft due to my personal ignorance of your real needs in this area and the time that went by when we last discussed the contents of this object for the last time... Problem description: We see more and more person objects in the database that are apparently not persons but referrals to help desks or ISP NOCs. The problem with the usage of person objects for this matter is that the person object isn't really designed for this and that in certain cases we require certain objects to point to real persons for accountability reasons. Usage of non-persons in person objects undermines therefore the usability of the RIPE database. However, it is quite obvious that there is a need for such an object, especially for larger organizations. Proposal: Since the object will be derived from the 'person:' object I will only describe *all* the differences between the 'person:' object and the 'role:' object. Attributes that are not used: person: - for obvious reasons nic-hdl: - a NIC handle is by definition assigned to persons and not to organizations. Since we don't expect too many people using this object it seems reasonable that we don't use a number as a unique identifier. If we will need it in the future we can add it. Additional attributes: role: - the name of the object itself admin-c: - as in 'mntner' objects tech-c: - as in 'mntner' objects We could decide to leave the 'tech-c:' out, since what's the point in having a technical contact for a administrative object only anyway ? How to reference the 'role:' object from an object: Here we can opt for two different solutions: 1) We can allow people to use the 'role:' object in tech-c/zone-c attributes (not in admin-c, this one can only point to a human due to our current assignment criteria) 2) Use a special attribute. The attribute will be an optional, single line attribute for all objects that currently have an 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC object if desired. Note that this can cause undesired loops...): Example: preferred-contact: Please advise on better and shorter names, but that makes clear that it is intended that a customer first checks with NOC/role object people. How does the lookup work: The RIPE database can be configured for objects that have references to other objects in such a way that it will also show the referenced objects when querying an object with referenced other objects. Since the NOC object itself can have references to persons/roles, it seems best to do such a recursive lookup only one level deep whenever we find a NOC/person object referenced. Examples: $ whois 193/8 inetnum: 193.0.0.0 admin-c: DK13-RIPE tech-c: RIPE-NOC [...] person: David Kessens nic-hdl: DK13-RIPE [...] role: RIPE-NOC tech-c: DK58 [...] and $ whois RIPE-NOC role: RIPE-NOC tech-c: DK58 [...] person: Daniel Karrenberg nic-hdl: DK58 [...] We hope that this draft is useful enough for you all to let us define a sound proposal for the NOC/role object. Please make as many amendments/added features as you want and that you think is needed for the object, Kind regards, David Kessens RIPE NCC

1 0