- db-wg - mailman.ripe.net

Re: NIC Handle's postfix
by Steven Bakker 15 Jan '97

15 Jan '97

==> From: Suwat Panitkullawat <suwat(a)rs.thnic.net> ==> Wed, 15 Jan 1997 21:43:39 +0700 (GMT+7:00) > From instruction in RIPE's configuration file. There is a suggestion that > we should not use NIC handle's postfix differrent from the source name. > > Can someone explain me why? Are there any serious errors if I do so. Depends on your definition of "serious" :-) If you set up your own database, with source "SUWAT" for example, but you choose to keep the "RIPE" postfix for NIC handles, you might be able to register a record for yourself, with handle "SP-RIPE". However, there is already an "SP-RIPE" in the RIPE database, causing some confusion. The idea of a NIC handle is to have a unique key pointing to a person. Using the "source:" as the postfix helps you identify in which database the handle is registered and avoids conflicting registrations for the same key. To be fair it's also a bit of a kludge, but probably the only thing that will work until we have a truly global IRR. And may facilitate merging existing operational databases once a global IRR is there, avoiding NIC handle clashes across databases. Of course, the postfix trick only works as long as the "source:"'s are allocated in a unique way. Hope this helps, Steven

1 0

RIPE-26, DB-WG, Proposed Agenda, 3rd Draft
by Wilfried Woeber, UniVie/ACOnet 14 Jan '97

14 Jan '97

Dear all! This is the 3rd draft of the proposed agenda for the January 1997 DB-WG Meeting in Amsterdam. This one - takes care of minor changes and some re-sequencing, - tries to estimate the time needed per topic (if it's not agreed already, please confirm presentation times!) - has some modifications for item F. As usual any and all comments and input appreciated. See you in Amsterdam, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-26, January 1997, Amsterdam 3rd Draft, Jan. 13, 1997 A. Administrative stuff (W.Woeber, chair) 10min - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions in the future? B. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) 10min - recent changes - recent bug fixes and development (if any) - feedback from the users (if any) C. Report on DB evaluation by VUA 20min - consistency - usage D. Reports (D.Kessens, ISI) 30min - on RPSL - on 'ride' (registry data exchange format) E. Documentation (DB-SW maintainers, RIPE-NCC) 10min - current status, progress, review, test-driving - availability F. New functionality, proposals, reports 40min - IPv6 object proposal (D.Kessens, ISI) - summary report on issues to improve DB security and authentication (J.Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - improved url handling (in HTML interface) - proposed/implemented changes in date format for changed: attribute - handling of timestamps (changed:, different time-zones, UTC,...) - multiple contact "body parts" for a person: object - report on/review of the consolidated wish-list G. General input from other WGs 10min - hierarchical authorisation for route: obj (from Routing WG) Y. RIPE Database AUP (D.Karrenberg, RIPE NCC) 10min - short term measures to prevent abuse - defining an AUP Z. AOB # - . - # -------------------------------------------------------------------------- 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

Re: Immediate - Date in Changed field
by Wilfried Woeber, UniVie/ACOnet 14 Jan '97

14 Jan '97

=>> =>> I definitely agree for the need for this. But the changed attribute is =>> inserted by the person who registers the object, not by the database =>> software, he has the full control over which timezone he uses and to =>> lie. =>> =>> May be what we really want is a timestamp field with the granularity =>> you suggest and in UTC zone, but inserted to the objects automatically =>> by the database software. I see a lot of value in this. =>> => I completely agree with you. This can only be done if the database software => sets the time stamp. I guess this also solves most of the race conditions => otherwise implied. = =This would most definitely be a significant improvement (but is a =different point than the "changed" field) I believe this is on the =the list of Open Issues to be reviewed next week. If not it will be =then. = =Greetings, = =-- Carol Carol, I'm aware of that. And yes, in principle (by definition) the submitter of an object has to care about the date field supplied. But! - first of all, the DB-SW checks the date supplied against a date "in the future" (or has done that?, I think) and, - if *no* date field is supplied int the update message, then the software supplies the local date. And this *can* make a diference, isn't it? Of course, solving that in a decent way is preferred. Otoh, if (as long as) we rely on the user, we might add an (optional?) offset +/-xx hours from GMT if "The Solution to Everything" takes another couple of month to implement. (We might end up with 42 for a solution anyway :-) Cheers and let's see next week, Wiflried. -------------------------------------------------------------------------- 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

Immediate - Date in Changed field
by Carol Orange 13 Jan '97

13 Jan '97

Dear Database WG members, We have been requested to ease the restrictions on the date in the "changed" attribute to allow for dates with 4 digit years specifically those starting with "19" and eventually "20". For obvious reasons, we agree with this proposition. However, we also understand that some of you may have software which presumes the date has the yymmdd format. If anyone has a serious problem with this change, please notify me personally (orange(a)ripe.net) before the end of the week. If we don't hear any show stoppers before the end of the week, we will proceed. Thereafter, the following will be acceptable formats: 19yymmdd 20yymmdd (eventually) yymmdd Thanks for your ear, -- Carol Orange

1 0

hierarchical route objects, part 1
by Schmitz＠RUS.Uni-Stuttgart.DE 11 Jan '97

11 Jan '97

Dear colleagues, regarding hierarchical authorization of route objects in the RIPE database: from what I have heard there is a general feeling that it is needed and the basic scheme to implement it should follow the lines: * The root of the authorization tree is an AS-object (aut-num object). If it contains a "mnt-lower" attribute it controls all route-objects which have this AS as origin. * Then for route-objects the same rules apply as for inetnum-objects with respect to IP subranges: If a route-object contains a "mnt-lower" attri- bute it controls all more specific route-objects immediately below. * The authorization is checked against - more or less specific route-objects, or existence of the route-object itself with same origin (differing origin rejected) - if no route-objects exist: which authorization is specified for the autnum-object referred to by the origin attribute (rejected if this authorisation is not met) - if not even an autnum-object exists no action is taken However: there is still a problem that route-objects are somehow logically linked to allocated address space. The question how to deal with this is still open - I continue on this in a separate mail. Yet, the three rules for route-objects described above are a kind of common denominator(*) and moreover a very reasonable approach (these rules are also independent of the address space allocation relation to route-objects). If there are no further denials I suggest to implement it that way. Regards Joachim (*) Yes, I know: When aiming for the common denominator, be prepared for the occasional division by zero. _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

5 5

Re: hierarchical route objects, part 1
by Steven Bakker 10 Jan '97

10 Jan '97

==> From: Gabor Kiss <kissg(a)sztaki.hu> ==> Thu, 9 Jan 1997 11:28:52 +0100 CA> I disagree that this is a good idea. If I register the following route CA> object (which actually exists): CA> CA> route: 128.0.0.0/1 CA> descr: HALF-DEFAULT-ONE CA> origin: AS1800 CA> advisory: AS690 1:1800 2:1239 CA> mnt-by: MAINT-AS1800 CA> mnt-lower: MAINT-AS1800 CA> CA> nobody else can register any route objects. GK> This can be prevented by this object GK> route: 0.0.0.0/0 GK> descr: for authorisation purposes GK> origin: AS0 GK> mnt-lower: MAINT-INTERNIC GK> etc. GK> GK> Internic (or whatever else) may delegate maintainer rights as well GK> as allocates address ranges. That still doesn't help you if the 128.0.0.0/1 is already registered (which it is); I imagine the proposed auth scheme would look for the most specific enclosing route object, which is 128.0.0.0/1 and not 0.0.0.0/0 (for most routes nowadays anyway). Steven

2 1

again: hierarchical route objects
by Schmitz＠RUS.Uni-Stuttgart.DE 09 Jan '97

09 Jan '97

Dear all, this is quite some discussion (I really did not expect this). Obviously, I could have been doing some more thinking before writing my earlier mail... Now, I try to summarize some of the points. I think Havard made some good comments. He really had me reconsider the effect of a "mnt-lower" attribute in the aut-num object. Actually, "mnt-lower" makes perfect sense if some hierarchically lower object exists (which is valid for IP address ranges). From some logical point of view, aut-num objects may well be understood as being hierarchically higher than route objects. However, to create a route object in the database the current imple- mentation already demands a reference to an autnum object and a main- tainer object: route: [mandatory] [single] descr: [mandatory] [multiple] origin: [mandatory] [single] hole: [optional] [multiple] withdrawn: [optional] [single] comm-list: [optional] [multiple] advisory: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [mandatory] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] By the mandatory mnt-by attribute some authorisation is already needed (as specified in the maintainer object). Adding a mnt-lower attribute to the *aut-num* object does not change much, and raises the question what objects are actually hierarchically below it - these are not necessarily route objects. I guess, this is one of the reasons why several people feel that a closer relationship to allocated IP address space should be established. As the mnt-lower attribute in an aut-num object seemingly does not lead to additional hierarchical authorisation we arrive at the question what we want to achieve with hierarchical authorization of route objects. For me the rationale behind it are similar to inetnum objects: to exert control. If some origin AS routes an IP range, no other AS shall claim this range or subranges. However, we must ask ourselves how reasonable this approach is because we run into several problems here (Cengiz, Gabor, Steven, and earlier Curtis discussed this): - There must be some starting point for the authorization - otherwise anybody may create route objects of IP address ranges where none do yet exist. This seems to tie the route objects closely to allocated address space (which again leads to problems - as noted before - be- cause several registries are pure routing registries). Moreover, route objects may be created in one registry which are forbidden by authorisation in another. This really calls for "the GRR" (where pure routing registries might be regarded as less authoritative). I fear we do not have a solution for this problem today. - Multihoming will be impossible if authorization is based upon IP address ranges alone because in this case only one route object of one origin is allowed in the registry for each IP range. - Situations may arise where IP subranges must be routed by another AS than specified in an less specific route object. To restrict access to these subranges the "hole" attribute might be applicable. Subranges defined by "hole" could be excluded from the authorization as long as no route object exists which covers this subrange. I can imagine that this is complicated regarding implementation in the database software. - Handing over route objects from one maintainer to another will become difficult - up to now this is solved by allowing existence of several route objects for the same address space but of differing origin. This is a very convenient solution thinking of cases where filters for router configurations are built from route objects in the database. If two identical route objects of different origin exist this may allow a smooth switch over from one AS to another. With an authorisation scheme solely based upon IP address ranges as specified above this would no longer be possible. - Others? While with inetnum-objects the "mnt-lower" attribute leads to strong control there was a suggestion by Daniel that for route objects noti- fication may be sufficient. On the one hand (taking it to the extremes) this might lead to cases where an organisation controls an inetnum object but others control the route objects of the same address range (this may be reasonable but also a real competitive problem). On the other hand is this restriction needed because then at least multi- homing will probably become impossible? Anyway: obviously, checking hierarchical authorization with route objects is quite complex regard- less of the fact whether notification only or restrictive authorization is applied. This whole thing became longer than I first intended. It seems there is more in it than we all thought first ... however, some of the problems we have run into look similar to those of inetnum objects ... may I ask for additional comments? Any further suggestions, problems,... ? Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

Re: hierarchical route objects, part 1
by Gabor Kiss 09 Jan '97

09 Jan '97

Dear Cengiz, > I disagree that this is a good idea. If I register the following route > object (which actually exists): > > route: 128.0.0.0/1 > descr: HALF-DEFAULT-ONE > origin: AS1800 > advisory: AS690 1:1800 2:1239 > mnt-by: MAINT-AS1800 > mnt-lower: MAINT-AS1800 > > nobody else can register any route objects. This can be prevented by this object route: 0.0.0.0/0 descr: for authorisation purposes origin: AS0 mnt-lower: MAINT-INTERNIC etc. Internic (or whatever else) may delegate maintainer rights as well as allocates address ranges. Gabor

2 1

Re: hierarchical route objects, part 1
by Havard.Eidnes＠runit.sintef.no 08 Jan '97

08 Jan '97

Hi, just a few quick comments to your proposal. > regarding hierarchical authorization of route objects in the > RIPE database: from what I have heard there is a general > feeling that it is needed and the basic scheme to implement it > should follow the lines: You say very little about the reasons and motivations for wanting the modified behaviour. I think that is important to state. I've made some guesses below -- correct them as appropriate. > * The root of the authorization tree is an AS-object (aut-num > object). If it contains a "mnt-lower" attribute it controls > all route-objects which have this AS as origin. Aren't the route objects with a given origin already controlled by the authorization specified in the aut-num object? (Sorry, it's been a while since I twiddled "my" route objects, so I'm a bit rusty on this now.) If I'm in error here and this is modified behaviour, what would the motivation be for it? > * Then for route-objects the same rules apply as for > inetnum-objects with respect to IP subranges: If a > route-object contains a "mnt-lower" attribute it controls > all more specific route-objects immediately below. The motivation seems to be to have the option of controlling the use of the given address space covered, e.g. to require intervention by the maintainer/"owner" of the address space should a customer want to leave and take the address space within this address block with him, or to prevent such a move. (?) Other than that I think your suggestions make sense. - Håvard

1 0

RIPE-26, DB-WG, Proposed Agenda, 1st Draft
by Wilfried Woeber, UniVie/ACOnet 07 Jan '97

07 Jan '97

Dear all! This is the initial draft of a proposed agenda for the January'97 DB-WG Meeting. As usual any and all comments and input appreciated. Best regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Database Working Group Proposed Agenda for the meeting during RIPE-26, 1st Draft, 7.1.1997 A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW status report by the RIPE NCC - recent changes, - recent bug fixes and development (if any) - feedback and experience C. Report on DB usage evaluation by VUA D. Reports by D. Kessens, ISI - on RPSL - on 'ride' (registry data exchange format) E. Documentation - current status, progress, review, test-driving - availability F. New functionality - IPv6 object proposal (D. Kessens, ISI) - hierarchical authorisation for route: obj (J. Schmitz, DFN NOC) - extension for inet-rtr: obj (tentatively, W.Woeber/E.J.Bos/et.al.) - extending the list of attributes that can be used in -i lookup? - handling of timestamps (changed:, different time-zones,...) - things on the consolidated wish-list - improved url handling (in HTML interface) Y. General input from other WGs Z. AOB -------------------------------------------------------------------------- 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

Re: setuid dbupdate
by Gabor Kiss 09 Dec '96

09 Dec '96

> I have not tested this code. Please let me know if it works. No need to > CC the whole db-wg mailing list since it is not really a design issue ... Sorry... Gabor

1 0

setuid dbupdate
by Gabor Kiss 06 Dec '96

06 Dec '96

Dear Ambrose, The ripe-dbase-2.0.4/README file writes: - perl has some build in checks for suid perl scripts. These are all taken care of, so dbupdate should not complain about not being able to do things because it is running suid or sgid. Have a look in the code for dbupdate to see what silly things one has to do to get around these checks ... kissg writes: This is not enough. ;-) Under Solaris 2.5, and with ... This is perl, version 5.003 with EMBED built under solaris at Sep 17 1996 16:40:19 + suidperl security patch I get: "Insecure dependency in open while running with -T switch at /usr/local/whois/lib/addkey.pl line 52." 52: if (open(OVERFLOWADD, ">>".$db[1].$OVERFLOWEXTENSION.$value)) { I tried at least six different tricks to avoid this message. No success. (Hardcoded direct setuid C wrapper is not included in the six.) Any suggestion? Gabor

2 1

None
by Paul Libauer 14 Nov '96

14 Nov '96

subscribe

1 0

Re: [RADB #2390] RADB Timezone
by sds＠jazzie.com 13 Nov '96

13 Nov '96

Gerald Winters suggests (see below) that this work group might be a good place to discuss the timezone used when calculating a proper date for the changed: field of RADB objects. Is there a valid rationale for the RADB's use of a local timezone rather than Universal Time? If not, can this work group make a recommendation (formally or otherwise) to the RADB suggesting Universal Time be used to calculate the date for this field? The other inter-registry consistency issues Gerald mentions are likely important too, but this one seems ... totally without controversy. Or am I missing something? -- Sean Shapira sds(a)jazzie.com +1 206 443 2028 Gerald A. Winters (gerald(a)merit.edu) > > Sean, > > Actually there are some good reasons to use universal > time. For example, we import the ripe registry and they > are not using EST as we are. So there is some conflict > there. > There has been talk of enforcing consistency among the > registries (ie, aut-num policy, maintainer registration, ...) > and the changed date (ie, time-stamping) will undoubably play > an important role. > I think the changed data is ignored to a certain extent because > humans supply the date and not the software. The software only > checks for dates in the future, I believe, but will accept dates > in the past. So the changed date is more like a hazy indicator > rather than a precise time stamp. You know the the real/exact > changed date is <= to the actual changed date. > The place to bring this point up is at the RIPE meetings > to the data base working group. > > --Gerald > > Sean Shapira writes: > >In response to a recent RADB update request I received: > >> WARNING: date in "changed" (961113) is in the future - changed to 961112 > > > >The trouble? I'm guessing auto-dbm(a)ra.net was using Eastern > >Standard Time; I was using Universal Time. It seems a window > >of vulnerability exists during which auto-dbm has an incorrect > >idea of the "one true date" ;-). > > > >Seriously, as the global route registration database of last > >resort, doesn't using Universal Time in the RADB make sense? > > > >-- > >Sean Shapira sds(a)jazzie.com +1 206 443 2028 > > Serving the Net since 1990. > > -- > Gerald A. Winters gerald(a)merit.edu > Merit Network, Inc. (313) 747-3522 (office) > 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) > Ann Arbor, MI 48105-2785

2 1

Telnet interface to the RIPE database.
by RIPE Database Administration 13 Nov '96

13 Nov '96

Dear Colleagues, If you use the telnet interface to the RIPE database, please note that a "-k" option is available. This will keep the connection open until you close it yourself. Example: ------- [ambrose] $telnet whois.ripe.net 43 Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. -k Ambrose Magee % Server is running at low priority for -M, -m and -k queries person: Ambrose Magee [...stuff deleted...] source: RIPE -T route 193.0.0.0/24 route: 193.0.0.0/24 [...stuff deleted...] source: RIPE -k Connection closed by foreign host. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Version 2.0.4 of the RIPE Database Software.
by RIPE Database Administration 12 Nov '96

12 Nov '96

Dear Colleagues, Version 2.0.4 of the interface software for the RIPE database is now available at ftp://ftp.rip.net/ripe/dbase/software/ripe-dbase-2.0.4.tar.gz . This new version has the following changes: enparse.pl and enread.pl have been improved to fix the problem of empty attribute lines; whoisd.pl has been changed to give clearer error messages for the "-s" and "-k" options; src/Makefile has been improved in a few minor ways. I wish to thank David Kessens for sending patches for the above files. If you have any problems, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database.
by RIPE Database Administration 12 Nov '96

12 Nov '96

Dear Colleagues, You can now create your own maintaininer objects in the TEST database. You do not need to send them to <ripe-dbm(a)ripe.net> anymore. If you have more problems, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TROTS -- RIPE Database questionnaire
by ppbakke＠cs.vu.nl 06 Nov '96

06 Nov '96

Dear reader, This questionnaire is sent to you by the TROTS project team. This team, consisting of students from the Vrije Universiteit Amsterdam, is currently looking at the RIPE database and hopes to gain some information on how users employ this database, and on what their attitude towards this database is. We would appreciate it if you could find time to sit down for a moment and fill in the questions that are in this questionnaire. The questions are set up in such a way that it doesn't take much time to answer them. The outcome of our project might help the RIPE NCC together with the RIPE Database Working Group to make a better database and improve the quality of its services. Thank you in advance, The TROTS project team. INSTRUCTIONS: If you find brackets under a question (i.e. [ ]), you can fill in a 'x' for the appropriate answer (i.e. [x]). If you find a word, followed by a semicolon (i.e. 'answer:'), you can write down your answer after it. (i.e. 'answer: this is my answer') We would appreciate it if we receive your reply before Wednesday, November 13th 1996. ========================= THE QUESTIONS ========================= -> SECTION I: INTRODUCTION 1. Who are you? (optional) Company name: Name: 2. What is your function? (optional) [ ] Network administrator [ ] Network technician [ ] Other, namely: 3. How do you use the database? [ ] for updates and queries. -> GOTO Section II [ ] only for queries. -> GOTO Section III [ ] I do not use it. -> As a last question: can you tell us why not? Answer: -> SECTION II: UPDATES 1. What kind of updates do you perform? [ ] in the assignment registry [ ] in the routing registry [ ] both 2. How do you grade making updates by the e-mail interface in the database? [ ] easy [ ] not so easy [ ] indifferent [ ] not so hard [ ] hard 3. Do you know what templates stand for and how to use them? [ ] Yes [ ] No [ ] I do not know what is meant by this question 4. How do you fill in the templates? (you can fill in more than one answer) [ ] by hand [ ] by applications (which: ) [ ] by applications that I wrote myself (for what: ) 5. When changing an object, do you always delete older objects or objects that are not referenced anymore? If not, can you tell us why? [ ] Yes [ ] No, because [ ] I have no time [ ] it is too much of a hassle [ ] do not know how [ ] other: 6. Do you always update the database when the facts change? If not, can you tell us why? [ ] Yes [ ] No, because [ ] I have no time [ ] too much of a hassle [ ] do not always know that facts have changed [ ] other: 7. Are there any routing policies which you would like to adopt, but cannot represent in the database? If so, which ones? [ ] No [ ] Yes, namely: 8. Can you give us an indication on how many updates you perform per month? [ ] less than 10 [ ] 10 - 50 [ ] 50 - 100 [ ] more than 100 -> SECTION III: QUERIES 1. How do you make queries? [ ] By using whois [ ] By using the RIPE tools (like prtraceroute) [ ] I run applications that make use of it (other than tools of RIPE) 2. What do you make queries for? [ ] trouble shooting [ ] making routing tables [ ] other, namely: 3. Do you ever encounter ambiguous/inconsistent data while making queries? If so, can you give us examples and a rate of how often this happens? [ ] No. [ ] Yes, namely: 4. Can you always find what you are looking for? [ ] Yes. [ ] No -> Can you give examples of what you could not find? Examples: 5. Do you miss any data that you would like to see added? If so, can you state which? [ ] No. [ ] Yes, namely: -> SECTION IV: GENERAL 1. How useful do you consider the database? [ ] I could not live without it. [ ] It is a nice feature. [ ] It's not very useful. 2. How would you grade the overall quality of the database on a scale of 1 to 5 (5 being the best) ? [ ] 1 [ ] 2 [ ] 3 [ ] 4 [ ] 5 3. Do you have any remarks you want to add? Remarks:

1 0

Finger tool to get a NIC handle.
by RIPE Database Administration 05 Nov '96

05 Nov '96

Dear Colleagues, You can no longer use `finger handle.YOURINITIALS(a)whois.ripe.net' to obtain the next free NIC handle. You will only get a message about using the `AUTO' NIC-handle mechanism. This finger tool was shut down because it could give NIC-handles with more than 4 characters in the initials and more than 11 characters in total. Furthermore, it placed an unacceptable (and unnecessary) load on the whois server, particularly at peak times. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database.
by RIPE Database Administration 28 Oct '96

28 Oct '96

Dear Colleagues, The TEST database is working again. Thank you for your patience. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database is tempoarily out of order.
by RIPE Database Administration 26 Oct '96

26 Oct '96

Dear Colleagues, The TEST database is temporarily out of order. It will be fixed as soon as possible. Regards, RIPE Database Administration.

1 0

Re: List of known bugs.
by Wilfried Woeber, UniVie/ACOnet 22 Oct '96

22 Oct '96

= > > =keep an exception for NEW only ... = > > Not just *another* exception please !! = > = > Agreed. I used dots for a reason ;-). = > I would prefer to use another uncommon word or a clear separator. I just = > don't like case sensitivity lazy as I am... = =How about 'createobj'? =Not very likely to be a common word in subject lines. I could live with that. =the other possibility is to do away with the subject line stuff =and create a real command interface. Actually I prefer the latter. Me too. It would be much cleaner and the password:-line mechanism was the first step into that direction, true ? Wilfried.

1 0

Re: mnt-nfy
by zsako＠banknet.net 21 Oct '96

21 Oct '96

> From owner-db-wg(a)ripe.net Fri Oct 18 08:19:02 1996 > In my opinion notifications should *not* be sent to the originator of > the change request. We had too many complaints about too many > notifications. Those wishing to receive notifications of their own > changes can easily achieve that by putting an alias mailbox into their > notification attributes. I think I have no problem with the above (I mean I will not argue in favour of changing this). > Note also that this smartness quite consciously introduces less > 'security' because it allows someone to make clandestine changes by > forging his From:-address to avoid notification. We did this because > those with really high security requirements shoud use maintainers with > a stronger authentication menthod. Correct. However I originally noticed that this "feature" also works by adding a Reply-to: in the header... My point at the RIPE meeting was that when sending an update with a Reply-to, the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, (since the "Congratulations" are sent to her), but has no clue wrt. WHAT exactly has been modified (usually the Subject: line does not provide accurate information - if at all)... (Of course, the situation can be even worse if the From: line is forged...) If I remember correctly, at the DB-WG session the absence of the notification (in the Reply-to case at least) was considered a *bug*. I still incline to consider the "Reply-to case" a bug (or *unwanted* feature). Forging the mail header is usually less trivial than adding a Reply-to. The latter can even occur inadvertently (this is how I discovered all the above). Janos PS. I suppose (and strongly hope :)) the authentication is based on the From: and not the Reply-to:.

3 2

Re: List of known bugs.
by Wilfried Woeber, UniVie/ACOnet 21 Oct '96

21 Oct '96

=I have a couple of comments on things that you list as bug that might =sometimes be better listed as a feature or are not as a bug at all...: But then at least as an undocumented wiseguy approach. Sorry for the sarcasm, but we seem to be doing some reverse intent engineering these days.. =under persons: = => 2/. FEATURE => Titles such as "Dhr" will be interpreted as names; a request => to create a person object for "Dhr J Russell" will receive => a nic-hdl = DJR#-RIPE, not JR#-RIPE. => => 3/. FEATURE => Titles such as "Mr" will be rejected. = =2 & 3 are the same issue. The software has a built in list of common =titles. However, such a list can never be complete and making it complete =might hurt people that speak other languages and that might have a common =title in one country as their first name in their local language. =Therefore I included a short list (that contains Mr(s)/Dr among others) =that would catch most of the problems. Of course, any very common title =that I forgot can be added if desired so. I have to think about that. PArt o fme likes the approach, the other one thinks it's a *very* bad idea to have potentially different reject lists. How does that interact with NRT-Mirroring in particular and object exchange in general? Shouldn't that move to somehow, somewhere into the update interface, and maybe be made controllable? => 4/. A person object may be created with a nic-hdl of the form => ASxxxx, even if there is an aut-num object with the same => AS number. A whois enquiry on ASxxxx will retrieve both => objects. = =What's the bug here ? It is perfectly valid to have AS# as your InterNIC =handle and it can indeed also be a valid AS number at the same time: = =$ internic AS100 =Sackheim, Andy (AS100) andys(a)DAVSYS.COM =daVinci Systems, Inc. =5410 NW 33d Ave Suite 100 =Ft. Lauderdale, FL 33309 =(305) 484-8100 Agreed. No bug. We have the -T flag to control the software behaviour. =In the past there was a bug in the database software that would regard =AS# as an AS number and thus wouldn't look up any persons that had the =same AS# as their NIC handle. = => 5/. The Auto-Nic-Hdl mechanism allows a maximum of four initials. => => However, when using the finger handle mechanism, => a RIPE nic-hdl may be generated which has more than 11 => characters e.g. => => ambrose $finger => handle.AMBROSE(a)whois.ripe.net => => gives => => First free handle: AMBROSE251-RIPE. = =I think that the limit of four is a healthy limit. This limit can be =increased if desired. No, I think 4 is definitely the maximum. If we had enforced a limit of 3, we wouldn't have had less ambiguity with AUTO-x and the like. But now it's 4, so let's stick with it. =It seems that the bug is in the finger tool, not in =the Auto_Nic-hdl mechanism. The problem here is that there is never =decided about a formal limit on the number of initials. = As the finger tool is to be decommissioned anyway, so what. => 6/. When a pseudo-person object is deleted, and its nic-handle used => in a genuine role object, the role object is not found using a => recursive look-up, even though it is in the database. = =This is not true. The problem some people might have had was: = =role objects are not allowed in 'admin-c:' fields as decided by the =database workinggroup. The software is optimized to not do unnessecary =lookups and will thus not do a lookup for a role object in 'admin-c:' =fields. Another wiseguy approach. We know, that we cannot guarantee integrity. Unless we change the very basic maintainance model, that is. Thus the SW should *not* imply integrity = The real bug is thus that there is no check that disallows the =use of role objects in 'admin-c:' fields, this is not possible right now =due to the lack of the 'non-existing references' checking (which is a =known problem!). The problem can be softened by changing the config file =and allowing role objects in the 'admin-c:' fields (for lookups). That's exactly the other way 'round. Note that we had input recently from other WGs to tighten the rules and have the SW enforce the decisions. =However, this defeats the decision made by the database working group for =not allowing role objects in the 'admin-c:' field... We have discussed that and I expect some activity towards closing that gap in the foreseeable future. =In all objects: = => 1/. The "NEW" keyword is case insensitive. If it appears anywhere => in the Subject line of an update, the update will be disallowed => with the message "ERROR: object already exists". => => E.g. an update with the following in its header: => => Subject: Old person object, but new address. = =This is a feature but probably not a very desirable one... I agree, about the not very desirable :-) =I think it is =a good thing to keep the keywords case insensitive (this was also the case =for LONGACK), It depends, see below =however something a less common word then NEW could solve =this problem just like LONGACK (nobody is using that in real life ;-)) or =keep an exception for NEW only ... Not just *another* exception please !! My preference would be for a real solution. Enforcing UPPERCASE is the minimum. I'd even vote for addtional constraints, like FLAG only being recognized at the very begging/end of the line, or even requiring some special characters to surround the FLAG string. Pick your favourite convention, like double quotes, html brackets,... =In routes: = => 2/. RIPE-181 states that the guardian attribute is mandatory in the => aut-num object. However, it is optional in the database => template. = =This is change decided by the database working group some time ago. =Some people would like to go even further and would like to obsolete the =attribute altogether or convert it to 'notify:' attributes. Unless I forget, I'll put it on the agenda for the January RIPE Meeting to obsolete it. => 3/. RIPE-181 states that "Whenever a route object is => created or deleted or => the comm-list attribute changes, the guardians of all communities and => ASes referenced by the old and new objects will be notified in addition = =The 'guardian:' attribute is behaving exactly as a 'notify:' attribute. =From the 2.0 release notes: = =- All support for the historical 'guarded' objects have been removed. The = guardian attribute can be obsoleted if the database working group = wishes to. Present guardian attributes will act as a 'notify:' attribute. Ditto. Another source for complexity. = =In inetnum: = => 2/. An inetnum object may be created with an range limit of => *.*.*.* - 255.255.255.255; a warning will be generated, => but the entry will be allowed. = =This can be solved with an hierarchical authorization 'inetnum:' object. For that special case I agree. =I don't think it's a good idea to include thousands of specific tests for =problems that happen only once in 1,000,000 updates. These kind of tests =tend to cause more harm then solving anything: If you disallow =255.255.255.255 people can still do 255.255.0.0 or 10.0.0.0 - 194.0.0.0. = =However, in *all* cases the software will issue a warning that you used a =very large range and asks the user to check if that was intended. This =should catch most of these problems. Furthermore, this kind of errors is =so obvious that other people will report it very, very soon when found as =happened recently ... Again, I don't support throwing in more tests at random. Instead I'd like to see structural tests that can be defined, implemented easily (concept-wise) and enforced by the IR rules. E.g. addess ranges must not overlap each other and should be in line wity registry allocations, etc. We're discussing this issue already. =In maintainer objects: = => 1/. Use of MAIL-FROM authorisation: => => use the full e-mail address gievn in the "From" field of => the mail header of the update message. = =This is not true. You may use part of the E-mail address, however be =warned that the matching is done case-sensitive as specified by RFC822 =(this is in fact sometimes a very nice security by obscurity mechanism ;-)) Well for the "nice" :-/ Is this in line with the notfication suppression logic? I don't think this is a good idea at all. Even if it's in the Books, what do we want to achieve by trying to enforce it? I think reality in the Mail environment is (mostly) caseINsensitive these days... =David K. Comments, please! Cheers, Wilfried.

3 2

Re: mnt-nfy
by zsako＠banknet.net 21 Oct '96

21 Oct '96

> From davidk(a)isi.edu Fri Oct 18 18:33:24 1996 Dear David, > > My point at the RIPE meeting was that when sending an update with a Reply-to, > > the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, > > (since the "Congratulations" are sent to her), but has no clue wrt. WHAT > > exactly has been modified (usually the Subject: line does not provide accurate > > information - if at all)... > > This is true. You will receive less information then with a notification > message in this case. This is clearly a disadvantage, but also an > advantage for those people that are getting a bit tired of the amount of > mails coming from the RIPE database automatic department. OK. I understand now, this really IS a feature. > > > (Of course, the situation can be even worse if the From: line is forged...) > > But you will always get at least one message from the database whether it > is an ACK message or a notify message. The smartness only eliminates more > mails sent to one and the same E-mail address. And again <ripe-dbm(a)ripe.net> > is always willing to investigate with the maillogs if you suspect > someting like this (in fact I *did* found a forgery once and I can assure > you that the person that did it will not do it another time ...) In fact I knew the NCC has very good logging (I once had to use this "service" :) ), but I thought we could spare some investigation. However, if such "errors" are infrequent, I agree it is not worth changing the behaviour. > > > PS. I suppose (and strongly hope :)) the authentication is based on the From: > > and not the Reply-to:. > > I can tell you from first hand experience (that is the code is > implemented as required in the specs) that the authentication is done on > the From: field and nothing else then that. This is what I wanted to hear, thank you. :) (I do not worry any more). Thanks again and regards, Janos

1 0