May 2004 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Deprecation of the NONE Authentication Scheme
by Ziya Suzen 08 Nov '05

08 Nov '05

Dear Colleagues, As announced at RIPE 47 the NONE authentication scheme will be deprecated. After 26 April 2004 the RIPE Whois Database will not accept updates using the NONE authentication scheme. If you have objects protected by a MNTNER object which has the NONE authentication scheme, please assign another authentication scheme or create another MNTNER object to protect these objects. If you are a RIPE NCC member you can create new MNTNER objects through the LIR Portal or send your update to <auto-dbm(a)ripe.net>. History and details: -------------------- 1. Motivation The RIPE Database protects data from unauthorised modification through the use of references to maintainer objects. The maintainer objects contain an "auth:" attribute which specifiy how a user is authenticated during updates to the database. One of the allowed authentication schemes is "NONE", which is actually not an authentication at all, but rather specifies that no authentication is necessary. NONE is intended to be used consciously, as a notification facility or as a means to tag objects. In April 2003, a proposal was sent to the Database Working Group by Hank Nussbacher: It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. It is likely that in many cases NONE is used simply because it is easy. Currently approximately 500 maintainers use NONE - about 5% of all maintainers. 2. Plan Normally with a database cleanup effort, an announcement is sent to the appropriate mailing lists, posted to the RIPE web page, and also sent to the specific users affected. A period of time for cleanup is given. Finally, if the users have not fixed the data then it is modified. However, for the NONE deprecation, it is inadvisable to do this as it means announcing what is in effect a security vulnerability. Also, our operational experience with past cleanups shows that most users do not really participate through the phases of the effort. Therefore, the plan for MNTNER objects with the NONE authentication scheme is: o Announcement only to db-wg mailing list. (This announcement) o Remove "auth: NONE" attributes from all MNTNER objects, by changing them to a "remarks:" attribute with a URL explaining the change. o If that is the only authentication scheme, update the mntner objects, adding MD5-PW with a generated password. o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the objects, explaining the change and including the new password if one is added. o Passwords can be requested via an e-mail to <ripe-dbm(a)ripe.net>. The reply with the password will be sent to the same contacts. After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact <ripe-dbm(a)ripe.net> for assistance. 3. RIPE-NCC-NONE-MNT A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to objects without any maintainer when the database was converted from RIPE-181 format to RPSL format in April 2001. There is a remark in these objects which includes the following: remarks: The RIPE NCC will never use this maintainer object to remarks: enforce any sort of control over user's objects. It is possible this could have been interpreted to mean that no restriction would ever be added to the object. One use of the RIPE-NCC-NONE-MNT has been to allow the creation of objects representing routing policy for resources not allocated or assigned by the RIPE NCC. This is done by using "mnt-routes: RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate. A new maintainer object will be created for these cases, with a well- known password, published in the object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE upd-to: ripe-dbm-notify(a)ripe.net auth: MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1 remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040301 source: RIPE The main use of this maintainer is for INETNUM objects. There are approximately 60000 such objects - about 6% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. For objects using RIPE-NCC-NONE-MNT: o If there are other "mnt-by:" attributes it will be changed to a "remarks:" attribute. o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT, which has a locked password (or PGP key). o A "remarks:" attribute will be added explaining how to generate a maintainer. o An e-mail will be sent to the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "notify:" attributes of the objects, explaining the change and giving a URL which will help to generate a new maintainer or assign another existing maintainer. o At the URL, the object will be automatically updated to have a new maintainer. o After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact ripe-dbm(a)ripe.net for assistance. 4. Other maintainers with "auth: NONE" The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be deleted in the 2001 person cleanup. It can be removed and the maintainer deleted. The LIM-MNT is used for limericks. It will have a well-known password similar to the RPSL maintainer. It will also be maintained by another maintainer (not itself, as currently). -- Ziya Suzen RIPE NCC

4 5

problems with NRTM
by Patrick Rother 01 Jun '04

01 Jun '04

Hello. I have a problem with a NRTM running at ripe-dbase-3.2.0 software with mysql "Ver 12.22 Distrib 4.0.20, for pc-linux (i686)", i.e. there are some updates failing: # grep -i failed /opt/whoisd/log/ripupd/* | grep -v " 0 objects failed" | tail -20 ripupdlog_RIPE.20040524: 2 objects failed ripupdlog_RIPE.20040524:[4905870] 0.03s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4905925] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905934] 0.02s FAILED [as-set:][M:---] ripupdlog_RIPE.20040524:[4905945] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905959] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 4 objects failed ripupdlog_RIPE.20040524:[4906036] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906140] 0.45s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906209] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906272] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906309] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906377] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed # The database was completely rebuilt from the daily snapshot at ftp.ripe.net, but the problem still exists. I also tried ripe-dbase-3.2.0-org-obj-beta, but it segfaults regularly at or after every NRTM run, so it is not usable at all. What can I do to get this fixed? Thank you.

2 1

Question on whois server software & org records
by william(at)elan.net 01 Jun '04

01 Jun '04

Quick question. Does current/latest/beta version of RIPE RPSL whois server now support org records? If not when in your plans will you be releasing server code that would support it? -- William Leibzon Elan Networks william(a)elan.net

2 1

Re: [db-wg] Country attribute to be removed?
by Wilfried Woeber, UniVie/ACOnet 28 May '04

28 May '04

Dear Hank, >Can we have a list of who was in attendance, ...while I think the "who" (explicit list of names) is less relevant, I guess you can get that piece of information from the nice folks at meeting(a)ripe.net ... >and how many people voted in favor of removing the country attribute usually we do not conduct formal votes, but rather try to find a common position regarding a particular proposal. The number of people in the room is (as usual) part of my WG summary report to the plenary which is available from the net at http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-plenary-db.p… >and whether people realized that the country attribute is used by organizations? Yes indeed, please see slide #4, item 1. and slide #5 action point AP 48.1 And in particular there was concern that the use of this entry is less than helpful for some parties because there is no way of making sure that data is "correct" (for any definition of correct [1] :-) and relevant for the particular use... >And what is the rule on consensus - does attendance at the RIPE conference >have more weight than discussion in the online mailing list? Yes, and no, but I presume this is off-topic in that context? >-Hank Wilfried. [1] one of the questions for which we could not find an answer is: which country to put into the object - . the country of residence of the LIR . the country of residence of the admin-c: of an piece of address space? . the country off "deployment" (which is fuzzy in itself...) ______________________________________________________________________

1 0

Country attribute to be removed?
by Hank Nussbacher 28 May '04

28 May '04

From the RIPE 48 minutes provided by Nick Hyrka: >DATABASE WORKING GROUP > >- It was agreed that the 'country:' attribute should be either removed or >be optional. I was not at the meeting but reading over the PDF: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-db-country.p… I believe the consensus in db-wg was to add a ZZ code and *not* to drop the country attribute totally. Israel uses the country attribute to filter ISP prefixes at its IIX: http://www.isoc.org.il/fr_reload.html?iix/2x_tech.4 When was it agreed to have it removed? -Hank

3 3

Re: [db-wg] Proposal: Abuse-C as a Reference
by Wilfried Woeber, UniVie/ACOnet 13 May '04

13 May '04

>Why do you not just use IRT? > >The prime reason, with which I agree, is that there is this 'mandatory' >encryption field. Two things: I have already polled the CERT community regarding the 'mandatory' for the key-cert attributes. As of today, I haven't heard anything which would prevent us from making those 'optional'. The NCC has confirmed that the modification would be straight-forward (and cheap :-). So this is solved, I think. Wilfried.

4 5

Glimpse search on email strings
by Hank Nussbacher 13 May '04

13 May '04

How does one search for a specific email string via Glimpse: http://www.ripe.net/db/whois-free.html Or is this disabled? If so, suppose an email contact has to be changed globally and I want to find all objects where it is listed - how do I find it? Thanks, Hank

2 1

make auth inverse key
by kieber＠gatel.net 13 May '04

13 May '04

Re Shane, WG, just a quick reminder and followup to my short talk with Shane during RIPE48 regarding the closed action item on adding a reverse lookup feature for key-cert objects. You might want to have a look at agenda item ``I: Key Certificates to person role'', http://www.ripe.net/ripe/wg/db/minutes/ripe-44.html. My original idea was to change irt: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [ ] ... and mntner: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [ ] ... to irt: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [inverse key] ... and mntner: [mandatory] [single] [primary/look-up key] ... auth: [mandatory] [multiple] [inverse key] ... and block inverse queries for CRYPT-PW and MD5-PW, allowing PGPKEY (and other possible future strong encrytion schemes) to be inversely queried. Than I could find all references to my key-cert object, and update those references in case I wish to delete a key-cert object (e.g. in case the key has been compromised). As far as I see, this has not yet been implemented, but is, according to Shane, a rather easy to add feature. -- Ulf Kieber email: kieber(a)gatel.net Sr. Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net

2 1

Abuse-C/IRT
by Ulrich Kiermayr 12 May '04

12 May '04

Hi *, Here are the Statistics from today I mentioned on Abuse-C/IRT IPV4 Statistics 2004-05-06 +----------+----------------------------+-------------------+----------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+----------------------------+-------------------+----------+ | inetnum | 3.8e+08 (100.0%) [/3.5 ] | 1048450 (100.0%) | 0 | +----------+----------------------------+-------------------+----------+ | irt | 2.6e+07 ( 6.9%) [/7.4 ] | 2244 ( 0.2%) | 20 | +----------+----------------------------+-------------------+----------+ | abuse | 7.1e+07 ( 18.6%) [/5.9 ] | 150727 ( 14.4%) | 0 | | abuse@ | 6.1e+07 ( 16.1%) [/6.1 ] | 113360 ( 10.8%) | 1050 | +----------+----------------------------+-------------------+----------+ IPV6 Statistics 2004-05-06 +----------+----------------------------+-------------------+----------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+----------------------------+-------------------+----------+ | inetnum | 2.9e+31 (100.0%) [/23.5 ] | 5360 (100.0%) | 0 | +----------+----------------------------+-------------------+----------+ | irt | 4e+29 ( 1.4%) [/29.7 ] | 135 ( 2.5%) | 12 | +----------+----------------------------+-------------------+----------+ | abuse | 4.4e+29 ( 1.5%) [/29.5 ] | 3213 ( 59.9%) | 0 | | abuse@ | 4.4e+29 ( 1.5%) [/29.5 ] | 3054 ( 57.0%) | 91 | +----------+----------------------------+-------------------+----------+ lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140

9 21

RE: [db-wg] Proposal: Abuse-C as a Reference
by Rodney Tillotson 11 May '04

11 May '04

Ulrich Kiermayr wrote at 5/6/04 09:25: > This abuse-c inherits all the features of irt as well ... Except that crypto is optional. Fair enough. > ... resulting in just one object for this area I suggest we keep IRT for the purpose for which it was built, and make no changes to it (so it will be different from the role or person used we make available for abuse). This might actually encourage the use of IRT objects, since it reduces the risk that CSIRTs will get abuse reports they mostly don't want. And IRTs may then be useful, so I don't support removing them. > Implementing abuse-c that way would give a 1:1 mapping between > irt and role and therefore making irt obsolete (and the existing > objects auto-convertable). I think the 1-1 mapping is unnecessary; auto-copying is still possible. Can you confirm that the abuse-c: attribute can also refer to an IRT object for people who want to do it that way? > Add the missing features from irt: to the person and role objects: > > person: [mandatory] [single] [lookup key] > address: [mandatory] [multiple] [ ] > phone: [mandatory] [multiple] [ ] > fax-no: [optional] [multiple] [ ] > e-mail: [optional] [multiple] [lookup key] > signature: [optional] [multiple] [ ] <-- > encryption: [optional] [multiple] [ ] <-- > nic-hdl: [mandatory] [single] [primary/look-up key] > remarks: [optional] [multiple] [ ] > notify: [optional] [multiple] [inverse key] > mnt-by: [optional] [multiple] [inverse key] > ref-nfy: [optional] [multiple] [inverse key] <-- > mnt-ref: [optional] [multiple] [ ] <-- > changed: [mandatory] [multiple] [ ] > source: [mandatory] [single] [ ] Do we need a dedicated attribute in role and person? abuse-mail: [optional] [multiple] [ ] (or the name could be 'abuse-mailbox' as in Ulrich's example) Does the attribute need to be a lookup key like e-mail? (again as in the example) Should we make the abuse-mail attribute mandatory for the object types concerned? But that might force us to use a new object type :-( > Query behaviour: > > Return abuse-c by default as well The thing to return is not the name of the abuse-c reference; it's the abuse-mail attribute of the object referred to. Perhaps that's what you meant anyway? > Return abuse-c by default as well > (or include default -c i.e. return abuse-c from the least specific > inetnum containing the ip in question). Not quite, surely. We want to provide one user population with exactly one e-mail address and not too much else; so somehow we have to walk the database for them and not put the burden on them or their client software. I do not believe we can expect tool writers (eg SpamCop, geektools) to do that for us; I do not believe we can deploy a different whois client. We might get away with publishing a different server location (whois-for-the-masses.ripe.net? abuse.ripe.net?); or with putting this behaviour on whois.ripe.net and moving the present behaviour to a new address. But don't we want to present the mail address derived from the _most_ specific inetnum (rather than the least)? > Change the -c flag to use abuse-c instead of mnt-irt. No need to change that behaviour if we take the above approach. Rodney Tillotson, JANET-CERT

6 10

Draft minutes for the RIPE 48 DB working group
by Titley, Nigel 08 May '04

08 May '04

Gentlefolk, Herewith first draft of the minutes for the WG meeting at RIPE 48 Comments and corrections to me please. 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

2 1

Re: [db-wg] Abuse-C/IRT
by Wilfried Woeber, UniVie/ACOnet 07 May '04

07 May '04

Hi Pim, >| Hmm, this is nice, but not really necessary, because with the -c flag in >| the whois-query you should get tho the allocated /40 anyway. >| >| i.e. your change should increase the # of objects, bur not the Footprint >| of the IRT > [ ... ] > , should I revert that software >change and NOT set mnt-irt in the more specifics, or should I leave it >as is. Opinions ? setting it to the _same_ pointer is superfluous or just duplication of information. Unless you want to do it for a particular purpose (like to be explicit), it is a bad idea - having duplicate info in a dataset leaves you with the risk of missing one copy when an update is necessary. BUT - what you can do with this mechanism is to point to a _different_ irt object. Either for a subset of your own infrastructure (like a regional PoP), or as a 1st level contact for your downstreams. And those downstreams can update the contact info without having to bother you in your role as the _address_ bookkeeping :-) Wilfried.

3 2

Proposal: Abuse-C as a Reference
by Ulrich Kiermayr 07 May '04

07 May '04

Hello, To put together a Proposal for how a Referece solution could be done . This abuse-c inherits all the features of irt as well, resulting in just one object for this area [Like in tech-c which is also not fine-grained like having something for routing, something for hardware, for peering, for .....] What can be done to have the 'abuse-mailbox' like in Randy/niall's proposal would be the Role/Person object: This would also make it easier to reference existing data, i.e. the one Person NOC where the local guru is admin and tech and abuse. For example: inetnum: 131.130.7.32 - 131.130.7.47 netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK3 tech-c: UK3 abuse-c: UK3 mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr(a)univie.ac.at 20040506 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 663 8174818 e-mail: Ulrich.Kiermayr(a)UniVie.ac.at abuse-mailbox:abuse@uk.atat.at # up to disc. nic-hdl: UK3 mnt-by: UK-MNT notify: Ulrich.Kiermayr(a)UniVie.ac.at changed: Ulrich.Kiermayr(a)UniVie.ac.at 20020723 source: RIPE --------------------------- Proposed Templates: [Changes are denoted by the <--] Add abuse-c to the objects where we need it (note that i have removed mnt-irt there) inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- 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] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- 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] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] aut-num: [mandatory] [single] [primary/look-up key] as-name: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] member-of: [optional] [multiple] [ ] import: [optional] [multiple] [ ] export: [optional] [multiple] [ ] default: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] <-- notify: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Add the missing features from irt: to the person and role objects: person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] signature: [optional] [multiple] [ ] <-- encryption: [optional] [multiple] [ ] <-- nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- 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] signature: [optional] [multiple] [ ] <-- encryption: [optional] [multiple] [ ] <-- trouble: [optional] [multiple] [ ] 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] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] For the consistency of the system one shoud add reference protection to the mntner too in that implementation. mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] ref-nfy: [optional] [multiple] [inverse key] <-- mnt-ref: [optional] [multiple] [ ] <-- changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Implementing abuse-c that way would give a 1:1 mapping between irt and role and therefore making irt obsolete (and the existing objects auto-convertable). Query behaviour: -) Return abuse-c by default as well (or include default -c i.e. return abuse-c from the least specific inetnum containing the ip in question). -) Change the -c flag to use abuse-c instead of mnt-irt. I hope that makes some sense. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr(a)univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140

3 14

draft agenda (V3) for DB-WG meeting, RIPE 48, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 04 May '04

04 May '04

Dear DB-WG community, this should be the final version (2) of the draft agenda for the DB-WG meeting at RIPE48 in Amsterdam, NL. Changes: - meeting schedule for 2005 - usability of RAToolSet, RPSLng checker compatibility Wilfried. ++++++++ [ slot Nr.1 ] A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (Shane K., RIPE NCC) [~20 min] C. ERX Phase 3 (Leo V., RIPE NCC) [~15 min] D. Value "ZZ" for country: attribute (Engin G., RIPE NCC) [~10 min] E. CRISP/Joint-Whois status [~30 min] . report by Andrew Newton, VeriSign . follow-up by RIPE NCC [ slot Nr.2 ] F. support for works of art (Nigel T., FLAG TC) [~10 min] . poetry | haiku | ??? G. irt: / abuse: [60+ min] . proposal by Niall O'R. & Randy B. . statistics by Marco H. H. RAToolSet & RPSLng (WW144) [~10 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 4-MAY-2004 14:09:08 UTC

1 0