- db-wg - mailman.ripe.net

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

RE: [db-wg] proposal: haiku object
by TAYON, Julien 11 Mar '04

11 Mar '04

Titley, Nigel <mailto:NTitley@flagtelecom.com> wrote: > Olaf M. Kolkman wrote: >> I'd suggest the descr: field to be in the poetic form itself. > >> >> Looking at the VERSE-SONNET we may have a problem. There are several >> subclasses that people may wish to use. The Italian Sonnet, The >> English Sonnet and more modern varieties. How do we indicate >> possible sub-classes in the object? >> >> poetic-form: VERSE-SONNET >> variety: ENGLISH >> descr: (Somebody needs to write an English Sonnet) I would propose to Keep It Simple Poetic form: MAJOR-[MINOR][-SUBMINOR][-...] Example : poetic-form: VERSE-SONNET-ITALIAN poetic-form: VERSE-SONNET-ENGLISH ex : Venitian variety of Italian Sonnet could be : >> poetic-form: VERSE-SONNET-ITALIAN-VENITIAN This way we can extend as much as we want the poetic form. This is based on the assumption that Poetric form are homothetic to a tree structure. Which cannot be proven according to Goedel's theorem however I would say it is sufficiently close to reality for me. We will let the work of demonstrating the tree like structure of poetic form to the mathematicians if you don't mind. Regards, -- julien.tayon(a)neuf.com +33 (0)1 70 18 14 45 Gestion des adresses IPs, BU Data n9uf telecom 40 - 42 Quai du Point du Jour 92659 Boulogne Billancourt

1 0

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

11 Mar '04

Olaf M. Kolkman wrote: > I'd suggest the descr: field to be in the poetic form itself. > > > poetic-form: VERSE-LIMERICK > desr: The object consists of a verse > in a format that is far from terse > a-a-b-b-a scheme > around a humorous theme > and is sometimes extremely perverse > > 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: The haiku object > only seven syllables > in its density > admin-c: HIKU1-RIPE > tech-c: HIKU1-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20040401 > source: RIPE > > > Looking at the VERSE-SONNET we may have a problem. There are several > subclasses that people may wish to use. The Italian Sonnet, The > English Sonnet and more modern varieties. How do we indicate possible > sub-classes in the object? > > poetic-form: VERSE-SONNET > variety: ENGLISH > descr: (Somebody needs to write an English Sonnet) I'm happy to take an action to write an English Sonnet > poetic-form: VERSE-SONNET > variety: ITALIAN > descr: (Somebody needs to write an Italian Sonnet) -- 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

1 0

RE: [db-wg] proposal: haiku object
by TAYON, Julien 11 Mar '04

11 Mar '04

Olaf M. Kolkman <mailto:olaf@ripe.net> wrote: > I'd suggest the descr: field to be in the poetic form itself. > > > poetic-form: VERSE-LIMERICK > desr: The object consists of a verse > in a format that is far from terse > a-a-b-b-a scheme > around a humorous theme > and is sometimes extremely perverse > > 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: The haiku object > only seven syllables > in its density > admin-c: HIKU1-RIPE > tech-c: HIKU1-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20040401 > source: RIPE > poetic-form: PROSE descr: Don't let the structure tie your tongue ; if you hate the masochism of verses, remember that you can feel free to use prose, and feel free because you are. admin-c: LIM1-RIPE tech-c: LIM1-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040401 source: RIPE

2 1

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

11 Mar '04

Robert S. Plaul wrote: > On Wed, 10 Mar 2004, Titley, Nigel wrote: > >> All poems are limericks, true. >> There are no need for objects haiku >> This thread is amusing >> It set us all musing >> But we plainly have little to do >> >> Nigel > > The RIPE Database > Guardian of the limericks > Now needs the haiku > > The haiku object - > Greater flexibility > The virtue is clear 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? 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] proposal: haiku object
by TAYON, Julien 10 Mar '04

10 Mar '04

Titley, Nigel <mailto:NTitley@flagtelecom.com> wrote: > And I, as usual, having sent the email, and gone off to make a cup of > tea, realised that there was a humorous interpretation of your > reply..... > Pssst RTFM (RFC 1855) Regarding Mailing lists it is written : - Remember that the recipient is a human being whose culture, language, and humor have different points of reference from your own. Remember that date formats, measurements, and idioms may not travel well. Be especially careful with sarcasm. Therefore remember to be deadly serious. PS is it possible to have a web page with all limmericks from the RIPE whois DB ? PPS march the 31st +-1 day is a good day for a RFC :) Jul

1 0

RE: [db-wg] proposal: haiku object
by TAYON, Julien 10 Mar '04

10 Mar '04

>> All poems are limericks, true. >> There are no need for objects haiku >> This thread is amusing >> It set us all musing >> But we plainly have little to do >> >> Nigel > > The RIPE Database > Guardian of the limericks > Now needs the haiku > > The haiku object - > Greater flexibility > The virtue is clear > > Robert Without Haiku, I pity that all verses are lame. Still, this thread is fun for a flame, misunderstanding is to blame it is all the same ... with poems Julien

1 0

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

10 Mar '04

Robert S. Plaul wrote: > On Tue, 9 Mar 2004, Poul-Henning Kamp wrote: > >> I can only say that I find it extremely unsporty that have not made >> the case for this new database object in haiku form then... > > That's because I first tried it in limerick form. These tries were so > exhausting (because of the restrictions of the limerick I described > before), that I did't even had the nerves to write haikus... Well, being a fan of the limerick form, as my previous posting has made clear, I present my argument in limerick form ;-) All poems are limericks, true. There are no need for objects haiku This thread is amusing It set us all musing But we plainly have little to do 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 09 Mar '04

09 Mar '04

Now I can certainly agree that March 31st + 1 would be a good day for an RFC As regards the web page, suggest you ask Bert's secretary. Titley, Nigel < mailto:NTitley@flagtelecom.com <mailto:NTitley@flagtelecom.com> > wrote: > And I, as usual, having sent the email, and gone off to make a cup of > tea, realised that there was a humorous interpretation of your > reply..... > Pssst RTFM (RFC 1855) Regarding Mailing lists it is written : - Remember that the recipient is a human being whose culture, language, and humor have different points of reference from your own. Remember that date formats, measurements, and idioms may not travel well. Be especially careful with sarcasm. Therefore remember to be deadly serious. PS is it possible to have a web page with all limmericks from the RIPE whois DB ? PPS march the 31st +-1 day is a good day for a RFC :) Jul ********************************************************************** 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

4 4

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

08 Mar '04

And I, as usual, having sent the email, and gone off to make a cup of tea, realised that there was a humorous interpretation of your reply..... Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 -----Original Message----- From: Robert S. Plaul [mailto:robert@plaul.de] Sent: 08 March 2004 15:49 To: db-wg(a)ripe.net Subject: RE: [db-wg] proposal: haiku object On Mon, 8 Mar 2004, Titley, Nigel wrote: > Anyone with even a meagre grasp of English should have been able to realise > that my response was intended humorously..... sigh.... no matter Sure. I possibly forgot to put some smilies in my answer. :) Robert > Nigel -- RSP-RIPE ********************************************************************** 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] proposal: haiku object
by Titley, Nigel 08 Mar '04

08 Mar '04

Robert S. Plaul wrote: > On Mon, 8 Mar 2004, Titley, Nigel wrote: > >> Whilst agreeing that the limerick is possibly restricted in its >> metrical form, I cannot agree with the statement that it is >> restricted to humorous subjects, and hence at least one of the >> objections to its general use is fallacious. > > $ whois -v limerick > [...] > The limerick class: > > The limerick object represents a humorous poem that has five > lines and the rhyme scheme "aabba". > [...] > text > > Text of the limerick. Must be humorous, but not malicious or > insulting. > [...] > > Although IMHO the limerick _is_ considered a humorous poem in > literature, the limerick object is not. > >> My solution to the lack of alternative metrical objects would simply >> be to redefine all poetry as limericks. > > I think, this is a poor solution. Haikus (and Sonnets, etc. > respectively) are no limericks and never will be. Do you want the > whole world to laugh about the RIPE NCC for not knowing what a > limerick is? > >> Also it has the merit of offering increased >> employment opportunities for poets, who would see their services >> called upon to rewrite all existing poetry in the limerick form. > > Sometimes. Maybe. But not every haiku can be rewritten into a > limerick. Sometimes a haiku can say more than a thousand words. > >> Nigel > > Robert Anyone with even a meagre grasp of English should have been able to realise that my response was intended humorously..... sigh.... no matter 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 08 Mar '04

08 Mar '04

Whilst agreeing that the limerick is possibly restricted in its metrical form, I cannot agree with the statement that it is restricted to humorous subjects, and hence at least one of the objections to its general use is fallacious. That the metrical scheme has considerable flexibility is illustrated by the many examples received by the secret Working Group which do not conform to this supposed limitation. My solution to the lack of alternative metrical objects would simply be to redefine all poetry as limericks. I feel that this would be a far more acceptable solution, and also involves less work for the RIPE NCC. Also it has the merit of offering increased employment opportunities for poets, who would see their services called upon to rewrite all existing poetry in the limerick form. 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 Wilfried Woeber, UniVie/ACOnet 08 Mar '04

08 Mar '04

>I can fully understand, that you prefer a more generic solution. However, >the remarks: field idea is IMHO not a very good solution. Just read the >mails in the abuse-c threads about abuse contact information in remark: >fields of inet(6)num objects... I agree, this is a very important aspect, and we should get it right this time!! >One advantage of my haiku object is, that its definition is - more or >less - a copy of existing limerick object. Again, a very important aspect: limit the impact on the large number of scripts which have to parse these objects on a regular basis! >The whois client as PIM application. I'm curious, what the database >administration is going to say about that... May I humbly suggest that the proponents of such an object come back with a draft write-up (ripe document format preferred) by 31 of March (maybe -0/+1 day :-)? This would allow scheduling a discussion topic for the May meeting in the DB-WG. Cordially, (your WG Chair) _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the street finds its own use for technology...

1 0

RE: [db-wg] proposal: haiku object
by TAYON, Julien 08 Mar '04

08 Mar '04

Robert S. Plaul <mailto:robert@plaul.de> wrote: > Proposal for Adding a Haiku Object to the RIPE Database > > Requirement: > > System Administrators and other users of the RIPE Database need some > avocation beside their exhausting work with ip address space > assignments, routing and other occupations concerning database > objects which have to be taken seriously. The existing limerick > object provides such avocation but obviously has some limitations: > [...] > > Solution: > ... Even Though I fully agree with the need for a haiku object, because I am not sure of my limmericks (LIM-ROSE LIM-FRIENDS LIM-STRESS) I don't think the creation of an haiku object -per se- might be the solution. Mayhaps can we reuse the limerick objects and use the remarks field with one of the possible value : HAIKU, for haiku SONNET for such PROSE for freestyle poetry .... Therefore not only would we satisfy : - sysadmin that like well labelled object for easier retrieval, - poets for increasing their potentiality, - RIPE dba for not chaging the actual object. And if an object was to be created I would propose on the model of limerick object whois -t poem poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] type: [mandatory] [single] [ ] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Where type would be one of the folllowing : LIMERICK, PROSE, QUATRAIN, SONNET, HAIKU, ASCII-ART ... Such a solution would broadly sataisfy any sysadmin wanting to express his art freely. For managers I would propose a MEMO object too. Because, the whois DB might be the fully legitimate place for such a thing, the last place where you are gonna search for such an abomination. ;) Regards, Julien Tayon

3 2

proposal: haiku object
by Robert S. Plaul 08 Mar '04

08 Mar '04

Proposal for Adding a Haiku Object to the RIPE Database Requirement: System Administrators and other users of the RIPE Database need some avocation beside their exhausting work with ip address space assignments, routing and other occupations concerning database objects which have to be taken seriously. The existing limerick object provides such avocation but obviously has some limitations: - The limerick has to have a fixed aabba rhyme scheme which restricts the creative genius of the author in an inadequate manner. It has to be admitted that this restriction can be considered as a challenge, but for spontaneous poetical outbreaks the fixed specifications and the great length of five lines are more debilitating than inspiring. - The limerick has to be humorous. While there is nothing wrong about funny poems, there are always moments in a System Administrators' life, when there is just not the need for jokes. Deeper insights into the meaning of life and other more or less important things are said to have come to people's minds while working with internet protocols. These insights should be given the opportunity to be put into a poetic form and as such into the RIPE database for the enlightenment of like-minded people. - Even System Administrators and other users of the RIPE Database need some variety, at least when writing poems. There is a need for another poem object beside the existing limerick object. Solution: The haiku ist a traditional Japanese poetic form without the restrictions of the limerick described before. It has no rhyme scheme and no measure encumbering the author. The only formal requirement (which is not even mandatory) is the segmentation into three lines of 5, 7 and 5 units each, which are usually understood as syllables in languages other than Japanese. Haikus don't have to be humorous, in fact the traditional Japanese haiku is not humorous at all.[1] Haikus have attracted attention in the IT world already some time ago. Mentionable appearances include the Salon Magazines's Haiku Error Message Contest[2] and the ActiveState Perl Haiku Contest[3]. Although there are also voices condemning the joke haiku (and proposing the limerick as an adequate poetic form)[4], the old Japanese poem still has its right to exist, even and particularly in the world of computer professionals. People occupied with servers, routing and internet protocols at large tend to have an own kind of humor not comparable to the stupid corny jokes told in the world outside. Besides the humorous aspects of computer adminstration, the haiku empowers computer professionals to turn their insights into other aspects of computer adminstration or even life to poetry. The haiku object as described below gives System Administrators and other users of the RIPE Database the opportunity to share their thoughts and feelings put into haikus with like-minded people. [1] http://en.wikipedia.org/wiki/Haiku [2] http://archive.salon.com/21st/chal/1998/02/10chal2.html [3] http://aspn.activestate.com/ASPN/Perl/Haiku/ [4] http://www.phenry.org/junkdrawer/haiku/ The haiku class: The 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. haiku: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] 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 content of the attributes of the haiku class are defined below: haiku Specifies the title of the haiku. HK-<string> <string> can include alphanumeric characters, and "_" and "-" characters. descr A short decription related to the object. A sequence of ASCII characters. text Text of the haiku. There are no fixed rules about the subject or form of the haiku although there are some traditional conventions. Further information about this Japanese poetic form can be found at <http://en.wikipedia.org/wiki/Haiku>. A sequence of ASCII characters. admin-c References an on-site administrative contact. From 2 to 4 characters optionally followed by up to 5 digits optionally followed by a source specification. The first digit must not be "0". Source specification starts with "-" followed by source name up to 9-character length. author References a haiku author. From 2 to 4 characters optionally followed by up to 5 digits optionally followed by a source specification. The first digit must not be "0". Source specification starts with "-" followed by source name up to 9-character length. remarks Contains remarks. A sequence of ASCII characters. notify Specifies the e-mail address to which notifications of changes to an object should be sent. An e-mail address as defined in RFC 2822. mnt-by Specifies the identifier of a registered mntner object used for authorisation of operations performed with the object that contains this attribute. Made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names: any as-any rs-any peeras and or not atomic from to at action accept announce except refine networks into inbound outbound Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names. Names starting with "irt-" are reserved for irt names. Names starting with "lim-" and "hk-" are reserved for limericks and haikus respectively. changed Specifies who submitted the update, and when the object was updated. An e-mail address as defined in RFC 2822, followed by a date in the format YYYYMMDD. source Specifies the registry where the object is registered. Should be "RIPE" for the RIPE Database. Made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a registry name must be a letter, and the last character of a registry name must be a letter or a digit. -- RSP-RIPE

3 3

FYI: Cleanup of domain objects.
by Olaf M. Kolkman 04 Mar '04

04 Mar '04

Dear Colleagues, Excuxes for the duplicate messages. During the third week of March we will perform the cleanup as described in section B of the "Domain Cleanup Proposal"[1]. Users affected by this cleanup were contacted during the first week of January 2004[2]. Once the domain object cleanup has been finished, the RIPE NCC provisioning system will be migrated to generate reverse zones from the whois database. We will proceed with that around the last week of March 2004. This change should be transparent. A small notification will be sent to the dns-wg mailing list. The next step of the RDNS project [3] will be the introduction of the "mnt-domain:" attribute. More information about this introduction will be sent to the ncc-services-wg and dns-wg mailing lists by the end of March 2004. Please reply to me in private or to the <dns-wg(a)ripe.net> mailing list if you have any questions or comments. --Olaf Kolkman New Projects RIPE NCC [1] http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html [2] The set of people contacted was larger than the set of people actually affected by the cleanup see http://www.ripe.net/ripe/mail-archives/db-wg/2004/msg00086.html for details. [3] http://www.ripe.net/reverse/rdns-project/

1 0

Minutes for DB WG RIPE 47
by Titley, Nigel 02 Mar '04

02 Mar '04

Folks, Please find attached the final minutes for the DB WG session. All comments received (thanks Leo), have been folded in. 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

1 0

Subnet administration
by Carl Smith 25 Feb '04

25 Feb '04

Hi, Im not sure if this is the right mailinglist for it .. if not sorry for posting it here. We are looking for a way to administer several subnets within our company. We use the 10.0.0.0 block and need to convert this from our excel sheets into something more manageable. What we need is to be able to do is VLAN (number and remark) fixed addresses/DHCP (per address two remarks) subnet (subnets from /16 til /30) Thanks for any advice ! Regards, Carl _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0