- lir-wg - mailman.ripe.net

Local-IR Draft Minutes
by Daniel Karrenberg 21 Sep '93

21 Sep '93

Thanks to Martijn we have prepared the draft minutes of the WG meeting last week. Please read and comment. The final minutes will be produced next monday. Daniel ------ Minutes of the Meeting of the local-ir working group at the 16th RIPE meeting. Date: September 16th 1993 Location: NIKHEF Amsterdam Chairman: Daniel Karrenberg Minutes: Anne Lord, Daniel Karrenberg, Martijn Roos Lindgreen The proposed agenda (see below) was accepted after extra points were added: - - discuss documentation that is needed - - discuss the procedure to set up new top level domains 0. Reports for information: The DE-NIC will be shut down and moved to another place at the 15th of December. It will be funded by all the DE service providers. A workshop was held on wednesday morning. As it was a closed meeting no minutes were taken. The workshop was considered useful and will be held in conjunction with a RIPE meeting on a yearly basis. A more extensive reporting was asked for, but was considered inappropriate because of the informal nature of the workshop. 1. Proxy network entries: Many participants felt that the network proxy entries should be avoided. After intensive discussion it was decided that a draft policy for this will be worked out by Duncan Rogerson and Daniel Karrenberg. Input from those service providers who are in favor of the proxy entries is necessary. 2. Autonomous Systems Database Template The AS Database template was formally accepted. 3. Should we maintain a list of local IRs and publish it? After intensive discussion it was decided that a list of Internet Registries will be maintained and published by the RIPE NCC. This list will be sorted by country and contain all local provider- and non-provider registries. A draft of the list will be circulated on the local-ir list by the NCC. 4. Input for the Activity Plan It was suggested to add the following activity: Maintain and regularly publish the list of local Internet registries Another suggestion is to strengthen the local registry liaison with tutorials and workshops. 5. AoB It was felt that more documentation is needed. The following volunteers were appointed to edit the documents: FAQ on CIDR and subnetting: GARR/NIS Why return unused IP address space and be a good network citizen: Daniel Karrenberg The problem of finding registrars for new toplevel domains was raised; there was consensus that the RIPE NCC shall offer to serve as temporary registrar for toplevel domains in our region, until about a dozen subdomains have been registered. Agenda for the local IR WG During RIPE Meeting Thursday September 16th 1993 0. Reports for Information - short reports of significant events at local IRs - short reports of significant events at the NCC - short report from local IR workshop the previous day 1. Proxy Network Entries in RIPE Database Some service providers have expressed the wish to act as proxy for some of their clients when registering in the RIPE database in order to protect their clients privacy. Under the present policy this is not possible. A proxy policy could be established. Is this a goo idea? Proposed points: - only on explicit request from client - only if proxy has 24x7 NOC - proxy must reveal client's identity to Internet Registries - proxy must reveal identity on request of other network operator in case of ongoing problems OR take immediate measures to stop traffic 2. Autonomous Systems Database Template Has been circulated. Should be accepted as this. 3. Should we maintain a list of local IRs and publish it? Speaks for itself 4. Input for new NCC activity plan. What do you really want? and pay for it! 5. AoB

1 0

Tomorrow's BOF
by mnorris＠dalkey.hea.ie 14 Sep '93

14 Sep '93

Daniel et al I can't get out of here today so I'll be a bit late at tomorrow's IR bof; should be there in time for the concluding coffee, though ;-) I don't have any war stories as such, just a few things that occur to me: 1. Most clients are beginning to learn about subnetting and are using single Class C addresses for multiple link IP addresses. 2. Some clients complained that they had not been allocated enough addresses. Such clients are always those who have done nothing about getting themselves connected, despite the advice and encouragement we have offered them. Our answer to them is that when they really need more addresses to connect hosts to the Internet, they should ask their local registry. They can't complain. 3. The service provided by the RIPE NCC as the European IP registry is an excellent one. The secondary nameservice for the reverse zones in 193.1.0.0 was a great idea and well implemented. Cheers. Mike

1 0

Draft Agenda local-ir WG
by Daniel Karrenberg 13 Sep '93

13 Sep '93

Draft Agenda for the local IR WG During RIPE Meeting Thursday September 16th 1993 0. Reports for Information - short reports of significant events at local IRs - short reports of significant events at the NCC - short report from local IR workshop the previous day 1. Proxy Network Entries in RIPE Database Some service providers have expressed the wish to act as proxy for some of their clients when registering in the RIPE database in order to protect their clients privacy. Under the present policy this is not possible. A proxy policy could be established. Is this a goo idea? Proposed points: - only on explicit request from client - only if proxy has 24x7 NOC - proxy must reveal client's identity to Internet Registries - proxy must reveal identity on request of other network operator in case of ongoing problems OR take immediate measures to stop traffic 2. Autonomous Systems Database Template Has been circulated. Should be accepted as this. 3. Should we maintain a list of local IRs and publish it? Speaks for itself 4. Input for new NCC activity plan. What do you really want? and pay for it! 5. AoB Daniel

1 0

(no subject)
by Daniel Karrenberg 13 Sep '93

13 Sep '93

Dear all, The closed local-IR workshop on Wednesday 15th September will take place in room Z009 (round the corner from the main auditorium), starting at 10.00 am. The proposed agenda is as follows: A G E N D A Local-IR Workshop September 15th, 10am. 1. Procedures at the RIPE NCC The NCC will describe how registry actions are being done at the RIPE NCC. 3. Procedrues at Local Registries Local Registries will describe how they do things. 2. Criteria for allocations: rfc1466 Short review of RFC1466. 3. Review and discussion of past "interesting" cases (ncc) 4. Review and discussion of past "interesting" cases (Local-ir's) See you there Daniel

1 0

assign versus dbm in the new software
by Marten Terpstra 09 Sep '93

09 Sep '93

People, I have put the difference between assign and dbm in the new automatic aliases as well. We now have: auto-dbm - similar to ripe-dbm, but automatic auto-assign - similar to assign, ie network objects that are already present wil be bounced, persons can be updated though. This to allow for tech-c and admin-c that need to be updated with these network numbers to simply go through. deletes are accepted either way, but preferably though auto-dbm. The software also supports the LONGACK string in the subject line of the mail which indicates that you wish verbose output, ie at least a one line status per object. Objects with warnings or errors will always be returned. It seems we are almost ready for the cutover tomorrow. Be prepared for fast and different looking acknowledgements ;-) -Marten PS It may happen that tomorrow some of the additional features of a database update (such as the split version for anonymous ftp, the WAIS index, and the cisco access-lists) might be a bit later. We have to track all the stuff we currently have installed that has to do with the database, and transform them. Almost the full staff will be in on the weekend (RIPE preparation) to look after things in case it breaks (no of course it doesn;t)

1 0

Re: misleading use of the connect: field in inetnum: object
by Wilfried Woeber, UniVie/ACOnet 08 Sep '93

08 Sep '93

Hi Daniel, >the real problem with the "connect" attribute is that it still is the >badly defined kludge it has been from the start. I can say so because I >invented it. Today we have a well defined and agreed way of specifying >the information you want: It is called ripe-81 by the document fans and >"The Routing Registry" by afficionados. I had one and only one basic concern: when we put info into the DB, this info should HELP and not CONFUSE. I agree with you that "connect:" is maybe far from optimal. >In my opinion we should put our efforts in getting the RR populated >rather than trying to specify how to use an un-specifyable kludge. So now I've got another concern: populating the RR helps the "afficionados", but probably doesn't help the (end-)user in finding out what he/she can expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy. And the basic issue remains - you can just as well put some string into the "as-*:" fields and still have only EARN-E-Mail connectivity... >The original plan was to keep connect alive with the only legal value of >LOCAL. Maybe we shouldn't even do this. An item for discussion at the RIPE >meeting! Definitely! And thanks for spending some minutes on it. Cheers, Wilfried.

5 4

Re: ** URGENT ** New database software at the NCC
by Wilfried Woeber, UniVie/ACOnet 08 Sep '93

08 Sep '93

Marten, >Just some explanation, the messages sent to assign are first checked to see >if they are already in the database, and currently bounced back to the NCC if >they are. I think what I will do is create something like auto-assign, which >has the same "on-the-fly" features as auto-dbm, but will only ADD new >objects, and bounce all objects that are already present. This would mean >that also contact people that are already present will not be updated when >sent to auto-assign. ...does this mean that we are no longer able to submit *updates* for person objects along with a new network object from the 193,194 address range? If this is the case, then I think we should generally go for a system where *all* objects *with the exception of objects for newly assigned networks* should go to the ripe-dbm mailbox. Wilfried.

1 0

Re: ** URGENT ** New database software at the NCC
by Marten Terpstra 08 Sep '93

08 Sep '93

Tim.Goodwin(a)pipex.net writes * Marten, * * > A new mailbox will be installed for direct access to the new database * > software without RIPE NCC staff intervention. This means fast response * > times, but since the updates are not looked at by the staff, updates * > containing errors will be bounced just as fast. The new mailbox will be * > <auto-dbm(a)ripe.net>. The old mailboxes will remain, and the NCC staff * > will look at mails directed to one of these mailboxes and forward * > updates to the new update procedure, after some very basic checking. * > ... * * Should new assignments from class C blocks continue to go to * "assign", with just updates to existing objects to "auto-dbm"? Or can * everything go to "auto-dbm"? Actually this is a good question ;-) We sort of have not made arrangements for this. I have some idea how to implement the difference between ripe-dbm and assign in the new database software, and I have to see how fast I can get that in (not too difficult I would say). Until further notice (I hope I can get this done before Friday) please send new assignments still to assign, and use auto-dbm or ripe-dbm for all others. Just some explanation, the messages sent to assign are first checked to see if they are already in the database, and currently bounced back to the NCC if they are. I think what I will do is create something like auto-assign, which has the same "on-the-fly" features as auto-dbm, but will only ADD new objects, and bounce all objects that are already present. This would mean that also contact people that are already present will not be updated when sent to auto-assign. The idea behind the difference between assign and ripe-dbm is to avoid some typos (especially in the beginning there were loads of 192/193 typos, and I am sure we will get some more 193/194 typos) and to cater for forwarding new entries directly to the InterNIC in the exchange format. The last has not been done yet. -Marten

1 0

misleading use of the connect: field in inetnum: object
by Wilfried Woeber, UniVie/ACOnet 07 Sep '93

07 Sep '93

Dear all, (and sorry for a possibly too wide distribution). We had some instances recently, where operations people were prompted by users to sort out connectivity problems to a given network that couldn't be reached. The most obvious thing to do is to look into the RIPE-DB, of course. The network(s) were registered, but further investigation revealed that the network(s) did not yet have full connectivity to the Internet. However the information in the connect: field of the network object contained strings like RIPE, NSF or EASI, but no indication about the more local situation. For the end-user, and most probably for a lot of operations people as well, it is definitely not obvious that the connect field is more or less just a (sometimes very misleading!) comment. Thus I propose to discuss and agree on a (RIPE) recommendation along the following lines, at least for registering new networks in the database: - The Local-IR registers the network with a (local/regional) network or service-provider string, but without using any misleading flags in the connect: field like RIPE, NSF, EASI... If -for whatever reason- commonly used strings are used, then the remarks: field should give a very clear indication about expected connection date(s) and service restrictions (like dial-up networks, e-mail only links...). - When the network is connected to a service provider to configure routing, (Reverse-)DNS, or services like e-mail, etc. the network should be tagged with a useful service-provider string. This "state" could and probably should be skipped for situations where full connectivity could be expected within a few days. Examples: ACONET or SURFNET for national academic networks, EUNET-DE for a EUnet connection, XLINK and the like Note: I'm not proposing to use the LOCAL tag, because this means that no connectivity to the outside world is wanted or intended at all! - Only after the point in time where there is really full connectivity, the usual strings like RIPE, NSF, etc. should be added to the connect: field, out-dated comments removed, DNS and AS-Number information added, and the like. In addition to that I propose to list the connect: strings in a kind of intuitive "local to global" sequence. Examples: "ACONET RIPE NSF" or "ARNES EMPB RIPE NSF" or "EUNET-XX RIPE" Thus we would end up with really useful information in the connect field, and maybe also with more complete database objects, because information is available for the second or last update phase that usually cannot be submitted when registering the network. Could I have your opinions and comments please? An example for a network in Western-Nowhere, that is connected to a regional net that gets connectivity throug ACOnet and EBONE would be: Phase-1 connect: WNWNET !while setting up the net !or eg. e-mail only conn Phase-2 connect: WNWNET ACONET RIPE !after adding... bdrygw-l: ACONET Phase-3 connect: WNWNET ACONET RIPE NSF !after registering NSF-conn. 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 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------

3 2

** URGENT ** New database software at the NCC
by Marten Terpstra 07 Sep '93

07 Sep '93

Dear people, You have all probably heard that new RIPE database software has been written at the NCC. We are convinced that this software should be used as soon as possible at the NCC, because the current update procedure has had several changes made already to keep it running with the current size of both the database and the amount of updates we receive. Therefore, we have planned to start using the new software at the NCC this Friday September 10th, at 10 AM. The new software has some consequences for whois users and people that send in updates. These consequences have been listed below. Please read the document below carefully. If you have any questions or major objections, please contact me, Daniel or Tony. Cheers, Marten PS All updates sent to the new mail alias before Friday 10 AM will either bounce, or update some test database. These updates will NOT be incorporated in the real RIPE database. ----- Introduction The software for the RIPE database has recently been completely rewritten, and the new implementation will have some effects on the behaviour of the database software as compared to the software currently in use at the NCC. This document describes the impact the new RIPE database software will have on usage of the database and on updates to it. USER IMPACT With the new database software, there will be some changes in the bahaviour of the database whois server. These include: New -s flag The indexed database will still contain information from various sources. As before normally only the RIPE information will be shown. The flag for requesting information from all sources remains the same (-a), and a new flag will be introduced to specify one or more specific source (-s source). The RIPE whois client available from the RIPE document store has been modified to accept this flag. Recursive Lookups Limited to Source of Reference The "-a" flag, or asking for information from multiple sources will show a slightly different behaviour. The old software used to perform recursive lookups on ALL the selected sources. This means that a contact person referenced by a NIC entry would be looked ap and listed from ALL other sources. The new software will ONLY perform recursive lookups in the source where the reference was found. Consequence is that one does not get a mix and match of referenced information from various sources. All references are ONLY looked up in the source where they are referenced. This was done to limit output volume and user confusion. Strict Enforcement of Object Definitions The current database file has objects in it that do not conform to the official object definitions. The new whois server will only output the legal fields for such an object. So, it may be that a network object contains a zone-c attribute in the database file, but the whois server will never show this attribute, because it is not in the network object definition. An overview of the defined attributes per object can be found at the end of this document. UPDATE IMPACT There are a number of changes that will affect people sending in updates for the RIPE database. Real Time Updates The new database software works with on-the-fly updates. This means that accepted and acknowledged database updates will be visible immediately in the whois server running at the NCC. These changes will not be visible immediately in the FTPable database file maintained via the RIPE Document Store. Once a day -or night rather- an automatic "cleanup" procedure will run which generates the FTPable file and adds all the guarded attributes as specified in the guardian files maintained at the NCC. This means that the database available for anonymous FTP does not necessarily have the same information as the running database. Guarded attributes will not be changed using the normal update procedure, they will be added once a day, and remain unchanged until the next cleanup time. New Update Procedure A new mailbox will be installed for direct access to the new database software without RIPE NCC staff intervention. This means fast response times, but since the updates are not looked at by the staff, updates containing errors will be bounced just as fast. The new mailbox will be <auto-dbm(a)ripe.net>. The old mailboxes will remain, and the NCC staff will look at mails directed to one of these mailboxes and forward updates to the new update procedure, after some very basic checking. The NCC will NOT correct all syntax errors in updates sent to one of these mailboxes, but it might correct some obvious errors. As before all updates and acknowledgements will be logged at the NCC. This means that errors and "strange" updates can be tracked quite easily. Stronger Syntax Checking The syntax checking in the new software has been improved and strengthened. As with the old software, database objects that cause errors will be bounced, and NOT be incorporated in the database. Warning messages are usually used to indicate corrections that have been made to the object sent in. Objects with warnings WILL be incorporated in the database, with the changes made as indicated in the warning messages. In general error and warning messages are descriptive and will give some indication where an error or warning was generated. The new syntax checking has the following rules: Database objects that miss mandatory attributes will generate an error, and will be bounced. An overview of the defined attributes per object can be found at the end of this document. Objects that have attributes that are not defined in the object, will generate an error and will be bounced. Objects that have syntax errors in the values of the various attributes will generate an error, and will be bounced. Objects that have a date in the changed field that is prior to the date in the current database entry will generate an error and will be bounced. Guarded attributes in updates will be ignored other than generating a warning if the values do not match the current value in the database. Currently only the boundary gateway and routing privilege in the network object are guarded attributes. The aut-sys attribute in the network object will be turned into a guarded attribute as soon as possible. Deletions have been made more easy to perform. To delete an object, it is sufficient to send in that object plus a delete: attribute that describes why this object has to be removed from the database. Objects that need to be deleted, will NOT be checked for syntax, but must exactly match the object currently in the database, otherwise an error will be generated, and the object will not be removed from the database. The order of the different attributes in the updates is NO LONGER relevant for the match. The order of different lines in the same attribute is. The new syntax rules have been determined from the original object definitions. It may well be that some syntax rules have been made too strict, or are simply wrong. Please do not hesitate to contact us in these cases. The syntax is not fixed forever. Attribute definition per object as used by the new database software. inetnum object Mandatory: inetnum netname descr country admin-c tech-c connect changed source Optional: aut-sys (will be guarded asap) gateway (obsolete) nsf-in nsf-out (obsolete ?) routpr-l (guarded) bdrygw-l (guarded) remarks rev-srv person object Mandatory: person address phone changed source Optional: e-mail fax-no nic-hdl remarks domain object Mandatory: domain descr admin-c tech-c zone-c changed source Optional: dom-net nserver sub-dom remarks aut-num object Mandatory: aut-num descr admin-c tech-c changed source Optional: guardian as-in as-out default remarks bdry-gw and rout-pr will be obsolete in the near future.

1 0