Proposed changes for abuse
Dear Colleagues, We've gone over the changes discussed and agreed on for improving the ability to find abuse information in the RIPE database, and have come up with the following modifications. Please have a look. We will be making announcements once final agreement is done, and adding a URL to the banner and dbupdate messages. Two things did not make it into this proposal from our side. One is that we find the name "IRT" somewhat confusing, but we have no specific proposal to change it. The second is a proposal to change the order of objects in query results, which will be sent as a separate proposal, since it is not very related and might cause controversy. -- Shane Kerr Software Manager RIPE NCC Following discussions in the Database Working Group at RIPE 49, we have prepared a proposal to make changes to the whois server software. The changes we propose are: o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature, o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, ORGANISATION, INETNUM, and INET6NUM objects, o To provide an option to display only key attributes and abuse contacts, o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory, o To change the behaviour of the '-c' switch in whois queries. We will announce the changes on our website. We will also contact any third-party software developers who rely on the RIPE Database for abuse contact information. You can read the minutes from the Database Working Group discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00469.html (1) Adding the "abuse-mailbox:" Attribute We will add a new attribute to the following object types: INETNUM INET6NUM PERSON ROLE IRT ORGANISATION MNTNER This optional attribute will contain at least one e-mail address. It will tell users where to send abuse complaints or queries. (The proposed templates for the above objects are at the end of this document.) The description of the new attribute will be the same in all objects: abuse-mailbox: Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:". As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@localhost trouble: for abuse reports, not info@localhost nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE We will replace this with: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@localhost admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@localhost remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@localhost 20050101 source: RIPE (2) Hiding Attributes That Contain E-Mail Addresses Finding the right e-mail address for abuse reports can be confusing. There is currently no easy way to find this information in the RIPE Database. Users often send mail to every e-mail address they see in a query result. To avoid this, we will hide all attributes that contain e-mail addresses from the default output of a whois query for an address. When a user looks up an address, the results may include the following objects: INETNUM INET6NUM ROUTE ROUTE6 ORGANISATION PERSON ROLE By default, MNTNER objects are not shown, but they are often also queried to get contact information. For each of the object types, the following attributes contain e-mail addresses: INETNUM: notify, changed INET6NUM: notify, changed ROUTE: notify, changed ROUTE6: notify, changed ORGANISATION: e-mail, notify, changed PERSON: e-mail, notify, changed ROLE: e-mail, trouble, notify, changed For each address range returned, if there is at least one "abuse-mailbox:" attribute in any of the returned objects, the attributes mentioned above will be removed from the output. If there is no "abuse-mailbox:" attribute, only "notify:" and "changed:" attributes will be filtered out. If an attribute of an object is changed, a comment will be added, to avoid confusion. Users can turn off this suppression. To make this possible, we will implement a '-B' flag. As an example: $ whois 10.0.0.10 Might currently give the following result: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE After the change, the result will be: % Note: this output has been filtered. inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 nic-hdl: ME1-RIPE mnt-by: I-MNT source: RIPE To see the unmodified result, users should type in: $ whois -B 10.0.0.10 (3) Adding 'abuse output' Option To help authors of tools or users who are only interested in the abuse contacts for IP addresses, we will implement a brief output mode. If a user types '-b' when querying the RIPE Database, they will only see the key attributes of address ranges and the "abuse-mailbox:" attribute. This switch will also imply '-c', which requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It will only work with address space related queries. Here is an example: $ whois 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE abuse-mailbox: ripe-dbm@localhost status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@localhost nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@localhost 20050101 abuse-mailbox: ripe-dbm-person@localhost source: RIPE So: $ whois -b 10.0.0.0 Will return: % Note: this output has been filtered. % Only primary keys and abuse contact will be visible. inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost This output will not generate valid objects, and there will be no object separators. If two ranges are returned after making a query, an object separator will be inserted between groupings. Therefore, the output will look like this: inetnum: 10.0.0.0 - 10.0.0.255 abuse-mailbox: ripe-dbm@localhost abuse-mailbox: ripe-dbm-person@localhost (*) inetnum: 10.0.1.0 - 10.0.0.255 abuse-mailbox: ripe-dbm-person-2@localhost (*) Attributes marked by (*) are taken from the person object retrieved by a recursive lookup. (4) Modifications on the IRT Object We will change the template for the IRT object will be changed. You will no longer need a KEY-CERT object to create an IRT object. Currently, the template for the IRT object is: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] "signature:" and "encryption:" attributes need existing key-cert objects. The Anti-spam Working Group asked us to make these objects optional. You can read an archive of this discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00452.html The template for irt objects will be: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Therefore, the object below would be valid: irt: irt-someorg-zz address: address for the irt phone: +11 22 3344556 fax-no: +11 22 3344556 e-mail: contact@localhost admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@localhost 20050505 source: RIPE We will automate this process, so that help from the RIPE Database Management will no longer be necessary create IRT objects. (5) Changing the behaviour of '-c' option in whois queries Currently, the -c option requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It does not return any related IRT objects. This will change, so that -c will treat IRT objects as contacts and do recursive lookups on related IRT objects. Here is an example: $ whois -c 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . After the change, the result will be: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info@localhost 20050101 source: RIPE person: TEST1-RIPE . . irt: IRT-TEST . . (6) Modified Templates inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** 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-domains: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** 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-domains: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [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] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] 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] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [ ] ** org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [ ] ** upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Rows that are marked with '**' are additions to the templates.
Hi *
We've gone over the changes discussed and agreed on for improving the ability to find abuse information in the RIPE database, and have come up with the following modifications. Please have a look.
I have one Point that I still not get about this.
abuse-mailbox:
Specifies the e-mail address to which abuse complaints should be sent.
An e-mail address as defined in RFC 2822.
There were discussins of changing the 'changed:' from RFC2822 email-adresses to References (Person/Role). Now we introduce another RFC2822 attribute. In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here. My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example. This would make it imho easier to maintain for larger organisations. It would not make it more complicated for small organisations (the tech-c gets an abuse-mailbox, and the inetnum an abuse-c in the inetnum). And everything else proposed in ordering and behaviour of the flags can in the same way be incorporated with that. But maybe I really miss something 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
Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> wrote:
abuse-mailbox:
Specifies the e-mail address to which abuse complaints should be sent.
[...]
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse,
seconded.
My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example.
There seems to be an important difference between an "abuse-mailbox:" in an inetnum, route, ... object and in a person, role, ... object. For the first group it denominates the contect when the object "hosts" the source of the complaint, while for the second group it specifies a purpose specific alternative address. I'm neither sure mixing these is a good idea nor do I understand whether the alternative address will take off. Is it meant to make me able to re-route any abuse complaints targeted at myself to, say, abuse@example.com? What happens if the same person is listed as contact for different organisations, so this re-routing would have to be context sensitive? -Peter
Hmmm,
Is it meant to make me able to re-route any abuse complaints targeted at myself to, say, abuse@example.com? What happens if the same person is listed as contact for different organisations, so this re-routing would have to be context sensitive?
I think this Problem ist not realy abuse-specific. When i work for to orgs, my org-A mail should go there, but my org-B stuff to my org-B mailbox. (also for admin/tech stuff). Often this person has more then one Person Object anyway in the context of the different Organisations (which migt even be maintained by the LIR and not the Person itself). my 0.02EUR -- 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 Feb 16, Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> wrote:
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here.
My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example. Agreed. Note that this "reference" is irt-mnt. It's annoying that requests to have IRT records returned by default have been ignored. I do not remember anybody arguing against this, and without this IRT records are just dead.
-- ciao, Marco
Marco d'Itri wrote:
On Feb 16, Ulrich Kiermayr <ulrich.kiermayr@univie.ac.at> wrote:
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here.
My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example.
Agreed. Note that this "reference" is irt-mnt. It's annoying that requests to have IRT records returned by default have been ignored. I do not remember anybody arguing against this, and without this IRT records are just dead.
100% agreed. Then let me turn that a bit. return what is in mnt-irt by default, add abuse-mailbox to things beeing someone. and permit Person/Roles in the 'mnt-irt:' attribute for those that do not want to bother with the referencing/gpg/crypto stuff. (irt is more of a role than a maintainer anyway) and no RFC2822 email in objects that describe a ressource. and modify the querying (-c, -b) to return that properly on first sight. 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
My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example.
Agreed. Note that this "reference" is irt-mnt. It's annoying that requests to have IRT records returned by default have been ignored. I do not remember anybody arguing against this, and without this IRT records are just dead.
Seconded. Why was this request ignored? Regards, - Håvard
Havard Eidnes wrote:
My view. It is valid to add the abuse mailbox to objects that describe Prrsons or Groups of them (person:, role:, organisation:), but to implement a reference to them for objects that describe ressources (inetnum, inet6num, route, ....). 'abuse-c:' for example.
Agreed. Note that this "reference" is irt-mnt. It's annoying that requests to have IRT records returned by default have been ignored. I do not remember anybody arguing against this, and without this IRT records are just dead.
Seconded.
Why was this request ignored?
We did note the request, but did not feel that there was any consensus for this on either the mailing list or at the RIPE meeting. I think it did not appear in the minutes as an agreed action. We *did* propose IRT objects appear when the "-c" switch is used, or when the new "-b" switch is used, since in these cases users know what they are doing (hopefully). There were two ideas that we discussed when trying to firm up the propsal: 1. Return IRT for all queries, when present as an "mnt-irt:". This one should not be too controversial, I think. Unless somebody opposes this, the proposal can be updated accordingly. 2. Make "-c" the default. I like this one myself, but I can see why there were objections to it. I like it because it lets network administrators insure that abuse complaints go to the right place in the hierarchy, and does not prevent users from seeing the entire view of the database if they want. (I think this gives most of the benefits of APNIC's use of "hidden" assignments without the drawbacks.) But it could be confusing for some users. Can we get some feedback on these two ideas here? -- Shane Kerr RIPE NCC
1. Return IRT for all queries, when present as an "mnt-irt:". This negates the main selling point of IRT objects, the ability to apply one to the less specific inetnum/inetnum6 object instead of having to add
On Feb 17, Shane Kerr <shane@ripe.net> wrote: the attribute to every most specific object. I still think that the first applicaple IRT record should be returned by default for queries.
2. Make "-c" the default.
I like this one myself, but I can see why there were objections to it. I If this would have the effect of returning a less specific inetnum/inetnum6 object then I consider it too much confusing (unless both objects are returned).
-- ciao, Marco
On 16 Feb 2005, at 17:39, Ulrich Kiermayr wrote:
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here.
On 6 May 2004, at 11:39, Niall O'Reilly wrote:
Making the _same_ distinguished attribute available in both primary (inet*num, AS) and secondary (reference-targets: person, role, org, irt) objects gives the widest scope for maintainers to do what is _convenient for them_ whilst retaining overall consistency.
Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
Niall O'Reilly wrote:
On 16 Feb 2005, at 17:39, Ulrich Kiermayr wrote:
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here.
On 6 May 2004, at 11:39, Niall O'Reilly wrote:
Making the _same_ distinguished attribute available in both primary (inet*num, AS) and secondary (reference-targets: person, role, org, irt) objects gives the widest scope for maintainers to do what is _convenient for them_ whilst retaining overall consistency.
This was what we thought the consensus was. I think the history was: - proposal to add "abuse-mailbox:" to INETNUM objects - concern with this, suggestion to put in contacts - concern that this was too hard, and confusing - suggestion to do both There seems to be a lot of concern with "abuse-mailbox:" in INETNUM and INET6NUM. Perhaps the easiest way forward is to exclude them at this time, and then add them later if problems persist? -- Shane Kerr RIPE NCC
On Feb 17, Shane Kerr <shane@ripe.net> wrote:
There seems to be a lot of concern with "abuse-mailbox:" in INETNUM and INET6NUM. Perhaps the easiest way forward is to exclude them at this time, and then add them later if problems persist? This looks like a good idea.
-- ciao, Marco
On Thu, Feb 17, 2005 at 12:03:37PM +0100, Shane Kerr wrote:
Niall O'Reilly wrote:
On 16 Feb 2005, at 17:39, Ulrich Kiermayr wrote:
In my opinion this aproach is wrong. an inetnum or route does not have an email or even read emails. There is *someone* there handling abuse, who has an email (maybe designated for abuse) that is reading malis and hopefully doing something. What do I miss here.
On 6 May 2004, at 11:39, Niall O'Reilly wrote:
Making the _same_ distinguished attribute available in both primary (inet*num, AS) and secondary (reference-targets: person, role, org, irt) objects gives the widest scope for maintainers to do what is _convenient for them_ whilst retaining overall consistency.
This was what we thought the consensus was.
I think the history was:
- proposal to add "abuse-mailbox:" to INETNUM objects - concern with this, suggestion to put in contacts - concern that this was too hard, and confusing - suggestion to do both
There seems to be a lot of concern with "abuse-mailbox:" in INETNUM and INET6NUM. Perhaps the easiest way forward is to exclude them at this time, and then add them later if problems persist?
Please do include them, I understand the concern, but it took I think over 2 years to get to this compromise, please implement it as we Really Need It Now. I also think it's a good compromise, for people who want to do it simple, there is abuse-mailbox, for people wanting to do it properly, there is the IRT object. Regards, Andre Koopal MCI
-- Shane Kerr RIPE NCC
On Feb 17, Andre Koopal <andre.koopal@nld.mci.com> wrote:
I also think it's a good compromise, for people who want to do it simple, there is abuse-mailbox, for people wanting to do it properly, there is the IRT object. IRT objects will never work until they will be kept hidden.
-- ciao, Marco
On Feb 17, Marco d'Itri <md@Linux.IT> wrote:
On Feb 17, Andre Koopal <andre.koopal@nld.mci.com> wrote:
I also think it's a good compromise, for people who want to do it simple, there is abuse-mailbox, for people wanting to do it properly, there is the IRT object. IRT objects will never work until they will be kept hidden. s/until/while/
-- ciao, Marco
On Thu, Feb 17, 2005 at 01:20:22PM +0100, Marco d'Itri wrote:
On Feb 17, Marco d'Itri <md@Linux.IT> wrote:
On Feb 17, Andre Koopal <andre.koopal@nld.mci.com> wrote:
I also think it's a good compromise, for people who want to do it simple, there is abuse-mailbox, for people wanting to do it properly, there is the IRT object. IRT objects will never work until they will be kept hidden. s/until/while/
Ok, this can be requested as an extra modification to the whois interface, and I completely agree to that modification btw, but that doesn't have to block implementation of the already agreed changed. So please do just implement abuse-mailbox now. Regards, Andre
There seems to be a lot of concern with "abuse-mailbox:" in INETNUM and INET6NUM. Perhaps the easiest way forward is to exclude them at this time, and then add them later if problems persist? Please do include them, I understand the concern, but it took I think over 2 years to get to this compromise, please implement it as we Really Need It Now.
<aol>me too</aol>
Shane, I disagree with your suggestion
There seems to be a lot of concern with "abuse-mailbox:" in INETNUM and INET6NUM. Perhaps the easiest way forward is to exclude them at this time, and then add them later if problems persist?
and agree very much with Andre's request:
Please do include them, I understand the concern, but it took I think over 2 years to get to this compromise, please implement it as we Really Need It Now.
Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE
Shane, Good stuff. I believe that what you describe matches the consensus we reached. On 16 Feb 2005, at 16:44, Shane Kerr wrote:
The changes we propose are:
o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature,
Fine.
o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, ORGANISATION, INETNUM, and INET6NUM objects,
Fine.
o To provide an option to display only key attributes and abuse contacts,
Fine.
o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory,
Fine.
o To change the behaviour of the '-c' switch in whois queries.
No opinion, but that's my fault. 8-) Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
On Wed, Feb 16, 2005 at 08:44:52PM +0000, Niall O'Reilly wrote:
Shane,
Good stuff.
I believe that what you describe matches the consensus we reached.
I totally agree, looks good. MarcoH
At 05:44 PM 16-02-05 +0100, Shane Kerr wrote:
There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:".
Then shouldn't the 'trouble:' attribute be marked as deprecated? -Hank
There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:".
Doesn't this change the associated semantics while just copying the contents? Is this a good idea? Regards, - Håvard
There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:".
Last week I asked the following and haven't heard any comments about it: !Then shouldn't the 'trouble:' attribute be marked as deprecated? Perhaps I wasn't clear. If the proposal is to change all current trouble attributes to either remarks or abuse-mailbox, then in the future, if we don't deprecate the trouble attribute, anyone can add a new role object with a trouble attribute, and it *won't* be converted. So shouldn't trouble be deprecated? -Hank
On 2005-02-23 08:52:07 +0200, Hank Nussbacher wrote:
There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:".
Last week I asked the following and haven't heard any comments about it:
!Then shouldn't the 'trouble:' attribute be marked as deprecated?
Perhaps I wasn't clear. If the proposal is to change all current trouble attributes to either remarks or abuse-mailbox, then in the future, if we don't deprecate the trouble attribute, anyone can add a new role object with a trouble attribute, and it *won't* be converted.
So shouldn't trouble be deprecated?
I agree it should be deprecated. It is free-text and its semantics is not very clear, which makes it not very different than "remarks:" attribute. -engin
-Hank
-- Engin Gunduz RIPE NCC Software Engineering Department
participants (12)
-
Andre Koopal -
Engin Gunduz -
Hank Nussbacher -
Havard Eidnes -
MarcoH -
md＠Linux.IT -
Niall O'Reilly -
Peter Koch -
Randy Bush -
Ruediger Volk, Deutsche Telekom T-Com - TE142 -
Shane Kerr -
Ulrich Kiermayr