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
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.
perhaps instead of adding another address they can call, we should allow changed: and notify: to be nic-handles:. randy
On Fri, Feb 06, 2004 at 05:06:37PM +0100, Randy Bush wrote:
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.
perhaps instead of adding another address they can call, we should allow changed: and notify: to be nic-handles:.
Changed: would be usefull, I think notify is nearly impossible as all kind of db processes use it and e-mail isn't mandatory on person objects. MarcoH
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:.
perhaps instead of adding another address they can call, we should allow changed: and notify: to be nic-handles:. Perhaps, but that's another discussion.
not when you are using it as a reason to affect decisions in this discussion, i.e. allowing email addresses in abuse-c: randy
Comments in context below ...
sad times you have to announce that ...
[ Hmm.. look at those victims! Must try to spread the load even wider! 8-) ]
Unfortunately this is sometimes indeed the strategy. So nothing would change.
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}'
So, why do you believe "they"'re going to change their attitude? First of all this ssemms to be an issue of the presentation format. One could have a cleaner db design with abuse-c-handle and still show it in the form suggested above. An even easier solution would be a dedicated server: whois -h abuse.ripe.net 137.43.0.0 -> abuse@ucd.ie I'm not too sure whose alleged requirements should be satisfied here: o clueful users o clueless operators o clueful bot writers o clueful and cooperative bot writers o clueful and not cooperative bot writers o [...] -Peter
I'm not too sure whose alleged requirements should be satisfied here: o clueful users o clueless operators o clueful bot writers o clueful and cooperative bot writers o clueful and not cooperative bot writers o [...]
operators, as we're paying the bills and supposedly ncc is our service org. and perhaps we should reward clue. randy
operators, as we're paying the bills and supposedly ncc is our service org. and perhaps we should reward clue.
OK, so what are the operators' requirements: 1) have a useful and usable database 2) don't be a target of widespread "complaints" resulting from non-operator use of the database (2) can be accomplished either at cost of (1) or by providing an alternative to the actual users. So we're back to my initial question. Who's the enemy? -Peter
On Feb 06, Randy Bush <randy@psg.com> wrote:
operators, as we're paying the bills and supposedly ncc is our service org. and perhaps we should reward clue. My requirements as an operator[1] are already fulfilled by irt objects, can you explain better what are yours?
I think that the main flaw in these abuse-c/abuse-mailbox proposals is that they require modifying every most specific inetnum/inetnum6 object, while with irt I only need to add an attribute to the top level ones. I also think that the proponents should explain more clearly which of the various problems discussed each proposal is trying to solve. I can't see which problem an abuse-c attribute referencing a role or person object would solve that applying the -c flag by default to inetnum/inetnum6 queries would not. [1] of associating abuse contacts to IP addresses in a machine-parseable format. -- ciao, | Marco | [4485 ribFnO50vJ3TY]
On Fri, Feb 06, 2004 at 09:33:23PM +0100, Marco d'Itri wrote:
On Feb 06, Randy Bush <randy@psg.com> wrote:
operators, as we're paying the bills and supposedly ncc is our service org. and perhaps we should reward clue. My requirements as an operator[1] are already fulfilled by irt objects, can you explain better what are yours?
My requirements as an operator[2] are clearly not met, I get loads of abuse complaints to my notify and changed addresses every week, which I have to forward to either the abuse dept or /dev/null. MarcoH [2] operator as in maintaining our database entries which is part of running an LIR
My requirements as an operator[2] are clearly not met, I get loads of abuse complaints to my notify and changed addresses every week, which I have to forward to either the abuse dept or /dev/null.
So, the problem is mainly a marketing/education problem. No matter what change to objects or presentation will be agreed upon, nothing short of limiting access to the database would stop the uneducatable or "let's hit them all" type uncooperative tool writer. The education or usability problem can IMHO best be achieved with a dedicated interface for "abuse" purposes, be it a web interface or a dedicated whois server. No new objects are needed. -Peter
On 09.02 10:14, Peter Koch wrote:
My requirements as an operator[2] are clearly not met, I get loads of abuse complaints to my notify and changed addresses every week, which I have to forward to either the abuse dept or /dev/null.
So, the problem is mainly a marketing/education problem. No matter what change to objects or presentation will be agreed upon, nothing short of limiting access to the database would stop the uneducatable or "let's hit them all" type uncooperative tool writer. The education or usability problem can IMHO best be achieved with a dedicated interface for "abuse" purposes, be it a web interface or a dedicated whois server. No new objects are needed.
will all e-mail addresses be wiped off standard whois interface? If not, ppl won't be forces to use the abuse interface. If yes, it would be very hard to get to right ppl in any case. -- 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. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
will all e-mail addresses be wiped off standard whois interface?
I wouldn't expect or recommend that.
If not, ppl won't be forces to use the abuse interface. If yes, it would
Correct, an education campaign will have to be an integral part of any solution. The dedicated interface would just provide for a mask to hide the unnecessary information. -Peter
Hi Peter,
My requirements as an operator[2] are clearly not met, I get loads of abuse complaints to my notify and changed addresses every week, which I have to forward to either the abuse dept or /dev/null.
So, the problem is mainly a marketing/education problem. No matter what change to objects or presentation will be agreed upon, nothing short of limiting access to the database would stop the uneducatable or "let's hit them all" type uncooperative tool writer. The education or usability problem can IMHO best be achieved with a dedicated interface for "abuse" purposes, be it a web interface or a dedicated whois server. No new objects are needed.
-Peter
I disagree. If ALL IP lookups in the whois gave an abuse email address at the beginning of a page which was more likely to be answered than mails to notify/changed addresses then users would surely start to use this instead. The problem is that currently we do not have an easy way to enter such an address, I understand that we have the IRT object but almost no LIRs use it probably because its a bit too complex, it contains many more features than is necessary to solve our abuse-address problem - which mean it doesn't solve anything. If we could get consensus to solve this problem we should try to find an easy solution likely to be implemented by the majority of the LIRs. My suggestion has been to include the abuse adddress in the maintainer object, it could default to the upd-to address, meaning all inetnum objects would instantly reference an abuse address. Secondly inetnum objects could include an optional abuse address attribute in case some LIRs prefer to differentiate. If an abuse address is present in the inetnum objects this has to be displayed at the top of the page in a whois query, if its not present then it should default to the address in the maintainer object. I don't see any purpose in the IRT object when we haven't even making sure an abuse address is available for all inetnum objects (which is probably the only thing all non-LIR-users use the Ripe DB for), but I don't see any problem in keeping the IRT object if some LIRs find it useful. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Feb 09, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote:
So, the problem is mainly a marketing/education problem. No matter what change to objects or presentation will be agreed upon, nothing short of limiting access to the database would stop the uneducatable or "let's hit them all" type uncooperative tool writer. The education or usability problem can IMHO best be achieved with a dedicated interface for "abuse" purposes, be it a web interface or a dedicated whois server. No new objects are needed. I fully agree with this. We should try to discuss how to make the information in irt objects easier to access by random users.
-- ciao, | Marco | [4512 pezk1XQLy8oBY]
On Feb 07, MarcoH <marcoh@marcoh.net> wrote:
operators, as we're paying the bills and supposedly ncc is our service org. and perhaps we should reward clue. My requirements as an operator[1] are already fulfilled by irt objects, can you explain better what are yours? My requirements as an operator[2] are clearly not met, I get loads of abuse complaints to my notify and changed addresses every week, which I have to forward to either the abuse dept or /dev/null. I have not seen any good argument which would lead me to believe that just adding yet another address would magically make clueless users use it.
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse? I do not pretend to be an expert in user interfaces, but I think that, for a random user, natural language should be easier to understand than something like "abuse-mailbox". I think that there is a consensus that there is the need for a method to look up the abuse desk address for an IP address, and I believe that irt objects (which have the big advantage of existing) are fit to this. 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). -- ciao, | Marco | [4502 co4fHliW8RaVw]
Hi Marco,
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse?
Of course not. But how many inetnum objects have these remarks?
I do not pretend to be an expert in user interfaces, but I think that, for a random user, natural language should be easier to understand than something like "abuse-mailbox".
Agreed. But the primary concern is the applications used to find an abuse address for a specific IP address, they have a hard time finding anything in a freetext format... We have to make sure these applications find the correct mail address, if they don't, we haven't solved anything.
I think that there is a consensus that there is the need for a method to look up the abuse desk address for an IP address, and I believe that irt objects (which have the big advantage of existing) are fit to this.
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. Next problem is the idea behind IRT, apparently it is to be used by companies who outsource handling of abuse - we don't. 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? 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@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Feb 09, Christian Rasmussen <chr@jay.net> wrote:
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse? Of course not. But how many inetnum objects have these remarks? How is this relevant to what we are discussing?
I do not pretend to be an expert in user interfaces, but I think that, for a random user, natural language should be easier to understand than something like "abuse-mailbox". Agreed. But the primary concern is the applications used to find an abuse address for a specific IP address, they have a hard time finding anything in a freetext format... We have to make sure these applications find the correct mail address, if they don't, we haven't solved anything. This is true, I agree that this must be a goal, but abuse-mailbox is not the only way to reach it. Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data), or maybe the port 43 server could be modified to always check for IRT objects for inetnum/inetnum6 queries and report the address in a comment at the top of the reply with big eye-catching ASCII art. So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools.
I think that there is a consensus that there is the need for a method to look up the abuse desk address for an IP address, and I believe that irt objects (which have the big advantage of existing) are fit to this.
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. No, you are getting it backward: this is the problem with abuse-mailbox or abuse-c. With IRT you only need to tag the top level allocation object and the attribute will be inherited by all end users assignments, while with abuse-* you need to add the attribute to every inetnum/inetnum6 object. This is a fundamental propriety of the IRT object and the main reason for which I consider it superior to the other proposals.
Next problem is the idea behind IRT, apparently it is to be used by companies who outsource handling of abuse - we don't. If I should use this It may support outsourcing, but I can't see why this would be a problem. I set up an IRT object for an ISP with an internal abuse desk and found it appropriate for my needs. Can you be more clear?
object it should have a normal mnt-by attribute and the following fields either removed or made optional: address, signature, encryption, auth. I would not strongly oppose to this, but I can't see how it would make easier to deploy IRT objects. It's not like you do not already have an address or a PGP key...
-- ciao, | Marco | [4511 dinMaQK0OHrNc]
On Mon, Feb 09, 2004 at 03:25:12PM +0100, Marco d'Itri wrote:
This is true, I agree that this must be a goal, but abuse-mailbox is not the only way to reach it. Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data), or maybe the port 43 server could be modified to always check for IRT objects for inetnum/inetnum6 queries and report the address in a comment at the top of the reply with big eye-catching ASCII art. So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools.
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. Adding abuse-mailbox would provide a clear way to to store this information, next step can be to change the whois server for an extra query type and/or modified output. Grtx, MarcoH
On Feb 09, MarcoH <marcoh@marcoh.net> wrote:
This is true, I agree that this must be a goal, but abuse-mailbox is not the only way to reach it. Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data), or maybe the port 43 server could be modified to always check for IRT objects for inetnum/inetnum6 queries and report the address in a comment at the top of the reply with big eye-catching ASCII art. So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools.
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.
Adding abuse-mailbox would provide a clear way to to store this information, next step can be to change the whois server for an extra query type and/or modified output. While IRT objects *already* provide an easier way to store this information...
-- ciao, | Marco | [4526 escBmKC6O5ewg]
On Tue, Feb 10, 2004 at 12:09:32PM +0100, Marco d'Itri wrote:
Adding abuse-mailbox would provide a clear way to to store this information, next step can be to change the whois server for an extra query type and/or modified output. While IRT objects *already* provide an easier way to store this information...
it contains a generic attribute called e-mail, a lot of companies use different addresses for different parts of the work covered by IRT. As an example, customer: "why is your dhcp server sending dhcp reasponses to my machine" isn't really something I want our incident response team aka security to be woken up for in the middle of the night. MarcoH
Hi Marco, hehe.. this is apparently always a good subject to get some discussion!.. :)
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse? Of course not. But how many inetnum objects have these remarks? How is this relevant to what we are discussing?
It is very relevant for your argument, you say this remark-thing is easy to understand, but if very few use it, then its not relevant if it's easy to understand or not.
Agreed. But the primary concern is the applications used to find an abuse address for a specific IP address, they have a hard time finding anything in a freetext format... We have to make sure these applications find the correct mail address, if they don't, we haven't solved anything. This is true, I agree that this must be a goal, but abuse-mailbox is not the only way to reach it. Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data), or maybe the port 43 server could be modified to always check for IRT objects for inetnum/inetnum6 queries and report the address in a comment at the top of the reply with big eye-catching ASCII art. So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools.
Im glad we can agree on something. And you're right, abuse-mailbox entered in each customer inetnum objects is not exactly the only way to do it. Yes, it might be a good idea to just have an "Abuse-Whois", abuse.ripe.net, enter an IP adresse and you get the corresponding abuse address and nothing else! I believe tool-writers can do anything which is not freetext.
I think that there is a consensus that there is the need for a method to look up the abuse desk address for an IP address, and I believe that irt objects (which have the big advantage of existing) are fit to this.
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. No, you are getting it backward: this is the problem with abuse-mailbox or abuse-c.
Yes, but not with abuse in the maintainer.
Next problem is the idea behind IRT, apparently it is to be used by companies who outsource handling of abuse - we don't. If I should use this It may support outsourcing, but I can't see why this would be a problem. I set up an IRT object for an ISP with an internal abuse desk and found it appropriate for my needs. Can you be more clear?
object it should have a normal mnt-by attribute and the following fields either removed or made optional: address, signature, encryption, auth. I would not strongly oppose to this, but I can't see how it would make easier to deploy IRT objects. It's not like you do not already have an address or a PGP key...
Well, I believe it would be easier to deploy IRT if LIRs wouldn't have to create encryptions, simply because it would be administrativly easier. If it did not matter how many LIRs create the object then it wouldn't be a problem with these mandatory attributes, but in this case we haven't achieved anything unless almost all LIRs create it. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc@jay.net Personal email: chr@corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net
On Feb 09, Christian Rasmussen <chr@jay.net> wrote:
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse? Of course not. But how many inetnum objects have these remarks? How is this relevant to what we are discussing? It is very relevant for your argument, you say this remark-thing is easy to understand, but if very few use it, then its not relevant if it's easy to understand or not. No, I'm not saying this. My point is that if is too difficult for users to find an abuse@example.com address when there is some text asking them to use it then it will probably be at least as difficult finding it when advertised only with something like "abuse-mailbox".
Yes, it might be a good idea to just have an "Abuse-Whois", abuse.ripe.net, enter an IP adresse and you get the corresponding abuse address and nothing else! It's a good idea, I think it could be easily implemented as a proxy, I'd like to know NCC's opinion about this.
Yes, but not with abuse in the maintainer. This requires defining new semantics for the mntner object. It would be possible, but we already have irt objects which are a more complete solution which exists right now. Let's try to fix them (if there is something to fix) before starting designing something new.
BTW, why don't you try creating an IRT object? I know somebody who yesterday registered one after reading this thread, and it took only a few minutes to him (after understanding that the TI marketing in the documentation should be ignored). -- ciao, | Marco | [4525 acN6O2k9DLSLs]
Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse?
Actually, yes. The only class of users for which equivalence is reasonable is humans who are competent in English. Non-human users (such as automated reporting tools), and to some extent non-anglophone humans, can be expected to have problems.
Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data),
Not a web page. Please, not a web page! If you _must_ use a web page, please cast the query and response formats in stone so that the result is scriptable. (Actually, there's nothing wrong with providing a human-friendly web interface per se. What I have a problem with is providing no automation-friendly interface. There is a strong tendency these days to consider a webpage as enough for all purposes, which it usually isn't.)
So far only one tool writer contributed to this thread, and he reported that both abuse-mailbox and irt could be used by his tools.
I'm a tool writer, though I haven't written any tools for this, largely because there is so little standardization among the various IP registries on query and response formats, and so many netblocks use human-targeted "remarks:" or equivalent to provide critical info. I would love it if we had something like abuse-mailbox:, especially if it had buyin from other IP registries (ARIN, registro.br, KRNIC, etc). Whether it actually is abuse-mailbox: or the IRT stuff is more or less irrelevant to me; buyin from others, quick deployment, and a format specified clearly enough to make queries automatable are much more important to me than the details of the spec. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Maybe RIPE could provide a web page to query the DB for abuse desk addresses (which would report no other data),
Not a web page. Please, not a web page!
If you _must_ use a web page, please cast the query and response formats in stone so that the result is scriptable. (Actually, there's We were discussing a way to provide this information to *users*. Computers can already access it by querying for the IP address and using
On Feb 09, der Mouse <mouse@Rodents.Montreal.QC.CA> wrote: the -c flag. -- ciao, | Marco | [4523 polNcUKVxyW.g]
On Mon, Feb 09, 2004 at 01:07:30PM +0100, Marco d'Itri wrote:
I looked at the inetnum object CISBRD-CUST-ADSL-113, one of these created by you for your broadband customers: it contains in the remarks attributes a well visible notice about where complaints should be sent, yet you say that you still get them at your personal email address. Do you really think that users would understand better if they read "abuse-mailbox: user@example.com" instead of that sentence in english which explains what the allocation is for and who should be notified of abuse? I do not pretend to be an expert in user interfaces, but I think that, for a random user, natural language should be easier to understand than something like "abuse-mailbox".
I think that there is a consensus that there is the need for a method to look up the abuse desk address for an IP address, and I believe that irt objects (which have the big advantage of existing) are fit to this.
The problem is that over 10% of the inetnum objects contain a remarks: attribute to an abuse contact. With this amount of usage, I think you can justify the creation of a dedicated attribute, which is not free-form and users don't have to rely on the string around it to find the correct address. MarcoH
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}'
On 06.02 17:08, Peter Koch wrote:
So, why do you believe "they"'re going to change their attitude? First of all this ssemms to be an issue of the presentation format. One could have a cleaner db design with abuse-c-handle and still show it in the form suggested above.
give them a chance... maybe 50% (I'm an optimist) of misplaced reportsa will disappear. for the others, you can still tell your colleagues just to drop it, or sent back a mail "read the abuse-email: contact, asshole"...
An even easier solution would be a dedicated server:
whois -h abuse.ripe.net 137.43.0.0
and you will think "they" would ever use THIS? I thought we are talking about efficient solution, not an easy one ;-) P.S. Yes, I think abuse-email: should be right name for the attribute... -- 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. He who laughs last thinks slowest.
On 6 Feb 2004, at 16:08, Peter Koch wrote:
So, why do you believe "they"'re going to change their attitude?
That's the marketing task. 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. Niall
participants (8)
-
Christian Rasmussen -
der Mouse -
Marco d'Itri -
MarcoH -
Matus UHLAR - fantomas -
Niall O'Reilly -
Peter Koch -
Randy Bush