[Fwd: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1]]
Thanks to Andre for reminding me about that item! I am a tad puzzled, because a DB-WG Action on this reads: 48.6 RIPE NCC To change DB behaviour to return IRT object [Complete] However, neither the web interface nor the RIPE whois client does return the irt information. Rather I get a route object under the heading of % Information related to 'prefix/length ASinfo' Any insight on that? Thanks, Wilfried. -------- Original Message -------- Subject: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1] Date: Tue, 11 Oct 2005 15:28:57 +0200 From: Andre Koopal <andre.koopal@nld.mci.com> To: Wilfried Woeber, UniVie/ACOnet <woeber@cc.univie.ac.at> CC: db-wg@ripe.net, RIPE NCC Meeting Registration <meeting@ripe.net>, wg-chairs@ripe.net References: <434BB603.4050409@cc.univie.ac.at> On Tue, Oct 11, 2005 at 01:54:27PM +0100, Wilfried Woeber, UniVie/ACOnet wrote:
Dear DB-WG folks, Chairs, Meeting!
Here is the 2nd draft of an agenda for the DB-WG next week at RIPE51 in Amsterdam.
For time slot allocation please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-51/meeting-plan.html
Hi Wilfried, A while ago I mailed the db working group to request a changed behavour when you lookup inetnum's. In principle what I would like to see is that when an inetnum is returned, that the IRT object that is relevant to this inetnum is returned as well. For example, if you lookup inetnum '193.78.240' you get that inetnum returned, and the irt-object 'IRT-MCI-NL', as that is specified in the inetnum above: '193.78/15'. Note that this is different then the current -c behavour as that would, in this example' return the inetnum for '193.78/15' instead. Can you add this discussion on the agenda as well? Unfortunately I won't be able to visit the WG session myself, I hope the proposal is clear this way. Regards, Andre Koopal
Best regards, Wilfried. ________________________________________________________________________
A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed)
B. DB Update (N.N., RIPE NCC) [~15 min]
C. Review of security mechanisms in the DB (Peter K., denic.de) [~15 min] . quality of CRYPT-PW, CRYPT-MD5, X.509 . level of vulnerabilty in current dataset
D. State of whois services, developments? (WW144, N.N., RIPE NCC) [~15 min]
E. IRIS pilot frontend to whois (N.N., RIPE NCC) [~10 min]
F. Fact finding: RoutingReg facilities at RIRs (Gert D, SpaceNet) [~15 min]
X. Impact of "PDP" on how the DB-WG operates (WW144) [~15 min] . ref: https://www.ripe.net/ripe/docs/ripe-350.html
Y. Input from other WGs . DNS: secureDNS requirements for the DB
Z. AOB
Wilfried, I'm not 100% sure what the AP is, but let me explain what we have done. We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here: http://www.ripe.net/fcgi-bin/whois?-c+193.78.240 It is possible to change the behaviour further, to make "-c" more useful I think. One way of doing this might be to try to find the "best" reply on a "-c" query. So, something like: - Find the closest matching INETNUM/INET6NUM object with "mnt-irt:" - return the INETNUM/INET6NUM object (along with the IRT object) - If there is no INETNUM/INET6NUM, perform a normal lookup Right now you have to do this on the client side. Anyway, we can certainly discuss this at the working group session. -- Shane Kerr RIPE NCC Wilfried Woeber, UniVie/ACOnet wrote:
Thanks to Andre for reminding me about that item!
I am a tad puzzled, because a DB-WG Action on this reads:
48.6 RIPE NCC To change DB behaviour to return IRT object [Complete]
However, neither the web interface nor the RIPE whois client does return the irt information. Rather I get a route object under the heading of
% Information related to 'prefix/length ASinfo'
Any insight on that? Thanks, Wilfried.
-------- Original Message -------- Subject: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1] Date: Tue, 11 Oct 2005 15:28:57 +0200 From: Andre Koopal <andre.koopal@nld.mci.com> To: Wilfried Woeber, UniVie/ACOnet <woeber@cc.univie.ac.at> CC: db-wg@ripe.net, RIPE NCC Meeting Registration <meeting@ripe.net>, wg-chairs@ripe.net References: <434BB603.4050409@cc.univie.ac.at>
On Tue, Oct 11, 2005 at 01:54:27PM +0100, Wilfried Woeber, UniVie/ACOnet wrote:
Dear DB-WG folks, Chairs, Meeting!
Here is the 2nd draft of an agenda for the DB-WG next week at RIPE51 in Amsterdam.
For time slot allocation please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-51/meeting-plan.html
Hi Wilfried,
A while ago I mailed the db working group to request a changed behavour when you lookup inetnum's.
In principle what I would like to see is that when an inetnum is returned, that the IRT object that is relevant to this inetnum is returned as well.
For example, if you lookup inetnum '193.78.240' you get that inetnum returned, and the irt-object 'IRT-MCI-NL', as that is specified in the inetnum above: '193.78/15'.
Note that this is different then the current -c behavour as that would, in this example' return the inetnum for '193.78/15' instead.
Can you add this discussion on the agenda as well?
Unfortunately I won't be able to visit the WG session myself, I hope the proposal is clear this way.
Regards,
Andre Koopal
Best regards, Wilfried. ________________________________________________________________________
A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed)
B. DB Update (N.N., RIPE NCC) [~15 min]
C. Review of security mechanisms in the DB (Peter K., denic.de) [~15 min] . quality of CRYPT-PW, CRYPT-MD5, X.509 . level of vulnerabilty in current dataset
D. State of whois services, developments? (WW144, N.N., RIPE NCC) [~15 min]
E. IRIS pilot frontend to whois (N.N., RIPE NCC) [~10 min]
F. Fact finding: RoutingReg facilities at RIRs (Gert D, SpaceNet) [~15 min]
X. Impact of "PDP" on how the DB-WG operates (WW144) [~15 min] . ref: https://www.ripe.net/ripe/docs/ripe-350.html
Y. Input from other WGs . DNS: secureDNS requirements for the DB
Z. AOB
On Wed, Oct 12, 2005 at 11:38:14AM +0200, Shane Kerr wrote:
Wilfried,
I'm not 100% sure what the AP is, but let me explain what we have done.
We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here:
http://www.ripe.net/fcgi-bin/whois?-c+193.78.240
It is possible to change the behaviour further, to make "-c" more useful I think. One way of doing this might be to try to find the "best" reply on a "-c" query. So, something like:
- Find the closest matching INETNUM/INET6NUM object with "mnt-irt:" - return the INETNUM/INET6NUM object (along with the IRT object) - If there is no INETNUM/INET6NUM, perform a normal lookup
Right now you have to do this on the client side.
Anyway, we can certainly discuss this at the working group session.
-- Shane Kerr RIPE NCC
To be clear on my proposal, what I basicly wants is that 'whois ip-number' gives the correct abuse information. As we decided to go with the irt-object IMHO that query (without any options) should then output the relevant irt-object. That is the rational behind my proposal. Regards, Andre
Wilfried Woeber, UniVie/ACOnet wrote:
Thanks to Andre for reminding me about that item!
I am a tad puzzled, because a DB-WG Action on this reads:
48.6 RIPE NCC To change DB behaviour to return IRT object [Complete]
However, neither the web interface nor the RIPE whois client does return the irt information. Rather I get a route object under the heading of
% Information related to 'prefix/length ASinfo'
Any insight on that? Thanks, Wilfried.
-------- Original Message -------- Subject: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1] Date: Tue, 11 Oct 2005 15:28:57 +0200 From: Andre Koopal <andre.koopal@nld.mci.com> To: Wilfried Woeber, UniVie/ACOnet <woeber@cc.univie.ac.at> CC: db-wg@ripe.net, RIPE NCC Meeting Registration <meeting@ripe.net>, wg-chairs@ripe.net References: <434BB603.4050409@cc.univie.ac.at>
On Tue, Oct 11, 2005 at 01:54:27PM +0100, Wilfried Woeber, UniVie/ACOnet wrote:
Dear DB-WG folks, Chairs, Meeting!
Here is the 2nd draft of an agenda for the DB-WG next week at RIPE51 in Amsterdam.
For time slot allocation please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-51/meeting-plan.html
Hi Wilfried,
A while ago I mailed the db working group to request a changed behavour when you lookup inetnum's.
In principle what I would like to see is that when an inetnum is returned, that the IRT object that is relevant to this inetnum is returned as well.
For example, if you lookup inetnum '193.78.240' you get that inetnum returned, and the irt-object 'IRT-MCI-NL', as that is specified in the inetnum above: '193.78/15'.
Note that this is different then the current -c behavour as that would, in this example' return the inetnum for '193.78/15' instead.
Can you add this discussion on the agenda as well?
Unfortunately I won't be able to visit the WG session myself, I hope the proposal is clear this way.
Regards,
Andre Koopal
Best regards, Wilfried. ________________________________________________________________________
A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed)
B. DB Update (N.N., RIPE NCC) [~15 min]
C. Review of security mechanisms in the DB (Peter K., denic.de) [~15 min] . quality of CRYPT-PW, CRYPT-MD5, X.509 . level of vulnerabilty in current dataset
D. State of whois services, developments? (WW144, N.N., RIPE NCC) [~15 min]
E. IRIS pilot frontend to whois (N.N., RIPE NCC) [~10 min]
F. Fact finding: RoutingReg facilities at RIRs (Gert D, SpaceNet) [~15 min]
X. Impact of "PDP" on how the DB-WG operates (WW144) [~15 min] . ref: https://www.ripe.net/ripe/docs/ripe-350.html
Y. Input from other WGs . DNS: secureDNS requirements for the DB
Z. AOB
On Oct 12, Shane Kerr <shane@ripe.net> wrote:
We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here: This is useful, but the desired behavious was to always return the relevant irt record for inetnum queries, along with the most specific inetnum object.
-- ciao, Marco
We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here:
This is useful, but the desired behavious was to always return the relevant irt record for inetnum queries, along with the most specific inetnum object.
I guess the missing phrase both in the action point and in the above reply is "by default". (And, yes, I agree, that is needed for this action point to make any sense.) Regards, - Håvard
From this discussion it looks like what you want is for the first query to return this irt object as the default, along with the inetnum object
Hi The irt object was implemented in a way to try to make it easy to use. We did not want to have to reference an irt object from every inetnum object. So when an irt object is referenced from an inetnum object it applies to all the more specific inetnum objects, until another irt object reference is found. With the -c flag we implemented a method of finding the related irt object to any given range. But it does require some effort on the part of the user to do this. You first query for the range to find out who operates that range. Then you query again using the -c flag to find the related irt object. that would normally be returned with this query. If we make this the default operation, then we have to have a way to turn it off. Not everyone wants yet more information returned with their query. This could be done with another flag. Or we could link it in with the recursive searching currently done with personal data. This would mean a query done for a range with no query flags would return the most specific inetnum object, route objects, organisation object, role/person objects and the irt object that would have been found with a -c query. The same query with the -r flag would only return the inetnum and route objects. Is this the behavior that most people would prefer? regards Denis Software Engineering Department RIPE NCC Havard Eidnes wrote:
We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here:
This is useful, but the desired behavious was to always return the relevant irt record for inetnum queries, along with the most specific inetnum object.
I guess the missing phrase both in the action point and in the above reply is "by default".
(And, yes, I agree, that is needed for this action point to make any sense.)
Regards,
- Håvard
On Wed, Oct 12, 2005 at 01:35:44PM +0200, Denis Walker wrote:
Hi
The irt object was implemented in a way to try to make it easy to use. We did not want to have to reference an irt object from every inetnum object. So when an irt object is referenced from an inetnum object it applies to all the more specific inetnum objects, until another irt object reference is found.
With the -c flag we implemented a method of finding the related irt object to any given range. But it does require some effort on the part of the user to do this. You first query for the range to find out who operates that range. Then you query again using the -c flag to find the related irt object.
From this discussion it looks like what you want is for the first query to return this irt object as the default, along with the inetnum object that would normally be returned with this query.
If we make this the default operation, then we have to have a way to turn it off. Not everyone wants yet more information returned with their query. This could be done with another flag. Or we could link it in with the recursive searching currently done with personal data.
This would mean a query done for a range with no query flags would return the most specific inetnum object, route objects, organisation object, role/person objects and the irt object that would have been found with a -c query. The same query with the -r flag would only return the inetnum and route objects.
Is this the behavior that most people would prefer?
That sounds like a very good proposal. Regards, Andre
regards Denis Software Engineering Department RIPE NCC
Havard Eidnes wrote:
We have changed the behaviour of the database so that when you do a "-c" lookup, we return the IRT object in the reply. I thought this was the desired behaviour. You can see it here:
This is useful, but the desired behavious was to always return the relevant irt record for inetnum queries, along with the most specific inetnum object.
I guess the missing phrase both in the action point and in the above reply is "by default".
(And, yes, I agree, that is needed for this action point to make any sense.)
Regards,
- H�vard
On Oct 12, Denis Walker <denis@ripe.net> wrote:
From this discussion it looks like what you want is for the first query to return this irt object as the default, along with the inetnum object that would normally be returned with this query. No, we are NOT asking for changes in which inetnums (and related) objects are returned, but that the relevant IRT object is returned along with the inetnum object which is currently returned.
If we make this the default operation, then we have to have a way to turn it off. Not everyone wants yet more information returned with their query. This could be done with another flag. Or we could link it in with the recursive searching currently done with personal data. I think it would be natural for -r to suppress IRT objects too.
This would mean a query done for a range with no query flags would return the most specific inetnum object, route objects, organisation object, role/person objects and the irt object that would have been found with a -c query. The same query with the -r flag would only return the inetnum and route objects.
Is this the behavior that most people would prefer? Yes.
-- ciao, Marco
Hi, On Wed, Oct 12, 2005 at 11:51:26AM +0200, Marco d'Itri wrote:
This is useful, but the desired behavious was to always return the relevant irt record for inetnum queries, along with the most specific inetnum object.
ACK. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
participants (7)
-
Andre Koopal -
Denis Walker -
Gert Doering -
Havard Eidnes -
md＠Linux.IT -
Shane Kerr -
Wilfried Woeber, UniVie/ACOnet