- db-wg - mailman.ripe.net

Beta release of Whois S/W with organisation object
by Engin Gunduz 06 Apr '04

06 Apr '04

Dear Colleagues, [Apologies for duplicate mails] We have made available the beta version of RIPE Whois Software that supports the organisation object. You can find it at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0-org-obj-beta.tar.gz Plese note that the software has been tested only on Solaris 8 environment. Please contact me at <engin(a)ripe.net> for any questions/comments. Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

New database Features
by Denis Walker 25 Mar '04

25 Mar '04

Dear Colleagues, [Apologies for duplicate mails] We have recently installed an updated version of the Whois software and Database update software. As well as some bug fixes there are three new features in the Database software. X.509 ----- This is now fully implemented. You are able to create the new X.509 KEY-CERT objects and reference these in the "auth:" lines of a maintainer. You can now use X.509 authentication with all our update methods: mail, syncupdates and webupdates. There is a link to the X.509 enabled webupdates script from the RIPE Whois Database page of the RIPE NCC web site: http://www.ripe.net/db/index.html The direct link is: https://www.ripe.net/perl/webupdates-x509.pl For documentation please refer to: http://www.ripe.net/db/x509.html You may also wish to check some other updated documents on security of objects: http://www.ripe.net/db/security.html http://www.ripe.net/db/Maintainer_Creation_Procedure.html http://www.ripe.net/db/pgp.html CIDR notation for inetnum creation. ---------------------------------- We now allow the use of CIDR notation when creating INETNUM objects. The CIDR string is replaced by the expanded range notation before the object is processed. This feature is ONLY permitted when creating an object. For example if the following object is submitted to the RIPE Database: inetnum: 1.2.0.0/16 before any further processing is done it will be converted to: inetnum: 1.2.0.0 - 1.2.255.255 A warning message will be added to the acknowledgement reply. It is now standard policy to add a warning if any changes are made to the submitted data. Prefix range lists for "mnt-routes:" ---------------------------------- The "mnt-routes:" attribute's syntax has been extended to allow prefix range lists. This will enable people to specify which maintainer has to authorise the creation of the specific routes. As an example: mnt-routes: MY-MNT { 20.34.0.0/1617-18, 20.34.0.0/16^- } mnt-routes: NOT-MY-MNT { ANY } Support for the previous syntax is unchanged. The extended syntax complies with RFC2725 which can be found at: ftp://ftp.ripe.net/rfc/rfc2725.txt For questions and comments please contact <ripe-dbm(a)ripe.net>. Best regards, -- Denis Walker RIPE NCC Software Engineering Department

1 0

Announcement: Changes to the ripe-dbm and auto-dbm acknowledgments
by Timur Bakeyev 23 Mar '04

23 Mar '04

Dear Colleagues, After 24 of March acknowledgments will be sent to all incoming mails send to <ripe-dbm(a)ripe.net>. This feature was promised to the community on the last RIPE meeting. Addition of this new feature has required changes to the way how acknowledgments are sent from <auto-dbm(a)ripe.net>. We realize that such a change may have an impact to the way how mails are processed by our customers, so here is the short description of the key changes: * All the acknowledgments will be sent with the 'Return-Path:' set to <>. * 'From:' field will point to the unattended mail address <unread(a)ripe.net>. This should protect us from the replies of the automated mail tools and mailer daemons. We are using the 'Auto-Submitted:' field to denote auto generated mail responses, as it is proposed in the draft RFC "Recommendations for Automatic Responses to Electronic Mail", available at: ftp://ftp.ripe.net/internet-drafts/draft-moore-auto-email-response-05.txt The widely recognized 'Precedence: bulk' mail header is used as well. There are two types of acknowledgments - ACK and NOTIFY, that are send by <auto-dbm(a)ripe.net>. ACKs are sent as the direct result of the updates of the Whois data. NOTIFYs are sent in the case when the updated object has 'notify:' or 'mnt-by:' fields or when an update fails to pass authorization check. Please consult the RIPE Database Reference Manual for farther details: http://www.ripe.net/ripe/docs/databaseref-manual.html#3.5 For the mail of ACK type: * The 'Reply-To:' field will be set to the <auto-dbm(a)ripe.net>. * 'Auto-Submitted:' will be set to the 'auto-replied' value. For mails of NOTIFY type: * The 'Reply-To:' field will be set to <ripe-dbm(a)ripe.net>. * 'Auto-Submitted' field will be set to the 'auto-generated' value. With best regards, Timur Bakeyev RIPE NCC

1 0

IRT object creation is easy
by Jeroen Massar 17 Mar '04

17 Mar '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, For the sake of promotion of the IRT object and for checking out if it really is easy creating it I requested an IRT object from RIPE, who have assigned it without much problems. The main problem was me not filling the form in correctly and after that being so stupid not having added the correct PGP key *whistle* and indeed it won't authenticate if the mnt-irt authentication is not satisified, thus that part is now also succesfully tested. Anyhow, it *is* easy getting it and if we (SixXS) can get it, then any ISP should be able to get it. Almost all the inet6nums assigned to the SixXS project now have a mnt-irt on their /40's, the other POPs will follow. Thus I can now say that: $ lftp ftp://ftp.ripe.net/ripe/dbase/split $ ls - -rw-r--r-- 1 ftpuser ftpgroup 176490 Mar 16 01:42 ripe.db.inet6num.gz $ get ripe.db.inet6num.gz $ gunzip ripe.db.inet6num.gz $ grep -cE inet6num ripe.db.inet6num 4206 $ grep -cE "mnt-by:.*SIXXS-MNT" ripe.db.inet6num 1872 1872/4206*100% ~= 44.50% of the inet6num's is now protected by the IRT-SIXXS object by adding about 10 mnt-irt attributes to 10 different objects. $ grep -c "mnt-irt:" ripe.db.inet6num ripe.db.inet6num 102 Add 6 to that at the moment, as the updated objects are not in this splitted file yet. For that matter, there are also other ISP's adding mnt's: $ cat ripe.db.inet6num |grep -E mnt-irt | sort | uniq -c 21 mnt-irt: IRT-AA 1 mnt-irt: IRT-ACOnet-CERT 49 mnt-irt: IRT-DFN-CERT 5 mnt-irt: IRT-ITGATE 2 mnt-irt: IRT-SPEEDKOM1 1 mnt-irt: IRT-UK 23 mnt-irt: irt-CERT-NL It would also be quite fast to deploy more mnt-irt's by making the field mandatory for new allocations forcing ISP's to make use of the object. Because of the above I don't see a reason for a abuse-c or similar object. If there is a need for adding things like 'spam' or 'ddos' etc then these should be added to the IRT object and not to a new one. Now everybody go request an IRT object and get it over with. In total it will probably cost you a max of 2 hours and I think that can be really worth it as when it is being used we can then tell abuse tool writers where to look. Handy docs: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-db-irt.pdf http://www.ripe.net/ripe/docs/irt-object.html Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQFZd8QAAxRMAn22KiziDgieySrdDQele+peb DXCPAJ9FwYSfaZy9XeU3SPK0gqkYM2a5LA== =ZDFN -----END PGP SIGNATURE-----

7 11

Re: [db-wg] IRT object creation is easy
by Wilfried Woeber, UniVie/ACOnet 17 Mar '04

17 Mar '04

>I wouldn't say this. I sent request day ago and unil now I didn't >get any response from people approving it. "... didn't get ANY response ..." I guess you should have got an automatic reply, with a ticket number?! Wilfried.

1 0

person objects update
by Pieterjan d'Hertog 17 Mar '04

17 Mar '04

Dear all, Just a sugestion Could it be possible to include the full name of the person in the detailed explanations of the ripe-dbm robot when creating new person objects in the ripe database ? If I remember well, in the previous version this was done ? This will be very usefull to more easily parse the results of an update and to import them in our own database. Example : The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] CS2321-RIPE ***Info: Authorisation for [person] CS2321-RIPE using mnt-by: authenticated by: SKYNETBE-MNT Could be : Create SUCCEEDED: [person] Chris Sanders NEW nic-hdl : CS2321-RIPE Thanks, --- Pieterjan d'Hertog, Belgacom ANS/ROC Internet Expertise Center

5 9

SUCCESS: [New person: Test User]
by ripe-dbm＠ripe.net 16 Mar '04

16 Mar '04

> From: "Robert S. Plaul" <robert(a)plaul.de> > Subject: [New person: Test User] > Date: Tue, 16 Mar 2004 16:12:55 +0100 (CET) > Reply-To: robert(a)plaul.de > Message-ID: <Pine.LNX.4.58.0403161611570.3525(a)klendathu.crossline.org> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 1 Create: 1 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 0 Create: 0 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: [New, person:, Test, User] ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] TU107-RIPE ***Info: Authorisation for [person] TU107-RIPE using mnt-by: authenticated by: CROSSLINE-MNT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net> Regards, Robert S. Plaul -- RSP-RIPE

1 0

person objects update
by Pieterjan d'Hertog 16 Mar '04

16 Mar '04

Dear all, Just a sugestion Could it be possible to include the full name of the person in the detailed explanations of the ripe-dbm robot when creating new person objects in the ripe database ? If I remember well, in the previous version this was done ? This will be very usefull to more easily parse the results of an update and to import them in our own database. Example : The following object(s) were processed SUCCESSFULLY: --- Create SUCCEEDED: [person] CS2321-RIPE ***Info: Authorisation for [person] CS2321-RIPE using mnt-by: authenticated by: SKYNETBE-MNT Could be : Create SUCCEEDED: [person] Chris Sanders NEW nic-hdl : CS2321-RIPE Thanks, --- Pieterjan d'Hertog, Belgacom ANS/ROC Internet Expertise Center

1 0

RE: [db-wg] proposal: haiku object
by Titley, Nigel 16 Mar '04

16 Mar '04

Niall O'Reilly wrote: > On 13 Mar 2004, at 03:33, der Mouse wrote: > >> >>> A low blow.... and also one that is incorrect. Look again, >>> "serenaders" rhymes (or is more strictly an assonance) with "made >>> us". >> >> Only in UK English. > > No; only in certain dialects of British English. This rhyme won't > work too well in Glasgow, or in the Welsh valleys. > > 8-) Niall Well, as I said, its really an assonance rather than a rhyme, the "a" in "serenaders" is an assonance with the "a" in "made us". It's a perfectly valid poetic device and very common in ballads, although possibly fights slightly shy of the RIPE database definition of a limerick. 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] proposal: haiku object
by Titley, Nigel 14 Mar '04

14 Mar '04

Shane Kerr wrote: > Titley, Nigel wrote: >> >> Does the RIPE NCC have a view >> On provision of objects haiku? >> Are you bored and depressed >> And in need of a rest? >> Is this just too much extra to do? > > I think that I shall never see, > A class as lovely as a tree. > Trees like ash and bitternut, > May be only made by God but, > Objects are made by fools like me. > > [ With apologies to Alfred Joyce Kilmer ] > > > Anyway, we are certainly willing to implement any feature that the > community thinks is necessary, including but not limited to new > classes, attributes, access methods, etc. > > > Having said that, we have some problems with the current limerick > class. > > First, we are having trouble coming up with a good way to detect > whether limerick contents match the rhyming scheme. We can implement > this, although we will probably limit it to English (even though > there are Dutch, French, German, and other limericks), and will have > to make it a warning rather than an error, to allow for artistic > leave (to help people who think that "serenaders" rhyme with "join > us", like in LIM-NT13-1). A low blow.... and also one that is incorrect. Look again, "serenaders" rhymes (or is more strictly an assonance) with "made us". The last line "join in" rhymes with "the din". Some sort of soundex scheme would possibly have found this... however I agree that this is not an easy problem. > > Second, it is difficult for us to enforce the requirement that the > poem is humorous. I tried various algorithms, but none of the > software I came up with seemed to find any of the limericks funny at > all. Actually, I thought my computer was angry enough to swear at > me, until I remembered that I had tried Perl, and the punctuation > symbols were just the program itself. Well, as you know, I'm not at all sure that limericks are *required* to be humourous. I agree that the database definition says they are, but I feel that this is too limiting. I would propose modification of the specification to be "usually humourous". Of course if the verse-form proposal below is adopted, this can be dealt with in the descriptive limerick. > Anyway, I find the haiku an interesting proposal, but I do like the > generality of the poem proposal. I also agree that limiting the > types of poems to a pre-defined set of types. Therefore I suggest we > use the database to self-document the types of poems using a > meta-poem object. So poems would look like this: > > 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] [ ] > > The "form:" attribute will reference a poetic-form object: > > poetic-form: [mandatory] [single] [primary/look-up key] > descr: [optional] [multiple] [ ] > admin-c: [mandatory] [multiple] [inverse key] > tech-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] [ ] > > The "descr:", "admin-c:", "tech-c:", "remarks:", "notify:", "mnt-by:", > "changed:", and "source:" attributes are required in all RPSL objects > according to RFC 2622. > > Initially we would have: > > poetic-form: VERSE-LIMERICK > desr: A limerick object represents a humorous poem that has > five lines and the rhyme scheme "aabba". > admin-c: LIM1-RIPE > tech-c: LIM1-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20040401 > source: RIPE > > poetic-form: VERSE-HAIKU > descr: A haiku object represents a poem that usually has three > lines with 5, 7 and 5 units. In languages other than > Japanese units are generally applied as syllables. > There is no rhyme scheme at all. > admin-c: HIKU1-RIPE > tech-c: HIKU1-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20040401 > source: RIPE > > We would restrict new poetic-form objects to creation by RIPE DBM, but > adding additional forms for sonnets, free verse, blank verse, and so > on, should be easy. If the community feels that identifying and > documenting poetic forms falls out of the scope of the RIPE NCC > activities, we can consider an alternative mechanism. Perhaps ICANN > would be able to perform this activity? I personally wouldn't trust ICANN to create any verse-form other than a writ, although in mitigation, we have an ex-speaker for the secret working group embedded as a mole within the organisation, and now may be the time to activate him. > In any case, we would need a conversion project to change the existing > limerick objects into poem objects. There are currently 152 of > these, so we need to be careful not to interfere with these in a way > that affect the production services that depend on them. Oh quite. Perhaps the RIPE NCC could come up with a migration plan. I think the above is an excellent proposal, and I further endorse the later suggestion that the description be in the verse form itself. Best regards -- 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