- db-wg - mailman.ripe.net

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

rpsl to arin format conversion
by terry l. ridder 23 Feb '04

23 Feb '04

hello; i am doing some research on the rir databases. for my purposes having all data in, what i call 'arin' format, would be the simplest for processing. are there any software utilities available for converting from rpsl to 'arin' format? if no software utilities are available is there a mapping description available from rpsl to 'arin' format? -- terry l. ridder ><>

2 4

RPSLng Deployment
by Tim Streater 23 Feb '04

23 Feb '04

Dear All, I was not at the recent RIPE Mtg and so may be behind the curve. I have been trying to see what is the status of the deployment of RPSLng, and testing the tools. My simple test worked OK, but I can't do more without having more objects to test against. These would need to be inserted by others. There was some traffic on the RPSLng list during the autumn, and near as I can make out there is still some dispute about some details of the syntax; I am not able to contribute meaningfully to that debate. I do note that the contentious items appeared to relate to the aut-num object. It seems to me we need: 1) Agreement 2) Deployment 3) Population 4) and for us, JunOS support The production database contains inet6num: objects. It does not contain or support route6: objects. Is anything in dispute about the route6: object? If not, could the production server be updated to support it, as a step forward. This would allow organisations to enter their route6: objects, and more extensive testing could then be done against these, using -f to keep the aut-num local. This would allow a bit of (2) and (3) in advance of complete (1). It would focus people's minds a bit. At present I have no lever to get customers to do (3) when any route6: objects they enter can only be in the test db. At the moment it feels like everyone is waiting for everyone else :-) Is this justified or am I completely at sea? Cheers, -- Tim

2 1

Organisation object timeline
by Engin Gunduz 18 Feb '04

18 Feb '04

Dear Colleagues, [apologies for duplicate mails] Please find below the timeline for deployment of organisation object in the RIPE Whois Database. You can find the latest organisation object proposal at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00689.html For questions and comments please contact me at <engin(a)ripe.net>. Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department ================================ Timeline for Organisation Object ================================ 11 March 2004 Thursday : Pre-release of whois software with organisation object capability. (for tests by external parties, LIRs) 17 April 2004 Saturday : Deployment of whois software with organisation object capability. Creation of organisation objects for existing LIRs, update of existing allocation inetnums and inet6nums. 19 April 2004 Monday : The RIPE NCC starts using the new request forms updated for organisation object.

1 0

RE: [db-wg] rpsl to arin format conversion
by Wilfried Woeber, UniVie/ACOnet 17 Feb '04

17 Feb '04

>are there any software utilities available for converting from rpsl to >'arin' format? Sorry, I don't have an answer, but rather a question: why don"t you try to do it "the other way 'round", as RPSL is properly described in an RFC? Wilfried. _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 3

RE: [db-wg] rpsl to arin format conversion
by Tim Streater 17 Feb '04

17 Feb '04

At 15:50 17/02/2004, Terry Ridder wrote: >On Tue, 17 Feb 2004, Wilfried Woeber wrote: > >> >are there any software utilities available for converting from rpsl to >> >'arin' format? >> >> Sorry, I don't have an answer, but rather a question: >> >> why don"t you try to do it "the other way 'round", >> as RPSL is properly described in an RFC? >> >> Wilfried. >> > >arin's db contains the most records. > >logically, it makes sense to convert the other rir dbs to arin format. > >also converting from arin to rpsl would lose information which exists in >arin's db. Examples please, both syntax and semantics. >those helping with the research have a better understanding of arin >format than rpsl. > >-- >terry l. ridder ><> Cheers, ___________________________________________________________________ * * Tim Streater Network Engineer * * * Francis House * 112 Hills Road Tel +44 1223 302992 * Cambridge CB2 1PQ Fax +44 1223 303005 D A N T E United Kingdom WWW http://www.dante.net ____________________________________________________________________

2 1

[off-topic] fwd: SMTP delivery error [was: rpsl to arin format conversion]
by Wilfried Woeber, UniVie/ACOnet 17 Feb '04

17 Feb '04

Just fyi ...the following is cute, I think. I didn't want to hide it from you all. Look at the "-Rcvd: 550" line ;-) Cheers, Wilfried. ______________________________________________________________________ Date: Tue, 17 Feb 2004 15:07:32 +0100 From: SMTP delivery agent <Postmaster(a)cc.univie.ac.at> To: <woeber(a)cc.univie.ac.at> Subject: SMTP delivery error Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: terrylr(a)blauedonau.com Error-Code: 3 Error-Text: %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable -(Via blauedonau.com) -Transcript: -Rcvd: 220-strauss.blauedonau.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 17 Feb 2004 08:07:31 -0600 -Rcvd: 220-blauedonau.com runs a whitelist mail server. -Rcvd: 220 spam and network abuse are not tolerated. -Sent: HELO access.cc.univie.ac.at -Rcvd: 250 strauss.blauedonau.com Hello access.cc.univie.ac.at [192.153.174.2], pleased to meet you -Sent: MAIL FROM:<woeber(a)cc.univie.ac.at> -Rcvd: 550 5.7.1 Austria blocked on account of spam and network abuse. Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ [ removed ]

2 1

Proposed change 2004.1: extended route creation rules
by Engin Gunduz 16 Feb '04

16 Feb '04

Dear colleagues, [apologies for duplicate mails] Some time ago, Frank brought an issue regarding route object aggregation to our attention in the DB-WG mailing list. Please see the short thread at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html We have prepared a proposal to extend the route object creation rules to resolve this issue. However, the resulting proposal turns out to be quite complex as it builds on the current route object creation rules, which are already complex enough. Considering that the need for route object aggregation is encountered very rarely, it might not be worth implementing it. After the deployment of version 3 of our whois software, we have seen only a couple of such cases. In those cases, we have resolved the issue by applying the rules that we specify below manually. I would like to ask the working groups if they think this proposal is too complex. Implementing it would not be a problem technically, but I'm more concerned about explaining the complex rules properly to the users of the whois database. Best regards, and thanks for your time, -- Engin Gunduz RIPE NCC Software Engineering Department ============================================================= A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES This document is about being able to create route objects that aggregate inetnums/route objects. This is needed where a user cannot merge two or more inetnum objects into one larger inetnum object, but still needs to create a route object that aggregates these inetnum objects. This is seen especially with assigned PI inetnum objects. A hypothetical example: Suppose there exist the following two inetnums in the whois database: inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI These are assigned to different end-users. Further suppose that they coincidentally take service from the same Internet Service Provider. The Internet Service Provider will want to aggregate these two assignments into a single 12.0.0.0/23 route to be announced, rather than announcing two separate prefixes, in order to keep the number of prefixes in routing tables to the minimum. However, the Internet Provider will not be able to create a single route object in the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This is because the inetnum object that contains the 12.0.0.0/23 prefix will be inetnum: 12.0.0.0 - 12.9.255.255 netname: EU-ZZ-000000 descr: block for PI assignments descr: maintained by RIPE NCC country: EU remarks: These addresses are assigned to network operators. The RIPE NCC does not operate any networks using address space from this block. An explanation of how to find the correct contacts is available at <http://www.ripe.net/nicdb.html> admin-c: CREW-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster(a)ripe.net 20030731 source: RIPE Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for a graphical representation of the current route object creation rules. Proposal: To address this problem, we need to extend the route object creation rules so that it would be possible to create a route object that takes its authorisation from a collection of route and/or inetnum objects that are more specific than the route object to be created. As the situation is quite rare, the 'extended' behaviour can be activated by using the keyword 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or with the syncupdates. The extended behaviour is not the default behaviour. The Algorithm: The proposed algorithm to authorise the route object creation is: Check if the keyword was used. If not, proceed with normal route creation rules as described in RFC2725 (http://www.ripe.net/ripencc/faq/database/qa4.html#5) Check if there is an exact match route object or an exact match inetnum object If there is one, then proceed with normal route creation rules even if the keyword was specified. Find the inetnums/routes that can be used for route creation: Get a list of all inetnums and route objects that are one level more specific than the route object to be created. (-r -Troute,inetnum -m <prefix>) From this list, eliminate the inetnums that have exact match or less specific route objects. (Note: During route object creation, the existing route objects take precedence over existing inetnum objects). Check if the resulting set of inetnums/routes cover the whole space of the route to be created. If not, authorisation fails, hence creation attempt fails. Collect the mntners to be used during the authorisation check. Follow these rules: For each object in the set, check if there are "mnt-routes:" attributes in the object. If there are, they will be used. If there are not, the mntners that are mentioned in "mnt-by:" attributes will be used. Check the authorisation: During the authorisation, the mntners in the same object will be ORed, while the mntners in separate objects will be ANDed. Example 1: Suppose we have these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 status: ALLOCATED PI mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 netname: EXAMPLE-PI descr: Example Banking PLC admin-c: AA1-RIPE status: ASSIGNED PI mnt-by: MNT-EXAMPLE-PI inetnum: 12.0.1.0 - 12.0.1.255 netname: ANOTHER-EXAMPLE-PI descr: Anotherexample Printing Industries NV admin-c: ZZ1-RIPE status: ASSIGNED PI mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 There is also this aut-num object: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES There are no route objects that are in 12.0.0.0/23 space, or less specific of 12.0.0.0/23. The user wants to create the following route object: route: 12.0.0.0/23 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: RIPE-NCC-HM-MNT". As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 - there are no inetnums to be eliminated from the list. - the resulting set of inetnums/routes (it actually has two inetnums and no routes) covers the whole space of 12.0.0.0/23. - collect the mntners to be used in the authorisation process. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-EXAMPLE-PI AND (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" must be used. 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be used, but they must be ORed. - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( MNT-EXAMPLE-PI AND ( MNT-ANOTHEREXAMPLE-MNT-ROUTES OR MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 ) ) ) Example 2: Suppose there are these inetnums in the database: inetnum: 0.0.0.0 - 255.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT inetnum: 12.0.0.0 - 12.255.255.255 mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT inetnum: 12.0.0.0 - 12.0.0.255 mnt-routes: MNT-INETNUM-1 inetnum: 12.0.1.0 - 12.0.1.255 mnt-routes: MNT-INETNUM-2 and the following route objects: route: 12.0.1.0/24 origin: AS65534 mnt-routes: MNT-ROUTE-1 route: 12.0.2.0/23 origin: AS6 mnt-routes: MNT-ROUTE-2 route: 12.0.2.0/23 origin: AS65534 mnt-routes: MNT-ROUTE-3 mnt-routes: MNT-ROUTE-4 and this aut-num: aut-num: AS65534 mnt-by: MNT-AUT-NUM-MNT-BY mnt-routes: MNT-AUT-NUM-MNT-ROUTES The user wants to create the following route object: route: 12.0.0.0/22 origin: AS65534 mnt-by: MNT-ROUTE When the creation is attempted without the keyword 'EXTENDED-ROUTE-CREATION,' the whois software will try to get the IP space authentication from inetnums, as no related route object exists. The one level less specific inetnum is 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" attribute. As the user does not have access to the authorisation for RIPE-NCC-HM-MNT mntner, the creation attempt will fail. When the creation is attempted with the keyword 'EXTENDED-ROUTE-CREATION': - There are no exact match route or inetnum objects, so proceed with extended route creation rules. - to get the authorisation from IP space, the whois software will perform '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return inetnum: 12.0.0.0 - 12.0.0.255 inetnum: 12.0.1.0 - 12.0.1.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - eliminate the inetnums with less specific or exact match route objects in the list. The resulting list will be: inetnum: 12.0.0.0 - 12.0.0.255 route: 12.0.1.0/24 route: 12.0.2.0/23 (origin AS6) route: 12.0.2.0/23 (origin AS65534) - the resulting list covers the whole 12.0.0.0/22 space. Continue. - Collect the mntners to be used during the authorisation check. from the aut-num: MNT-AUT-NUM-MNT-ROUTES from the route object itself that will be created: MNT-ROUTE from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4))) - the resulting mntner list: ( MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND ( ( MNT-INETNUM-1 AND MNT-ROUTE-1 AND ( MNT-ROUTE-2 AND ( MNT-ROUTE-3 OR MNT-ROUTE-4 ) ) ) ) )

3 5

Re: abuse-c: proposal
by Niall O'Reilly 10 Feb '04

10 Feb '04

Comments in context below ... On 6 Feb 2004, at 14:31, Randy Bush wrote: >> Attribute name >> Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail' > > since it should be a handle, which allows me to even get to > a <gasp!> phone number, calling it mail-anything seems a > mis-direction. since all the rest are of the form <foo>-c:, > do we have to invent something new? Yes, we do. A number of ppl (MarcoH, dfk), in different ways, and for divers reasons, have made it clear that we need a new attribute to carry as its value (yes, I do mean RHS) the e-mail address where abuse notifications should be sent. Marco explained this particularly well; The following example is an attempt to illustrate his point. Running whois -h whois.ripe.net 137.43.0.0 | \ perl -ne 'next unless /@/; ($addr) = grep /@/, split; print "$addr\n"' gives a bunch of addresses, which will probably ALL be used by your generic cheap-n-cheerful, save-the-world-from-SPAM robot. [ Hmm.. look at those victims! Must try to spread the load even wider! 8-) ] We aim to make it easy for everyone; the following should be nearly enough. whois -h whois.ripe.net 137.43.0.0 | \ awk '/^abuse-mailbox:/ {print $2}' > >> Handle >> Handle is upwardly scalable >> Handle could refer to person, role, or maintainer > > yep > >> Value >> Value is necessary; if not in primary object, then indirectly >> Value in primary object is attractive at low end of scale >> Value is vulnerable to RHS-hijacking, even if not in primary object! > > do not understand. do you mean the value (right hand side) > of the abuse-c: attribute? or are we sending cash? :-) [ I'll happily receive cash. 8-) ] I mean the RHS of the abuse-mailbox: attribute. This attribute MAY be specified in the primary (inet*num or such) object, but for scalability belongs in the object whose handle is on the RHS of a *-c: or mnt-by: attribute. [ Hmm.. *-c, *-by, *-fly 8-) ] As dfk has pointed out, we can get by without abuse-c: if we focus on taking advantage of _existing_ person/role/mntner objects linked by *-c: or mnt-by: and just use abuse-mailbox:. <p loaded-with="irony" remark="In case it's not obvious"> This is the speedy-deployment option, so I'm sure we won't want to use it! </p> IHTH TGIF /NO8

8 27

(no subject)
by Wilfried Woeber, UniVie/ACOnet 10 Feb '04

10 Feb '04

>> Creating irt objects is not any harder than creating a new maintainer, >> maybe the documentation should focus more on this and less on marketing >> the TI concept (which apparently only NRENs care about). > >First problem with IRT is that in order for it to have any value every LIR >has to actively modify ALL their inetnum objects......... Now that must mean >that the intention has never been to make sure all LIRs implement it. Sorry, but this just wrong. It is exactly one of the advantages (of course you might want to have a different point of view :-) that modifying 1 (or a very small number of) object(s) would be sufficient - as long as we are talking hierarchical (i.e. LIR) address space. Tagging the _allocation_ object of an LIR would cover _all_ the _assignment_ objects in that block. With the added benefit that you can still have a "more specific" or 1st-line pointer in an assignment object. >Next problem is the idea behind IRT, apparently it is to be used by >companies who outsource handling of abuse - we don't. Out-sourcing would be supported, but it is a secondary issue. The primary issue is that it allows maintaining the data by the group being responsible for a certain function. There are real life situations where the role/group/team keeping track of address assignments is _different_ from the role/group/team being responsible for abuse or incident handling. If I should use this >object it should have a normal mnt-by attribute and the following fields >either removed or made optional: address, signature, encryption, auth. > >I can appriciate the need for the features of the IRT object, but WHY can't >the rest of us get a working solution to our problem? "You" (actually we ;-) can certainly get a solution, as soon as there is rough consensus in the WG that the approach proposed is _probably_ going to work and has a reasonable "price tag" (i.e. the implementation effort). > It doesn't necessarily >mean that we can't preserve the features of the IRT. > > > >Med venlig hilsen/Best regards > >Christian Rasmussen >Hosting manager, jay.net a/s > >Smedeland 32, 2600 Glostrup, Denmark > >Email: noc(a)jay.net >Personal email: chr(a)corp.jay.net >Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 > >Produkter / Products: >http://hosting.jay.net -------------------------------------------------------------------------------- Wilfried.

3 2

RE: [db-wg] Re: abuse-c: proposal
by TAYON, Julien 09 Feb '04

09 Feb '04

MarcoH <mailto:marcoh@marcoh.net> wrote: > On Mon, Feb 09, 2004 at 03:25:12PM +0100, Marco d'Itri wrote: [...] > > To provide such a behaviour, we need to store the information somewhere in > the database and free-form remarks or a more generic e-mail attribute is > IMHO not the way. I have been caught in a story of alledged spam with an end-user customer and my experience is that ISP abuse team is at the crossroad between - lawyer (commercial and penal one), - wannabe hacker (coders with good programming skills and poor comprehension of the universe ;) - end-user customer that want bad guy punished and their mails delivered (especially the unsollicited one they send), - anti and pro spam lobby wich abhores one another What I understood is abuse / IP problems are mostly resolved if you teach / inform / communicate correctly. As the situation is already quite confusing and complicated I definitively want a Keep It Simple Stupid solution. IMHO abuse-c: field wich is a valid email is Simple & Stutid (aka what I need) : as a proof of concept I can successfully "sell" it today in my company to the marketing department :) Regards, Julien Tayon 9T

1 0

c-client lib?
by Randy Bush 09 Feb '04

09 Feb '04

building on a new machine. freebsd 5.2-current. have never built on 5.x before. # ./build.sh --prefix=/usr/home/whois checking build system type... i386-unknown-freebsd5.2 checking host system type... i386-unknown-freebsd5.2 checking for /usr/local/bin/glib-config... yes checking for /usr/local/include/mysql/mysql.h... yes checking for /usr/local/lib/mysql/libmysqlclient_r.so... yes checking for /usr/local/bin/mysql... yes checking for /usr/local/bin/xslt-config... yes checking for /usr/local/bin/xml2-config... yes checking for /usr/local/src/mail/imap-2001.RELEASE-CANDIDATE.1/c-client/mail.h... yes checking for /usr/local/src/mail/imap-2001.RELEASE-CANDIDATE.1/c-client/c-client.a... yes checking for /usr/local/bin/gpg... yes checking for gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables Configure failed. Exiting\n any hints? # gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 # cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 randy

2 1

Re: [db-wg] Re: abuse-c: proposal
by Niall O'Reilly 07 Feb '04

07 Feb '04

On 7 Feb 2004, at 04:43, Randy Bush wrote (privately): > how little can we do > and get the result I think a truly minimalist approach would be to add the abuse-mailbox: attribute, with an e-mail address on RHS and an optional hint string on far-RHS beyond the '#', to the existing person, role, and mntner objects only. This would provide a means for operators/sysadmins to advertise 'effectively'. They are not doing this at present because IRT is (perceived as) too complex, and 'remarks:' is easier. MarcoH's statistics (as I recall) show on the order of 900k objects, 100k with remarks pointing to abuse contacts, and about 1k with IRT's set up. Adding one optional attribute to the three objects mentioned has the following advantages: the new attribute name signals its specific semantics; no new object is required; no new cross-checking between objects is required; no new RHS systax-checking is required (syntax is as for 'e-mail:'); deployment is optional; deployment scales per-contact, not per-network; the motivation (whatever it is) for overloading the 'remarks:' attribute is undermined; and use of the new attribute is simple, both for operators and for tool writers. The chief disadvantage is that the motivation for using IRT is undermined. Since IRT uptake is about 0.1%, and going nowhere fast, this is something I can live with. Niall O'Reilly

2 1