[db-wg] Draft Minutes of the RIPE 52 DB-WG meeting

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 at 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.
>
>  
>