Hi I think Marco is right that there seemed to be a consensus on the mailing lists for making the whois server return the irt object by default. I was not at the RIPE meeting, but reading the minutes several times it looks like the members at the meeting no longer want that to be the case. There were some quite strong arguments about this in the previous discussion on the mailing list. The general view seemed to be that if this is not implemented in the right way it makes the whole concept of the irt useless. If we get this wrong again, I feel that either the discussions on the mailing list will never end or the irt object will be abandoned. Many people believe the concept of the irt object is important. Also that the implementation of it will make or break the usefullnes of it. Should we therefore take any further proposal through the Policy Development Process? This will ensure that all those who are concerned about it will have their say and a final consensus can be reached. There are a few points I would like to make regarding the discussions today at the meeting and on the mailing list. Firstly, the RIPE NCC will implement this in whatever way is shown by a consensus. We have already looked at the code and worked out roughly how we can implement the change we proposed at the meeting. The complexity is in working out the logic behind the query flags rather than the amount of code we change. If some people are concerned about having another object returned in a default query, there is a way round this. We could reverse the -c flag in the query. So the logic behind the -c flag returns an irt object. If -c is not used in an inet(6)num query, the server adds it. Then any irt object is returned by default in these queries. If -c is used in a query, on its own, the server takes it out. So by using -c you do not get the irt object. The benefit of this is that clueless users will get irt objects as a default. Those who know what they are doing and don't want it, can surpress it. If this is of interest to anyone, I can explain it in more detail with examples. Another point that confused me from the minutes. Returning irt objects with -m? Was this a typo or did you really mean return irt objects for more specific ranges? Is there a use case for this? regards Denis Walker Software Engineering Department RIPE NCC Marco d'Itri wrote:
On Apr 28, Nigel Titley <nigel.titley@uk.easynet.net> wrote:
E. "51.8 RIPE NCC" (return irt: by default) revisited (RIPE NCC)
It was eventually decided that the RIPE NCC client software would add the -c flag to default queries, but that default behaviour would remain as it is.
This is very annoying. We had a clear consensus on the mailing list and NCC even started implementing the needed server changes, but now the proposal has been nullified with a motivation like "it would take too long to be implemented".
Because of the following reasons I believe that the new proposal is, at best, useless: - the official RIPE whois client is irrelevant because it's probably[1] used by only a tiny part of the users base, which very probably is clueful enough to not need that irt records are forced down on them - not being able to rely on support from clients and users was the reason for the original proposal, and the new proposal fails the initial requirement
If NCC really cannot do anything better (but so far I do not believe that it has clearly explained why) then please use your resources to improve the WWW interface instead, which is used much more by inexperienced users. Creating and *prominently* advertising a new query form which would automatically process abuse-mailbox attributes and irt records (and fall back to admin-c/tech-c) for the purpose of finding an abuse contact would be more useful than changing the default settings of the C whois client.
[1] I now have another reason to ask RIPE NCC to publish some statistics about the client info specified with the -V flag.