Dear Colleagues, The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27. ***************************************************************** These changes alter the default output of the Whois server. If you need the old output, you can get it by using the "-B" and "-G" flags, like this: whois -B -G 193.0.1.17 ***************************************************************** The current implementation is different from the original proposal in this way: - INETNUM and INET6NUM object types will *not* have the "abuse-mailbox:" attribute added. The reason for not adding the "abuse-mailbox:" attribute to the INETNUM and INET6NUM object types is that there was no consensus to add these. Some people supported it and some people did not. It is easier to add attributes than to delete them. Anyone in favour of adding this attribute can attempt to create consensus within the Database Working Group. We have also implemented the proposal to change the order of objects in query results. A revised proposal is attached. As well as the above change: - It explicitly states that "trouble:" will be deprecated. - Some templates and examples were not correct, and have been fixed. -- Shane Kerr Software Manager RIPE NCC 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, and ORGANISATION 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: 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:". The "trouble:" attribute will be deprecated. As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@example.com trouble: for abuse reports, not info@example.com nic-hdl: TESTROLE1-RIPE changed: info@example.com 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@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@example.com remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@example.com 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 status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 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 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 status: ALLOCATED PI mnt-by: I-MNT mnt-irt: IRT-I changed: ripe-dbm@ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 abuse-mailbox: ripe-dbm-person@ripe.net 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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net 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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net (*) inetnum: 10.0.1.0 - 10.0.0.255 e-mail: ripe-dbm-person-2@ripe.net (*) 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@example.com admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@example.com 20050101 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@example.com 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@example.com 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] 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] 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] [inverse key] ** 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] [inverse key] ** 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] [inverse 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] [ ] 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] [inverse key] ** 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] [inverse key] ** 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.
On Thu, Apr 21, 2005 at 06:06:16PM +0200, Shane Kerr wrote:
The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27.
Hi there, Looks like these changes weren't made yesterday. Is there a revised planning available ? Grtx, MarcoH
On Thu, Apr 28, 2005 at 04:28:11PM +0200, MarcoH wrote: Marco,
The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27.
Hi there,
Looks like these changes weren't made yesterday. Is there a revised planning available ?
Due to unforeseen circumstances (sickness) there has been a little delay. These changes are in production now. -- Kind regards, Katie Petrusha RIPE NCC
On 28 Apr 2005, at 16:05, Katie Petrusha wrote:
These changes are in production now.
I'm getting rejection for a syntax error. This seems to contradict the documentation. In response to whois -h whois.ripe.net -- '-v role' I get abuse-mailbox Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. In RFC 2822, I find address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] display-name = phrase Yet, I get the following in response to my update request. abuse-mailbox: Contact for SPAM <abuse@ucd.ie> ***Error: Syntax error in "Contact for SPAM <abuse@ucd.ie>" abuse-mailbox: Contact for other abuse <security@ucd.ie> ***Error: Syntax error in "Contact for other abuse <security@ucd.ie>" What's the story? 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 Apr 29, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Yet, I get the following in response to my update request.
abuse-mailbox: Contact for SPAM <abuse@ucd.ie> ***Error: Syntax error in "Contact for SPAM <abuse@ucd.ie>" abuse-mailbox: Contact for other abuse <security@ucd.ie> ***Error: Syntax error in "Contact for other abuse <security@ucd.ie>"
I suppose that the parser only accepts an addr-spec and not complete addresses with comments. I really really hope that this will not be changed, because the purpose of abuse-mailbox is to help stupid people who write simple-minded autocomplaints scripts, and asking them to implement a full RFC 2822 parser is a recipe for troubles. -- ciao, Marco
Marco d'Itri wrote:
On Apr 29, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Yet, I get the following in response to my update request.
abuse-mailbox: Contact for SPAM <abuse@ucd.ie> ***Error: Syntax error in "Contact for SPAM <abuse@ucd.ie>" abuse-mailbox: Contact for other abuse <security@ucd.ie> ***Error: Syntax error in "Contact for other abuse <security@ucd.ie>"
I suppose that the parser only accepts an addr-spec and not complete addresses with comments. I really really hope that this will not be changed, because the purpose of abuse-mailbox is to help stupid people who write simple-minded autocomplaints scripts, and asking them to implement a full RFC 2822 parser is a recipe for troubles.
That is exactly right. It is possible to use comments to indicate which mailboxes are for which type of abuse, by using the "remarks:" attribute: remarks: Contact for SPAM abuse-mailbox: abuse@ucd.ie remarks: Contact for other abuse abuse-mailbox: security@ucd.ie Alternately, using the end-of-line comments: abuse-mailbox: abuse@ucd.ie # contact for SPAM reports abuse-mailbox: security@ucd.ie # contact for other abuse As a side issue, we don't really implement a full RFC 2822 parser. E-mail can look like: some.&#$%~.?+mess@example.com "pretty much anything except chr(34) or chr(64)"@ripe.net We require two names in the part after the '@', because AFAIK there are no TLD's that accept e-mail. The actual rules allow only up to 80 characters, and match this regular expression: ^((([A-Z0-9~#$%&'*+=?^_`{|}~/-]+\.)*[A-Z0-9~#$%&'*+=?^_`{|}~/-]+)|("[^"@\\]+"))@([A-Z0-9-]+(\.[A-Z0-9-]+)+)$ -- Shane
We require two names in the part after the '@', because AFAIK there are no TLD's that accept e-mail. I seem to remember that there are TLDs with MX records. On the top of my head .tk, .io and .tl; others have an A record (sh). jaap
On Fri, Apr 29, 2005 at 10:50:50AM +0200, Jaap Akkerhuis <jaap@NLnetLabs.nl> wrote a message of 8 lines which said:
We require two names in the part after the '@', because AFAIK there are no TLD's that accept e-mail.
I seem to remember that there are TLDs with MX records.
It does not mean they can accept e-mail. Giving the typical setup of a MTA (qualify "unqualified" domains), an address like jaap@nl will be rewritten long before reaching a dutch name server.
It does not mean they can accept e-mail. Giving the typical setup of a MTA (qualify "unqualified" domains), an address like jaap@nl will be rewritten long before reaching a dutch name server.
FWIW: I know a couple of people (probably on this list) who make use of their address@dk Regards, Marcos
> It does not mean they can accept e-mail. Giving the typical setup of a > MTA (qualify "unqualified" domains), an address like jaap@nl will be > rewritten long before reaching a dutch name server. FWIW: I know a couple of people (probably on this list) who make use of their address@dk And I guess that works. Which shows that it is bad practice to make assumptions about whether or not TLDs can accept mail or have other special attributes. One of these day it will start to hunt you. As an example, think about the assumptions that once where made about a tld not longer then 3 (ASCII) chars, and then museum, info and others came along. jaap
We require two names in the part after the '@', because AFAIK there are no TLD's that accept e-mail.
please do not add restrictions which are not in the protocol. and there are current email recipients of the form user@tld. randy
Randy Bush wrote:
no TLD's that accept e-mail.
please do not add restrictions which are not in the protocol.
agreed in the spirit of RFC 3696, if nothing else.
and there are current email recipients of the form user@tld.
As an exercise that's fine, but in this particular case it is calling for trouble. There are some role addresses that should have lower access thresholds, so I'm fine with the test. Even more, it might be useful to check whether the address given ends in a valid TLD and/or an MX RRSet for the domain name eists. -Peter PS: VA had postmaster@va in their SOA and years ago and at that time there was quite some debate about pros and cons already.
no TLD's that accept e-mail. please do not add restrictions which are not in the protocol. agreed in the spirit of RFC 3696, if nothing else.
actually, i was thinking of 2821
and there are current email recipients of the form user@tld. As an exercise that's fine, but in this particular case it is calling for trouble. There are some role addresses that should have lower access thresholds
don't tell others how to manage their email, thank you very much randy
At 06:06 PM 21-04-05 +0200, Shane Kerr wrote: How can one add an abuse-mailbox attribute to an organisation object that is type=LIR? The LIR portal "organisation object editor" doesn't provide that attribute as an option. Thanks, Hank
Dear Colleagues,
The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27.
*****************************************************************
These changes alter the default output of the Whois server.
If you need the old output, you can get it by using the "-B" and "-G" flags, like this:
whois -B -G 193.0.1.17
*****************************************************************
The current implementation is different from the original proposal in this way:
- INETNUM and INET6NUM object types will *not* have the "abuse-mailbox:" attribute added.
The reason for not adding the "abuse-mailbox:" attribute to the INETNUM and INET6NUM object types is that there was no consensus to add these. Some people supported it and some people did not.
It is easier to add attributes than to delete them. Anyone in favour of adding this attribute can attempt to create consensus within the Database Working Group.
We have also implemented the proposal to change the order of objects in query results.
A revised proposal is attached. As well as the above change:
- It explicitly states that "trouble:" will be deprecated.
- Some templates and examples were not correct, and have been fixed.
-- Shane Kerr Software Manager RIPE NCC
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.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, and ORGANISATION 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:
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:". The "trouble:" attribute will be deprecated.
As an example, see the following:
role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@example.com trouble: for abuse reports, not info@example.com nic-hdl: TESTROLE1-RIPE changed: info@example.com 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@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@example.com remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@example.com 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 status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 source: RIPE
person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 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 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 status: ALLOCATED PI mnt-by: I-MNT mnt-irt: IRT-I changed: ripe-dbm@ripe.net 20050101 source: RIPE
person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 abuse-mailbox: ripe-dbm-person@ripe.net 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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net
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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net (*)
inetnum: 10.0.1.0 - 10.0.0.255 e-mail: ripe-dbm-person-2@ripe.net (*)
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@example.com admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@example.com 20050101 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@example.com 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@example.com 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] 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] 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] [inverse key] ** 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] [inverse key] ** 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] [inverse 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] [ ]
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] [inverse key] ** 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] [inverse key] ** 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 Hank,
How can one add an abuse-mailbox attribute to an organisation object that is type=LIR? The LIR portal "organisation object editor" doesn't provide that attribute as an option.
You're right, it is not there. I'm looking at it. I will let you know when abuse-mailbox attribute is added into "organisation object editor". Arife
Thanks, Hank
Dear Colleagues,
The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27.
*****************************************************************
These changes alter the default output of the Whois server.
If you need the old output, you can get it by using the "-B" and "-G" flags, like this:
whois -B -G 193.0.1.17
*****************************************************************
The current implementation is different from the original proposal in this way:
- INETNUM and INET6NUM object types will *not* have the "abuse-mailbox:" attribute added.
The reason for not adding the "abuse-mailbox:" attribute to the INETNUM and INET6NUM object types is that there was no consensus to add these. Some people supported it and some people did not.
It is easier to add attributes than to delete them. Anyone in favour of adding this attribute can attempt to create consensus within the Database Working Group.
We have also implemented the proposal to change the order of objects in query results.
A revised proposal is attached. As well as the above change:
- It explicitly states that "trouble:" will be deprecated.
- Some templates and examples were not correct, and have been fixed.
-- Shane Kerr Software Manager RIPE NCC
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.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, and ORGANISATION 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:
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:". The "trouble:" attribute will be deprecated.
As an example, see the following:
role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse@example.com trouble: for abuse reports, not info@example.com nic-hdl: TESTROLE1-RIPE changed: info@example.com 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@example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse@example.com remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info@example.com 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 status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 source: RIPE
person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 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 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 status: ALLOCATED PI mnt-by: I-MNT mnt-irt: IRT-I changed: ripe-dbm@ripe.net 20050101 source: RIPE
person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm@ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm@ripe.net 20050101 abuse-mailbox: ripe-dbm-person@ripe.net 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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net
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 e-mail: ripe-dbm@ripe.net e-mail: ripe-dbm-person@ripe.net (*)
inetnum: 10.0.1.0 - 10.0.0.255 e-mail: ripe-dbm-person-2@ripe.net (*)
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@example.com admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone@example.com 20050101 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@example.com 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@example.com 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] 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] 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] [inverse key] ** 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] [inverse key] ** 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] [inverse 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] [ ]
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] [inverse key] ** 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] [inverse key] ** 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.
Is it just me or is RIPE Whois Database Free Text Search (Glimpse) not working? I am getting no hits for any search I do. http://www.ripe.net/db/whois-free.html Thanks, Hank
Hi! Same thing: couldn't contact server extsearch.ripe.net:9000: Connection refused, some indices have not been searched. Is there any other way to find all objects I ever changed (i.e. having changed: my@e.mail field)?
Is it just me or is RIPE Whois Database Free Text Search (Glimpse) not working? I am getting no hits for any search I do.
http://www.ripe.net/db/whois-free.html
Thanks, Hank
-- С Уважением, Максим Тульев (MT6561-RIPE, 2:463/253@FIDO)
All, Unfortunately when we looked at this the system was working. We have not noticed any problems over the last few weeks either. The monitoring has been tweaked, and we will get notification if it happens again so that we can investigate the underlying causes. Apologies for the inconvenience. One idea that we have discussed is to remove the Glimpse search, and provide full text search in the Whois server itself. I see several advantages (consistent output format, no arbitrary rate limits, and so on), but only one disadvantage (performance). Unless the working group has a big problem with it, we will probably do some investigation of speed and see if it is possible. -- Shane Kerr RIPE NCC Max Tulyev wrote:
Hi!
Same thing: couldn't contact server extsearch.ripe.net:9000: Connection refused, some indices have not been searched.
Is there any other way to find all objects I ever changed (i.e. having changed: my@e.mail field)?
Is it just me or is RIPE Whois Database Free Text Search (Glimpse) not working? I am getting no hits for any search I do.
http://www.ripe.net/db/whois-free.html
Thanks, Hank
participants (14)
-
Arife Vural -
Hank Nussbacher -
Jaap Akkerhuis -
Katie Petrusha -
MarcoH -
Marcos Sanz/Denic -
Max Tulyev -
md＠Linux.IT -
Niall O'Reilly -
Peter Koch -
Randy Bush -
Randy Bush -
Shane Kerr -
Stephane Bortzmeyer