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 --
At 12:42 PM 29-01-04 +0100, Niall O'Reilly wrote: Excellent. The sooner the better. -Hank
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 --
On 29.01 12:42, Niall O'Reilly wrote:
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.
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough... all the rest is OK for me. -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends?
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. I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that randy
At 12:56 PM 29-01-04 +0000, Randy Bush wrote:
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. I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that
Ditto - makes no difference to me - whatever the consensus agrees on. -Hank
randy
On 29 Jan 2004, at 13:59, Hank Nussbacher wrote:
At 12:56 PM 29-01-04 +0000, Randy Bush wrote:
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that
Ditto - makes no difference to me - whatever the consensus agrees on.
-Hank
randy
Me too /Niall
Hi, On Thu, Jan 29, 2004 at 12:56:48PM +0000, Randy Bush wrote:
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. I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that
Same here. Both would be fine. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
Hi,
On Thu, Jan 29, 2004 at 12:56:48PM +0000, Randy Bush wrote:
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.
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that
Same here. Both would be fine.
From the user's viewpoint yes, from the viewpoint of having to maintain the objects, I'd prefer a reference, because if the mailbox changes, you just have to maintain 1 Object and not n (for arbitrary positive integers of n) Just my 0.02EUR lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
Hay, Ulrich Kiermayr wrote: [...]
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.
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
i could live with that
Same here. Both would be fine.
From the user's viewpoint yes, from the viewpoint of having to maintain the objects, I'd prefer a reference, because if the mailbox changes, you just have to maintain 1 Object and not n (for arbitrary positive integers of n)
well an address like abuse@do.main seldomly changes. If someone is dumb enough to put in a personal e-mail address, well... Anyways, for cases like mergers ect. with Domains changing, i'd prefer the inital suggestion - using a *-c I don't really see the problem with creating another role-object if needed. Heck, i don't even see why mnt-irt: is considered too complicated :-) ==> It's 'abuse-c: <handle>' - not a 'abuse-to: <email>' (or something like that) for me -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On Thu, Jan 29, 2004 at 02:42:10PM +0100, Ulrich Kiermayr wrote:
From the user's viewpoint yes, from the viewpoint of having to maintain the objects, I'd prefer a reference, because if the mailbox changes, you just have to maintain 1 Object and not n (for arbitrary positive integers of n)
Therefore my proposal to also allow for it on the mntner object and optionally modify the database server to return the maintainer when the attribute is not present on the inetnum, but one of the maintainers carries it. Can somebody from Ripe give some insigth in how much work would be involved on the various suggestions made, like adding attributes, complete objects and or modifying the default behaviour of the server ? MarcoH
On Thu, Jan 29, 2004 at 12:56:48PM +0000, Randy Bush wrote:
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.
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
On 29.01 14:42, Ulrich Kiermayr wrote:
From the user's viewpoint yes, from the viewpoint of having to maintain the objects, I'd prefer a reference, because if the mailbox changes, you just have to maintain 1 Object and not n (for arbitrary positive integers of n)
- if I understand correctly, this atribute is going to be added just because of those users, and because they often don't read what is there and send e-mail to whatever addresses they find, the abuse-c: should contain direct e-mail. - also, as MarcoH said, it's very easy to change remarks: to abuse-c:, while it's hard to put them all into newly created contacts. - third argument is, as many organizations do have only one IP-range, they would really find creating of new handle superflous. (well, we have 3 ranges, and I think that's very easy to put e-mail to all of them) The best would probably be, if abuse-c: would accept e-mail, or pointer to another object, so the network maintainer could decide which one to use. - Is that possible? -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
On Thu, Jan 29, 2004 at 03:29:57PM +0100, Matus UHLAR - fantomas wrote:
- if I understand correctly, this atribute is going to be added just because of those users, and because they often don't read what is there and send e-mail to whatever addresses they find, the abuse-c: should contain direct e-mail.
I want that object, because the number of wrongly addressed complaints is growing bigger as the daily portion of viagra advertisements. The cause for this are probably people who are to lazy read some docs before they start coding. But as I already said during the meeting, we're talking to the wrong group of people and it's hard to reach them for any input.
- also, as MarcoH said, it's very easy to change remarks: to abuse-c:, while it's hard to put them all into newly created contacts.
Please note that it's not meant to be a :s/remarks/abuse/ on the database, but looking at the numbers (10% of the objects), people shouldn't really complain about the maintenance involved as they already need to update each and every inetnum object when you want to change the abuse address. It would be nice if, while we're at it, we can make maintenance more easy, but it looks like already a lot of LIR's are using a unmaintainable system called remarks:
- third argument is, as many organizations do have only one IP-range, they would really find creating of new handle superflous. (well, we have 3 ranges, and I think that's very easy to put e-mail to all of them)
They can always use the same role for all contacts.
The best would probably be, if abuse-c: would accept e-mail, or pointer to another object, so the network maintainer could decide which one to use. - Is that possible?
That will create more confusion as you have to check what is returned. MarcoH
On Thu, Jan 29, 2004 at 03:29:57PM +0100, Matus UHLAR - fantomas wrote:
- if I understand correctly, this atribute is going to be added just because of those users, and because they often don't read what is there and send e-mail to whatever addresses they find, the abuse-c: should contain direct e-mail.
On 29.01 16:06, MarcoH wrote:
I want that object, because the number of wrongly addressed complaints is growing bigger as the daily portion of viagra advertisements. The cause for this are probably people who are to lazy read some docs before they start coding. But as I already said during the meeting, we're talking to the wrong group of people and it's hard to reach them for any input.
I understand your point. My point is, that a person doing whois lookup for an IP addresses will already get huge result, and lazy people take up first few addresses and quit. We want to avoid this, and returning the relevant data in a first few lines would help much. The IP lookup already returns huge amount of data which should probably be reduced. Not returning data usable only for maintainers, if the client does not request them all is a good point. Adding another person/role object as abuse contact won't do it, unless maintainers will re-use their contacts, in which case, the abuse-c: attribute is kinda useless.
- also, as MarcoH said, it's very easy to change remarks: to abuse-c:, while it's hard to put them all into newly created contacts.
Please note that it's not meant to be a :s/remarks/abuse/ on the database, but looking at the numbers (10% of the objects), people shouldn't really complain about the maintenance involved as they already need to update each and every inetnum object when you want to change the abuse address.
It would be nice if, while we're at it, we can make maintenance more easy, but it looks like already a lot of LIR's are using a unmaintainable system called remarks:
Of course. But it's always better to have this system then no no system at all. I asked our network maintainers to ass abuse data to remarks and will ask them for making abuse contact, when it will be pushed into production system.
- third argument is, as many organizations do have only one IP-range, they would really find creating of new handle superflous. (well, we have 3 ranges, and I think that's very easy to put e-mail to all of them)
They can always use the same role for all contacts.
which will overload roles with different types of data.
The best would probably be, if abuse-c: would accept e-mail, or pointer to another object, so the network maintainer could decide which one to use. - Is that possible?
That will create more confusion as you have to check what is returned.
Agreeed. So what about abuse: email versus abuse-c: handle? -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
On Thu, Jan 29, 2004 at 04:30:56PM +0100, Matus UHLAR - fantomas wrote:
- third argument is, as many organizations do have only one IP-range, they would really find creating of new handle superflous. (well, we have 3 ranges, and I think that's very easy to put e-mail to all of them)
They can always use the same role for all contacts.
which will overload roles with different types of data.
If your company is so small it's the same person running the registry, doing the network and handling abuse complaints you can use the same person/role for all contacts. Where is the overloading in this ?
The best would probably be, if abuse-c: would accept e-mail, or pointer to another object, so the network maintainer could decide which one to use. - Is that possible?
That will create more confusion as you have to check what is returned.
Agreeed. So what about abuse: email versus abuse-c: handle?
See my other mails over the past few weeks and the slides I'm mailing to the webmaster in a few minutes :) The problem is in 'overloading' the tag e-mail, you need to look at the context (object) which it came in, to find in wath cases you should use it. To just launch yet another idea: Implement a (client) library returning hierarchical names: tech-c.e-mail admin-c.e-mail irt.e-mail abuse-c.e-mail There is no definite need to change the schema to incorporate new objects/attrfibutes. There are already multple suggestions to just change the default appearance of the data returned by a whois query. MarcoH
Hello. On Thu, Jan 29, 2004 at 01:48:48PM +0100, Matus UHLAR - fantomas wrote:
On 29.01 12:42, Niall O'Reilly wrote:
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.
I don't see any reason why abuse-c: should refer to person: or role: object.
Because admin-c and tech-c are person or role objects, too, and not simple email addresses. Because person or role objects have phone and snailmail addresses. I strongly second the original proposal, please implement this asap!
I don't see any reason why abuse-c: should refer to person: or role: object. Because admin-c and tech-c are person or role objects, too, and not simple email addresses. Because person or role objects have phone and snailmail addresses.
when using the database for manual lookup, i am often having actual technical problems, and may want to speak with a human on the <gasp!> telephone, because email/net to them is not working. hence, i was inclined to a nic-handle: when i wrote it up. but i can live without. randy, who still has the last copy of the paper edition of the whois published by sri
On 30.01.2004 at 05:47, Randy Bush wrote:
I don't see any reason why abuse-c: should refer to person: or role: object. Because admin-c and tech-c are person or role objects, too, and not simple email addresses. when using the database for manual lookup, i am often having actual technical problems, and may want to speak with a human on the <gasp!>
You still have the person and/or role objects in the ac and tc left to talk to. My experience has shown, that complains about abuse -- spam, scanning, etc -- has never reached me by snail mail or phone (yet), only by email. And yes, I know, only because it hasn't been that way does not mean it will not ever be. Beside that, as a technician I would prefer the usage of IRT objects or the utilisation of references like handles to person or role objects because of the easy administration. But we don't have to forget that on the other end are most likely no technicians but "users". (And now we have done the full circle and are back at the beginning) Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/
On 29.01.2004 at 13:48, Matus UHLAR - fantomas wrote:
On 29.01 12:42, Niall O'Reilly wrote:
attribute "abuse-c:". The value of the attribute is a nic-handle:
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
I would say it will be even a better solution to have only the mailadress there and no person object. As the discussion has shown, "people" do not want to dig for another object. All they want is that damn address to complain to. Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/
Hendrik T Voelker wrote:
On 29.01.2004 at 13:48, Matus UHLAR - fantomas wrote:
On 29.01 12:42, Niall O'Reilly wrote:
attribute "abuse-c:". The value of the attribute is a nic-handle:
I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough...
I would say it will be even a better solution to have only the mailadress there and no person object.
As the discussion has shown, "people" do not want to dig for another object. All they want is that damn address to complain to.
Problem is imho that a simple mail-address would only scale downwards [i.e. for those with few netblocks]. From the discussion it seems that irt only scales upwards [i.e. for the ones with many netblocks who are willing to understand the system without a priori saying 'it's too complicated] Nowing that admin-c and tech-c seems to scale over the whole spectrum, it seems the most natural implementation to have abuse-c reference a (enhanced) person/role too. This is the only way that I could see that is .) Making it simple for the small database-users .) Incorporating _all_ the features of irt for those who need them [it is imho important not to have 2,3,4... pointers for the same problem-space] .) The structure would waguely look like what arin returns (for the people this would have the advantage of only haveing to understand one structure) lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On 30.01.2004 at 09:15, Ulrich Kiermayr wrote:
attribute "abuse-c:". The value of the attribute is a nic-handle: I don't see any reason why abuse-c: should refer to person: or role: object. Simple email address(es) would be imho just enough... I would say it will be even a better solution to have only the mailadress there and no person object.
Problem is imho that a simple mail-address would only scale downwards [i.e. for those with few netblocks]. From the discussion it seems that irt only scales upwards [i.e. for the ones with many netblocks who are willing to understand the system without a priori saying 'it's too complicated]
Ok, opening up the can of worms: The question will then be: what abuse address do we write into the objects. In allocations for sure the contact of the LIR/Provider. But into the object of the customer networks? The address of the customer's abuse department? Or, here too, the one of the provider? Or both? And if we use the customer's abuse department's address, are we going forward and demand that this address will be mandatory and has to be given in the requests for new netblocks? And if we use both addresses, do we need tags for them to indicate the escalation level? Probably we should head in two directions simultaneously 1. A short term solution, using admin-c: <email> to better the current situation a little. 2. A longterm solution with a proper hierarchy, clear defined policy, and technically easy to administrate objects -> IRT.
Nowing that admin-c and tech-c seems to scale over the whole spectrum, it seems the most natural implementation to have abuse-c reference a (enhanced) person/role too.
Even though I would have to touch relatively many objects, I am still willing to got for the admin-c: <email>. Cheers Hendrik -- Hendrik T. Voelker HTV5-RIPE MCI EMEA Registrar Team UUNET Deutschland GmbH, Sebrathweg 20, 44149 Dortmund, GERMANY A MCI Company tel+49-231-972-1565 fax+49-231-972-1180 http://www.mci.com/de/
Hi *,
Problem is imho that a simple mail-address would only scale downwards [i.e. for those with few netblocks]. From the discussion it seems that irt only scales upwards [i.e. for the ones with many netblocks who are willing to understand the system without a priori saying 'it's too complicated]
Ok, opening up the can of worms:
The question will then be: what abuse address do we write into the objects. In allocations for sure the contact of the LIR/Provider. But into the object of the customer networks? The address of the customer's abuse department? Or, here too, the one of the provider? Or both? And if we use the customer's abuse department's address, are we going forward and demand that this address will be mandatory and has to be given in the requests for new netblocks? And if we use both addresses, do we need tags for them to indicate the escalation level?
I'd say always to the 'best match' i.e. most specific netblock that has an abuse-c/irt (that is what -c is for!). anything else should be local policy from the LIR.
Probably we should head in two directions simultaneously
1. A short term solution, using admin-c: <email> to better the current situation a little.
I don't see how this is a solution to the above problem.
2. A longterm solution with a proper hierarchy, clear defined policy, and technically easy to administrate objects -> IRT.
<cynical>tong term solution most probably means 'never'</cynical> If we do it we should do it properly in the first place.
Even though I would have to touch relatively many objects, I am still willing to got for the admin-c: <email>.
I disagree. Are there any other direct opinions apart from 'i can live with both' ? lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Fri, Jan 30, 2004 at 09:15:00AM +0100, Ulrich Kiermayr wrote:
Nowing that admin-c and tech-c seems to scale over the whole spectrum, it seems the most natural implementation to have abuse-c reference a (enhanced) person/role too.
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects. MarcoH
MarcoH wrote:
On Fri, Jan 30, 2004 at 09:15:00AM +0100, Ulrich Kiermayr wrote:
Nowing that admin-c and tech-c seems to scale over the whole spectrum, it seems the most natural implementation to have abuse-c reference a (enhanced) person/role too.
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects.
from am management level it seems so. But given the fact we are discussing it, it does not scale for the tool-writers. if i am wring, what is the discussion about? lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On Fri, Jan 30, 2004 at 10:26:17AM +0100, Ulrich Kiermayr wrote:
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects.
from am management level it seems so. But given the fact we are discussing it, it does not scale for the tool-writers.
if i am wring, what is the discussion about?
The fact remarks is a generic name and the field is freeform MarcoH
MarcoH wrote:
On Fri, Jan 30, 2004 at 10:26:17AM +0100, Ulrich Kiermayr wrote:
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects.
from am management level it seems so. But given the fact we are discussing it, it does not scale for the tool-writers.
if i am wring, what is the discussion about?
The fact remarks is a generic name and the field is freeform
and therefore it does not scale? right? lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
At 10:05 30/01/2004, Ulrich Kiermayr wrote:
MarcoH wrote:
On Fri, Jan 30, 2004 at 10:26:17AM +0100, Ulrich Kiermayr wrote:
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects.
from am management level it seems so. But given the fact we are discussing it, it does not scale for the tool-writers.
if i am wring, what is the discussion about?
The fact remarks is a generic name and the field is freeform
and therefore it does not scale? right?
Remarks/comments fields should never be relied upon by anyone except the person entering the comments. -- Tim
On Fri, Jan 30, 2004 at 11:05:58AM +0100, Ulrich Kiermayr wrote:
MarcoH wrote:
On Fri, Jan 30, 2004 at 10:26:17AM +0100, Ulrich Kiermayr wrote:
'remarks: complaints to abuse@' also seem to scale to >10% of the inetnum objects.
from am management level it seems so. But given the fact we are discussing it, it does not scale for the tool-writers.
if i am wring, what is the discussion about?
The fact remarks is a generic name and the field is freeform
and therefore it does not scale? right?
Looking at the numbers this obvious scaling issue doesn't hold people back to put it in. However it does create problems for people looking for information, especially the email address from the abuse desk responsible for that block. It scales on the LIR part, although there are more ways to do it, which are easier to maintain. Using a generic name and freeform content doesn't exactly help people to find the correct information exept when they actually read the complete whois output. And to repeat one of my sidenotes from the presentation, using <> to enclose the email address breaks a lot of webbased whois tools. Grtx, MarcoH
Hello *, Nicely crafted Probposal. But ther is one thing I do not yet understand; could someone please enlighten me: 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): [Sorry for the lengthy posting.] ---------------- inetnum: 131.130.7.32 - 131.130.7.47 netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK6107-RIPE tech-c: UK3 abuse-c: UKIRT-RIPE mnt-by: AS760-MNT mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr@univie.ac.at 20020822 changed: uk@uk.atat.at 20040128 source: RIPE route: 131.130.0.0/16 descr: UNIVIE origin: AS760 mnt-by: AS760-MNT changed: ripe-dbm@ripe.net 19941121 source: RIPE person: Ulrich Kiermayr address: Vienna University address: Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna address: Austria phone: +43 1 4277 14104 fax-no: +43 1 4277 9140 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK6107-RIPE remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: ACONET-LIR-MNT changed: panigl@cc.univie.ac.at 20010629 changed: kiermayr@cc.univie.ac.at 20020603 changed: ulrich.kiermayr@univie.ac.at 20020805 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK3 remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: UK-MNT notify: Ulrich.Kiermayr@UniVie.ac.at changed: Ulrich.Kiermayr@UniVie.ac.at 20020723 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UKIRT-RIPE notify: Ulrich.Kiermayr@UniVie.ac.at mnt-by: UK-MNT changed: Ulrich.Kiermayr@UniVie.ac.at 20020820 changed: Ulrich.Kiermayr@UniVie.ac.at 20030115 source: RIPE ---------------- inetnum: 131.130.7.32 - 131.130.7.47 netname: UK-V4 descr: LAN Ulrich Kiermayr country: AT admin-c: UK6107-RIPE tech-c: UK3 mnt-irt: IRT-UK mnt-by: AS760-MNT mnt-by: UK-MNT status: ASSIGNED PA changed: ulrich.kiermayr@univie.ac.at 20020822 changed: uk@uk.atat.at 20040128 source: RIPE route: 131.130.0.0/16 descr: UNIVIE origin: AS760 mnt-by: AS760-MNT changed: ripe-dbm@ripe.net 19941121 source: RIPE person: Ulrich Kiermayr address: Vienna University address: Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna address: Austria phone: +43 1 4277 14104 fax-no: +43 1 4277 9140 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK6107-RIPE remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: ACONET-LIR-MNT changed: panigl@cc.univie.ac.at 20010629 changed: kiermayr@cc.univie.ac.at 20020603 changed: ulrich.kiermayr@univie.ac.at 20020805 source: RIPE person: Ulrich Kiermayr address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at nic-hdl: UK3 remarks: GPG-Key: PGPKEY-A8D764D8 mnt-by: UK-MNT notify: Ulrich.Kiermayr@UniVie.ac.at changed: Ulrich.Kiermayr@UniVie.ac.at 20020723 source: RIPE irt: IRT-UK address: Lacknergasse 71/23 address: A-1180 Wien address: AT phone: +43 1 5248266 phone: +43 664 8174818 e-mail: Ulrich.Kiermayr@UniVie.ac.at signature: PGPKEY-A8D764D8 encryption: PGPKEY-A8D764D8 admin-c: UK3 tech-c: UK3 irt-nfy: Ulrich.Kiermayr@UniVie.ac.at auth: PGPKEY-A8D764D8 notify: Ulrich.Kiermayr@UniVie.ac.at mnt-by: UK-MNT changed: Ulrich.Kiermayr@UniVie.ac.at 20020820 changed: Ulrich.Kiermayr@UniVie.ac.at 20030115 source: RIPE ---------------- -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
What is the difference between the following to answers from the database
the abuse-c: proposal does not require creation of a new object type, the irt: object. it reuses the person: and role: objects, as the semantics, "here is who you contact," are really the same. i don't think we want to differentiate the kind of people/groups who handle abuse from those who handle tech/admin things. they're all just contacts. randy
Randy Bush wrote:
What is the difference between the following to answers from the database
the abuse-c: proposal does not require creation of a new object type, the irt: object. it reuses the person: and role: objects, as the semantics, "here is who you contact," are really the same.
i don't think we want to differentiate the kind of people/groups who handle abuse from those who handle tech/admin things. they're all just contacts.
Fair enough, thx. What I am afraid of is having 2 things basically doung the same irt and abuse-c. so maybe there is a way to 'merge' these two things (wild thinking of me): Looking at the difference between irt and roles in general, there are actually quite few: 1. Role lacks of the two pgp-attributes. Might it be worth to put them as optional into that templates? [I'd say probably yes, because it might be useful in other situations as well] 2. Protection against 'illegal' referecing. (Meaning "Hey UCD has a nice role for abuse, i reference this role in my inetnums as well") There we had a discussion in the context of the org object, putting a generalized machinery (mnt-ref, ref-nfy) in place. IMHO this _should_ be added (optional) to role/person anyway. 3. The -c flag: This could be incorporated with the irt as well. Or in a even more generalized way have a "whois -c abuse-c 131.130.7.44" returning the most specific inetnum containing an abuse-c, and maybe if useful extending the semantics to other attributes if useful. If those three things are incorporated, abuse-c has all the features irt has, except for the creation policy. But this is up to discussion anyway. I hope I make some sense here lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On 29 Jan 2004, at 14:34, Ulrich Kiermayr wrote:
1. Role lacks of the two pgp-attributes. Might it be worth to put them as optional into that templates? [I'd say probably yes, because it might be useful in other situations as well]
I'ld agree. Safety options should always be available.
2. Protection against 'illegal' referecing. (Meaning "Hey UCD has a nice role for abuse, i reference this role in my inetnums as well") There we had a discussion in the context of the org object, putting a generalized machinery (mnt-ref, ref-nfy) in place. IMHO this _should_ be added (optional) to role/person anyway.
Do we need a new machinery for this? If a role or person object acquires a new inverse-key relationship, I would find it reasonable to alert the 'mnt-by:' and 'notify:' targets as a matter of course. I don't see the value in defining new attributes just to cover this.
3. The -c flag: This could be incorporated with the irt as well. Or in a even more generalized way have a "whois -c abuse-c 131.130.7.44" returning the most specific inetnum containing an abuse-c, and maybe if useful extending the semantics to other attributes if useful.
I like "whois -c abuse-c 131.130.7.44".
If those three things are incorporated, abuse-c has all the features irt has, except for the creation policy. But this is up to discussion anyway.
I hope I make some sense here
I think so.
lG uk MfG NO8
Hi,
2. Protection against 'illegal' referecing. (Meaning "Hey UCD has a nice role for abuse, i reference this role in my inetnums as well") There we had a discussion in the context of the org object, putting a generalized machinery (mnt-ref, ref-nfy) in place. IMHO this _should_ be added (optional) to role/person anyway.
Do we need a new machinery for this? If a role or person object acquires a new inverse-key relationship, I would find it reasonable to alert the 'mnt-by:' and 'notify:' targets as a matter of course. I don't see the value in defining new attributes just to cover this.
Hmm, I'd prefer the protection from that to happen instead of: Bad Guy does something -> You hear from it -> You have to persuade the RIPE-NCC to do something against it (Because you can't do it yourself, since you do _not_ maintain the object where the reference is in). That machinery is not really new, since the DB-Folks are as I understood it Implementing that attribute-combination for the org-object as well. And then it is optional, so if you dont want real protection, you do not have to use it. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
On 29 Jan 2004, at 14:57, Ulrich Kiermayr wrote:
[ Niall O'Reilly wrote ]
Do we need a new machinery for this? If a role or person object acquires a new inverse-key relationship, I would find it reasonable to alert the 'mnt-by:' and 'notify:' targets as a matter of course. I don't see the value in defining new attributes just to cover this.
Hmm, I'd prefer the protection from that to happen instead of: Bad Guy does something -> You hear from it -> You have to persuade the RIPE-NCC to do something against it (Because you can't do it yourself, since you do _not_ maintain the object where the reference is in).
Right. I should have thought of that. For " ... alert the 'mnt-by:' and 'notify:' targets ... " read " ... alert 'mnt-by:' and 'notify:' targets, and block the update pending their confirmation ... ". MfG Niall
Niall O'Reilly wrote:
On 29 Jan 2004, at 14:57, Ulrich Kiermayr wrote:
[ Niall O'Reilly wrote ]
Do we need a new machinery for this? If a role or person object acquires a new inverse-key relationship, I would find it reasonable to alert the 'mnt-by:' and 'notify:' targets as a matter of course. I don't see the value in defining new attributes just to cover this.
Hmm, I'd prefer the protection from that to happen instead of: Bad Guy does something -> You hear from it -> You have to persuade the RIPE-NCC to do something against it (Because you can't do it yourself, since you do _not_ maintain the object where the reference is in).
Right. I should have thought of that.
For " ... alert the 'mnt-by:' and 'notify:' targets ... " read " ... alert 'mnt-by:' and 'notify:' targets, and block the update pending their confirmation ... ".
Ok, but this in my vision this has 2 drawbacks: 1. Then you cant have the the object itself protected, but leave the referencing unprotected. (This is a change in the default behaviout that might break tools) 2. There are cases where the one maintaining the data [i.e. content of the object] != the one who wants to control who references it. [Your Company (auto)-provides the objects contents out of a database and protects that path, but leaves it to you or the LIR guy to reference te object. ] lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
I can also live with the value of the attribute being either a reference or a mailbox directly. In the latter case I suggest that the name should not end on -c to prevent confusion. In <20040112074509.GC2101@arbeit.karrenberg.net> I wrote:
I am also in favour of adding the 'abuse-mailbox' attribute to the maintainer object in order to provide a quick way for deployment that does not involve changing a lot of inet*num objects. The referencing recommendation should be: "If the inet*num object for the address concerned has an 'abuse-mailbox', use this address *only* for sending abuse complaints. If such an attribute is not present, check the maintainer object for an 'abuse-mailbox' attribute and use this address *only* for sending abuse complaints."
Would you consider including that in your proposal? Daniel
On Thu, Jan 29, 2004 at 12:42:04PM +0100, Niall O'Reilly wrote:
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.
First thanks for getting the proposal out so fast. One comment, unless the behaviour of the db software is modified, we stilll can't really prevent people from using the wrong address when parsing the output, actually if you take a look at the template: role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] We already have 3 attributes with an ip-address (e-mail,notify and changed) and it is referring to other roles (tech-c, admin-c) which are both mandatory. A default network lookup will return all these objects and we still have to trust (or teach) the person who is writing a reporting tool to pick the correct e-mail attribute and not something else carrying a space delimited string containing the '@' character. We maybe could solve thhis by adding another flag (Shane ?) which, when queried for a network/ip will _only_ return the abuse-c role and nothing else. Doing it like this, I'm afraid we end up with another 'irt' object. Nobody takes the time to create one and update his inet*num objects and the 'users' still won't parse the returned objects correctly. I am really in favor for the 'keep it simple' approach, just take that 100.000 remarks: attributes and rename them to abuse:. That way we have a specific attribute people can search for and not another generic name (e-mail) with a specific meaning. I don't like the idea of creating new attributes, but I also have the opinion that it will be the only way we can fight the problem we have, getting an annoying amount of complaints in my personal mailbox. Please consider rephrasing the proposal to: o The inetnum: and inet6num: objects are enhanced with an optional attribute "abuse-c:". The value of the attribute is a syntactically valid email address (as per rfc2822). Which will handle the abuse role as specified in rfc2142 There may be zero or more abuse-c: attributes in an inet*num: object. If you take a look at the template arin uses to present the data to the user, it uses a distinct name which is easy to parse the output for... OrgAbuseHandle: OrgAbuseName: OrgAbusePhone: OrgAbuseEmail: It doesn't exactly match the ripe naming scheme, but at least the label is specific for the purpose.a And that so far has been missing from the other proposals, including the irt schema. Grtx, MarcoH
On 29 Jan 2004, at 14:50, MarcoH wrote:
First thanks for getting the proposal out so fast.
Credit to Randy. He pushed. Niall
On 29 Jan 2004, at 14:50, MarcoH wrote:
A default network lookup will return all these objects and we still have to trust (or teach) the person who is writing a reporting tool to pick the correct e-mail attribute and not something else carrying a space delimited string containing the '@' character.
That's the 'Document and Publish' part. Perhaps 'Document, Publish and Promote' is a better way of putting it. Niall
On Thu, Jan 29, 2004 at 03:04:43PM +0100, Niall O'Reilly wrote:
A default network lookup will return all these objects and we still have to trust (or teach) the person who is writing a reporting tool to pick the correct e-mail attribute and not something else carrying a space delimited string containing the '@' character.
That's the 'Document and Publish' part. Perhaps 'Document, Publish and Promote' is a better way of putting it.
That can be done on the exsting inet*num object also..in short: "look for irt object, if not present look at the remarks and if everything else fails, pick the e-mail: from the tech-c role. AND DON'T USE CHANGED ATTRIBUTES AND NOTIFY" For some reason Shane's proposal via jabber wasn't that bad: "surpress all data which is only usefulll for maintainers from the default output". MarcoH (sorry for shouting)
On 29 Jan 2004, at 15:16, MarcoH wrote:
For some reason Shane's proposal via jabber wasn't that bad: "surpress all data which is only usefulll for maintainers from the default output".
Spot on! Niall
For some reason Shane's proposal via jabber wasn't that bad: "surpress all data which is only usefulll for maintainers from the default output". Spot on!
sounds nice, but two issues o spam response tool writers will read docs and add the opt to get all the refs o it adds pain for us old operators who actually use the db to find out who is responsible for running some chunk of net but no big deal either way randy
On Thu, Jan 29, 2004 at 02:26:44PM +0000, Randy Bush wrote:
For some reason Shane's proposal via jabber wasn't that bad: "surpress all data which is only usefulll for maintainers from the default output". Spot on!
sounds nice, but two issues
o spam response tool writers will read docs and add the opt to get all the refs
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
o it adds pain for us old operators who actually use the db to find out who is responsible for running some chunk of net
but no big deal either way
We'll provide you with a whois-client which turns on the flag by default :) MarcoH
On 29.01 15:50, MarcoH wrote:
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
They do not read the docs at all. They parse any ascii that comes back for something that syntactically looks like and e-mail address. One way to stop this might be to identify the tool authors and put as many of their e-mail addresses as one can find in free text in objects. ;-) Daniel
On Thu, Jan 29, 2004 at 04:21:23PM +0100, Daniel Karrenberg wrote:
On 29.01 15:50, MarcoH wrote:
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
They do not read the docs at all. They parse any ascii that comes back for something that syntactically looks like and e-mail address. One way to stop this might be to identify the tool authors and put as many of their e-mail addresses as one can find in free text in objects. ;-)
I suggest rot13 encryption of all addresses except the one taking complaints :) MarcoH
On Thu, Jan 29, 2004 at 04:21:23PM +0100, Daniel Karrenberg wrote:
On 29.01 15:50, MarcoH wrote:
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
They do not read the docs at all. They parse any ascii that comes back for something that syntactically looks like and e-mail address. One way to stop this might be to identify the tool authors and put as many of their e-mail addresses as one can find in free text in objects. ;-)
Some of us read the docs :) Cheers, Steve
On Thu, Jan 29, 2004 at 08:11:11AM -0800, Steve Atkins wrote:
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
They do not read the docs at all. They parse any ascii that comes back for something that syntactically looks like and e-mail address. One way to stop this might be to identify the tool authors and put as many of their e-mail addresses as one can find in free text in objects. ;-)
Some of us read the docs :)
But do you also implement complaining tools...if that's the case more info on how it works would be welcome as is input on the usabillity of the database from a 'user' perspective.
On Thu, Jan 29, 2004 at 05:20:55PM +0100, MarcoH wrote:
On Thu, Jan 29, 2004 at 08:11:11AM -0800, Steve Atkins wrote:
Make sure that part of the docs is surrounded by the stuff about where to find certain information...if they read the docs, they would also be able to figure out that changed: and notify: are not meant as an abuse pointer.
They do not read the docs at all. They parse any ascii that comes back for something that syntactically looks like and e-mail address. One way to stop this might be to identify the tool authors and put as many of their e-mail addresses as one can find in free text in objects. ;-)
Some of us read the docs :)
But do you also implement complaining tools...if that's the case more info on how it works would be welcome as is input on the usabillity of the database from a 'user' perspective.
Eh. To give you some context on my perspective, I think all currently deployed automatic spam-complaint tools are deeply flawed. They're too inaccurate to be widely useful, and cause more problems than benefits for 7 out of 10 abuse desks. I don't think that's an intrinsic issue, so much as an implementation issue, though. (I do have automated spam analysis tools written, and use them internally, but don't consider them accurate enough to let loose on Joe SpamCop.) But I also develop tools for abuse desks to use, so I see a lot of the database problems both from being a (hopefully) informed user myself and seeing the deluge of complaints from Joe SpamCop. I'm also involved with the IRTF antispam research group subgroup on abuse reporting standards - where a lot of these issues are relevant. Many of the complaints based on RIR lookups are from people using web interfaces (like mine) to the whois servers, rather than actual automated tools. That population certainly doesn't read the docs. Many (most?) of the spam complaining users don't really understand the way the records are put together, and the complexity of person or role elements. A standard whois query provides them with too much information, in a hard to understand form - leading to the "email everything with an @ sign in it" problem. (And that population is the same population writing automated complaint tools - so, you're right, most of those tool authors probably aren't even aware there are docs, let alone have read them.) So, while with my DBA hat on I can see that it's clearly the right thing to do to have an abuse-c object that points to a role object I don't think that's optimal in avoiding misaimed abuse reports while still allowing valid abuse reports to go to an appropriate role. Providing a direct mailbox to the querying user would improve things somewhat. i.e. abuse-box: abuse@example.com, or even better a few different mailboxes abuse-box: spam-box: security-box: to encourage some level of self-sorting by complainers. How to provide those is an implementation detail - personally I'd still have them in the database as abuse-c: pointing at a role object, but generate a synthetic abuse-box: field from the e-mail field of the role object pointed at by the abuse-c: field at query time. That would improve things somewhat for those on the receiving end of the other email addresses in a record. To really improve things, though, the right thing to do is to discourage people complaining about spam or whatever from using the RIR whois servers directly. They don't really want to, but they've learned to do so because that's the best approach available to someone with minimal tools available. What would be ideal for them, and would remove many of the issues of "how do we present data that's useful for the intended technical audience, but not harmful via the not really intended non-technical audience" would be to provide an alternate interface that would hide all the other information. That would be quite a lot of work for the RIRs to do, but it doesn't have to be done by them. Given a bulk feed of RIPE data I'd be happy to republish it via such a heavily stripped down interface. I'm on first name terms with the maintainers of most of the heavily used web gateways, automatic lookup and complaint tools, so I suspect I could convince the majority of them to switch to using that stripped-down data source. Cheers, Steve
participants (12)
-
Daniel Karrenberg -
Gert Doering -
Hank Nussbacher -
Hendrik T Voelker -
MarcoH -
Matus UHLAR - fantomas -
Niall O'Reilly -
Patrick Rother -
Randy Bush -
Sascha Lenz -
Steve Atkins -
Tim Streater -
Ulrich Kiermayr