- db-wg - mailman.ripe.net

RE: Loop in AS macro
by Lu, Ping 18 Jan '01

18 Jan '01

Hi, Shane, Thank for the tip. It works. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Thursday, January 11, 2001 4:46 AM > To: Lu, Ping > Cc: 'cengiz(a)packetdesign.com'; Wilfried Woeber, UniVie/ACOnet; > farrache(a)cc.in2p3.fr; db-wg(a)ripe.net; routing-wg(a)ripe.net; > Henk.Uijterwaal(a)ripe.net > Subject: RE: Loop in AS macro > > > Ping, > > What I usually do (in Perl) is something like this: > > my %entries_seen; > foreach my $as_set (@as_sets) { > # if we've seen this value (recursive as-set), skip > next if ($entries_seen{$as_set}); > > # note that we've seen this as-set > $entries_seen{$as_set}++; > > # get a list of members of the as-set, and process appropriately > foreach my $member (members($as_set)) { > # add member as-sets to the list of as-sets to process > push(@as_sets, $member) if ($member =~ /^AS-/i); > > # other processing here > . > . > . > } > } > > If you're using some other scripting language, it will be > different, but > typically no more difficult. If you're in C, you may want to > use glib or > something like that, otherwise you'll need to use a list or > hash you write > yourself. > > Shane Kerr <shane(a)ripe.net> > Database Software Engineer > RIPE NCC > +31 20 535 4427 > > On Wed, 10 Jan 2001, Lu, Ping wrote: > > > Hi, I am new to this list and would like to ask a (maybe > stupid) question to > > the dicussion: > > > > If we want to write a script to expand the AS MACRO, how > can we avoid to go > > into a loop if multiple AS-MACROs reference each other ? > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: 703-292-2359 > > E: plu(a)cw.net > > > > > -----Original Message----- > > > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > > > Sent: Wednesday, January 10, 2001 12:14 PM > > > To: Shane Kerr > > > Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; > > > db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net > > > Subject: RE: Loop in AS macro > > > > > > > > > > > > Shane Kerr (shane(a)ripe.net) on January 10: > > > > Gilles, Wilfried, and all, > > > > > > > > This is not a bug, or even an inconsistency. Consider > the following > > > > as-macro objects: > > > > > > > > as-macro: AS-X > > > > members: AS-Y, AS123 > > > > > > > > as-macro: AS-Y > > > > members: AS-X, AS456, AS789 > > > > > > > > In this case, AS-X and AS-Y both expand to the same > aut-num objects: > > > > AS123, AS456, and AS789. However, they may have different > > > maintainers, > > > > contacts, descriptions, and so on. In RPSL, many more > > > kinds of loops are > > > > possible as well, in as-set, route-set, and filter-set objects. > > > > > > RPSL defines semantics when loops exist. However, it does > not promote > > > them, or prohibit additional restrictions by the registry > operators > > > not to have loops. > > > > > > > > > > > External software that deals with the set objects needs > to do loop > > > > detection in order to prevent infinite loops. For as-set > > > objects (which > > > > are as-macro objects in RIPE-181), this is fairly easy: > > > keep a list or > > > > hash of the AS sets expanded, and don't expand them again. > > > For route-set > > > > and filter-set objects it is not quite so easy. If you > > > need help with > > > > these, you can send me and e-mail and I can explain the > > > techniques that > > > > I've used for these objects. > > > > > > > > Shane Kerr <shane(a)ripe.net> > > > > Database Software Engineer > > > > RIPE NCC > > > > +31 20 535 4427 > > > > > > > > p.s. This is actually a feature, not an bug. :) > > > > > > > > p.p.s. It has been argued (by me) that RPSL allows > objects that are > > > > logically impossible, but the RFC authors don't seem to > think so! > > > > > > > > On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > > > > > Hi Gilles, > > > > > > > > > > I guess we wouldn't be able to check against those > > > accidents at the time > > > > > of a DB _update_... > > > > > > > > > > But checking the RR internal _data_ consistency could > > > maybe become part > > > > > of the RIS (or similar) project? > > > > > > > > > > Henk, any comments? > > > > > > > > > > An interesting aside: I guess similar problems > could occur with > > > > > RPSL-based RRs? > > > > > > > > > > -WW > > > > > > > > _________________________________:____________________________ > > > _________ > > > > > Wilfried Woeber : e-mail: > Woeber(a)CC.UniVie.ac.at > > > > > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > > > > > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > > > > > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP > > > keyID 0xF0ACB369 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > ~~~~~~~~~ > > > > > > > > > > To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, > > > admin-c(a)tli.de > > > > > CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net > > > > > Subject: Loop in AS macro > > > > > Date: Wed, 10 Jan 2001 10:28:15 +0100 > > > > > From: Gilles Farrache <farrache(a)cc.in2p3.fr> > > > > > > > > > > Dear database managers, > > > > > > > > > > I notice a loop in the followings AS-MACRO, in fact > > > AS-TELEDANMARKINTERNATIONAL > > > > > is calling AS-TLI which is calling AS-TELEDK which is > > > calling AS-TELEDANMARKINTERNATIONAL. > > > > > (and all that make that our automatic filter generation > > > tool fails) > > > > > > > > > > Could you correct those macro and will the Ripe database > > > management provide any > > > > > control on that kind of loop ? > > > > > > > > > > Gilles > > > > > > > > > > as-macro: AS-TELEDANMARKINTERNATIONAL > > > > > descr: Tele Danmark customers outside Denmark > > > > > as-list: AS1902 AS12461 > > > > > as-list: AS8881 AS-KOMTEL > > > > > as-list: AS13194 AS-BITE > > > > > as-list: AS6709 > > > > > as-list: AS8650 AS-TLI > > > > > as-list: AS8542 > > > > > as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 > > > AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 > > > > > as-list: AS12546 > > > > > as-list: AS15389 > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 20001103 > > > > > changed: toba(a)tdk.dk 20001117 > > > > > changed: tee(a)tdk.dk 20001123 > > > > > changed: jesper(a)skriver.dk 20001228 > > > > > changed: jesper(a)skriver.dk 20010109 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TLI > > > > > descr: Talkline GmbH, Internet Division > > > > > descr: List of ASes according to Talkline > Internet (AS8650) > > > > > descr: and customers > > > > > as-list: AS5605 > > > > > as-list: AS6783 > > > > > as-list: AS8650 > > > > > as-list: AS8881 > > > > > as-list: AS12461 > > > > > as-list: AS12546 > > > > > as-list: AS-TELEDK > > > > > as-list: AS-GLOBAL > > > > > tech-c: TLIP1-RIPE > > > > > admin-c: TLIP1-RIPE > > > > > notify: peering(a)tli.de > > > > > mnt-by: TALKLINE-MNT > > > > > changed: thomas(a)tli.de 19990923 > > > > > changed: thomas(a)tli.de 19991020 > > > > > changed: thomas(a)tli.de 19991025 > > > > > changed: thomas(a)tli.de 20001023 > > > > > changed: thomas(a)tli.de 20001025 > > > > > source: RIPE > > > > > > > > > > as-macro: AS-TELEDK > > > > > descr: Tele Danmark and Tele Danmark customers > > > > > as-list: AS-TELEDANMARKDANISH > > > > > as-list: AS-TELEDANMARKINTERNATIONAL > > > > > as-list: AS-BELBONEMEMBERS > > > > > as-list: AS-GLOBAL > > > > > tech-c: AS5071-RIPE > > > > > admin-c: AS5071-RIPE > > > > > notify: staff(a)ip.tele.dk > > > > > notify: peering(a)tli.de > > > > > mnt-by: AS3292-MNT > > > > > changed: jesper(a)skriver.dk 19990922 > > > > > changed: jesper(a)skriver.dk 19991019 > > > > > changed: jesper(a)skriver.dk 19991025 > > > > > changed: jesper(a)skriver.dk 19991210 > > > > > changed: toba(a)tdk.dk 20000903 > > > > > source: RIPE > > > > > > > > -------------------------------------------------------------- > > > ------------------ > > > > > > > > > > > > > > > > > > > > > > Cengiz > > > > > > -- > > > Cengiz Alaettinoglu Packet Design Inc. > > > > > > > > >

1 0

Re: CERT Object summary (for review in Paris)
by Wilfried Woeber, UniVie/ACOnet 17 Jan '01

17 Jan '01

Below please find the most recent summary of our proposal for a "CERT Object", taking into account all the comments I am aware of - as well as a couple of proposals for clarifiaction and open issues. This is for discussion and review by CERTs/IRTs in Barcelona and input for the DB-WG meeting next week in Amsterdam. Attributes that are "DB-Standard" get no tag, the CERT Object specific attributes are tagged with "*". For the description of the "DB-Standard" attributes refer to the DB Software documentation, please. * irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [ ] auth: [mandatory] [multiple] [ ] * mnt-cert: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] * signature: [mandatory] [multiple] [] * encryption: [mandatory] [single] [] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] - The irt: attribute assigns a unique name to an IRT object. Q: [to the NCC DB group] in your example, the IRT: attribute's value looks like a handle, and it is used like a handle in references. Wouldn't it be "cleaner" to allow person: and role: like identifications and assign a handle, which is then used to as a reference? Q: Another issue: assuming that a similar facility becomes available in other registry databases, should we try to "reserve" a handle-suffix for those handles? The use of "RIPE-CERT" got me wondering... - The mnt-cert: attribute points to a key-cert: object; it is checked when this irt object is added to e.g. an inetnum:. For all objects that support a pointer to an irt: object, a new attribute is defined as a reference pointing to an irt: object. This attribute might be named irt-c: or incident-c: Q: from an end-user point of view, wouldn't it be more "obvious" to use abuse-c: ? Q: We said that as a value for the auth: attribute, only PGPKEY-<key-id> would be allowed. Do we really need both, the (restricted) auth: _and_ the mnt-cert: ? - The signature: attribute points to a key-cert: object which defines one or more keys that are user by the CERT's team members to sign and/or encrypt messages sent by the team. - The encryption: attribute points to a key-cert: object which defines the key that should be used to sign and/or encrypt messages sent to the team. Q: should we try to find a more "obvious" name for those tags? I could think of sig-from: and encrypt-to: (similar to SMTP mail from and rcpt to :-) or even from-irt: and to-irt: Wilfried.

2 1

Re: Minutes from San Diego
by Randy Bush 17 Jan '01

17 Jan '01

i could not even get into the room. the minutes say whois users RIRs, routing registries, domain registries, registrars #1 and #2 are close #3 is a bit different actually, the whois port/protocol is used by all sorts of strange and arcane uses by all sorts of folk. imiho, we do not have the prerogative to break their uses by a change to the base whois/43 protocol. this is not to say that some group of applications of the whois protocol could not agree to use it in a common way, essentially forming an overlay protocol. randy

1 0

Moving the whois protocol discussion
by Paul Hoffman / IMC 15 Jan '01

15 Jan '01

Greetings. At the San Diego IETF meeting, it was decided that there was a desire to continue the discussion of updating the whois protocol. In the BOF, the address of this list was given for the discussion. Clearly, this list has lots of discussion that is not relevant to the whois update discussion, and vice versa. Because of this, I have set up a new list just for discussing the update to the whois protocol. Subscription information for the new list can be found at <http://www.imc.org/ietf-whois/>. The list is accepting subscriptions now, and posting to the list will start tomorrow. --Paul Hoffman, Director --Internet Mail Consortium

1 0

LIR-ALLOCATED revisited
by James Aldridge 15 Jan '01

15 Jan '01

LIR and DB Working Groups (with apologies for duplicate email), Discussed at RIPE-34 but with little subsequent action, I would like to repropose the addition of LIR-ALLOCATED as a valid status value for inetnum objects in the RIPE database. Attached is a slightly revised version of the document ("troff -ms" source version available on request) I last posted a year ago as a result of LIR-WG Action LIR-34.8. The suggestion then was that this could be massaged into a RIPE document (I think dfk volunteered!) to update ripe-185 (European Internet Registry Policies and Procedures) and that support for the new value be added to the database (and NCC tools as necessary). Regards, James -- Senior Network Engineer, IP Archictecture Group, KPNQwest Singel 540, 1017 AZ Amsterdam, NL ----------cut here---------- "Status: LIR-ALLOCATED" Considered Useful James Aldridge ----- -------- This document proposes a new value for the status field of the inetnum object in the RIPE database in addition to those listed in sections 3.4.2 (PA vs PI space) and 4.4 (Allocation Registration) of the "European Internet Registry Policies and Procedures" document ripe-185. For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). -2- An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGYZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGYZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - REGY-MNT in this case. There is also a mnt- lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The final inetnum object here is a final assignment from the national organisation to a customer.

1 0

Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball (fwd)
by Wilfried Woeber, UniVie/ACOnet 15 Jan '01

15 Jan '01

Dear Andreas Jennen! >Subject: Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) > X-NCC-RegID: de.aball (fwd) >please answer my questions idown in my text ! I'll try ;-) >Will i have soon 20 hdl ? Maybe... (unless the community succeeds to get the mess sorted out again. Any help - including yours - would be appreciated ;-) >Is that, what you wanted ? Definitely: NO. For a few more comments, see below, marked "****" Regards, Wilfried (DB-WG chair) PS: and by the way, shouting at innocent people like NCC staff is not necessarily the best approach to get problems resolved in the Internet... ______________________________________________________________________ >----- Forwarded message from RIPE NCC Hostmaster ----- > >Message-Id: <200101121426.PAA15401(a)x60.ripe.net> >To: jennen(a)aball.de >Subject: Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball >In-reply-to: Your message of Fri, 05 Jan 2001 22:46:46 +0100. > <200101052146.WAA20734(a)sonne.aball.de> ><References: <200101052146.WAA20734(a)sonne.aball.de> >From: RIPE NCC Hostmaster <hostmaster(a)ripe.net> >X-Organization: RIPE Network Coordination Centre >X-Phone: +31 20 535 4444 >X-Fax: +31 20 535 4445 >Date: Fri, 12 Jan 2001 15:26:11 +0100 >Sender: hostmaster(a)ripe.net > > >Hi Andreas, > >This change was agreed by the Database Working Group. If you have a >problem with this decision please raise it on the <db-wg(a)ripe.net> >mailing list or at the working group meeting during this month's >meeting. **** This problem was already on the DB-WG Meeting during RIPE37, September 2000. It might again get put onto the DB-WG Meeting agenda **** for RIPE38, January 2000. >Sorry to have upset you - have a good weekend. > > > Regards, > > ------------------- > Geoff Charters > Ripe NCC Hostmaster > ------------------- > >"QUICK TIPS FOR REQUESTS": <http://www.ripe.net/ripencc/tips/tips.html> > > In the previous mail Andreas Jennen <jennen(a)aball.de>, wrote: > * > * from Andreas Jennen > * jennen(a)aball.de > * x-NCC-RegID: de.aball > * > * Dear hostmaster, > * > * what a hell why is this ? See below > * > * Is this correct, what *.at need ? > * > * One handle for every European contry, where i am admin of an domain ? > * > * Before i was in Europe and also USA: > * > * AJ4-RIPE > * > * now i need 20 or 30 handles ? > * > * Why is RIPE so stupid ? **** A few clariciations should be helpful here. There is . RIPE the "community", the users, some working groups run by volunteers, some eMail lists, some meetings - and there is the . RIPE NCC a service organisation with a well-defined mandate, an activity plan, and customers like the LIRs. While RIPE (the community) is discussing Internet issues in general, coming up with recommendations and consensus, this RIPE is not the "Internet Police". Nor is the RPE community authoritative for everything that is happening in CyperSpace. While RIPE (the community) is regularly interacting with the RIPE NCC (receiving support from and providing guidance to the RIPE NCC), the RIPE *NCC* is an autonmous organisation, which by consensus of the community (and not the least supported by the financial backing of it's members and customers!) is *responsible* and *authoritative* for . *IP-Adress distribution*, . ReverseDNS delegation for the relvant parts of the inverse tree, . and a couple of other things which is outlined as community service in the activita plan. The RIPE NCC (and RIPE, btw.) is NOT authoritative for any ccTLD administration issues! Indeed, for coordination issues regarding ccTLDs (mostly in Europe), another organistion was formed and has taken responsibilty (CENTR, see their info pages at http://www.centr.org/). nd CENTR is workling **** within the framework of ICANN/IANA. > * > * Whatfor we pay 2100 Euro every jear ? > * **** I guess for the services as extended by the RIPE NCC according to **** your customer and membership agreement??? > * Please also give the national domain organisation like e.g. > * Denic > * > * the order to take our full Ripe handles as nic-hdl. **** Neither the RIPE NCC, nor any of the RIPE Working Groups would have any authority to do so. The Organisations you are pointing fingers at can accept input and guidance, and usually they do, but they also have to operate according to their existing administrative, legal and financial framework, and responsibility to their constituencies. It would certainly be helpful if you could summarize your concerns **** and forward them to the relvant channels (e.g. CENTR)! > * > * e.g. > * whois -h whois.ripe.net AJ4-RIPE > * > * RIPE says: > * > * % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-servic > * es/db/copyright.html > * > * person: Andreas Jennen > * address: aball Internet Netzdienste GmbH > * address: Roscherstr. 10 > * address: D-30161 Hannover > * address: Germany > * phone: +49 511 270 737-0 > * fax-no: +49 511 69 90 91 > * e-mail: jennen(a)aball.de > * nic-hdl: AJ4-RIPE > * notify: quardian(a)aball.de > * mnt-by: ABALL-NCC-MNT > * changed: knocke(a)nic.de 19941214 > * changed: knocke(a)nic.de 19950103 > * changed: jennen(a)aball.de 19990623 > * changed: jennen(a)aball.de 20000621 > * source: RIPE > * > * whois -h whois.denic.de AJ4-RIPE > * the denic says: > * > * % Copyright (c)2000 by DENIC > * % > * % Restricted rights. > * % > * % > * % Except for agreed Internet operational purposes, no part of this > * % information may be reproduced, stored in a retrieval system, or > * % transmitted, in any form or by any means, electronic, mechanical, > * % recording, or otherwise, without prior permission of the DENIC > * % on behalf of itself and/or the copyright holders. Any use of this > * % material to target advertising or similar activities are explicitly > * % forbidden and will be prosecuted. The DENIC requests to be notified > * % of any such activities or suspicions thereof. > * > * person: Andreas Jennen > * address: aball Internet Netzdienste GmbH > * address: Roscherstr. 10 > * address: 30161 Hannover > * address: DE > * e-mail: jennen(a)aball.de > * nic-hdl: AJ4-RIPE > * changed: lastchange(a)denic.de 20000621 > * source: DENIC > * > * that is not the same, we do not see> notify. mtn-by, history > * > * That is nonsence ! > * > * > * Are you not able to let work an domain whois server for Europe ? **** I am perfectly convinced that the RIPE NCC would be capable of engineering and operating such a service. Although, for the moment at least, the prerequisites (like community consensus, financial support, and obvious solutions to the massive **** scaling issues) are not in place. > * No, then i will say on the next meeting, that the RIPE organisation > * should change to an new and better and cheaper organisation ! **** Well, you might be able to provide RIPE (the community) with guidance on how to become a new and better organisation, but I doubt that it is going to be cheaper - because participation in RIPE (the community) **** is for free :-) **** Assuming that you intend to provide input to the RIPE NCCs activity plan and funding model, then you should use the established channels (talking to the RIPE NCC's management, membership mailing list, NCC **** General Assembly,...) > * If you don not want to answer this request, please give it to your > * General Manager ! > * > * > * Gruss Andreas Jennen. > * -- / \__ Festverbindungen auch 34 MBit/s und 155 MBit/s erhaeltlich > * ( *\___ <- Nando,Andreas Jennen, Roscherstr. 12, 30161 Hannover, DE > * / O EMAIL jennen(a)aball.de Voice: (+49 511)270 737-0, Fax:699091 > * / (_____/ Pos(Grad, Minuten): N 52 18.559';E 009 35.714' Hoehe: 112 m > * /_____/ U http://www.aball.de Privat: http://www.jennen.de > * > * > * ----- Forwarded message from whois-info(a)nic.at ----- > * > * From whois-info(a)nic.at Fri Jan 5 20:51:41 2001 > * From: whois-info(a)nic.at > * Message-ID: <645525DACC86A945B4DA2B199D8481F64412BA(a)nics-01.sbg.nic.at> > * To: jennen(a)aball.de > * Subject: WHOIS-Database .at-Domains > * Date: Fri, 5 Jan 2001 20:48:24 +0100 > * X-Mailer: Internet Mail Service (5.5.2650.21) > * X-MIME-Autoconverted: from quoted-printable to 8bit by sonne.aball.de id UAA > * 20098 > * > * Sehr geehrte Damen und Herren! > * > * Sie erhalten folgende Information von nic.at, da Sie als Kontaktperson > * (tech-c oder zone-c) einer .at-Domain eingetragen sind. > * > * This is an information from nic.at to all contacts (tech-c and zone-c) of > * .at-domains. To view the english version please click here: > * www.nic.at/english/whois_info.html. Please note your nicat-handle below. > * > * Aus administrativen Gruenden kann die Organisation Ripe (www.ripe.net) ihre > * Datenbank nicht mehr zur Speicherung von Domain-Daten ("Whois"-Abfragen) zur > * Verf|gung stellen. > * nic.at wird daher die relevanten Daten aus der Ripe-Datenbank absiedeln und > * lokal verwalten. Die Funktionalitaet und Wartung von Domains ist damit in > * keinster Weise beeintraechtigt. Die Domain-Daten sind weiterhin (auch |ber > * www.ripe.net) oeffentlich abrufbar und sicher verwaltet - es wird lediglich > * bei Abfragen direkt auf die nic.at-Datenbank zugegriffen. > * > * Im Zusammenhang mit dieser Umstellung werden alle bestehenden Ripe-Handles > * bei .at-Domains automatisch durch NICAT-Handles ersetzt. Nach einer > * Uebergangsphase wird nic.at bei Neuregistrierungen und Aenderungen nur noch > * NICAT-Handles akzeptieren. Beruecksichtigen Sie das bitte, falls Sie > * Ripe-Handles in Ihrer internen Software zur Verwaltung von .at-Domains > * verwenden. > * Sollten Sie Ihr Ripe-Handle f|r andere Ripe-Services benutzen, bleibt er > * nat|rlich bestehen und ist bei Ripe weiterhin g|ltig. > * > * ********************************************************** > * Ihr 'alter' Ripe-Handle/your old ripe-handle: AJ4-RIPE > * Ihr neuer NICAT-Handle/your new nicat-handle: AJ552432-NICAT > * ********************************************************** > * > * Folgender Zeitplan ist f|r die Umstellung vorgesehen: > * ab 12.1.2001 kvnnen NICAT-Handles verwendet werden - es sind Ripe-Handles > * UND NICAT-Handles gueltig. Alle domain objects, die davor angelegt oder > * geaendert wurden, werden im alten Format ausgegeben. Alle neuen domain > * objects, erzeugt durch Neuantrag oder Aenderung werden im neuen Format > * ausgegeben. Eine Aenderung bewirkt, dass das Object in der Ripe Datenbank > * geloescht wird und das in Object in der nic.at-Datenbank zum Tragen kommt. > * ab 29.1. gelten bei nic.at nur mehr NICAT-Handles, die .at-Domain Objects > * werden in der Ripe-Datenbank geloescht. Bitte verwenden Sie ab 29.1. keine > * RIPE-Handles mehr! Bis zum Ende der Loeschaktion kann es zwei Ausgabeformate > * (alt oder neu) geben. > * > * Eine detaillierte Beschreibung der Aenderungen in den Domain und Person > * Objects finden Sie auf unserer Homepage unter > * (www.nic.at/german/whois_info.html), FAQ's zum Thema Whois unter > * www.nic.at/german/whois_FAQ.html. > * > * Bei weiteren Fragen kontaktieren Sie bitte das nic.at Team unter 0800 800 > * 888 844 bzw. per E-Mail unter whois-info(a)nic.at > * Wir helfen Ihnen gerne weiter. > * > * Ihr nic.at Team > * > * nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H. > * Jakob-Haringer-Stra_e 8 > * A-5020 Salzburg > * > * Infos zu Domainregistrierung www.nic.at > * > * E-Mail: whois-info(a)nic.at > * Tel.: +43 (662) 4669-844 > * Fax: +43 (662) 4669-29 > * In Oesterreich gebuehrenfrei: > * Tel.: 0800 800 888-844 > * Fax: 0800 800 888-29 > * > * ----- End of forwarded message from whois-info(a)nic.at ----- > * > * ----- End of forwarded message from Andreas Jennen ----- > >----- End of forwarded message from RIPE NCC Hostmaster -----

1 0

draft agenda (v1), for DB-WG meeting, RIPE 38, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 15 Jan '01

15 Jan '01

Dear WG list members, fellow chair persons, "meeting"! Attached please find the 1st draft, proposed agenda for the DB-WG Meeting. We are still working on arranging for a joint Routing <=> DB-WG session to cover Routing Registry (RPSL) aspects and migration to DB-SW V3. Please stay tuned for last minute updates! As usual, comments, suggestions and additions are welcome. Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-38, January 2001, Amsterdam, NL 1. Draft Wednesday, January 24, 2001 16:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part 1: Joint Session with Routing-WG Thursday, January 25, 2001 09:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part 2: DB-WG Meeting P2-A. Administrative stuff (WW, chair) . volunteering a scribe . list of participants . agenda bashing . minutes distributed P2-B. Actions Items . P2-C. RIPE DB, operations update (RIPE NCC, Ambrose Magee) 20min P2-D. Migration to the new Database (RIPE NCC, Andrei Robachevsky) 20min P2-E. CERT Object, IRT pointer (Wilfried Woeber) . proposal . feed-back from TF-CSIRT Barcelona P2-F. Report from Re-Implementation/Migration TF (tentative, Ulf Kieber) 15 min PI.Y. Input from other WGs . PI.Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 15-JAN-2001 11:02:45 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Minutes of the DB Working group, RIPE 37
by Nigel Titley 15 Jan '01

15 Jan '01

Dear All, Please find attached the first draft of the minutes of the DB Working group for RIPE 37. Please let me know if I have made any errors. I'll issue the final version in a couple of days time. Nigel

1 0

Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball (fwd)
by Andreas Jennen 14 Jan '01

14 Jan '01

Hi, please answer my questions idown in my text ! Yhanks. Will i have soon 20 hdl ? Is that, what you wanted ? Gruss Andreas Jennen. -- / \__ Festverbindungen auch 34 MBit/s und 155 MBit/s erhaeltlich ( *\___ <- Nando,Andreas Jennen, Roscherstr. 12, 30161 Hannover, DE / O EMAIL jennen(a)aball.de Voice: (+49 511)270 737-0, Fax:699091 / (_____/ Pos(Grad, Minuten): N 52 18.559';E 009 35.714' Hoehe: 112 m /_____/ U http://www.aball.de Privat: http://www.jennen.de ----- Forwarded message from RIPE NCC Hostmaster ----- Message-Id: <200101121426.PAA15401(a)x60.ripe.net> To: jennen(a)aball.de Subject: Re: NCC#2001014534 WHOIS-Database .at-Domains (fwd) de.aball (fwd) X-NCC-RegID: de.aball In-reply-to: Your message of Fri, 05 Jan 2001 22:46:46 +0100. <200101052146.WAA20734(a)sonne.aball.de> References: <200101052146.WAA20734(a)sonne.aball.de> From: RIPE NCC Hostmaster <hostmaster(a)ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 12 Jan 2001 15:26:11 +0100 Sender: hostmaster(a)ripe.net Hi Andreas, This change was agreed by the Database Working Group. If you have a problem with this decision please raise it on the <db-wg(a)ripe.net> mailing list or at the working group meeting during this month's meeting. Sorry to have upset you - have a good weekend. Regards, ------------------- Geoff Charters Ripe NCC Hostmaster ------------------- "QUICK TIPS FOR REQUESTS": <http://www.ripe.net/ripencc/tips/tips.html> In the previous mail Andreas Jennen <jennen(a)aball.de>, wrote: * * from Andreas Jennen * jennen(a)aball.de * x-NCC-RegID: de.aball * * Dear hostmaster, * * what a hell why is this ? See below * * Is this correct, what *.at need ? * * One handle for every European contry, where i am admin of an domain ? * * Before i was in Europe and also USA: * * AJ4-RIPE * * now i need 20 or 30 handles ? * * Why is RIPE so stupid ? * * Whatfor we pay 2100 Euro every jear ? * * * Please also give the national domain organisation like e.g. * Denic * * the order to take our full Ripe handles as nic-hdl. * * e.g. * whois -h whois.ripe.net AJ4-RIPE * * RIPE says: * * % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-servic * es/db/copyright.html * * person: Andreas Jennen * address: aball Internet Netzdienste GmbH * address: Roscherstr. 10 * address: D-30161 Hannover * address: Germany * phone: +49 511 270 737-0 * fax-no: +49 511 69 90 91 * e-mail: jennen(a)aball.de * nic-hdl: AJ4-RIPE * notify: quardian(a)aball.de * mnt-by: ABALL-NCC-MNT * changed: knocke(a)nic.de 19941214 * changed: knocke(a)nic.de 19950103 * changed: jennen(a)aball.de 19990623 * changed: jennen(a)aball.de 20000621 * source: RIPE * * whois -h whois.denic.de AJ4-RIPE * the denic says: * * % Copyright (c)2000 by DENIC * % * % Restricted rights. * % * % * % Except for agreed Internet operational purposes, no part of this * % information may be reproduced, stored in a retrieval system, or * % transmitted, in any form or by any means, electronic, mechanical, * % recording, or otherwise, without prior permission of the DENIC * % on behalf of itself and/or the copyright holders. Any use of this * % material to target advertising or similar activities are explicitly * % forbidden and will be prosecuted. The DENIC requests to be notified * % of any such activities or suspicions thereof. * * person: Andreas Jennen * address: aball Internet Netzdienste GmbH * address: Roscherstr. 10 * address: 30161 Hannover * address: DE * e-mail: jennen(a)aball.de * nic-hdl: AJ4-RIPE * changed: lastchange(a)denic.de 20000621 * source: DENIC * * that is not the same, we do not see> notify. mtn-by, history * * That is nonsence ! * * * Are you not able to let work an domain whois server for Europe ? * * No, then i will say on the next meeting, that the RIPE organisation * should change to an new and better and cheaper organisation ! * * If you don not want to answer this request, please give it to your * General Manager ! * * * Gruss Andreas Jennen. * -- / \__ Festverbindungen auch 34 MBit/s und 155 MBit/s erhaeltlich * ( *\___ <- Nando,Andreas Jennen, Roscherstr. 12, 30161 Hannover, DE * / O EMAIL jennen(a)aball.de Voice: (+49 511)270 737-0, Fax:699091 * / (_____/ Pos(Grad, Minuten): N 52 18.559';E 009 35.714' Hoehe: 112 m * /_____/ U http://www.aball.de Privat: http://www.jennen.de * * * ----- Forwarded message from whois-info(a)nic.at ----- * * From whois-info(a)nic.at Fri Jan 5 20:51:41 2001 * From: whois-info(a)nic.at * Message-ID: <645525DACC86A945B4DA2B199D8481F64412BA(a)nics-01.sbg.nic.at> * To: jennen(a)aball.de * Subject: WHOIS-Database .at-Domains * Date: Fri, 5 Jan 2001 20:48:24 +0100 * X-Mailer: Internet Mail Service (5.5.2650.21) * X-MIME-Autoconverted: from quoted-printable to 8bit by sonne.aball.de id UAA * 20098 * * Sehr geehrte Damen und Herren! * * Sie erhalten folgende Information von nic.at, da Sie als Kontaktperson * (tech-c oder zone-c) einer .at-Domain eingetragen sind. * * This is an information from nic.at to all contacts (tech-c and zone-c) of * .at-domains. To view the english version please click here: * www.nic.at/english/whois_info.html. Please note your nicat-handle below. * * Aus administrativen Gruenden kann die Organisation Ripe (www.ripe.net) ihre * Datenbank nicht mehr zur Speicherung von Domain-Daten ("Whois"-Abfragen) zur * Verf|gung stellen. * nic.at wird daher die relevanten Daten aus der Ripe-Datenbank absiedeln und * lokal verwalten. Die Funktionalitaet und Wartung von Domains ist damit in * keinster Weise beeintraechtigt. Die Domain-Daten sind weiterhin (auch |ber * www.ripe.net) oeffentlich abrufbar und sicher verwaltet - es wird lediglich * bei Abfragen direkt auf die nic.at-Datenbank zugegriffen. * * Im Zusammenhang mit dieser Umstellung werden alle bestehenden Ripe-Handles * bei .at-Domains automatisch durch NICAT-Handles ersetzt. Nach einer * Uebergangsphase wird nic.at bei Neuregistrierungen und Aenderungen nur noch * NICAT-Handles akzeptieren. Beruecksichtigen Sie das bitte, falls Sie * Ripe-Handles in Ihrer internen Software zur Verwaltung von .at-Domains * verwenden. * Sollten Sie Ihr Ripe-Handle f|r andere Ripe-Services benutzen, bleibt er * nat|rlich bestehen und ist bei Ripe weiterhin g|ltig. * * ********************************************************** * Ihr 'alter' Ripe-Handle/your old ripe-handle: AJ4-RIPE * Ihr neuer NICAT-Handle/your new nicat-handle: AJ552432-NICAT * ********************************************************** * * Folgender Zeitplan ist f|r die Umstellung vorgesehen: * ab 12.1.2001 kvnnen NICAT-Handles verwendet werden - es sind Ripe-Handles * UND NICAT-Handles gueltig. Alle domain objects, die davor angelegt oder * geaendert wurden, werden im alten Format ausgegeben. Alle neuen domain * objects, erzeugt durch Neuantrag oder Aenderung werden im neuen Format * ausgegeben. Eine Aenderung bewirkt, dass das Object in der Ripe Datenbank * geloescht wird und das in Object in der nic.at-Datenbank zum Tragen kommt. * ab 29.1. gelten bei nic.at nur mehr NICAT-Handles, die .at-Domain Objects * werden in der Ripe-Datenbank geloescht. Bitte verwenden Sie ab 29.1. keine * RIPE-Handles mehr! Bis zum Ende der Loeschaktion kann es zwei Ausgabeformate * (alt oder neu) geben. * * Eine detaillierte Beschreibung der Aenderungen in den Domain und Person * Objects finden Sie auf unserer Homepage unter * (www.nic.at/german/whois_info.html), FAQ's zum Thema Whois unter * www.nic.at/german/whois_FAQ.html. * * Bei weiteren Fragen kontaktieren Sie bitte das nic.at Team unter 0800 800 * 888 844 bzw. per E-Mail unter whois-info(a)nic.at * Wir helfen Ihnen gerne weiter. * * Ihr nic.at Team * * nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H. * Jakob-Haringer-Stra_e 8 * A-5020 Salzburg * * Infos zu Domainregistrierung www.nic.at * * E-Mail: whois-info(a)nic.at * Tel.: +43 (662) 4669-844 * Fax: +43 (662) 4669-29 * In Oesterreich gebuehrenfrei: * Tel.: 0800 800 888-844 * Fax: 0800 800 888-29 * * ----- End of forwarded message from whois-info(a)nic.at ----- * * ----- End of forwarded message from Andreas Jennen ----- ----- End of forwarded message from RIPE NCC Hostmaster -----

1 0

formular for access to dbm
by glaess＠element5.de 12 Jan '01

12 Jan '01

hi folks, i need the name of the formular what i will send to auto-dbm(a)ripe.net for mirror the dbm . in the documents (ripe-157) under 2.5 are written you must be in the access list ... send us the ip address after the the emailaddr. but what kind of formular ?

2 1

RE: Loop in AS macro
by Lu, Ping 11 Jan '01

11 Jan '01

Hi, I am new to this list and would like to ask a (maybe stupid) question to the dicussion: If we want to write a script to expand the AS MACRO, how can we avoid to go into a loop if multiple AS-MACROs reference each other ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: 703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Cengiz Alaettinoglu [mailto:cengiz@packetdesign.com] > Sent: Wednesday, January 10, 2001 12:14 PM > To: Shane Kerr > Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; > db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net > Subject: RE: Loop in AS macro > > > > Shane Kerr (shane(a)ripe.net) on January 10: > > Gilles, Wilfried, and all, > > > > This is not a bug, or even an inconsistency. Consider the following > > as-macro objects: > > > > as-macro: AS-X > > members: AS-Y, AS123 > > > > as-macro: AS-Y > > members: AS-X, AS456, AS789 > > > > In this case, AS-X and AS-Y both expand to the same aut-num objects: > > AS123, AS456, and AS789. However, they may have different > maintainers, > > contacts, descriptions, and so on. In RPSL, many more > kinds of loops are > > possible as well, in as-set, route-set, and filter-set objects. > > RPSL defines semantics when loops exist. However, it does not promote > them, or prohibit additional restrictions by the registry operators > not to have loops. > > > > > External software that deals with the set objects needs to do loop > > detection in order to prevent infinite loops. For as-set > objects (which > > are as-macro objects in RIPE-181), this is fairly easy: > keep a list or > > hash of the AS sets expanded, and don't expand them again. > For route-set > > and filter-set objects it is not quite so easy. If you > need help with > > these, you can send me and e-mail and I can explain the > techniques that > > I've used for these objects. > > > > Shane Kerr <shane(a)ripe.net> > > Database Software Engineer > > RIPE NCC > > +31 20 535 4427 > > > > p.s. This is actually a feature, not an bug. :) > > > > p.p.s. It has been argued (by me) that RPSL allows objects that are > > logically impossible, but the RFC authors don't seem to think so! > > > > On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote: > > > > > Hi Gilles, > > > > > > I guess we wouldn't be able to check against those > accidents at the time > > > of a DB _update_... > > > > > > But checking the RR internal _data_ consistency could > maybe become part > > > of the RIS (or similar) project? > > > > > > Henk, any comments? > > > > > > An interesting aside: I guess similar problems could occur with > > > RPSL-based RRs? > > > > > > -WW > > > > _________________________________:____________________________ > _________ > > > Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at > > > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > > > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > > > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP > keyID 0xF0ACB369 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~ > > > > > > To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, > admin-c(a)tli.de > > > CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net > > > Subject: Loop in AS macro > > > Date: Wed, 10 Jan 2001 10:28:15 +0100 > > > From: Gilles Farrache <farrache(a)cc.in2p3.fr> > > > > > > Dear database managers, > > > > > > I notice a loop in the followings AS-MACRO, in fact > AS-TELEDANMARKINTERNATIONAL > > > is calling AS-TLI which is calling AS-TELEDK which is > calling AS-TELEDANMARKINTERNATIONAL. > > > (and all that make that our automatic filter generation > tool fails) > > > > > > Could you correct those macro and will the Ripe database > management provide any > > > control on that kind of loop ? > > > > > > Gilles > > > > > > as-macro: AS-TELEDANMARKINTERNATIONAL > > > descr: Tele Danmark customers outside Denmark > > > as-list: AS1902 AS12461 > > > as-list: AS8881 AS-KOMTEL > > > as-list: AS13194 AS-BITE > > > as-list: AS6709 > > > as-list: AS8650 AS-TLI > > > as-list: AS8542 > > > as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 > AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 > > > as-list: AS12546 > > > as-list: AS15389 > > > tech-c: AS5071-RIPE > > > admin-c: AS5071-RIPE > > > notify: staff(a)ip.tele.dk > > > notify: peering(a)tli.de > > > mnt-by: AS3292-MNT > > > changed: jesper(a)skriver.dk 20001103 > > > changed: toba(a)tdk.dk 20001117 > > > changed: tee(a)tdk.dk 20001123 > > > changed: jesper(a)skriver.dk 20001228 > > > changed: jesper(a)skriver.dk 20010109 > > > source: RIPE > > > > > > as-macro: AS-TLI > > > descr: Talkline GmbH, Internet Division > > > descr: List of ASes according to Talkline Internet (AS8650) > > > descr: and customers > > > as-list: AS5605 > > > as-list: AS6783 > > > as-list: AS8650 > > > as-list: AS8881 > > > as-list: AS12461 > > > as-list: AS12546 > > > as-list: AS-TELEDK > > > as-list: AS-GLOBAL > > > tech-c: TLIP1-RIPE > > > admin-c: TLIP1-RIPE > > > notify: peering(a)tli.de > > > mnt-by: TALKLINE-MNT > > > changed: thomas(a)tli.de 19990923 > > > changed: thomas(a)tli.de 19991020 > > > changed: thomas(a)tli.de 19991025 > > > changed: thomas(a)tli.de 20001023 > > > changed: thomas(a)tli.de 20001025 > > > source: RIPE > > > > > > as-macro: AS-TELEDK > > > descr: Tele Danmark and Tele Danmark customers > > > as-list: AS-TELEDANMARKDANISH > > > as-list: AS-TELEDANMARKINTERNATIONAL > > > as-list: AS-BELBONEMEMBERS > > > as-list: AS-GLOBAL > > > tech-c: AS5071-RIPE > > > admin-c: AS5071-RIPE > > > notify: staff(a)ip.tele.dk > > > notify: peering(a)tli.de > > > mnt-by: AS3292-MNT > > > changed: jesper(a)skriver.dk 19990922 > > > changed: jesper(a)skriver.dk 19991019 > > > changed: jesper(a)skriver.dk 19991025 > > > changed: jesper(a)skriver.dk 19991210 > > > changed: toba(a)tdk.dk 20000903 > > > source: RIPE > > > > -------------------------------------------------------------- > ------------------ > > > > > > > > > > Cengiz > > -- > Cengiz Alaettinoglu Packet Design Inc. > >

4 3

inetnum update
by Panagiotis Skoulikaritis 11 Jan '01

11 Jan '01

Hi, I am new to this list and would like to ask a (maybe stupid) question to the dicussion: how can I update the inetnum object in the database. The company I work for got a new allocation and they asked me to update the database, I' new to the company and I have no prior experience in managing/updating the database objects. If anyone could help me it would be appreciated. Thanks Panagiotis

1 0

Re: inetnum update
by RIPE NCC Staff 11 Jan '01

11 Jan '01

Dear Panagiotis Skoulikaritis, Information on creating, updating and deleting objects in the RIPE Network Management Database is available from: <http://www.ripe.net/ripe/docs/ripe-157.html> <ftp://ftp.ripe.net/ripe/docs/ripe-157.ps> <ftp://ftp.ripe.net/ripe/docs/ripe-157.txt> with a supplement available at: <http://www.ripe.net/ripe/docs/ripe-189.html> <ftp://ftp.ripe.net/ripe/docs/ripe-189.ps> <ftp://ftp.ripe.net/ripe/docs/ripe-189.txt> Help on using <auto-dbm(a)ripe.net> is available by sending an e-mail to <auto-dbm(a)ripe.net> with HELP in the Subject line. Help on using whois is available by doing whois -h whois.ripe.net HELP If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz -------------------------------- RIPE NCC Database Administration Original Message follows: ------------------------- This is a multi-part message in MIME format. ------=_NextPart_000_016E_01C07BD1.1453C730 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Hi, I am new to this list and would like to ask a (maybe stupid) = question to the dicussion: how can I update the inetnum object in the database. The company I work = for got a new allocation and they asked me to update the database, I' = new to the company and I have no prior experience in managing/updating = the database objects. If anyone could help me it would be appreciated. Thanks=20 Panagiotis ------=_NextPart_000_016E_01C07BD1.1453C730 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-7"> <META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2> <DIV><FONT size=3D2><FONT size=3D3>Hi, I am new to this list and would = like to ask a=20 (maybe stupid) question to the dicussion:<BR></FONT>how can I = update the=20 inetnum object in the database.  The company I work for got a new=20 allocation and they asked me to update the database,  I' new to the = company=20 and I have no prior experience in managing/updating the database = objects. =20 If anyone could help me it would be appreciated.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Thanks </FONT></DIV> <DIV><FONT size=3D2>Panagiotis</FONT></DIV></FONT></DIV></BODY></HTML> ------=_NextPart_000_016E_01C07BD1.1453C730--

1 0

RE: Loop in AS macro
by Wilfried Woeber, UniVie/ACOnet 10 Jan '01

10 Jan '01

Hi Gilles, I guess we wouldn't be able to check against those accidents at the time of a DB _update_... But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project? Henk, any comments? An interesting aside: I guess similar problems could occur with RPSL-based RRs? -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: staff(a)ip.tele.dk, peering(a)tli.de, ip-oper(a)tli.de, admin-c(a)tli.de CC: farrache(a)cc.in2p3.fr, db-wg(a)ripe.net, routing-wg(a)ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache(a)cc.in2p3.fr> Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 20001103 changed: toba(a)tdk.dk 20001117 changed: tee(a)tdk.dk 20001123 changed: jesper(a)skriver.dk 20001228 changed: jesper(a)skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering(a)tli.de mnt-by: TALKLINE-MNT changed: thomas(a)tli.de 19990923 changed: thomas(a)tli.de 19991020 changed: thomas(a)tli.de 19991025 changed: thomas(a)tli.de 20001023 changed: thomas(a)tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 19990922 changed: jesper(a)skriver.dk 19991019 changed: jesper(a)skriver.dk 19991025 changed: jesper(a)skriver.dk 19991210 changed: toba(a)tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------

6 6

RE: Loop in AS macro
by Christian Storch 10 Jan '01

10 Jan '01

Please don't say 'include'. - What about "expand" as Shane used it already? So think about a macro as a set of AS'es and only form the set union of it. Every AS should be a set of size 1 and a macro a set of size n. As a result you would get an infinite iteration but A = B! So if somebody would suggest it to be nonsense, what about Pi etc.? ;-)) I think a script has only to expand a macro and to insert it into a list of already expanded macros. ... Christian -----Original Message----- From: Gilles Farrache [SMTP:farrache@cc.in2p3.fr] Sent: Wednesday, January 10, 2001 12:17 PM To: Shane Kerr Cc: Wilfried Woeber, UniVie/ACOnet; farrache(a)cc.in2p3.fr; db-wg(a)ripe.net; routing-wg(a)ripe.net; Henk.Uijterwaal(a)ripe.net; farrache(a)cc.in2p3.fr; Jesper Skriver Subject: Re: Loop in AS macro Shane and al, When I was at school (a long time ago) I learn what was called the "set theory" ( "Theorie des ensembles" in French) that was part of what was called the NEW Mathematics. In those courses I learned that : If set A is included in set B and if set B was included in set A then A = B. Whet your telling me is that there are New New mathematics (as there is a new economy) in which : if set A is included in set B and set B included in set A that does not implie A = B. I am very interrested by that theory and will be happy that you give me some pointers to it. :-) Or what is an AS-MACRO ? It is a set of AS (or a set of set of AS ....). So they have to follow the set theory. Gilles

2 1

Loop in AS macro
by Gilles Farrache 10 Jan '01

10 Jan '01

Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 20001103 changed: toba(a)tdk.dk 20001117 changed: tee(a)tdk.dk 20001123 changed: jesper(a)skriver.dk 20001228 changed: jesper(a)skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering(a)tli.de mnt-by: TALKLINE-MNT changed: thomas(a)tli.de 19990923 changed: thomas(a)tli.de 19991020 changed: thomas(a)tli.de 19991025 changed: thomas(a)tli.de 20001023 changed: thomas(a)tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff(a)ip.tele.dk notify: peering(a)tli.de mnt-by: AS3292-MNT changed: jesper(a)skriver.dk 19990922 changed: jesper(a)skriver.dk 19991019 changed: jesper(a)skriver.dk 19991025 changed: jesper(a)skriver.dk 19991210 changed: toba(a)tdk.dk 20000903 source: RIPE

3 4

RIPE Whois RPSL Migration
by RIPE NCC 21 Dec '00

21 Dec '00

[ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC

1 0

Announcement: RIPE Whois Database version 3.0 beta is out
by RIPE Database Administration 08 Dec '00

08 Dec '00

Dear All, [ Apologies for duplicate messages ] This mail is to inform you that version 3.0 beta of the RIPE Whois Database is out. Read on! You will be affected too. The RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". The version 2 of the RIPE Database, the one currently in production on whois.ripe.net, will in the next months be replaced by version 3. All the entries in the RIPE Database will be translated into RPSL format, and that is the format you will get when you will be querying the Database. Don't be mistaken: for the moment, whois.ripe.net continues running with version 2 and answering to your queries in the old-fashioned way. But this will not last forever; in a few months, all will become RPSL. So if you use the Whois database, we encourage all of you to prepare for this change as soon as possible. We strongly suggest you to start to get used to RPSL and version 3.0 . In this aim, you can do the following: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to <auto-rip(a)ripe.net> and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. We are currently preparing additional resources to help ease the transition; we will announce them as soon as they are available, which will happen later this month. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at <dbrip(a)ripe.net> ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to <ripe-dbm(a)ripe.net> and ask to join the Task Force. For the ones interested in viewing or trying the code, you can download it at: ftp://ftp.ripe.net/ripe/dbase/reimp/whois-rip-3.0beta1.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, The RIPE Database Group.

1 0

Re: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 01 Dec '00

01 Dec '00

I've tried to sort some of the various aspects/expectations. Lets see.... => It depends on the level of "responsibility" and functionality granted to => and exercised by that end site. As I've said in a private mail already, => we should ask the question about the usefulness of "assigning" (in the => good old sense) very small amounts of addresses to sites which are tied => in to the services of their provider anyway. I guess most of the ADSL, => dial-up, cable-TV connection assignments sh/could be reviewed from that => point of view. = =The name and address info in the RIPE database needs to contain the =person (or organisation) responsible for a certain amount of IP space, =in my opinion. = =So, if an ISP wants to be responsible for the IP space it hands out to =customers, then the ISP should be free to fill in their own name and =address. This gives ISPs the freedom to fill the RIPE db with names =and addresses of customers (that saves them the hassle of dealing with =for example abuse coming from that site), or putting their own name =in it (meaning they have to respond actively to for example abuse reports, =which is the ISP's job anyway). 1) IP-Addresses are taken from a globally unique pool. Thus the global Internet community expects to have access to publicly accessible registry data to query the status (unassigned/reserved - allocated - assigned) for a particular address or address block or other unique resource. 2) The contact information listed for the individual resource serves 2 purposes: a) it offers info to get in contact with a human being to resolve connectivity problems (IP or application layer) between end sites b) it offers info to get in touch with a human being in case of operational problems that have an unwanted impact on the performance or security of networks other than the source of the problem (routing issues, spam, abuse). Ref: 1: While I still think that the open availability of that info is essential for the responsible and continued operation of the Internet, it can be argued whether contact info to get in touch with a human being has to be publicly available. In the long run, we probably have to deal with the authorities in one way or another (on a national and international level), to get the existence and maintainance of such a global registry recognized and endorsed. Ref: 2)a): While "we" certainly have become comfortable with the notion of being able to "talk" to everyone who is on the net (to resolve operational problems for our own applications or customers), we might have to let go here - and also to openly tell *our* customers, that we cannot help in case of problems when the "other end" opts to remain anonymous (by requesting contact info to be suppressed or, better yet, not to be collected at all). Ref: 2)b): I think it is - as much a resonable expectation held by all people and sites and backbones on the net that their network(s) can be protected against misuse (proactively), or that any incidents can be resolved quickly and easily, - as it might be reasonable to request anonymity on the net for end sites. I guess we have similar situations in real life, where there is a conflict of expectations and interests between the individual and the community, like . license plates on vehicles to follow up on violation of rules, . a public registry for real estate ownership to settle ownership claims . or to track down the owners in case the patch of land becomes a source of danger or nuisance for neighbours, . registries for companies, their legal representatives and financial backing (which many would certainly prefer not to disclose :-) . registries for the address of citizens in case they do not live up to contractual obligations So, would we be better off by following up on our "IRT-pointer" proposal and then offer the alternative to supply - *either* the end users's contact information - *or* the contact information for an IRT that has accepted responsibility for the operational use of that resource? In most cases, and for small end-user sites, this would be ISP staff, anyway. Having a certain resource listed in the registry without any contact information (neither individual contact nor IRT/ISP contact) should be seen as a _strong_ hint to exercise strong care in dealing with that site - by applying whatever means available to minimize the impact of misconfiguration and/or attacks originating from those sites. This could indeed limit the usefulness of those resources on a global scale, much like you are allowed to obtain and drive a vehicle without registration and thus without a license plate on private property - but this vehicle gets filtered or blocked on any public road :-) Comments? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 30 Nov '00

30 Nov '00

=> I'm writing for your opinions, suggestions, and comments regarding updating => the RIPE database with assignments made for broadband (xDSL) customers. As => you may or may not be aware, ADSL is now being offered in the UK, which => has very strict data protection laws. We offer ADSL services as a NATted = =IP addresses and data related to them is international resource. =I don't think you should apply any law in UK when we talk about =RIPE(.int) resources. But that doesn't mean the people *collecting* customer related info *and transferring that data to somewhere abroad* would be exempt from local laws. Quite the opposite holds true for many (most?) countries... =I assume we are still supposed to maintain single nic-hdl per person. =What's the plan now, if my LIR would need to refer to the same contact =person? It doesn't make sense to direct any calls to your LIR, if the =problem lies at customer network at our LIR's addresses. It depends on the level of "responsibility" and functionality granted to and exercised by that end site. As I've said in a private mail already, we should ask the question about the usefulness of "assigning" (in the good old sense) very small amounts of addresses to sites which are tied in to the services of their provider anyway. I guess most of the ADSL, dial-up, cable-TV connection assignments sh/could be reviewed from that point of view. => phone: +44-845-272-0444 => remarks: Phone is Demon Internet Helpdesk = =The same rule should apply to all assignments. If a (home) network =contact person doesn't want to be 'listed', s/he can try to live =without real network and buy NAT from a provider. That's a very valid point. =If people think RIPE db contains too much sensitive information, =I would rather see the query results restricted somehow. For example =operators (LIRs) could have full query access, and the others =could merely receive pointers to the LIR for further information. This idea happens to pop always now and then, again and again. the last time I heard a proposal along those lines was at the Brisbane APNIC meeting. I then asked the following question: "So you are going to collect information, but you are going to hide it. Fair enough. Have you thought about criteria and/or mechanisms to disclose that information, either to entites with a "valid" interest and/or to law enforcement?" I did not receive a useful answer. Just as a virtual poll - would anyone in the RIPE region care to propose criteria and/or mechanism? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problems with windows? re-boot! Problems with unix? be root!

4 3

Re: Privacy, Broadband, & the Database
by Wilfried Woeber, UniVie/ACOnet 30 Nov '00

30 Nov '00

>The name and address info in the RIPE database needs to contain the >person (or organisation) responsible for a certain amount of IP space, >in my opinion. I agreee, and the important word here is "responsible". >So, if an ISP wants to be responsible for the IP space it hands out to >customers, then the ISP should be free to fill in their own name and >address. Doing that means that an assignment (*to the customer*, in the traditional sense) has not been performed. >This gives ISPs the freedom to fill the RIPE db with names >and addresses of customers (that saves them the hassle of dealing with >for example abuse coming from that site), or putting their own name >in it (meaning they have to respond actively to for example abuse reports, >which is the ISP's job anyway). This is very similar to my reasoning regarding the usefulness of performing an assignment for a (small) site which does not fully (independently and in a responsible way) manage their address space. Wilfried.

1 0

Privacy, Broadband, & the Database
by Sam Bradford 29 Nov '00

29 Nov '00

Hello all. (Apologies if you got a 'subscribe' message from me earlier. I wasn't thinking about Majordomo for some reason.) I'm writing for your opinions, suggestions, and comments regarding updating the RIPE database with assignments made for broadband (xDSL) customers. As you may or may not be aware, ADSL is now being offered in the UK, which has very strict data protection laws. We offer ADSL services as a NATted service (with one large entry in the RIPE database like for dial-up customers) and a non-NAT service that includes an IP assignment. Our concern is that a large percentage of our non-NAT ADSL customers are either home users or home businesses. Updating the RIPE database with an IP assignment requires an end-user Admin contact, and the person object requires a telephone number. Worst case scenario is that we update the database for a home business or a home user with the customer's telephone number, his teenage daughter enters a chat room, and you can imagine the rest... After brief consultation with the RIPE NCC Hostmasters, we have begun updating the database with our role object as Tech Contact and the customer as Admin contact. For the phone number, we are using our own, noting as much in a 'remarks' field. For example: inetnum: 62.49.8.64 - 62.49.8.79 netname: PYAR-ADSL descr: DEMON ADSL CUSTOMER country: GB admin-c: PY84-RIPE tech-c: DHG5-RIPE status: ASSIGNED PA notify: hostmaster(a)demon.net mnt-by: AS2529-MNT changed: hostmaster(a)demon.net 20001115 source: RIPE <snip DHG5-RIPE> person: Phil Yarranton address: GB phone: +44-845-272-0444 nic-hdl: PY84-RIPE remarks: Phone is Demon Internet Helpdesk notify: hostmaster(a)demon.net mnt-by: AS2529-MNT changed: hostmaster(a)demon.net 20001115 source: RIPE However, I'm not sure that is the best option, and could lead to inconsistency. At what point do we determine (and should we determine?) if an obvoius business customer is home-based or office-based? Should we have one set of rules for the database for leased line & ISDN customers and another for ADSL? Or one set for business customers (regardless of home-based or office-based) and another for home users? Looking forward to your comments. :-) Sam Bradford ----------------------------------------------------------------- sam bradford, senior hostmaster sam.bradford(a)demon.net Demon Internet / Thus plc . hostmaster(a)demon.net Tel: +44-845-272-0666 . . http://www.demon.net/ Fax: +44-20-8371-1285 t h u s http://www.thus.net/

3 3

About the Hermes Project
by Andrea Carmignani 06 Nov '00

06 Nov '00

Hi my name is Andrea Carmignani, I belong to the network research group of the university of Roma3. We developed a tool, known as Hermes, able to explore the Internet topology. Its based mainly on the information coming from the databases belonging to some Internet Resource Record like RIPE, RADB, VERIO, CABLE & WIRE, ARIN and BELL in addiction to the BGP routing information coming from the Route Projects of the Oregon University. Hermes is able to dynamically explore the Internet Topology, providing a Map representing the As and their interconnections. For any AS present on the map, it can also provide several information like: AS name, Maintainers, Routing Policies, list of the known border Router, list of the routes originated by the AS and the As macro which the AS belongs. We will be grateful if you could give us some feedback on the real utility of this tool and hopefully some suggestion able to improving it. Please visit the URL: http://www.dia.uniroma3.it/~hermes here you will find a more detailed paper, some screenshot galleries, a screencam of the tool working and you will able to use Hermes through the Applet provided. I think this is the right mailing list where to post this news if not I apologize otherwise Thanks in Advance Andrea

2 1

reimp.ripe.net (rpsl.ripe.net) server is temporarily unavailable
by Andrei Robachevsky 27 Oct '00

27 Oct '00

Dear Colleagues, Yesterday a machine that was used for the new prototype DB server crashed and could not be restarted due to hardware problems. We are working on this and will bring the prototype server up as soon as possible. Sorry for any inconvenience. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Re: mark
by Randy Bush 29 Sep '00

29 Sep '00

> -----BEGIN PGP SIGNED MESSAGE----- > > person: Mark Bold > address: Verio/UK sigh. apologies. i think i made this same address book stoopid once before. sorreeeee. randy

1 0