- db-wg - mailman.ripe.net

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

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

06 Feb '04

>> we might consider to also extend irt with the abuse-mailbox and >> allow abuse-c to refer to an irt object ? > >why not remove irt entirely? it is not needed given this proposal. Sorry, I have to disagree. The abuse / abuse-c /abuse-mailbox proposal(s) as being discussed will (maybe - maybe not) solve a different problem... >"less is more." -- mies van der rohe and nothing is best? >randy Wilfried.

1 0

abuse-c: proposal
by Niall O'Reilly 30 Jan '04

30 Jan '04

Co-authors: Randy Bush, Niall O'Reilly Proposal for Adding Abuse Contact to inet*num: Objects in RIPE Database Requirement: Net users who perceive abuse from some net source wish to contact some service which has officially agreed to deal with the abuse. Currently, they seem to scan the inet*num: objects and send mail to any or all contacts in that object, including strange things such as the email address in the changed: attribute. This need seems to be clearly applicable to the inetnum: and inet6num: objects, so those objects are addressed by this proposal. Should there be similar needs in other object types, it is anticipated that the abuse-c: attribute would be added to those objects as appropriate. Two things are needed: o The inetnum: and inet6num: objects are enhanced with an optional attribute "abuse-c:". The value of the attribute is a nic-handle: which must refer to an extant person: or role: object. There may be zero or more abuse-c: attributes in an inet*num: object. The value of the abuse-c: attribute MAY be extended by appending a hint string. This is expected to be useful to organizations who wish to advertise more than one abuse contact, and to give guidance as to which of these is the appropriate notification target in particular circumstances. In case a hint string is specified, it MUST be discarded when forming inverse keys. Therefore, the syntax of the inetnum: object would become inetnum: [mandatory] [single] [primary/lookup key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-c: [optional] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] o Document and Publish that the abuse-c: contact is the one and only contact that should be used to report spam and other forms of abuse. This documentation should be made prominently available so that manual seekers and creators of automated reporting tools will all clearly know that the abuse-c: is the one and only place at which abuse should be reported, and that other contacts in the objects should not be abused. The documentation should make it clear that automated reporting tools MAY always ignore the hint string, but SHOULD search the advertised abuse-c: attributes to find a hint string that matches the circumstances of the abuse to be reported. The hint string specified SHOULD be taken from a limited vocabulary. This vocabulary SHOULD be reviewed from time to time. It contains initially the following terms, treated as case-insensitive, and with the indicated semantics: '' Always notify this contact 'Spam' Notify this contact for spam abuse ONLY 'Security' Notify this contact for DDoS and intrusion abuse ONLY -- End --

12 32

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

29 Jan '04

Ulli, On 29 Jan 2004, at 14:03, Ulrich Kiermayr wrote (privately): > What is the difference between the following to answers from the > database (One with the existing Machine [ changing the default answer > behaviour] and one following the proposal): I want to share my response with the list. No difference between the answers. The difference is in the cost to (effort for) a netadmin in setting up the IRT stuff. Marco's statistics, as I understood them, seem to bear this out: there is a ratio of 2 orders of magnitude between the instances respectively of IRT references and free-text remarks about abuse notifications. I'm close to convinced that the IRT approach is correct, elegant, and the rest. I just find it too much trouble to use: I need it to be much easier than that to advertise my abuse contacts. As the saying goes, "Le mieux est l'ennemi du bien." Make it barely good enough, but simple; then we'll see it adopted. Niall PS. "Daddy, what does 'feature creep' mean?"

1 0

[announce] releasing a tool to help LIR visualizing IPv4 LIR-as signments vs RIPE-allocations
by TAYON, Julien 28 Jan '04

28 Jan '04

Hello, LDCOM Networks/N9uf telecom release its tool ripe_wrap. Its purpose is to enable a LIR to make a cross view between Assigned inetnums (such as seen when making a whois request) and the "netnames" allocated by the RIPE (such as seen through the lirportal). It gives usefull information such as biggest available holes per ip-range, % of assigned space over the space that was declared for a netname. Since LDCOM is not a software editor, it has been decided to release our tool under Afferro GPL licence. Temporarily, its location is http://www.julbox.net/ripe_wrap-1.0.tgz I use it every day and I think it is quite fine, but I made no intensive test. Please report to the author(s) (see AUTHORS) any bug(s) and suggestion. Our main gool is to build a toolbox for a LIR to work on its RIPE informations without hosting any Database by crossing various informations such as the configuration it have on its network equipments. Beware, first access is slow since it makes requests to the web and then sort out the data. We will think of a way to improve this ... later. Friendly, -- Julien Tayon - N9uf Telecom - BU DATA - +33 1 70 18 14 45

1 0