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

(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

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

06 Feb '04

On 6 Feb 2004, at 17:18, Randy Bush wrote: > not when you are using it as a reason to affect decisions in > this discussion, i.e. allowing email addresses in abuse-c: Not me! Something must have gotten lost in translation. My picture is that the RHS of abuse-c: is a handle, while the RHS of abuse-mailbox: is an RFC822 addr-spec. Niall

1 0

Re: [db-wg] Re: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

Niall, I'd like to add one line... >We're trying for something with the following characteristics: > > something new and specifically focused, to avoid existing baggage; > simplicity for sysadmins; > simplicity for robot-builders; > a simple message for marketing/evangelism. [ and doesn't break concepts or tools which are there already ] >Niall Could you agree to that? Wilfried.

3 2

Re: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

>not when you are using it as a reason to affect decisions in >this discussion, i.e. allowing email addresses in abuse-c: > >randy Assuming that we build the abuse[xyz], I'd suggest to use abuse-c: if we want to use a pointer, i.e. a handle. This preserves DB conventions. From my point of view there is a pro and a con in allowing an email address directly in a dedicated attribute (whatever its name): - pro: . it saves a couple of lines in a robot script, and it gets displayed irrespective of the querying tool or path . but at the same time it would not support hierarchy or tree-walk towards the encompassing address block objects - con: . it runs against a concept we tried to adhere to in designing the schemas for objects: "don't try to put attributes into the same object, for which the values will be maintained by different entities". Putting an email address directly into the "primary" objects would be such a case. The inet*num objects are the responsibility of the LIRs, maintaining (at least most specific) abuse contact information would be the responsibility of the end site (or direct up-stream connectivity provider). In many cases those are different entities. Wilfried.

1 0

Draft Minutes for DB-WG Ripe 47
by Titley, Nigel 06 Feb '04

06 Feb '04

Gentlefolk, Please find attached Draft minutes for the recent DB Working group meeting at RIPE 47. Comments please. Best regards Nigel ********************************************************************** 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. 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: abuse-c: proposal
by Wilfried Woeber, UniVie/ACOnet 06 Feb '04

06 Feb '04

>Perhaps, but that's another discussion. >Let's put that on the WIBNI list and stay focused. > >Niall > >On 6 Feb 2004, at 16:06, Randy Bush wrote: > >> perhaps instead of adding another address they can call, we >> should allow changed: and notify: to be nic-handles:. notify:, upd-to: and maybe one or too more are defined as email addresses. I don't see a good reason to get those changed. Both are used to manage successful or unsuccessful database updates. Different purpose. The changed is a sort of "weird" attribute anyway. It has been under discussion a few times, but no definite result as yet. AFAIK the NCC's hostmasters use it (the date part) for some sort of internal sanity checking of assignment transaction. I agree here: out of scope for this discussion. Wilfried.

1 0

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

06 Feb '04

It's been very quiet on the list since the frantic activity at the end of last week. I expect day-to-day reality has imposed itself. I've done some further thinking, and have reviewed the contributions last week on the db-wg list. I've tried to recognize the issues and alternatives in this message and to make proposals as straw-men for consensus. I've used a bullet-point approach, as I think no-one is likely to have time to read anything more discursive. I'll happily explain anything that people find too terse. Here goes ... Attribute name Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail' Handle Handle is upwardly scalable Handle could refer to person, role, or maintainer 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! Hint string Trailing #-comment is easiest RFC822 parens-comment as part of value is possible Qualifier to attribute name would be neat, but may be difficult to implement (eg: abuse-mailbox-{spam,security}) Proposal (1) Advertisement (sysadmin) side Use two attributes: one to hold value, the other to hold handle Use attribute 'abuse-mailbox' to hold value Use attribute name 'abuse-c' to hold indirect object handle Allow use of 'abuse-mailbox' attribute in primary object Encourage use of attribute in indirect object as best practice Support all relevant indirect objects (person, role, maintainer) in order to make it easy for sysadmins We REALLY WANT sysadmins to ADOPT this (NAFS: no apol for shout) Inheritance Implemented in query tool: design and coding resource impact Must be 'intuitive' for advertising sysadmin Two axes: by reference to handle; by containing block Priority: by reference first, but ... Proposal (2) Query side algorithm Specifies behaviour of focused query tool Sysadmins must take account when advertising in order to align query result with their intent Needs discussion: Concept Implementation: cost to implement, performance, possible pruning of search tree Given object (from inet*num, asnum, ...) and circumstances To identify appropriate abuse contact Find contact set for given object Include tech-c.email value for given object if set is empty Discard members of set unless circumstances match hint Return survivor(s) To find contact set Start with empty set Add all abuse-mailbox values found in current object While set still empty visit abuse-c, mnt-c, tech-c ... (?) Find contact set for visited object Stop visiting as soon as set is no longer empty While set still empty visit containing block Find contact set for containing block (if any) (Note: person, role, mntner have no containing block) Stop visiting as soon as set is no longer empty Return set -- Ends --

4 7