- db-wg - mailman.ripe.net

Draft minutes 17th RIPE meeting: DB-WG
by Wilfried Woeber, UniVie/ACOnet 02 Feb '94

02 Feb '94

Dear all, this is the draft minutes of the Database-WG meeting(s) at the 17th RIPE meeting. Any input and comments welcome, especially from those being affected by these things in one way or the other :-). Best regards, Wilfried. -------------------- start of draft minutes -------------------- 17th RIPE Meeting: Draft minutes for the DB-Working-Group meeting 25.1.1993, Amsterdam. ----------------------------------------------------------------------------- Due to the scheduling (and the un-avoidable overlap) of some WG meetings, the items on the agenda were treated in a different order than originally proposed. However the minutes follow the original ordering. 0. Opening, Scribe, Admin The DB-WG meeting was opened and Ruediger Volk volunteered to take notes. As a direct result of the preceding meeting of the Routing-WG and following other discussions the proposed agenda was amended (DB statistics for Domain-Object, maintainance of e-mail attribute and .forward files for guarded objects, timing considerations for guarded objects and values, aspects of ownership of objects and deletions and inter-dependancies). 1. New Databse software 1.1 . current status Marten Terpstra gave a concise report on the current state of the "new" database software. Due to timing constraints (and the lack of documentation) there is still no official distribution of the "New DB Software". However it has already been successfully installed at a couple of sites. The slides for the presentation can be found in ftp.ripe.net:ripe/presentations/ripe-m17-marten-DB.ps.Z 1.2 . experiences No operational problems were mentioned. Operation of the software, including the organizational environment, is going very smooth and was generally appreciated. 1.3 . documentation (who, how, when, what) Documentation is still missing. A new effort is needed and will be made early February. It has to be taken into account, that Marten Terpstra will primarily work on the PRIDE project, reducing his involvement with the DB software. Action (Wilfried Woeber, NCC): produce the necessary documentation for the new DB software. 2. RIPE-Handles RIPE-Handles are urgently needed to make progress in the area of Database Exchange. Several possible methods of assigning these handles were discussed. the group reached consensus that the RIPE-Handles will be of the form RIPE-XYZ9999. It was decided that from the DB's point of view, there exists only ONE handle: the RIPE-Handle. Thus this handle is stored in the person object in the "nic-hdl:" attribute. For the initial population/conversion of the current entries, the value of the NIC-Handle will be taken and converted to a RIPE-Handle by appending the string "-RIPE". E.g. the NIC-Handle for Wilfried Woeber (WW144) will be converted to form the RIPE-Handle (WW144-RIPE). This conversion will be done only once for the inital population. There will then be a short period, when missing handles can be provided by means of "vanity-handles". After a to-be-announced flag-day, RIPE-Handles will be required for any operation on person objects in the Database. Any vanity handles used MUST be properly registered with the NCC! The same syntax has already been adopted by the JPNIC and the AUNIC. *** Please note that during the discussion (by accident) we all were talking about a prefix format *** The NCC was mandated to circulate an updated proposal, including operational aspects, and after a short review-process (e-mail), go ahead with the implementation. Action (NCC): update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation. 3. PRIDE - DB Interaction Editorial comment: RIPE-81++ was treated in the Routing-WG. Currently there is no real pending issue with regard to the interaction between the PRIDE project and the RIPE-DB. After discussing possible future modifications or additions to DB objects, the NCC was mandated to go ahead and implement changes/additions to support the PRIDE project (like the hidden flags/options), unless there is a direct influence on operational aspects or changes to the user interface to the RIPE-DB. 4. Future needs 4.2 . Delete Operation vs Guarded Field interaction Various aspects of implementation of guarded objects were reviewed. With regard to possible "delete:" operation on network objects that are tagged with a guarded AS-value, consensus was to automatically notify the guardian of the AS-value. Changes to such objects do NOT generate a notification message. This functionality can be achieved by using the "notify:" attribute. The "notify:" attribute for an object is evaluated before the update is made. The technical issues of RIPE-81 was treated in the Routing-WG. Generally the transaction of deleting an object must be described. The document with the proposal for implementing guarded attributes is to be updated and recirculated for comment (e-mail, 14 days comment period). Then the NCC goes ahead with the implementation as soon as possible. Action (NCC): update and re-circulate the Guarded Fields proposal and then go ahead with the implementation. 4.3 . Phase-out of RIPE-60 stuff Jean-Michel Jouanigot continues to coordinate the migration to the RIPE-81 functionality. Any technical issues treated in the Routing-WG. 4.4 . Tools A proposal to have a certain kind of "template-mode" for checking and/or updating database objects was discussed. Several possible ways of implementing this were discussed (like a special flag for the whois-client, an interactive method at the NCC, providing a full template for further processing). Any solution proposed should be usable on most platforms. Action (NCC): investigate and propose facilities for a "template-mode" to support the maintaining database objects. 4.5 . Syntax checkers (distributed, and/or @ the NCC) The need for syntax-checking facilites for objects was again stated. The NCC was asked to look into providing this functionality and come up with a proposal. Action (NCC): Investigate and propose a syntax-checking facility for the new database software. 5. New/Revised Objects 5.1 . CLNS Routing "dom-prefix:" Henk Steenman provided an introduction to the current version of the proposal to have a database object for CLNS Routing. The only technical amendment discussed was to present the CLNP addresses in the format of xx.xxxx.xxxx.xxxx (no trailing dots). The NCC may have to review the current shell of scripts supporting the database operations for limitations in line-length. The NCC was mandated to go ahead with implementing this object after another short round of review (e-mail) of Henk's updated specification. Action (Henk Steenman): update and re-circulate the "dom-prefix:" proposal. Action (NCC): implement the CLNS Routing Object. >>>>>>>>>>>> I'm going to ask Henk to provide the (updated) proposal for the presentations directory!? 5.2 . status of "connect:" and value "LOCAL" Decision about the future of the "connect:" attribute for a Network Object was postponed after full deployment of the RIPE-81 stuff. It is expected that the "connect:" will be phased out and be replaced by a different mechanism (community?). The "connect:" attribute is no longer mandatory. 5.3 . Domain Object The status of the Domain Object was reviewed, prompted by the fact of poor coverage in the database. Again the object was felt to be useful, although currently there is little operational influence of registering (or NOT registering) domains in the database. Consensus was to ask the DNS-WG to review and maybe update the definition of the Domain Object. Action (Francis Dupont): Have the DNS group review the Domain Object and come up with either a recommendation for retirement or with an updated functionality 5.4 . others The "notify:" attribute is already implemented and is already used by the database software. The "maintainer:" attribute is already implemented but currently not used by the databse software. 6. Exchange Format 6.1 . current status No progress has been made due to the lack of RIPE-Handles. Can be progressed after implementation of RIPE-Handles. 6.2 . recommendations for further action As an aside - the group propsed to NOT enforce uniqueness of network names. 7. DB statistics (Domain-Object) Having stistics about the DB coverage of domains was seen to be potentially useful. Postponed to wait for the Domain Object review by the DNS-WG. 8. Maint. of e-mail: and .forward for guarded objects After evaluating possible szenarios it was decided that an automatic modification of either the "e-mail:" attribute of a guarded object or the .forward file for the guardian's account is not desirable. Responsibility of the maintainance remains with the guardians. 9. Timing considerations for guarded objects, values, secondary DBs Some operational issues of implementing guarded fileds were reviewed. Aspects discussed in more detail were: - timing and interlock: Some mechanism must be set up by the NCC to allow for checking the merge/update status of the current version of the database. This should allow for an automatic delay of retrieving the DB for local use and/or providing read-only copies. The NCC will come up with a technical proposal how to do this. - change control: in order to preserve the update history for databse objects a structured scheme was proposed. This method preserves the "changed:" attributes supplied by any manual update process. In addition to that any automatic up-date and/or merge operation done by the database software maintains a single related "changed:" attribute describing the "agent" performing the modification. From a formal point of view, regular maintainance and/or merge operations are NOT treated as update operations, thus e.g. they do not trigger (automatic) notification messages. Action (NCC): Propose and implement a mechanism to check the current state of the database with regard to garbage-collection and merging of guarding values. Action (NCC): Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification operations. 10. Deletions, Ownership of Objects, Interdependency This was a more general discussion, focussing on issues of "ownership" of objects, inter-dependency of various components and quality of the information in the database. >From a formal point of view, there was agreement that we should stick with the concept that the responsibility for maintaining objects remains with the owner of the object. From an operational point of view it was felt necessary to perform automatic modifications to certain attributes of an objects. In the long run this could eventually lead to splitting objects along the lines of maintainance. This is for further discussion. Concern was voiced that we do not have the concept of winding down the use of methods, removing out-dated information and/or deleting objects, closing guardian's accounts, etc. It was felt that there is a need to analyze, discuss and document these issues. For the time being these aspects have to be covered in individual documents describing certain procedures, in the long run this should be an intrinsic part of the documentation. The aspect of "sanity checking" the information in the databse was shortly touched. Given the current shortage of manpower in the NCC and the important changes to be implemented in the near future this issue was postponed. Z. AOB None. -------------------- end of draft minutes --------------------

1 0

Draft Guarded Field document
by Tony Bates 24 Jan '94

24 Jan '94

Please find enclosed a DRAFT copy of a document describing the Guarded Field procedure. This gives details of both the process for updating guardian files as well as how conflicts are handled. The current status is that the software is in final beta test and all the auto-generated "AS" accounts/files have been generated (see doc for more details). Our plan is to turn the "guarded field" software on in the database on February 7th. There will be a short introduction for both the paper and implementation given in the routing working group session at next weeks RIPE meeting. All comments welcome. We plan to agree and close this document at the RIPE meeting. See you next week. --Tony. Support of Guarded fields within the RIPE Database * DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW aut-sys: AS1104 ripe-1nn.txt January 19, 1994 - 2 - comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS<positive integer between 1 and 65535> (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the <routing policy expression> KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: Multiple text strings representing the routing privilege. _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt January 19, 1994 - 3 - bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt January 19, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt January 19, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. ripe-1nn.txt January 19, 1994 - 6 - o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt January 19, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra(a)gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt January 19, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt January 19, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt January 19, 1994

3 4

Proposal for a CLNS routing domain object for the RIPE database.
by Henk Steenman 21 Jan '94

21 Jan '94

Here is the proposal for the CLNS routing domain object for the RIPE datase as will be presented next tuesday during the DB workgroup meeting. This version is almost similar as the one presented at a previous RIPE meeting. The main differences are a new attribute "dom-name", an introduction describing shortly why such an object is desired and an appendix that gives a very short comment on the breakdown of NSAP's for some commonly used AFI's. - Henk Steenman SARA, NIC --------------------- CUT HERE --------------------------------------------- CLNS routing-domain object for the RIPE database Version 1.2 Jan 1994 Henk Steenman Henk_Steenman(a)sara.nl +31 20 5928038 CLNS routing-domain object Page 2 Introduction. ____________ In the RARE lower layer technology work group for CLNS it was recognised that in order to coordinate routing between CLNS routing domains a central registry for such domains was necessary. At a meeting of the work group at the 27 IETF in Amsterdam it was decided to write a registry specification. At this meeting the RIPE NCC offered to extend their database for IP domains/networks with CLNS related objects if a sound proposal came forward. Below a description of a database object for CLNS routing domains is defined. The object can be used to describe some general information of a CLNS routing domain such as NSAP prefix, name, description and responsible persons. It can also be used to describe routing policies in a manner comparable to that for IP domains ( AS's ) as defined in the paper RIPE 81 [1]. The attributes describing routing policy are intended to be set-up such that routing tables for static inter-domain routing can be derived from them or excisting routing can be checked against the described policy. It is desired that tools are made to serve these tasks. It is understood that the object as described below is subject to change when CLNS routing developes. An example of this could be the future availability of IDRP for dynamic inter-domain routing. In an appendix, some generally used combinations of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI) are shown. CLNS routing-domain object Page 3 Object Description _________________ dom-prefix: Defines an unique routing domain, characterised by a NSAP prefix , within a certain prefix hierarchy. Example: dom-prefix: 39528f1100 dom-name: String representing the routing domain. Format: Text string. Example: dom-name: SURFnet-CLNS descr: Description of the organisation and place of its location Format is equal to the descr attribute as defined for IP autonomous systems in [1]. bis: Format : < bis NET > < dom-prefix > NET of boundary intermediate system to between two domains Example: SURFnet BIS for EuropaNet bis: 39528f1100100020000000000100000c0429b400 39528f1103 CLNS routing-domain object Page 4 dom-in: Description of accepted routing domain prefixes, from other domain BIS. Analogue to "as-in" in [1]. Format:< dom-prefix > < cost> <routing policy expression > For every BIS you peer with, there should be such an entry <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <cost> is a relative cost to discriminate between different routes to the same domain. The lowest cost gives the most preferred route. <routing policy expression > can be expressed in the following way's 1: list of "dom-prefixes" Example: dom-in: 39528f1103 100 39124F 470005 2: KEYWORD Only one keyword for the moment ANY - accept everything you get announced. 3: A logical expression of 1 and/or 2. The following operators should be defined AND OR NOT Parenthesis are used to group rules. Example: dom-in: 39528f1103 ANY AND NOT 39756f Accept all announcements from EMPB BIS except for the Switzerland routing domain. CLNS routing-domain object Page 5 dom-out: Routing domain prefixes announced to other BIS'. Analogue to the "as-out' tag in [1]. Format : < dom-prefix > <routing policy expression > <dom-prefix> is the routing domain prefix where the BIS you peer with belongs to. <routing policy expression > As defined with the dom-in tag. Example: dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 Advertise to Europanet the SURFnet-CLNS routing domain but not the PTT-Research routing domain. default: Indication how default routing is done default: < dom-prefix> <cost> <dom-prefix> again is the prefix of the domain where the BIS peer is in. <cost> indicates which default path is preferred. In a static routing environment this doesn't make sense. Example: default: 39528f1103 10 Default everything is routed to 39528f1103 CLNS routing-domain object Page 6 admin-c: Administrative contact. Format equal to admin-c in [1]. tech-c: Technical contact Format equal to tech-c in [1]. guardian: e-mail and/or postal address of domain guardian. Analogue to AS guardian in [1]. source: Source of the information. Equal to source field in [1]. remark: remarks or comments Equal to remark field in [1] changed: Who and when of last change. Equal to change field in [1]. CLNS routing-domain object Page 7 Example: _________ dom-prefix: 39528f1100 descr: SURFnet-CLNS domain. bis: 39528f1100100020000000000100000c0429b400 39528f1103 dom-in: 39528f1103 100 ANY AND NOT 39528f1100000910 dom-in: 39528f1100000910 100 39528f1100000910 dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910 dom-out: 39528f1100000910 39528f1100 default: 39528f1103 10 admin-c: Victor Reijs tech-c: Henk Steenman guardian: domain-guardian(a)surfnet.nl source: RIPE changed: henk(a)sara.nl 930716 SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one, 39528f1100000910, which is PTT-research that is connected to both EMPB and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix. SURFnet announces to EMPB, 39528f1100 but not 39528f1100000910. To PTT-research only 39528f1100 is announced. Translated to static routing; on the SURFnet BIS connected to PTT- research, there is a static route to 39528f1100000910. And on the SURFnet BIS connected to EMPB there is a static route to all other know prefixes. On both the PTT-reserach and EMPB BIS's connected to SURFnet there is a static route to 39528f1100. ^L ^L CLNS routing-domain object Page 8 Appendix A. ___________ Definition of NSAP structure is defined in OSI 8348 Ad2 [2]. In general: NSAP's are always an integer number of octets where the AFI is always one octet and the IDI is always an integer number of octets. NSAP's are hierarchical structured and once the AFI is decided upon, structuring of the rest of the NSAP is up to authorities down the tree. Two common AFI are 47 and 39 and can be described by some general rules. AFI: 39 Describes that the following two octets are the ISO DCC country codes. Since these codes are always described by three digits, padding with an "f" is necessary to complete the 2 octets. Further structure is done by the authority for each country and there is no general rule. AFI: 47 IDI: 4 defines OSINET. Followed by a two byte organisation identifier. IDI: 5 defines US-GOSIP Version 1 defines a two byte organisation identifier. Version 2 defines a one byte data format identifier, a two byte zero field a three byte administrative authority a two byte routing domain id. ^L ^L CLNS routing-domain object Page 9 References __________ [1] : RIPE-81, Representation of IP routing Policies in the RIPE database, Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and Marten Terpstra, Feb. 1993 [2] : Network Services Definition, Addendum 2, covering Network Layer Addressing.

1 0

Draft Agenda DB-WG for RIPE #17, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 19 Jan '94

19 Jan '94

Dear all, this is the first draft of the agenda for the up-coming meeting of the RIPE DB-WG in Amsterdam. Comments, additions, modification requests welcome! See you in Amsterdam, Wilfried. -------------------------------------------------------------------------------- ripe-17.940119-a Draft agenda for the DB-Working-Group at RIPE-17, Amsterdam. ------------------------------------------------------------ 0. Opening, Scribe, Admin 1. New Databse Software . current status . experiences . documentation (who, how, when, what) - object definition and background - software documentation - maintainer's guide for Local-IRs - secondary server's guide 2. RIPE-Handles 3. PRIDE - RIPE-DB Interaction (if any) 4. Future needs . Guardians, operational aspects . Delete Operation vs Guarded Filed interaction (unless treated in the Presentation in the Routing Group) . Phase-out of RIPE-60 stuff (unless treated in the Presentation in the Routing Group) . Tools . Syntax checkers (distributed, and/or @ the NCC) 5. New/Revised Objects . CLNS Routing "dom-prefix:" . status of "connect:" and value "LOCAL" . status of "notify:" . others 6. Exchange Format . current status . recommendations for further action Z. AOB ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 4065822 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 4065822 170 NIC: WW144 -------------------------------------------------------------------------------

1 0

Latest on the dbase software
by Marten Terpstra 13 Jan '94

13 Jan '94

Folks, here is an update of what has happened with the database software over the last few months: - options have been added to whoisd (some you may have already seen): -r do NOT lookup referenced objects -F do fast lookup, in short format, without reformatting (implies -r) -V faciltates version numbers to be logged in queries this is used to identify prtraceroute and prcheck queries. For instance, prtraceroute is logged with -Vpt0.32 at the moment, where "pt" stands for prtraceroute and 0.32 is the version of prtraceroute used. This option is internal to special tools that use the database, and should NOT be used on command line. -k keepalive. This option will keep the connection between client and server open after a query. Also this option is ONLY used in tools that need a number of queries fast after one another (like prtraceroute) All the options (except the -V and -k) are available in the latest ripe whois client: ftp.ripe.net:tools/ripe-whois.tar.Z Please note that these options will NOT work with other whois servers, and only work with the latest beta whoisd. - the "notify" attribute as defined in ripe-096 has been implemented. The database has accepted "notify" and "maintainer" already for some months, but now the functionality of "notify" has been added last week. The functionality of "maintainer" is not implemented yet. You are welcome to use "notify" but please do not go mad on it. - the guarded stuff has (finally) been implemented, and is currently under heavy test at the NCC. It includes all the things needed to implement ripe-81 guarded attributes, including conflict handling and all other things needed. A document describing the procedures is being written (at this moment actually) and will be ready soon. - many many many small and big bugs have been reported and fixed. Most modules of the software have had some 5-10 fixes each, and the main programs like whoisd have had some 20 fixes. Many of these bugs were nasty little programming errors that appear in only some circumstances, and were thus hard to find. Also, many things have changed to speed things up a bit more. - the software is unfortunately still beta, simply because there are too many changes made every day. Once the guarded attributes have been debugged and the documentation written ;-( it will be an official release. - Some stats, taken out of the quarterly report December 93 (which will be published this week): (All stats over Oct, Nov and Dec 1993) queries: 177,423 e-mail messages with updates processed: 3,575 number of objects processed from these e-mails: 42,767 number of networks in database: 29,646 number of persons in database: 13,238 number of domains in database: 2,339 number of AS in the database: 224 More info of course at the RIPE meeting. If you have any questions about the database (from general to very specific) please send me a mail. See you in 11 days. -Marten

1 0

NIC Handles
by Daniel Karrenberg 21 Dec '93

21 Dec '93

Friends, after all the useful input from you and some more thought we have concluded that introducing the RIPE handles this year is too ambitious. So it will be January. I see two alternatives: 1) We wait until the RIPE meeting in order to discuss all the possibilities and make a firm decision. This delays introduction well into February. Database exchange with the InterNIC is also delayed until then. 2) We introduce like planned in the first week(s) of January. In order to address concerns quick and easy assignment we will operate a server for real-time assignments. If this does not solve the expected problems we can decide about local assignements at the RIPE meeting. In order not to delay database exchange with the NIC we favour option 2. About the real-time server: It will run on a special TCP port accessible only to local IRs. The server will accept a person object with "nic-hdl: assign" and immediately echo back the person object with the NIC handle or an error message. We will provide a filter "assignhandle" to go with it so you can integrate it into your own software (we will often run it in vi/emacs). We will also provide the filter mentioned in the paper which adds handles to an existing database without handles. Does anyone have real problems with option 2? Daniel

4 3

[Robert Martin-Legene: New fields for objects]
by RIPE NCC Staff 13 Dec '93

13 Dec '93

Any comments/ideas ? -Marten ------- Forwarded Message Date: Mon, 13 Dec 93 12:54:43 MET From: Robert Martin-Legene <robert(a)dknet.dk> To: ncc(a)ripe.net Subject: New fields for objects Part D is completed if you're making the application on behalf on another organisation. How about making this a complete person-entry, and add a "via:" field in the "inetnum:" object ? - -- Robert Martin-Legene, DKnet, Fruebjergvej 3, DK-2100 Kobenhavn O, +45 39 17 99 00 ------- End of Forwarded Message

1 0

Re: RIPE Handle document
by bonito＠nis.garr.it 09 Dec '93

09 Dec '93

> > The problem of delay in registrations by "regional" > registries could perhaps be overcome by an automated > "handle assignment" service by RIPE, where a handle > could be obtained interactively by authorised persons. > Given the turnaround-time with the new DB-software, > I really don't see where there is potential for delay > in registering objects? > But maybe we could (on paper) relax the rules a bit to > officially allow the registration of person objects that > are not (yet) referenced by other objects. > The software never prohibited this, as much as I know. > As NL domain registrar I'm used to honouring requests > for (new) registrations as soon as possible. I don't > like a registration to become a multi-stage procedure: > - register the domain and associated person(s) in > my NL database; > - wait till the whole business has been submitted > to the RIPE database (weekly, automated); > - see what handles RIPE has assigned and add them > to the entries in my NL database; > - wait again till the stuff has been sent to RIPE. > Even if I would make the submission a daily one, it > would still take several days before the registration > in my NL database and in the RIPE database have been > finalised. If RIPE would provide an interactive way > of obtaining a handle, then there would be no delay. > > Piet Piet, you've clearly expressed the same worries I actually have: I don't like the RIPE registration process to become not as fast and easy as it is now! But I don't see why the solution of distributing Internet handles assignment (the actual way is not the point: using number ranges, appending different suffixes, ...) is not taken in serious consideration. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

1 0

Re: RIPE Handle document
by Wilfried Woeber, UniVie/ACOnet 09 Dec '93

09 Dec '93

Piet and others, >True, but that would only make the problem worse: >then you could have e.g. 10 Person objects which >are each unique in their own [source] context but >which actually refer to one and the same person. >In such a case I'd still prefer to have a specific >tag (like a handle) assigned centrally by RIPE even >when the source of the object is not RIPE. I agree with your point of view, that we should thrive to have only _very_ few instances that assign handles! Everything else is calling for trouble. >The problem of delay in registrations by "regional" >registries could perhaps be overcome by an automated >"handle assignment" service by RIPE, where a handle >could be obtained interactively by authorised persons. Given the turnaround-time with the new DB-software, I really don't see where there is potential for delay in registering objects? But maybe we could (on paper) relax the rules a bit to officially allow the registration of person objects that are not (yet) referenced by other objects. The software never prohibited this, as much as I know. Maybe this is the time to think about combining the idea of an interactive handle generator and an interactive (eg. prompt-mode) (person-)object registration script, offered on a special telnet port at the NCC? Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 4065822 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 4065822 170 NIC: WW144 -------------------------------------------------------------------------------

3 2

RE: RIPE Handle document
by Wilfried Woeber, UniVie/ACOnet 07 Dec '93

07 Dec '93

>RIPE Handle > >Internet handles issued by the RIPE NCC are called RIPE handles. >The purpose of a RIPE handle is to uniquely identify a person in the >RIPE network management database and other related databases that >choose to use it. so we manufacture Internet Handles! >... >All persons in the RIPE database must have an Internet handle. > agreed. >Every person in any of the databases keeping contact information >should only use Internet handle. sure enough, probably this isn't telling me what was intended? > >Assignment >... >It should be noted that the RIPE NCC only issues RIPE handles and >not other Internet handles. this is in contradiction to the first assumption!??? ____________________ I think the wording, and maybe even the thinking, has to be made a little bit clearer (at least to me :-) I'm reading the proposal to mean the following: - On a global scale, we need unique handles (Internet Handles). - InterNIC doesn't provide them for use by Regional Registries - There is an agreement that Internet Handles are manufactured in a distributed way by appending the Regional Registry code - It doesn' matter from where I get the handle, it is an Intenet Handle that is globally unique and valid. (ie. I can get my person object registered in any database other than the RIPE-DB with my RIPE-assigned Internet Handle) **correct?? - we have to get this going by a) converting all existing handles, which have by definition been assigned by the InterNIC into the -INIC format/syntax b) assign -RIPE format/syntax handles for all the others in the RIPE-DB - to keep it going we refuse person objects, that do neither come with an Internet Handle, nor request assignment by the agreed string of "assign" Anything wrong with this? Wilfried (WW144-INIC :-)

2 1