- db-wg - mailman.ripe.net

abuse stuff implemented in the DB, and thanks
by Wilfried Woeber, UniVie/ACOnet 11 May '05

11 May '05

Dear WG Members, earlier today we had a very interesting presentation by Shane, summarizing the various changes in the DB machinery related to implementing the abuse-mailbox facilities. I'd like to take this opportunity to remind you about the availability of the presentation slides from the RIPE50 meeting pages on the web, AND to say "thank you" to everyone at the NCC involved in the implemenation. Looks like a job well done, and in time for review during this meeting! Wilfried.

2 1

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Olaf M. Kolkman wrote: >> Note the hierarchical naming convention for poetic-form objects, all >> verse > > I have a few maintenance questions. > > Although my colleagues are technically competent, they have > not been hired for their literary skills(*). So although the RIPE DB > staff will technically maintain the poetic-form: we still need a > mechanism to ensure the quality of the "poetic-form" objects. Agreed and it was always noted that this was a highly skilled job. > Will RIPE NCC staff need to contact a secret cabal for quality > control? Alternatively, will we skip quality control and act on first > come first served (serious security considerations: culprits might > specify a Haiku in the form of a Dada poem)? Or should a poetic-form > first be discussed by the db-wg? I would suggest that quality control should be managed by a secret cabal as at present with the limerick object. Secret cabals have a long and illustrous history on the internet and have usually resulted in fast, effective decision making albeit at the slight expense of annoying and upsetting large numbers of people (since my email is always bounced by Randy's "no legal disclaimer" filters, I feel perfectly safe in making this remark). > > I'd settle for the first option, a secret cabal... I may just know an > institution that could perform this task. I'm sure that they will prove themselves adequate to the task, even though I have no idea who they might be, or even if they exist. > > The classification scheme may also need some work. How do we classify > the different forms? Would the Aphorism have its own class or is it a > subclass of PROSE? > > In absence of the review process. Hereby a new proposal > > poetic-form: PROSE-APHORISM > descr: A database entry to be remembered by > admin-c: OK65-RIPE > tech-c: OK65-RIPE > mnt-by: RIPE-DBM-MNT As far as the name is concerned this would be perfectly correct, although ending a sentence with a preposition is perhaps to be regarded as slightly suspect style. (One must, though, remember Winston Churchill's comments on the matter). poetic-form: PROSE-APHORISM descr: A database entry by which to be remembered admin-c: OK65-RIPE tech-c: OK65-RIPE mnt-by: RIPE-DBM-MNT Might be slightly better stylistically. > > and > > poetic-form: VERSE-HAIKU > descr: The haiku object > descr: only seven syllables > descr: in its density > admin-c: OK65-RIPE > tech-c: OK65-RIPE > mnt-by: RIPE-DBM-MNT This is correct in all respects. > -- Olaf > > (*) I am sure I lost credit with my colleagues with this remark but > these are matters of high public interest. Of course. Perhaps we should include an examination of literary skill when engaging RIPE NCC staff. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

3 2

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Niall O'Reilly wrote: > On 11 May 2005, at 11:43, Titley, Nigel wrote: > >> ending a sentence with a preposition is perhaps to be regarded as >> slightly suspect style. > > Not really. > > From the Oxford Dictionary of English, 2nd edition (ISBN > 0-19-8613474): > >> The superstition that a preposition should always precede the word >> it governs and should not end a sentence [...] is not based on a >> real appreciation of the structure of English [...]. I did say "perhaps". -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Arife Vural wrote: >> No, not quite that. The requirements (which came at the end of the >> thread) suggested that the description of a limerick (for example) >> should be in the form of a limerick. The description of a haiku >> should be in the form of a haiku etc. An example for limerick was >> >> poetic-form: VERSE-LIMERICK >> descr: The object consists of a verse >> descr: in a format approaching the terse >> descr: The rhymes, very strict >> descr: Must be carefully picked >> descr: and it's funny and often perverse >> admin-c: LIM1-RIPE >> tech-c: LIM1-RIPE >> mnt-by: RIPE-DBM-MNT >> changed: ripe-dbm(a)ripe.net 20040401 >> source: RIPE > > Those desc lines are much nicer than mine :-) > > By any chance you have pointer for the presentation. Yes indeed http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-db-poem.pdf -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Abuse information: quick snapshot
by Shane Kerr 11 May '05

11 May '05

All, Just a quick update with counts of objects containing "abuse-mailbox:" PERSON objects: 108 of 1138186 0.0095% ROLE objects: 860 of 8662 9.9284% ORGANISATION objects: 19 of 19065 0.0997% IRT objects: 6 of 65 9.2308% MNTNER objects: 34 of 16354 0.2079% The ROLE objects are mostly because of the "trouble:" attribute conversion. The heavy use in the IRT objects is probably because people with IRT objects are especially clueful about the RIPE Database changes, and also concerned about making sure people get to the correct abuse contact. I expect to see ORGANISATION objects increase, especially after we fix the allocation editor on the LIR portal to allow allocations to have "abuse-mailbox:" entries (we expect to have this done today). -- Shane

1 0

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 10 May '05

10 May '05

wrote: > Dear Colleagues, > > [Apologies for duplicates] > > Following discussions in the Database Working Group, we have made > changes to the whois server software. > > These are the proposed changes: > > - Add a new object POETIC-FORM that will contain the supported poem > types. > - Add a new object POEM that will hold the poem itself. > - Add a new attribute "form:" that shows the type of poem. > > There is more information about this below. > > You can find more details about the discussion at: > > http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html > > We expect to put a new whois server on line with new object support > on 2 May 2005 at 16:00 CET. > > - Add a new POETIC-FORM object: > > The POETIC-FORM object contains information about the poem type. > > This is an example of a LIMERICK object: > > poetic-form: FORM-LIMERICK > descr: Poem type for Limerick > admin-c: AMR68-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20050429 > source: RIPE Slight problem with this example. I beleive we agreed that the description of the poetic form should be in the form of the poetic form itself. I gave a number of examples: limerick, haiku, prose, and english sonnet in my original presentation. This example does not comply with the requirement. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

2 1

RIPE50 DB-WG Draft Agenda V1
by Wilfried Woeber 04 May '05

04 May '05

Dear DB-WG folks, Chairs, Meeting! Here is the 1st draft of an agenda for the DB-WG later this week. Comments and additional topic proposals requested. Wilfried. ________________________________________________________________________ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) B. DB Update (Shane K., RIPE NCC) [~15 min] C. Changes in the DB for "abuse" stuff (Shane K., RIPE NCC) [~15 min] Y. Input from other WGs - "whois2005" from Address Policy? Z. AOB

1 0

Implementation of POEM object
by Arife Vural 04 May '05

04 May '05

Dear Colleagues, [Apologies for duplicates] Following discussions in the Database Working Group, we have made changes to the whois server software. These are the proposed changes: - Add a new object POETIC-FORM that will contain the supported poem types. - Add a new object POEM that will hold the poem itself. - Add a new attribute "form:" that shows the type of poem. There is more information about this below. You can find more details about the discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html We expect to put a new whois server on line with new object support on 2 May 2005 at 16:00 CET. - Add a new POETIC-FORM object: The POETIC-FORM object contains information about the poem type. This is an example of a LIMERICK object: poetic-form: FORM-LIMERICK descr: Poem type for Limerick admin-c: AMR68-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20050429 source: RIPE These objects will be maintained by RIPE DBM. You can send new POETIC-FORM objects to <auto-dbm(a)ripe.net>. - Add a new POEM object: A POEM object is similar to the LIMERICK object. Unlike the LIMERICK object, it will have a "form:" attribute that contains information about the poem type. This is an example of a simple POEM object: poem: POEM-NT13-1 descr: RIPE24 dinner text: At a RIPE Meeting, held in Berlin, text: The meal was unusual, the din text: Of the two serenades text: Whose repertoire made us text: All smile and want to join in form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Add a new "form:' attribute: The "form:" attribute indicates the type of poem. - Changes to the default whois query interface: There will be no changes to the whois query interface. - Data transition All existing LIMERICK objects will will be converted to POEM objects. LIMERICK objects will appear in the database for a while, but we will eventually delete them. Here is an example of a LIMERICK object: limerick: LIM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Here is how it will appear with new object types: poem: POEM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE - Object templates Here is the template for the POEM object: poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] form: [mandatory] [single] [inverse key] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] POETIC-FORM object template is: poetic-form: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Regards, Arife Vural RIPE NCC, SED

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 25 Apr '05

25 Apr '05

* * * Announcement * * * Routing Registry Training Courses Date: Friday 1 July 2005 Time: 0900 - 1700 Location: Vladivostok, Russian Federation AND: Date: Friday 29 July 2005 Time: 0900 - 1700 Location: London, United Kingdom AND: Date: Friday 12 August 2005 Time: 0900 - 1700 Location: Sofia, Bulgaria AND: Date: Friday 2 September 2005 Time: 0900 - 1700 Location: Vilnius, Lithuania The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. Please note that the Routing Registry Training Course is conducted in the English language and is free of charge to attend. The cost of the Course is covered by the members contribution every LIR pays when setting up. You can register two participants from your LIR per Course. If you would like to register more than two people, then please contact us and we will see if extra places are available. More information about the contents of the Course can be found at: http://www.ripe.net/training/ If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. REGISTRATION: ============ To register for this Course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Training Services RIPE NCC

1 0

all objects for my maintainer
by Randy Bush 21 Apr '05

21 Apr '05

i thought whois -h whois.ripe.net -r -i mnt-by MAINT-RGNET used to get me all the objects i maintain. but it seems not to. what am i doing wrongly this time? randy

2 2

Operating the RIPE Whois Database Server Workshop
by training＠ripe.net 17 Mar '05

17 Mar '05

Dear Colleagues, The RIPE NCC is inviting you to a workshop entitled "Operating the RIPE Whois Database Server" before the RIPE 50 meeting in Stockholm. The workshop is scheduled for Sunday, 1 May 2005. We have a limited number of places available. If you are interested in attending, please use the form below to register (send it to training(a)ripe.net). We will do the pre-selection based on your input, and we'll let you know if you have a place at the workshop by Monday, 4 April 2005. If you are unable to attend this workshop, but would like to attend on a different date, please let us know. Kind regards, Training Services RIPE NCC ---[begin workshop details]--- http://www.ripe.net/ripe/meetings/ripe-50/db-op-workshop.html The "Operating the RIPE whois Database Server" workshop is a full-day hands-on event. It will include presentations, practical exercises, examples, and finish with a 'Question and Answer' session. Participants will install the RIPE Database software, configure it in several modes, access each other's servers, and review several troubleshooting scenarios. Objectives This workshop will cover the following aspects of the RIPE Whois Database server software: - possible uses; - different modes of operations - query, update, NRTM; - practical installation and set-up; and - practical maintenance and troubleshooting. This workshop will NOT cover: - introduction to the RIPE Database usage (querying, updating objects, using various protection mechanisms); - details of the RPSL; - details of the MySQL; nor - how to receive IP resources from the RIPE NCC. Target audience This workshop is open to all, and is not limited to RIPE NCC members. There are 20 places available. There is no attendance fee. Lunch and refreshments are included. This workshop is aimed at engineers, system administrators and network operators who are either already running a whois database server, or are planning to do so in the future (for example: "mirror" operators; those who run their own routing registry; other RIR staff; operators of ccTLD databases, etc). Required knowledge: - experience in operating server software (preferably database server, or web, mail, etc); - basic MySQL knowledge; and - software development work experience. Participants should bring a laptop, preferably running Linux (RedHat8, Mandrake, Fedora or other flavor), FreeBSD or Solaris, with administrator privileges, and basic networking configured. Workshop authors / leaders: Can Bican, Software Engineer Shane Kerr, Software Manager Vesna Manojlovic, Advanced Courses Trainer ---[end workshop details]--- Registration form ================= ---[begin form]--- 0. I wish to attend the 'Operating the RIPE whois Database Server' Workshop at RIPE 50 [] 1. Name: 2. Organisation/Affiliation: 3. E-mail address: 4. What are you expecting from this workshop: 5. Extra topics that you would like to see covered: 6. Your experience regarding (database) server operation: ---[end form]---

1 0

Operating the RIPE Whois Database Server Workshop
by training＠ripe.net 17 Mar '05

17 Mar '05

Dear Colleagues, The RIPE NCC is inviting you to a workshop entitled "Operating the RIPE Whois Database Server" before the RIPE 50 meeting in Stockholm. The workshop is scheduled for Sunday, 1 May 2005. We have a limited number of places available. If you are interested in attending, please use the form below to register (send it to training(a)ripe.net). We will do the pre-selection based on your input, and we'll let you know if you have a place at the workshop by Monday, 4 April 2005. If you are unable to attend this workshop, but would like to attend on a different date, please let us know. Kind regards, Training Services RIPE NCC ---[begin workshop details]--- http://www.ripe.net/ripe/meetings/ripe-50/db-op-workshop.html The "Operating the RIPE whois Database Server" workshop is a full-day hands-on event. It will include presentations, practical exercises, examples, and finish with a 'Question and Answer' session. Participants will install the RIPE Database software, configure it in several modes, access each other's servers, and review several troubleshooting scenarios. Objectives This workshop will cover the following aspects of the RIPE Whois Database server software: - possible uses; - different modes of operations - query, update, NRTM; - practical installation and set-up; and - practical maintenance and troubleshooting. This workshop will NOT cover: - introduction to the RIPE Database usage (querying, updating objects, using various protection mechanisms); - details of the RPSL; - details of the MySQL; nor - how to receive IP resources from the RIPE NCC. Target audience This workshop is open to all, and is not limited to RIPE NCC members. There are 20 places available. There is no attendance fee. Lunch and refreshments are included. This workshop is aimed at engineers, system administrators and network operators who are either already running a whois database server, or are planning to do so in the future (for example: "mirror" operators; those who run their own routing registry; other RIR staff; operators of ccTLD databases, etc). Required knowledge: - experience in operating server software (preferably database server, or web, mail, etc); - basic MySQL knowledge; and - software development work experience. Participants should bring a laptop, preferably running Linux (RedHat8, Mandrake, Fedora or other flavor), FreeBSD or Solaris, with administrator privileges, and basic networking configured. Workshop authors / leaders: Can Bican, Software Engineer Shane Kerr, Software Manager Vesna Manojlovic, Advanced Courses Trainer ---[end workshop details]--- Registration form ================= ---[begin form]--- 0. I wish to attend the 'Operating the RIPE whois Database Server' Workshop at RIPE 50 [] 1. Name: 2. Organisation/Affiliation: 3. E-mail address: 4. What are you expecting from this workshop: 5. Extra topics that you would like to see covered: 6. Your experience regarding (database) server operation: ---[end form]---

1 0

RE: [db-wg] Proposed changes for abuse
by Titley, Nigel 28 Feb '05

28 Feb '05

Sorry about the delay in response, I'm in Kyoto at the moment, 9 hours ahead (or 15 hours behind in email terms). Niall O'Reilly wrote: > Shane, > > Good stuff. > > I believe that what you describe matches the consensus we reached. > > On 16 Feb 2005, at 16:44, Shane Kerr wrote: > >> The changes we propose are: >> >> o To hide attributes that contain e-mail addresses in the default >> output of queries. We will also provide an option to disable this >> feature, > > Fine. Yes, we agreed this. > >> o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, >> MNTNER, ORGANISATION, INETNUM, and INET6NUM objects, > > Fine. We did *not* agree this. We agreed to add the abuse-mailbox attribute to IRT, PERSON and ROLE objects. We specifically decided not to add it to the INETNUM and INET6NUM objects (although this wasn't minuted) and we didn't mention ORGANISATION objects at all. See AP49.4. > >> o To provide an option to display only key attributes and abuse >> contacts, > > Fine. Nice idea. > >> o To change the IRT object template so that the "signature:" and >> "encryption:" attributes are no longer mandatory, > > Fine. Fine > >> o To change the behaviour of the '-c' switch in whois queries. > > No opinion, but that's my fault. 8-) Fine > Best regards, > > Niall O'Reilly > University College Dublin Computing Services > > PGP key ID: AE995ED9 (see www.pgp.net) > Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

3 2

Can't find a lot of IPs in the DB
by Thomas Unternaehrer 25 Feb '05

25 Feb '05

Dear list, a part of a small research project includes to analyze our servers log-file. I need to find out a bit more from the IP entries (reverse look-up) like the name of the company and the country. To do so, I was downloading the WhoIs-DB "ripe.db.inetnum.gz" from ftp://ftp.ripe.net/ripe/dbase/split/ but a lot of the IPs can't be resolved. E.g. I have the IP of my uni 160.85.0.0 that I can't find in the above DB. But if I try it in a shell with the whois command "whois -h whois.ripe.net 160.85.0.0" it gives me all what I need. What do I missunderstand here? Is it the wrong DB? My skills in such things are not really good, so sorry, if my question is to basic. thanks for any hints Thomas <ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz> Content Security by MailMarshal

2 2

Re: NCC#2005023954 [local-ir@ripe.net]AfriNIC Transition Completed
by RIPE NCC Hostmaster 24 Feb '05

24 Feb '05

Dear Gbebga Olubisi, The AfriNIC has put processes in place for providing services via e-mail, request forms etc. Like the RIPE NCC did before the lir-portal came into being. Lets take this discussion off list and I can direct you to more detailed information. Regards, ------------------- Timothy Lowe RIPE NCC IPRA ------------------- AfriNIC developments -----> http://www.afrinic.net On Wed, 23 Feb 2005 15:25:12 +0100, Gbenga Olubisi wrote: > hi Timothy Lowe, > > From the mail i have been receiving from RIPE, it is stated that the > LIR portal on RIPE will no more be available to LIRs that falls under > the geographical space of AFriNIC whihc my LIR (ng.briscoetel) falls. > Without access to the LIR on AfriNIC, how do i manage our IP address > whihc has been allocated to us already since late last year. > > Regards > > gbenga olubisi > > On Wed, 23 Feb 2005 14:16:41 +0100, RIPE NCC Hostmaster > <hm-africa(a)ripe.net> wrote: > > Dear Gbenga Olubisi, > > > > AfriNIC does not have an lir-portal like web interface at > > this time. One is planned. AfriNIC request forms and other > > documents can be found here: > > > > http://www.afrinic.net/documentation.htm#templates > > > > For further information please > > contact hostmaster(a)afrinic.net > > > > Regards, > > > > ------------------- > > Timothy Lowe > > RIPE NCC Hostmaster > > ------------------- > > > > AfriNIC developments -----> http://www.afrinic.net > > > > On Wed, 23 Feb 2005 12:23:42 +0100, Gbenga Olubisi wrote: > > > ng.briscoetel > > > > > > Hi , > > > > > > I can no longer access the LIR portal on www.ripe.net and i can't see > > > any link to the portal either on the AfriNIC website. Please help. > > > > > > Regards > > > > > > Gbenga Olubisi > > > ng.briscoetel > > > > > > On Wed, 23 Feb 2005 10:25:19 +0100, Axel Pawlik <ncc(a)ripe.net> wrote: > > > > > > > > Dear Colleagues, > > > > > > > > AfriNIC is the emerging Regional Internet Registry (RIR) for the African > > > > and Indian Ocean region. In preparation for its final recognition expected > > > > in April by ICANN, AfriNIC began operating as a fully functional RIR for > > > > the African region on 21 February 2005. LIRs in the AfriNIC service region > > > > can now request IP address space, AS Numbers and reverse delegation from > > > > AfriNIC and enter objects in the AfriNIC Whois Database. > > > > > > > > Details of the RIPE NCC to AfriNIC transition can be found at: > > > > > > > > http://www.ripe.net/info/resource-admin/afrinic/ > > > > > > > > If you have questions regarding the transition to AfriNIC, please contacts > > > > us at <afritrans(a)ripe.net>. > > > > > > > > Regards, > > > > > > > > Axel Pawlik > > > > RIPE NCC > > > > > > > > > > > > > > > > > -- > > > Gbenga Olubisi > > > Plot 267 Etim Inyang Crescent > > > Victoria Island , Lagos. > > > > > > > > > -- > Gbenga Olubisi > Plot 267 Etim Inyang Crescent > Victoria Island , Lagos.

1 0

AfriNIC Transition Completed
by Axel Pawlik 23 Feb '05

23 Feb '05

Dear Colleagues, AfriNIC is the emerging Regional Internet Registry (RIR) for the African and Indian Ocean region. In preparation for its final recognition expected in April by ICANN, AfriNIC began operating as a fully functional RIR for the African region on 21 February 2005. LIRs in the AfriNIC service region can now request IP address space, AS Numbers and reverse delegation from AfriNIC and enter objects in the AfriNIC Whois Database. Details of the RIPE NCC to AfriNIC transition can be found at: http://www.ripe.net/info/resource-admin/afrinic/ If you have questions regarding the transition to AfriNIC, please contacts us at <afritrans(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

4 3

Proposed changes for abuse
by Shane Kerr 23 Feb '05

23 Feb '05

Dear Colleagues, We've gone over the changes discussed and agreed on for improving the ability to find abuse information in the RIPE database, and have come up with the following modifications. Please have a look. We will be making announcements once final agreement is done, and adding a URL to the banner and dbupdate messages. Two things did not make it into this proposal from our side. One is that we find the name "IRT" somewhat confusing, but we have no specific proposal to change it. The second is a proposal to change the order of objects in query results, which will be sent as a separate proposal, since it is not very related and might cause controversy. -- Shane Kerr Software Manager RIPE NCC Following discussions in the Database Working Group at RIPE 49, we have prepared a proposal to make changes to the whois server software. The changes we propose are: o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature, o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, ORGANISATION, INETNUM, and INET6NUM objects, o To provide an option to display only key attributes and abuse contacts, o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory, o To change the behaviour of the '-c' switch in whois queries. We will announce the changes on our website. We will also contact any third-party software developers who rely on the RIPE Database for abuse contact information. You can read the minutes from the Database Working Group discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00469.html (1) Adding the "abuse-mailbox:" Attribute We will add a new attribute to the following object types: INETNUM INET6NUM PERSON ROLE IRT ORGANISATION MNTNER This optional attribute will contain at least one e-mail address. It will tell users where to send abuse complaints or queries. (The proposed templates for the above objects are at the end of this document.) The description of the new attribute will be the same in all objects: abuse-mailbox: Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:". As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@localhost trouble: for abuse reports, not info@localhost nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE We will replace this with: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@localhost remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE (2) Hiding Attributes That Contain E-Mail Addresses Finding the right e-mail address for abuse reports can be confusing. There is currently no easy way to find this information in the RIPE Database. Users often send mail to every e-mail address they see in a query result. To avoid this, we will hide all attributes that contain e-mail addresses from the default output of a whois query for an address. When a user looks up an address, the results may include the following objects: INETNUM INET6NUM ROUTE ROUTE6 ORGANISATION PERSON ROLE By default, MNTNER objects are not shown, but they are often also queried to get contact information. For each of the object types, the following attributes contain e-mail addresses: INETNUM: notify, changed INET6NUM: notify, changed ROUTE: notify, changed ROUTE6: notify, changed ORGANISATION: e-mail, notify, changed PERSON: e-mail, notify, changed ROLE: e-mail, trouble, notify, changed For each address range returned, if there is at least one "abuse-mailbox:" attribute in any of the returned objects, the attributes mentioned above will be removed from the output. If there is no "abuse-mailbox:" attribute, only "notify:" and "changed:" attributes will be filtered out. If an attribute of an object is changed, a comment will be added, to avoid confusion. Users can turn off this suppression. To make this possible, we will implement a '-B' flag. As an example: $ whois 10.0.0.10 Might currently give the following result: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE After the change, the result will be: % Note: this output has been filtered. inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 nic-hdl: ME1-RIPE mnt-by: I-MNT source: RIPE To see the unmodified result, users should type in: $ whois -B 10.0.0.10 (3) Adding 'abuse output' Option To help authors of tools or users who are only interested in the abuse contacts for IP addresses, we will implement a brief output mode. If a user types '-b' when querying the RIPE Database, they will only see the key attributes of address ranges and the "abuse-mailbox:" attribute. This switch will also imply '-c', which requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It will only work with address space related queries. Here is an example: $ whois 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 abuse-mailbox: ripe-dbm-person@localhost source: RIPE So: $ whois -b 10.0.0.0 Will return: % Note: this output has been filtered. % Only primary keys and abuse contact will be visible. inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost This output will not generate valid objects, and there will be no object separators. If two ranges are returned after making a query, an object separator will be inserted between groupings. Therefore, the output will look like this: inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost (*) inetnum: 10.0.1.0 - 10.0.0.255 abuse-mailbox: ripe-dbm-person-2@localhost (*) Attributes marked by (*) are taken from the person object retrieved by a recursive lookup. (4) Modifications on the IRT Object We will change the template for the IRT object will be changed. You will no longer need a KEY-CERT object to create an IRT object. Currently, the template for the IRT object is: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] "signature:" and "encryption:" attributes need existing key-cert objects. The Anti-spam Working Group asked us to make these objects optional. You can read an archive of this discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00452.html The template for irt objects will be: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Therefore, the object below would be valid: irt: irt-someorg-zz address: address for the irt phone: +11 22 3344556 fax-no: +11 22 3344556 e-mail: contact@localhost admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@localhost 20050505 source: RIPE We will automate this process, so that help from the RIPE Database Management will no longer be necessary create IRT objects. (5) Changing the behaviour of '-c' option in whois queries Currently, the -c option requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It does not return any related IRT objects. This will change, so that -c will treat IRT objects as contacts and do recursive lookups on related IRT objects. Here is an example: $ whois -c 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . After the change, the result will be: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . irt: IRT-TEST . . (6) Modified Templates inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Rows that are marked with '**' are additions to the templates.

12 23

Announcement Routing Registry Training Courses
by RIPE NCC Training 21 Feb '05

21 Feb '05

------- Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Training Services RIPE NCC **************************************************************************** COURSE DATES AND VENUES ======================== Date: Wednesday 18 May 2005 Time: 0900 - 1700 Location: London, United Kingdom AND: Date: Friday 17 June 2005 Time: 0900 - 1700 Location: Paris, France ***************************************************************************** REGISTRATION: To register for this Course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Training Services RIPE NCC

1 0

Re: [db-wg] whois_rip feature request, multiple inverse attribute queries needed
by Wilfried Woeber, UniVie/ACOnet 17 Feb '05

17 Feb '05

>To: av(a)nethead.de >CC: db-wg(a)ripe.net >Subject: Re: [db-wg] whois_rip feature request, multiple inverse attribute > queries needed >From: Havard Eidnes <he(a)uninett.no> >Date: Fri, 07 Jan 2005 16:59:42 +0100 (CET) > >> would it be possible to enhance the RDB query in a way that >> multiple inverse queries are possible?! I would like to be able >> to query objects which match a certain set of inverse >> attributes with only one whois-query. > >If I understood the question correctly, that's already possible. > >You can list the multiple attribute names (admin-c, tech-c, etc.) >separated by comma as the argument to the -i query option. > >Regards, > >- Håvard Supplying a list of arguments actually results in a logical .OR. operation. But at 1st reading, my interpretation of the request was a .AND. operation. I think we need more details, please! _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 5

Proposed changes for object ordering
by Shane Kerr 16 Feb '05

16 Feb '05

Dear Colleagues, As mentioned in the posting with the subject "Proposed changes for abuse", here is the proposal to change object ordering. As always, please have a look and discuss it here. -- Shane Kerr Software Manager RIPE NCC This is a proposal to display output differently, making recursive lookup results clearer. Currently, the software has a grouping algorithm that sorts objects by type. For example, if a query finds two INETNUM objects, such as: inetnum: 10.0.0.0 - 10.0.0.127 . . admin-c: PERSON1-RIPE tech-c: PERSON1-RIPE . . inetnum: 10.0.0.128 - 10.0.0.255 . . admin-c: PERSON1-RIPE tech-c: PERSON2-RIPE . . For a query, such as: $ whois 10.0.0.0 - 10.0.0.0.255 Here, the related PERSON/ROLE/ORGANISATION objects will also be returned, after being grouped into types, ending duplication. Therefore, the actual result will contain: inetnum: 10.0.0.0 - 10.0.0.127 inetnum: 10.0.0.128 - 10.0.0.255 person: PERSON1-RIPE person: PERSON2-RIPE This kind of output may be misleading. The user needs to find contact details by looking first at the "admin-c:" and "tech-c:" attributes, and then look them up in the PERSON/ROLE objects shown at the end of the list. This becomes time consuming as the number of objects returned increases. We will change the default output format. We will group objects by relevance. This change will give the following result for the same query: % Information related to '10.0.0.0 - 10.0.0.127' inetnum: 10.0.0.0 - 10.0.0.127 person: PERSON1-RIPE % Information related to '10.0.0.128 - 10.0.0.255' inetnum: 10.0.0.128 - 10.0.0.255 person: PERSON1-RIPE person: PERSON2-RIPE The changes explained in the section 'Hiding Attributes That Contain E-Mail Addresses' in the abuse proposal will apply to each grouping in turn. If only PERSON2-RIPE contains an "abuse-mailbox:" attribute, PERSON1-RIPE will not be filtered when it first occurs in the output, but it will be filtered upon its second occurrence. The 'traditional' output format of the whois server will still be possible, by using the '-G' option. Note: Another proposal could be to present the reordered output if the '-G' option is passed, otherwise to use the current ordering. This would leave the average user with the confusing output, and give the more advanced users the intuitive output. Making it an option would avoid potential problems with tools breaking, but some of the abuse changes will break tools so this may be a good time to change the default.

1 0

RE: [db-wg] whois_rip feature request, multiple inverse attribute queries needed
by Titley, Nigel 15 Feb '05

15 Feb '05

Joao Damas wrote: > Perhaps it is time to think about leaving the whois query syntax as it > is now and look at a different way of looking up things in RIR DBs > (based on crisp?). > The current RIPE whois syntax may not be the best but it has been > consistent for quite a few years and overloading it is likely to not > make things easier for casual users while it would be muddle things > for long time users I must say, I'm inclined to agree with Joao on this. Let's leave the RIPE whois syntax to enjoy its retirement in peace and concentrate on how to get the features we want in CRISP. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

AfriNIC Transition
by Axel Pawlik 09 Feb '05

09 Feb '05

Dear Colleagues, AfriNIC is the emerging Regional Internet Registry (RIR) for the African and Indian Ocean region. In preparation for its final recognition expected in April by ICANN, AfriNIC will begin operating as a fully functional RIR for the African region from 21 February 2005. The RIPE NCC is committed to its members and has therefore created a structured transition for members moving from the RIPE NCC to AfriNIC. Details of the transition can be found at: http://www.ripe.net/info/resource-admin/afrinic/ If you have questions regarding the transition to AfriNIC, please contacts us at <afritrans(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

1 0

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 19 Jan '05

19 Jan '05

Shane Kerr wrote: > We also plan on having the POEM object type implemented before the > next RIPE meeting, with work on that beginning as soon as the abuse > changes are completed. Excellent.... this is the *really* important work. Glad to see you have it scheduled so promptly. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 19 Jan '05

19 Jan '05

Gentlefolk, Niall has pointed out some major inaccuracies in the draft minutes, which I have corrected. Apologies for this. However luckily none of the action points have been impacted. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

3 2

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Wilfried Woeber, UniVie/ACOnet 18 Jan '05

18 Jan '05

Yesterday I had a chat with Rodney T. about the same thing. I'll work with the NCC to come forward with an update on progress. Wilfried. ______________________________________________________________________ From: "Titley, Nigel" <NTitley(a)flagtelecom.com> To: "'MarcoH'" <marcoh(a)marcoh.net>, db-wg(a)ripe.net Subject: RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0 Date: Mon, 17 Jan 2005 16:17:21 -0000 MarcoH wrote: >> [AP49.3 RIPE NCC] To produce a document detailing the programme for >> introducing the changes. >> >> [AP49.4 RIPE NCC] To implement the abuse-email: attribute in the >> irt, person and role objects. > > Not that I want to push people, but is there any progress on this > topic or can anybody from the NCC give some indication on when this > is expected to get done ? I would be expecting both of these to be complete by next meeting, in the absence of any response to the contrary by the Ripe NCC. Nigel --

1 0