Draft Minutes of the RIPE 52 DB-WG meeting
Please find enclosed the first rough draft of the minutes. Please check your action points and make corrections to me. Thanks Nigel <<DB-minutes.txt>>
Hello Titley, i am a little bit surprised about the wording concerning route objects in the ripe database: F. Modify checks for creation of route: (input from Routing-WG) The checks at the moment are fully compliant with the RFCs so we should perhaps change the RFCs. It was suggested that maybe we should be looking at the model proposed for the PKI to allow the overall holder of a block of address space to allow objects to be created, but that the onus finally rests on the holder of the AS number object. It was agreed to do nothing and wait for the PKI model to be more fully developed. Is i started this discussion i got a lot of feedback and as i remember at least the owner of the inet-object should be able to delete unwanted route-objects. I got no argument against this proposal. There were diffrent views of the question who should be able to create such an object but not about the fact the the inet-object owner should be able to delete such objects. The current situation gives an owner of an as with a route-object more power than the owner of this inet-object itself. It can also prevent to add a NEW route object. If you have a large block you can add a route object for a more specific network as a workaround. This leads to more routes announced to the routing table than necessary. But you are lost with a /24 as many dont accept /25 announcements. Even the idea to wait for the pki model doesnt change anything. For the removal of an route object i need a response from the holder of the AS object. What happens if he doensnt respond ? -> even the new PKI model doesnt help the inte-object owner and will not change the situation. Do you really want people to send faxes to ripe for route object removal? This is a stupid idea and doesnt scale. We had and have issues with that and sometimes -especially in large companies- it can take days, weeks or months until somebody responds. I would like to hear some technical reasons why we cant change the current situation. I dont see them :-( Winfried --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Hi Winfried, Winfried Haug wrote: [...]
Do you really want people to send faxes to ripe for route object removal? This is a stupid idea and doesnt scale.
Indeed. But I guess the problem in your case was that you had to obtain authorisation from a holder of the old route object. In this case I don't see why can't it be the customer (you as I understand) who maintains (i.e. mnt-by: CUSTOMER-MNT) PI inetnum and all route objects that represent this address space? That will allow you to have as many route objects as necessary and also have full control over deletion Regards, Andrei Robachevsky
Indeed. But I guess the problem in your case was that you had to obtain authorisation from a holder of the old route object.
correct and he is very very slow -> delay of provider change.
In this case I don't see why can't it be the customer (you as I understand) who maintains (i.e. mnt-by: CUSTOMER-MNT) PI inetnum and all route objects that represent this address space? That will allow you to have as many route objects as necessary and also have full control over deletion
Customer has a maintainer of his inet object but even with that he cant delete an existing route object for the network because the route object is maintained by the AS owner. There are many PI networks given but routed by another upstream. In this case the route object is maintained by the AS owner and only he can delete or alter this object. Without the AS owner the inetnum object user is lost and needs assistance from ripe. I doubt that we should force people to query ripe or send faxes to ripe. Winfried Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Hi Winfried,
I would like to hear some technical reasons why we cant change the current situation. I dont see them :-(
This is a bit of a "holding" answer. In the routing working group, Andrei presented a summary of the discussion on the lists, but there was very little feedback from the floor, or via Jabber, about which direction to move in. As I recall, Joao said he was going to write a summary of the points to consider and put it out to the routing-wg list, where perhaps there can be some more discussion. One of the reasons to approach this with caution is that the current behaviour is as described in RPSS (RFC2725), and we'd like to get a bit more feedback on why those authentication rules were chosen to make a better decision on how to change them. Regards, Rob
Hello Rob,
In the routing working group, Andrei presented a summary of the discussion on the lists, but there was very little feedback from the floor, or via Jabber, about which direction to move in.
seems to me that the comments from the list were ignored. The problem we have is mentioned in rfc2725 section d 3
As I recall, Joao said he was going to write a summary of the points to consider and put it out to the routing-wg list, where perhaps there can be some more discussion.
One of the reasons to approach this with caution is that the current behaviour is as described in RPSS (RFC2725), and we'd like to get a bit more feedback on why those authentication rules were chosen to make a better decision on how to change them.
Ok i looked at RFC2725: 9.1 "For example, when authorizing a route object software would look at "mnt-routes", if it does not exist, look at "mnt-lower", if that does not exist look at "mnt-by". " and more interesting: D.3 provider independent addresses and multiple origin AS Provider independent addresses and multihoming arrangement using multiple origin AS present a similar problem to multihoming. The maintainer of the address space and the maintainer of the AS is not the same. Permission can be granted using mnt-routes or multiple signatures can appear on the submission. Well the RFC is from 12/1999 , we have now 2006. Things may change!. Even 1999 people saw the problem and according to the wording in D.3 it is not clear that the mnt-routes must appear in the route object itself. It can also be seen that a mnt-routes in the inetobject itself could be used. Or am i wrong? Winfried --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Well the RFC is from 12/1999 , we have now 2006. Things may change!.
Indeed.
Even 1999 people saw the problem and according to the wording in D.3 it is not clear that the mnt-routes must appear in the route object itself. It can also be seen that a mnt-routes in the inetobject itself could be used. Or am i wrong?
I hope I'm not misunderstanding what you're saying, but I think you may have missed part of section 9.9, "Adding to the Database". Adding a route object is somewhat more complicated. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or if no applicable route object is found, then an inetnum. An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10). If the aut-num does not exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs). If the aut-num exists then the submission is checked against the applicable maintainer. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed. If the search for a route object fails, then a search is performed for an inetnum that exactly matches the prefix or for the most specific inetnum that is less specific than the route object submission. The search for an inetnum should never fail but it may return an unallocated or reserved range. The inetnum status must be "allocated" and the submission must match the maintainer. Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt- by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects. Does that help explain the current authorisation model? Regards, Rob
On 28 Apr, 2006, at 12:02, Winfried Haug wrote:
Hello Titley,
i am a little bit surprised about the wording concerning route objects in the ripe database:
OK, let me comment on this and write down what I think I said, or was trying to say:
F. Modify checks for creation of route: (input from Routing-WG)
The checks at the moment are fully compliant with the RFCs so we should perhaps change the RFCs.
It was suggested that maybe we should be looking at the model proposed for the PKI to allow the overall holder of a block of address space to allow objects to be created, but that the onus finally rests on the holder of the AS number object. *** with this I tried to say that whether the AS announces the prefix or not is a decision to be taken by the operator of the AS, not the holder of the address space, and that the owner of the address space may be allowed to create the object as it, by itself, does not
*** or the database if we agree to that. *** directly reflect operations. At least this is how understood the points that were brought up during the discussion ***
It was agreed to do nothing and wait for the PKI model to be more fully developed.
I think it was agreed to take the discussion to the mailing list and request more input as there was not much feedback during the session. Joao
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. -- ciao, Marco
Marco, 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".
The proposal and the agreement were slightly different, and I believe the minutes should reflect this. We propose to implement the desired behaviour as a -c flag first and after some use time make it a default query. At the same time it was decided that the web interface to whois will "prepend" the -c flag and thus irt object will be returned by default. We will be sending a detailed proposal to this mailinglist for review and comments.
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.
Andrei
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.
Hi Denis, Denis Walker wrote:
Hi
[...]
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?
This was me :-) As the lookup for irt: has the nice capability to do a search towards the less specific blocks (by design!) it is easy to implement both an optional "local" irt: contact which is handled directly by (some of) our customers plus a catch-all on our allocated block. Just as I use the -m or -M flag to look at the more specifics in generla, it occurred to me that it might be equally useful to find out which more specific blocks assigned to our customers have been linked to a local irt: object. If this is hard to implement, or nobody else can see a use case for it, then we can forget about it :-) there are other ways to find this out, albeit less fancy :-)
regards Denis Walker Software Engineering Department RIPE NCC
Wilfried.
Hi, On Fri, Apr 28, 2006 at 06:58:06PM +0200, Denis Walker wrote:
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.
This sounds very useful to me (and I think it reflects what was agreed upon, in Manchester, IIRC). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On May 03, Gert Doering <gert@space.net> wrote:
On Fri, Apr 28, 2006 at 06:58:06PM +0200, Denis Walker wrote:
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. This sounds very useful to me (and I think it reflects what was agreed upon, in Manchester, IIRC).
No, after Manchester the agreement was to return the irt record relevant to the queried ip/network. This is subtly different from the behaviour of -c, which may return a less specific inetnum object if the irt record is referenced by it. -- ciao, Marco
On Fri, Apr 28, 2006 at 06:58:06PM +0200, Denis Walker wrote:
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.
It is still unclear to me what now has been decided on the RIPE meeting. Having abuse information in the RIPE database is useless if it is not returned in the default query, and you can't depend on the client to have some option by default as all kind of clients/webpages and whatever are used, so it must be be solved on server side. I was really under the impression we agreed that if you lookup an ip-number the correct inetnum would be displayed together with the relevant irt object that might be from a level up. It has been remarked that in that way a not referenced block would be returned, but that was taken for granted. I still think the above solution must be implemented to make the irt object usefull, and if the code can't easily handle it, the code must be changed. Whatever options will be implemented to finetune the output for experienced users/coders I don't care, but the average user should see the relevant information. Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - Int ITSD Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands tel : +31 (0)20 711 1000 fax : +31 (0)20 711 2519 Verizon and MCI are now operating as Verizon Business ! This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated.
Andre, Andre Koopal wrote: [...]
I was really under the impression we agreed that if you lookup an ip-number the correct inetnum would be displayed together with the relevant irt object that might be from a level up. It has been remarked that in that way a not referenced block would be returned, but that was taken for granted.
I still think the above solution must be implemented to make the irt object usefull, and if the code can't easily handle it, the code must be changed.
Yes, that is what we plan to implement. There are a few details that need to be clarified, but that will be in the proposal that will be sent to the working group shortly. The matter of discussion was deployment considerations: whether to implement this new behaviour for the default query right away, or with a -c flag. It was suggested that at the first phase we may want to implement it as a default behaviour for the whois web cgi, but expect the whois client to use the -c flag explicitly. And that would meet the needs of the average user.
Whatever options will be implemented to finetune the output for experienced users/coders I don't care, but the average user should see the relevant information.
Regards,
Andre Koopal
Regards, Andrei
On May 15, Andrei Robachevsky <andrei@ripe.net> wrote:
The matter of discussion was deployment considerations: whether to implement this new behaviour for the default query right away, or with a -c flag. It was suggested that at the first phase we may want to implement it as a default behaviour for the whois web cgi, but expect the whois client to use the -c flag explicitly. And that would meet the needs of the average user. Last week I asked for the -V statistics to be published, to better understand the different sources of queries. Can you comment on this?
-- ciao, Marco
Marco, Marco d'Itri wrote:
On May 15, Andrei Robachevsky <andrei@ripe.net> wrote:
The matter of discussion was deployment considerations: whether to implement this new behaviour for the default query right away, or with a -c flag. It was suggested that at the first phase we may want to implement it as a default behaviour for the whois web cgi, but expect the whois client to use the -c flag explicitly. And that would meet the needs of the average user.
Last week I asked for the -V statistics to be published, to better understand the different sources of queries. Can you comment on this?
We can produce some statistics and then send it to the list to see if it is useful. That should also show what percentage of queries comes through the whois cgi. We can do this quickly. Regards, Andrei
participants (10)
-
Andre Koopal -
Andrei Robachevsky -
Denis Walker -
Gert Doering -
João Damas -
md＠Linux.IT -
Nigel Titley -
Rob Evans -
Wilfried Woeber, UniVie/ACOnet -
Winfried Haug