Last week we updated all our allocations with an IRT object. However, this ended out to be quite useless as the IRT object isn't shown in a default query, which 99% of joe-user will do, they don't know to specify -c. Another problem I noticed is that the irt-nfy isn't suppressed if you do specify -c. So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query. Regards, Andre Koopal MCI
So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query. I second this. IRT objects are still not useful for most users unless
On May 23, Andre Koopal <andre.koopal@nld.mci.com> wrote: they will be returned by default queries. -- ciao, Marco
Andre Koopal wrote:
Last week we updated all our allocations with an IRT object.
However, this ended out to be quite useless as the IRT object isn't shown in a default query, which 99% of joe-user will do, they don't know to specify -c.
Another problem I noticed is that the irt-nfy isn't suppressed if you do specify -c.
So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query.
I definately think that the "irt-nfy:" attribute should be hidden - this was basically an oversight with the abuse change proposal on my side. The "upd-to:" and "mnt-nfy:" should also be filtered. As for the "-c" flag, I would propose that the default behaviour should be: 1. Perform a lookup that works the same as "-c" today, and if it would return some INETNUM objects, then finish (returning IRT objects as today) 2. If no INETNUM objects would be found, fall back to the current behaviour We could have the "-c" flag change its meaning, to give you the query without consideration for the "mnt-irt:" attribute, just like today. APNIC has a model where members can hide information about their assignments: http://www.apnic.net/news/2004/0930.html By implementing the "-c" change above, the maintainer managing the Whois database records int the RIPE Database could decide which block users would get back on a query. I think that this would give the benefits of the APNIC approach (for me, getting users to the "best" person to help them with their problems), without what I consider a drawback of the APNIC approach (there is "secret" data in the database). A futher suggestion that Wilfried (I think) mentioned to me, was to add "mnt-irt:" to the AUT-NUM object type. -- Shane Kerr RIPE NCC
On May 23, Shane Kerr <shane@ripe.net> wrote:
1. Perform a lookup that works the same as "-c" today, and if it would return some INETNUM objects, then finish (returning IRT objects as today) I think that returning by default only the top level object would be a bad idea. Contact information are already hidden by the abuse-mailbox attribute in the IRT record, so this would not make things simpler for users looking for an abuse desk contact and would be annoying for everybody else.
If you really want to help users to quickly find a good contact then please add in a prominent place on www.ripe.net a form like http://www.cert.pl/cgi-bin/ipdig.pl, which automatically looks for a the best possible abuse contact and presents only that. This is trivial to implement and would serve the needs of most of the whois web interface users. -- ciao, Marco
On Mon, May 23, 2005 at 12:20:18PM +0200, Marco d'Itri wrote:
On May 23, Shane Kerr <shane@ripe.net> wrote:
1. Perform a lookup that works the same as "-c" today, and if it would return some INETNUM objects, then finish (returning IRT objects as today) I think that returning by default only the top level object would be a bad idea. Contact information are already hidden by the abuse-mailbox attribute in the IRT record, so this would not make things simpler for users looking for an abuse desk contact and would be annoying for everybody else.
It doesn't return the top-level object, it returns the most specific inetnum together with the irt object specified in the most specific inetnum with an irt object. To be honest exactly what you expect.
If you really want to help users to quickly find a good contact then please add in a prominent place on www.ripe.net a form like http://www.cert.pl/cgi-bin/ipdig.pl, which automatically looks for a the best possible abuse contact and presents only that. This is trivial to implement and would serve the needs of most of the whois web interface users.
I am not against it, but getting users to use something else will not solve the problem. We always need 'whois -h whois.ripe.net ip-number' returns the wanted information. Regards, Andre Koopal MCI
On May 23, Andre Koopal <andre.koopal@nld.mci.com> wrote:
I think that returning by default only the top level object would be a bad idea. Contact information are already hidden by the abuse-mailbox attribute in the IRT record, so this would not make things simpler for users looking for an abuse desk contact and would be annoying for everybody else. It doesn't return the top-level object, it returns the most specific inetnum together with the irt object specified in the most specific inetnum with an irt object. To be honest exactly what you expect. Yes, this is what I meant, and I do not think that it is what people expect when doing a whois query.
If you really want to help users to quickly find a good contact then please add in a prominent place on www.ripe.net a form like http://www.cert.pl/cgi-bin/ipdig.pl, which automatically looks for a the best possible abuse contact and presents only that. This is trivial to implement and would serve the needs of most of the whois web interface users. I am not against it, but getting users to use something else will not solve the problem. We always need 'whois -h whois.ripe.net ip-number' returns the wanted information. Reality check: most of the people who need this do not even know what a command line is.
-- ciao, Marco
On Mon, May 23, 2005 at 05:53:27PM +0200, Andre Koopal wrote:
Reality check: most of the people who need this do not even know what a command line is.
So they use a webpage someone wrote that basicly does the same thing.
But don't assume we control the tools they use.
That was one of the sidelines on the abuse-mailbox: proposal and the change in default behaviour. Everybody filtering for mail addresses is lucky and doesn't need to change things. For the rest, they almost have to dig up some docs to see what changed. Oh and I think the NCC has a list these days of known toolbuilders... MarcoH
On Mon, May 23, 2005 at 12:07:23PM +0200, Shane Kerr wrote:
Andre Koopal wrote:
Last week we updated all our allocations with an IRT object.
However, this ended out to be quite useless as the IRT object isn't shown in a default query, which 99% of joe-user will do, they don't know to specify -c.
Another problem I noticed is that the irt-nfy isn't suppressed if you do specify -c.
So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query.
I definately think that the "irt-nfy:" attribute should be hidden - this was basically an oversight with the abuse change proposal on my side. The "upd-to:" and "mnt-nfy:" should also be filtered.
As for the "-c" flag, I would propose that the default behaviour should be:
1. Perform a lookup that works the same as "-c" today, and if it would return some INETNUM objects, then finish (returning IRT objects as today)
2. If no INETNUM objects would be found, fall back to the current behaviour
We could have the "-c" flag change its meaning, to give you the query without consideration for the "mnt-irt:" attribute, just like today.
APNIC has a model where members can hide information about their assignments:
http://www.apnic.net/news/2004/0930.html
By implementing the "-c" change above, the maintainer managing the Whois database records int the RIPE Database could decide which block users would get back on a query. I think that this would give the benefits of the APNIC approach (for me, getting users to the "best" person to help them with their problems), without what I consider a drawback of the APNIC approach (there is "secret" data in the database).
A futher suggestion that Wilfried (I think) mentioned to me, was to add "mnt-irt:" to the AUT-NUM object type.
As I don't see any more comments on this, have we already reached consensus? Wilfried: how to best proceed with this? If there is hardly any discussion about this, it seems silly to wait for a RIPE meeting on this. Regards, Andre Koopal MCI
On May 27, Andre Koopal <andre.koopal@nld.mci.com> wrote:
As I don't see any more comments on this, have we already reached consensus? Hiding more-specific objects by default is such a major change that I do not think it can be deployed after a discussion among just three or four people.
-- ciao, Marco
Hi, On Fri, May 27, 2005 at 07:51:31PM +0200, Marco d'Itri wrote:
As I don't see any more comments on this, have we already reached consensus? Hiding more-specific objects by default is such a major change that I do not think it can be deployed after a discussion among just three or four people.
Nobody wants to hide more-specifics. The goal is to show the inetnum: object (as before) and, in addition to that, the most-specific available irt: object. *In the default response*. So if the inetnum: has its own mnt-irt: then show it, but if there is only one for the encompassing /16 (or whatever), then show the "parent" irt: - otherweise irt: is pretty useless. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Fri, May 27, 2005 at 10:05:34PM +0200, Gert Doering wrote:
Hi,
On Fri, May 27, 2005 at 07:51:31PM +0200, Marco d'Itri wrote:
As I don't see any more comments on this, have we already reached consensus? Hiding more-specific objects by default is such a major change that I do not think it can be deployed after a discussion among just three or four people.
Nobody wants to hide more-specifics.
The goal is to show the inetnum: object (as before) and, in addition to that, the most-specific available irt: object. *In the default response*.
So if the inetnum: has its own mnt-irt: then show it, but if there is only one for the encompassing /16 (or whatever), then show the "parent" irt: - otherweise irt: is pretty useless.
That is exactly what I mean. And I don't see this as a discussion between 3 or 4 people, everybody can read this and participate. So the rest either doesn't care or agrees :-) Regards, Andre Koopal
On Fri, May 27, 2005 at 11:32:49PM +0200, Andre Koopal wrote:
On Fri, May 27, 2005 at 10:05:34PM +0200, Gert Doering wrote:
Hi,
On Fri, May 27, 2005 at 07:51:31PM +0200, Marco d'Itri wrote:
As I don't see any more comments on this, have we already reached consensus? Hiding more-specific objects by default is such a major change that I do not think it can be deployed after a discussion among just three or four people.
Nobody wants to hide more-specifics.
The goal is to show the inetnum: object (as before) and, in addition to that, the most-specific available irt: object. *In the default response*.
So if the inetnum: has its own mnt-irt: then show it, but if there is only one for the encompassing /16 (or whatever), then show the "parent" irt: - otherweise irt: is pretty useless.
That is exactly what I mean.
And I don't see this as a discussion between 3 or 4 people, everybody can read this and participate. So the rest either doesn't care or agrees :-)
And it is going now as I feared it. Because most seem to either agree or don't care there is hardly any discussion and as a result notting seems to be happening. Wilfried: how can I make this an official proposal? Should I use the new policy proposal process? Regards, Andre Koopal MCI
On May 27, Gert Doering <gert@space.net> wrote:
So if the inetnum: has its own mnt-irt: then show it, but if there is only one for the encompassing /16 (or whatever), then show the "parent" irt: - otherweise irt: is pretty useless. I agree with this, but this is not how I read the original proposal. If this is the new proposed behaviour for default database queries then I fully support it.
-- ciao, Marco
participants (5)
-
Andre Koopal -
Gert Doering -
MarcoH -
md＠Linux.IT -
Shane Kerr