- db-wg - mailman.ripe.net

RIPE Whois Server version 3.0.2
by Shane Kerr 19 Sep '01

19 Sep '01

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.2 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is intended both as a bug fix release, and also to offer much-improved ease of installation and configuration. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2-nocxref.tar.gz A patch for the 3.0.1 "nocxref" version is also available, if you already have that version, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.1-nocxref-3.0.2… If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. -- Shane Kerr RIPE NCC

3 3

on the question of 'right to maintainership'
by Petra Zeidler 17 Sep '01

17 Sep '01

Dear all, I am herewith soliciting opinions and 'current practise' on the question of maintainership of inetnums. We are in the position of having several allocations that are infested with 'historical' PI assignments, i.e. address assignments that have been assigned before the advent of CIDR. My LIR (de.xlink) currently refuses to enter maintainers different from ours to inetnums from our allocation, due to less than happy experiences with different (even also LIR) maintainers in the past (when the user of the 'historical' PI left its new provider and renumbered they lost all interest in the inetnum and it took quite some time to get the object referring to the then long returned address space deleted). Some people seem to think that they have a right to maintainership to objects that are assigned to them; I cannot find any such rule in the LIR procedures, and also it would be a good question where that would stop .. has anybody assigned a PA /29 a right to maintain their own object? and if yes, how are the hostmasters responsible for an allocation supposed to keep their charge in order? After assignment, anything but the size of the range would be fair game, very fun especially in cases where a tech-c decides that the inetnum range is their personal property even though it has not been assigned to them personally (and that is by no means a rare occurrence). Of course both the crook and the misled are the exception, not the rule, but we -do- have maintainers in the first place because of them, and a rule ought to be based on something better than 'you look kind of trustworthy'. What's your position on the problem as such? And if you give third parties maintainership of inetnums in your allocation(s), under what rules do you do so? To any kind of inetnum? To anyone asking who has a maintainer object? And if you do so, do you still assign from that allocation(s)? kind regards, Petra Zeidler -- [A] KPNQwest Germany * Emmy-Noether-Strasse 9 * D-76131 Karlsruhe [T] +49 721 9652 215 [F] +49 721 9652 171 [E] petra.zeidler(a)kpnqwest.com [I] www.kpnqwest.de

2 1

Reminder: Removal of selected sets of contact information from the RIPE Database
by Joao Luis Silva Damas 14 Sep '01

14 Sep '01

Dear all, (apologies for duplicates) This message is a reminder of the ongoing process of removal of unreferenced contact information from the RIPE Database. We have updated the web page http://www.ripe.net/ripencc/pub-services/db/orphaned.html with a more up to date list of maintainer objects relevant to this process. I would like to use the opportunity to clarify an apparently confusing aspect of previous notes: If your person/role object already has a mnt-by attribute that references a maintainer object not contained in the list provided in the above mentioned web page, there is no need to add a reference to RIPE-NCC-PN-NONE-MNT. This maintainer has been created by the RIPE NCC with the sole purpose of facilitating a mechanism for people without maintainer objects to tag their person/role objects to avoid deletion. If you already have a proper maintainer object, DO NOT include RIPE-NCC-PN-NONE-MNT as this would lower your protection level. Best regards, Joao Damas RIPE NCC

3 4

Removal of selected sets of contact information from the RIPE Database
by Joao Luis Silva Damas 03 Sep '01

03 Sep '01

Dear all, (apologies for duplicates) This is a reminder notice regarding the process of removal of selected sets of contact information from the RIPE Database as initially announced in my mail of 21-8-2001. This phase of the process will affect all person and role objects that are either: - both un-maintained and unreferenced - unreferenced and maintained by maintainers related to registration of domain names in .de For further details about this process, visit the RIPE NCC's web site at http://www.ripe.net/ripencc/pub-services/db/orphaned.html or the "RIPE NCC Annoucements" section at http://www.ripe.net Best regards, Joao Damas Chief Technical Officer RIPE NCC

1 0

RPSL WWW Whois Script ...
by Low, Adam 24 Aug '01

24 Aug '01

Hi, Was the new RPSL web whois script used by RIPE released to the general public ? Cheers, Adam

2 1

summary for CERT/IRT object proposal [3]
by Wilfried Woeber, UniVie/ACOnet 23 Aug '01

23 Aug '01

Dear TF-CSIRT, dear DB-WG community, [ and apologiess to those receiving more than one copy ] I was working with the RIPE NCC recently to finalize the implementation plan for the CERT/IRT Object. We had some interesting discussions (also including Yuri working on IODEF et.al.), and the NCC was checking "our" proposals against some implementation constraints. The result of that process is attached below. I'd ask the CERTs and IRTs in particular, and everyone else being interested, to review the summary. Please try to deploy the stuff "on your desk" and maybe submit your comments. I hope to be able to have a very final and brief discussion, and the technical "go-ahead", in Prague. As I understand from the NCC, we can then expect to see a quick implementation! Regards, and thanks to the NCC for offering very helpful suggestions, and thanks to the IRTs which have been patient for so long! Wilfried. ______________________________________________________________________ inetnum: 193.171.2.0 - 193.171.2.255 netname: ACONET-DEMO-2 descr: ACOnet addresses for demos and transient events country: AT admin-c: WW144 tech-c: UVNA1-RIPE tech-c: WW144 status: ASSIGNED PA remarks: ---------------- remarks: 20000720-20001231: UniVie/PTA ADSL trials - core remarks: ---------------- mnt-by: ACONET-LIR-MNT mnt-irt: ACONET-IRT # use irt object name here changed: panigl(a)cc.univie.ac.at 20010629 source: RIPE irt: ACONET-IRT address: ACOnet Incident Response Team address: c/o Vienna University Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna, Austria phone: +43 1 4277 140 00 fax-no: +43 1 4277 9 140 e-mail: Domain-Admin(a)UniVie.ac.at signature: PGPKEY-<key-id> # IRT team key first (mand.) remark: # member keys next (optional) remark: # messages from the IRT are remark: # signed with this/ese key/s encryption: PGPKEY-<key-id> # use this to encrypt a message remark: # to be sent to the IRT remark: # multiple entries allowed admin-c: WW144 tech-c: WW144 auth: CRYPT-PW bocEHQ0niH52I # checked to authenticate auth: PGPKEY-DBC579D4 # insertion of ref. to this obj. notify: Woeber(a)CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT # use the regular mntner: mech. remark: # to protect the irt object changed: woeber(a)cc.univie.ac.at 20000202 source: RIPE mntner: ACONET-LIR-MNT descr: ACOnet Local-IR admin-c: WW144 tech-c: WW144 upd-to: Domain-Admin(a)UniVie.ac.at mnt-nfy: Domain-Admin(a)UniVie.ac.at auth: MAIL-FROM .*(a)cc\.univie\.ac\.at # a *very* bad example auth: PGPKEY-DBC579D4 notify: Woeber(a)CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT referral-by: RIPE-DBM-MNT changed: woeber(a)cc.univie.ac.at 20000202 source: RIPE Operations: irt: object creation is manual (like mntner:) Semantics/Security: "auth:" mechanisms specified are used for authenticating the reference insertion. For an irt: object, only CRYPT-PW and PGPKEY SHOULD be used! However, this recommendation is not enforced by the DB software. This is considered to be a BCP issue. The 1st entry in the list of signature: SHOULD be the team-key, any additional entries MAY BE secondary team keys and/or team members' keys. This is considered to be a BCP issue. The key-cert objects for the PGP keys will be stored in the public keyring. More generally, only keys supported by the RIPE DB will be allowed. However, as soon as the DB accommodates additional certificate formats, those should be allowed here as well by default. Lookup and use: $whois iplookup Default behaviour, no irt is returned (as expected) because mnt-irt is more a mntner reference, which is never returned automatically. The user will need to perform a second query to retrieve info about the IRT. This will also reduce the abuse of an irt object by people sending reports to whatever e-mail address they see in an output. $whois -c iplookup This query would do a tree-walk, like the referral mechanism, trying to find an entry with an mnt-irt attribute present. The query will display an object containing the reference, but not the irt object itself. Again, people will need to perform a second query to retrieve info about the IRT. The ideas behind this proposal are: - not to alter the default behaviour for object lookups (only contact info is returned, not mntners) - not to modify the behaviour of -l flag. [ed. comment: during the discussion we were thinbking about modifying the behaviour of the -l flag when a -c flag were present.] Questions/Comments: Q: Do we allow any mntner: object in an irt: object's mnt-by: attribute, even those having weak authentication? A: no special provisions in the software. This is considered to be a BCP issue. A: a more useful approach is to deprecate weak authentication mechanisms altogether. Q: Do we want to have/allow a hierarchy similar to mnt-lower: for .e.g. inetnum: and inet6num: objects? A: no Q: should the reference to an irt: object be it's name or it's handle? A: the irt object is very similar to mntner object, so global uniqueness should not be an issue. Q: Do we want something like a trouble: in the role:, or simply use remark or put an (optional) abuse attribute into the irt object? A: probably not. Including uniform info for spam or abuse contacts is a BCP issue. [ed. comment: see discussion on anti-spam list.] Q: do we want to use more descriptive attribute names for signature and encryption? E.g. irt-sig: and encrypt:, or sig-from: and encrypt-to: Q: no clear preference, no decision in WG... so, what? A: stick with signature and encryption Decisions: Do not implement a url: attribute. Can be done with remark: Interaction with (public) key servers is outside the scope of this proposal. Implement irt object for inet[6]num initially. Extending functionality to e.g. AS number objects [ed. comment: and route objects] leads to the interesting question how to extend RPSL. This is similar to the issue of IPv6-extensions to RPSL. Separate project. Suggested object templates: 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] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inetnum: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... inet6num: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... _________________________________:_____________________________________ 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: New RIPE-147 needed!
by Sabrina Waschke 23 Aug '01

23 Aug '01

Berislav, Thank you for your comments regarding the AS Number request form. You are correct in that the RIPE-147 document needs updating due to the new RPSL syntax. Over the last couple of months the RIPE NCC has been working hard on writing new documentation, developing training material and updating current documents to adjust to the new database software. RIPE-147 is on our to-do list and you should be able to expect a new version in the near future. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Berislav Todorovic <beri(a)kpnqwest.net> writes: * Maybe this will sound like a hassle, but ... * * ... Everytime I receive a ripe-147 form from teh customer I have to "patch" * it myself, to make it compliant with the new RPSL syntax. * * Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE * document, please!)? Here's what should be changed: * * * Add "as-name:" attribute. * * Replace "as-in:" with "import:" and "as-out:" with "export:". * * Check to see if RPSL syntax is honored. * * Check the examples and make them compliant with RPSL syntax. * * Regards, * Beri * * --------- Berislav Todorovic, Network Engineer --------- * ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- * ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- * --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- * -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- * --- _ _ ____ _ .--. ____ ____ __/_ --- * ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ * ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- *

1 0

Re: Re[2]: Removal of selected sets of contact information from the RIPEDatabase
by hostmaster＠bsws.de 23 Aug '01

23 Aug '01

owner-db-wg(a)ripe.net wrote on 23.08.2001 15:34:38: > At the moment there is not. I have just spoken to DENIC though, and > they told me they were migrating those person objects to an own DENIC > database. The same was done for domains quite a while ago also by the > way, domains were stored in the RIPE database and have been ported to > DENIC. Also, most other NICs have - according to my infos - already > migrated to own databases, why would not DENIC do also? That's not the question here. The problem is he way DENIC wants to migrate and their non-existant information politics. As always, not a single statement on public-l(a)denic.de - but that's not RIPE's fault of course. Thanks for the information (we should have had from DENIC long time ago) and keep up your good work. Greetings Henning -- BS Web Services | www.bsws.de Roedingsmarkt 14 | hostmaster(a)bsws.de 20459 Hamburg Germany

1 0

RPSL: Providers exchanging full tables.
by Low, Adam 23 Aug '01

23 Aug '01

Hi, Mr. Nipper had pointed out an interesting issue with our as-macro recently, I believe its the first situation we've come across that isn't easily depicted within an RPSL routing policy without the requirement to manually update multiple near identical objects. The situation arises when we exchange full route tables with another provider, we then in turn should announce their prefixes listed in their macro onto our other providers and they too should do the same for our respective macro. So by adding each others macros to each others macros, we effectively create loops. Now is this a real problem ? In my opinion, I don't think it is, I believe that to truly understand the policy between two peers you have to take into account more (aut-num/import/export) than just the contents of an as-macro and that any tool that uses as-macros to generate prefix lists should check for duplicates and loops. It also appears that the tools we use today (RtConfig/peval) are not adversely effected by providers listing each others macros, output is as expected. Does anyone else have a view on this or a good idea of how it can be easily depicted within RPSL ? Cheers, Adam

1 0

Re: Removal of selected sets of contact information from the RIPEDatabase
by Christian Zietz 23 Aug '01

23 Aug '01

Hi, > 1. The following unreferenced person objects will be deleted: > - objects referenced only from *.de domains, according to the list > provided by DENIC (or list of mntners that define that set); > - objects that are un-maintained. Did I understand that correctly? Objects (e.g. persons) referenced only from .de domains are going to be deleted even if they are maintained (e.g. by DENIC-P). Imho that would be quite a big problem because DENIC's database relies on the RIPE database for person objects. Afaik there's no possibility to create a person object directly in the DENIC database. Christian

4 3