- db-wg - mailman.ripe.net

Re: Domain object template
by Andreas.Knocke＠nic.de 11 Jan '95

11 Jan '95

Hello, a couple of additions to the discussion: > * Can we please drop the possibility of allowing IP numbers here? > * If one of the secondaries of your domain changes IP number, then > * he has the nearly impossible task of finding all these outdated > * references. Bind only allows hostnames here; I think it is a good > * idea to restrict the database in the same way. > * > * => IP numbers were allowed in the previous template then we need > * a general agreement before dropping this possibility... > > Perhaps we should try and completely overhaul the domain object? Why > would we go for small changes when we may need major changes? I somehow agree with the positions Geert Jan and Marten gave, a complete overhaul is probably needed and especially the nserver, IP-address idea was much discussed the last time at the RIPE meeting in Amsterdam (May 1994) with the idea that there is a much more useful place to store it - BIND ! On the other hand there is maybe one useful point to IP-numbers here, for a domain abc.zz with a set of nameservers ns1.abc.zz and ns2.abc.zz which have lost connectivity - a very bad situation, I agree - it might be helpful to find there IP addresses here as well, so I would propose to use it only for nserver within the specified domain. domain: ABC.zz descr: ABC company .... nserver: ns1.abc.zz 194.205.120.3 nserver: ns2.abc.zz 194.205.120.6 nserver: ns.domain.my nserver: foo.bar.com ... Giving the primary first is probably a good idea, but what about 'hidden' primaries. It is I think a common situation for organisation behind a dial-up connection administering there own nameserver (as given in the SOA) with only a set of secondaries published as NS-RR's. This cannot be documented - if one wants to - this way, but maybe with a useful remark: > * => there is a loose binding between names and addresses. > * This attribute can be used if someone'd like to describe it. > * This attribute has been made optional then you use it only > * if you like. > > Hmm, personally I'd bin the attribute..... I think that most of the attributes made optional instead of obsolete could be seen as a compromise we can agree upon as a transitional step until the complete overhaul - if not achieveable at this meeting ? > > admin-c: The admin-c attribute contains the name or the NIC > > I suggest to make mandatory that the administrative contact > should reside on the site itself. Assume that people have outsourced > the 'technical stuff' of their network, then it is likely that the > technical contact is someone belonging to another company, and > it might be difficult to get in touch with the holder of the > domain itself because the address/phone number is different. > > => the admin contact for domains is different from the admin > contact for networks. It is explicitely an administrative > person who can answer to questions about name property, > legal problems, etc... In fact I understand your problem > but I believe the change should be done in the network > template. I totally agree with Geert Jan here, the admin-c should be from the organisation using domain and should be changed if he no longer represents this organisation. I didn't follow the discussion but heard some rumors about mtv.com but this way might be a good start. You have to have the organisation's address and at least one phone number somewhere. Another but important aspect I think would be to find a better (more up to date) example, if it should convince and educate new registries. The current one contains a number of factional errors (I'll append the correct entry at the bottom of this posting) and some discrepancy to it's own explanation for instance the format of the change dates not in format YYMMDD. Finally with the handles and names as key values for person objects 1.2 could be reformulated. Before entering or updating person objects the database should be checked for existing entries which were created as references of other objects (inetnum,...). Care should be taken to keep them up to date, without generating duplicate entries one with and one without a handle. I did it a number of times myself when I started using handles so please don't take it as an accusation to anybody. On the other hand the advent of ripe handles gives us the proper way to create different objects for one person where necessary - e.g. if he has his own domain at home and supports a number of networks or anything else at work. -------------------------------------------------------------------------- domain: uka.de descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5, D-76128 Karlsruhe, Germany admin-c: WZ5-RIPE tech-c: KB49 tech-c: AN45 zone-c: KB49 nserver: iraun1.ira.uka.de nserver: iraux1.ira.uka.de nserver: ns.germany.eu.net nserver: ns.nic.de sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 mnt-by: DE-DOM changed: nipper(a)ira.uka.de 910208 changed: knocke(a)nic.de 941121 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)IRA.UKA.DE nic-hdl: WZ5-RIPE mnt-by: DENIC-P changed: dfk(a)cwi.nl 900411 changed: rv(a)Informatik.Uni-Dortmund.DE 930704 changed: knocke(a)nic.de 941121 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de nic-hdl: KB49 mnt-by: DENIC-P changed: nipper(a)xlink.net 940406 changed: knocke(a)nic.de 941121 source: RIPE person: Arnold Nipper address: NTG Netzwerk und Telematic GmbH address: Geschaeftsbereich XLINK address: Vincenz-Priessnitz-Str. 3 address: D-76131 Karlsruhe address: Germany phone: +49 721 9652 0 fax-no: +49 721 9652 210 e-mail: nipper(a)xlink.net nic-hdl: AN45 changed: nipper(a)xlink.net 940616 source: RIPE

1 0

Re: Domain object template
by Dave Morton 11 Jan '95

11 Jan '95

All very good points - I agree with Geert. Dave

1 0

Re: "Dale S. Johnson": # Comment characters in templates
by Wilfried Woeber, UniVie/ACOnet 02 Dec '94

02 Dec '94

= * > which would be processed normally, ie the # lines ignored. They = * > would not end up in the database of course. = * = * > Any major showstoppers here? = * = * = * Well, no objections... this is really simple to implement, and may be = * very useful. = =It should be noted though that from that moment on "#" lines no longer =can be used to end an object. Two objects with only a "#" line between =them will be viewed as one, and will generate a syntax error. = =-Marten I agree that the proposed functionality to allow comments is useful. As to the aspect of separation of objects - well, I think with the invention of the password stuff and with the idea of grabbing the whois template output and writing scripts and the like, we should be asking whether just a blank line is the best way to separate objects... How about an "end: whatever string you like to put here" attribute to be equivalent to a blank line separating objects? Any hard feelings? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

"Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

Folks, Dale Johnson from MERIT brings up the issue of allowing "#" style comments in objects between attributes. From an implementation point of view this is *very* simple. Any major objections? The database sw would simply ignore them. Note that they would have to be on a line by themselves, NOT inside an attribute. An example would be: person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands # This is some comment phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra(a)ripe.net nic-hdl: MT2 # And this as well notify: marten(a)ripe.net changed: marten(a)ripe.net 941128 source: RIPE which would be processed normally, ie the # lines ignored. They would not end up in the database of course. Any major showstoppers here? -Marten ------- Forwarded Message Date: Mon, 28 Nov 1994 14:49:50 -0500 From: "Dale S. Johnson" <dsj(a)merit.edu> To: Marten(a)ripe.net cc: Tony.Bates(a)ripe.net Subject: # Comment characters in templates Marten, What do you think of the idea of allowing #Comments in templates that are processed by auto-dbm? I bring this up privately because it seems like something that must have caused some discussion before if it isn't all ready implemented. The arguments are the same as for commenting programs: objects (especially aut-num objects) can be huge and complex now. Even if the comments aren't preserved in the storage and output formats, it would make lots of sense for people to keep comments in their original versions on their own machines, and not have to sed these out before they send them to auto-dbm. Is there all ready a history on this question? Or could it be done without discussion? Or if it needs discussion, what list would be appropriate? --Dale ------- End of Forwarded Message

3 3

Re: "Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

David.Kessens(a)ripe.net writes * Hi Marten, * * I see no problems but is a '#' also allowed after a number of spaces : * * # This is a comment Yup, leading spaces are always ignored. * Do you check the attributes for '#' when sent in ? * Does this generate a warning ? Well, if there is a "#" type comment inside an attribute (ie somewhere inside the value of an attribute) this will generate a syntax error in most cases. Ie something like: person: Marten Terpstra address: ....... phone: +31 20 592 5065 # Preferred phone: +31 20 592 5064 # Backup would spefically NOT be allowed and would generate syntax errors for that attribute. Unless of course the syntax for an attribute allows # chars (I don't think there are any though). -Marten

1 0

RIPE Database Transition T2
by Marten Terpstra 17 Nov '94

17 Nov '94

Dear all, Apologies for this wide distribution but I think it is important enough. This is a reminder that coming Monday the 21st of November, the second and last step of the RIPE database transition will take place. This transition is the transition from network number objects that hold all policy information, to route objects that contain all this information. For more detailed info on what exactly will change and how, please read ripe-123 which is available as: ftp://ftp.ripe.net/ripe/docs/ripe-123.{txt|ps} Especially section 5 explains forthe various RIPE database user groups what is going to change. -Marten

1 0

Database transition step 1 completed
by Marten Terpstra 14 Oct '94

14 Oct '94

Dear all, I am pleased to say that the first step of the RIPE database transition has been succesfully completed yesterday. Up till now, one minor and one major bug have been found and fixed and the database seems stable. Those who daily ftp the ripe database from ftp.ripe.net may have found that it was not there this morning. This was a simple typo in one of my scripts and has been fixed. The ftpable files (the complete database in ripe/dbase/ripe.db and the split versions in ripe/dbase/split) are currently generated at around 5:30 (AM for the US folks ;-) Dutch time, which is currently UTC+1. All database files ara available as uncompressed and compressed (both normal compress and gzip) versions. The generation time can be changed if you think there is a need (earlier, not later). Those who run a secondary copy of the database may find that the latest ftpable database takes much longer to index. This is because the database now includes large provider blocks, and the old software is not good at handling large blocks. The current plan is to have a beta release of the software (with some documentation on the changes) ready this weekend, so you can pick up this software and use it to index the RIPE database. This version will have all of the classless and other features as per the database transition plan (T1). As far as conflicts/problems in the guardian files are concerned, most of them have been resolved. There are some 15 guardian files left with problems. These guardians will be approached to correct these problems. If you have questions/comments/bugs, please report to me personally, or to any of the above lists if you think they are interesting for a larger audience. Regards, -Marten

1 0

New Document available: ripe-123
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-123 Title: RIPE Database Transition Plan Author: Tony Bates, Daniel Karrenberg, Marten Terpstra Date: 3 October 1994 Format: PS=70350 TXT=35083 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document guves full details of the transition plan for the new proposed RIPE database and routing registry objects. Please make sure you are aware of the details in the document including the actual dates. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-123.txt for the ASCII version ripe-123.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-123.txt

1 0

New Document available: ripe-122
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-122 Title: Specifying an `Internet Router' in the Routing Registry Author: Tony Bates Date: 3 October 1994 Format: PS=37970 TXT=14242 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document specifies a simple object for detailing Internet routers with the RIPE routing registry. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-122.txt for the ASCII version ripe-122.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-122.txt

1 0

New Document available: ripe-121
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-121 Title: Support for Classless Internet Addresses in the RIPE Database Author: Tony Bates, Daniel Karrenberg, Marten Terpstra Date: 3 October 1994 Format: PS=36698 TXT=14177 Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document details the added support for classless Internet addresses in the RIPE database. It details the change in representation and handling of database objects. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-121.txt for the ASCII version ripe-121.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-121.txt

1 0