ad-hoc RIPE db-wg meeting at IETF93
Dear best-db-working-group-in-the-world! I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-) I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage. Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details. Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest. Kind regards, Job
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest.
I hope, you mean Bucharest. ;-) Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Sun, Jul 19, 2015 at 08:36:03PM +0200, Piotr Strzyzewski wrote:
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest.
I hope, you mean Bucharest. ;-)
Oops! In my defense, the letters are so close to each other on this keyboard ;-)
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
Dear best-db-working-group-in-the-world!
I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-)
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
We are meeting at the back of the "ZEST BAR" on the lobby floor. Tim was kind enough to prepare a small list of topics. Kind regards, Job
On 20/07/2015 16:29, Job Snijders wrote:
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
Dear best-db-working-group-in-the-world!
I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-)
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
We are meeting at the back of the "ZEST BAR" on the lobby floor.
Tim was kind enough to prepare a small list of topics.
...and the topics are? (for the benefit of those who won't be there..it is nice to know what is on the radar) cheers denis
Kind regards,
Job
On Jul 20, 2015, at 4:29 PM, Job Snijders <job@ntt.net> wrote:
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
Dear best-db-working-group-in-the-world!
I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-)
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
We are meeting at the back of the "ZEST BAR" on the lobby floor.
Tim was kind enough to prepare a small list of topics.
Sure, I am around as well and would love the opportunity to talk about these topics: = route object authorization = RPSL maintainer on out of region route objects = personalized authentication But of course discussion does not need to be limited to this. Kind regards, Tim
Kind regards,
Job
On 19/07/15 15:59, Job Snijders wrote:
Dear best-db-working-group-in-the-world!
I was looking through the IETF93 attendees list and noticed quite a few familiar names are attending the IETF meeting in Prague this week! :-)
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
Let me know if you are interested in attending this ad-hoc db-wg meeting. No worries if you aren't around this time, we'll see each other at RIPE71 in Budapest.
Please accept my apologies. Although I'll be at IETF, it will only be on a 1-day pass on the following day (and I don't arrive until just before midnight). Nigel
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
My notes: Attending: Tim Kleefass, Job Snijders, Tim Bruijnzeels, Shane Kerr, Andy Newton, Ruediger Volk * Route object authorisation - rv@ objects to allowing anybody to create a route-object with his own origin asn. Shane Kerr in turn suggests to make the new, relaxed mechanism something to 'opt-out' from (very interesting!) * RPSL utf8/whitespace - someone needs to create a list of all attributes and their expected encoding - by default the output of the whois.ripe.net server should be old-style ASCII (and through a %command you should be able to request the utf8 output) * RPSL maintainer on out of region route objects - add business rule that no object can reference the RPSL maintainer (splot out error message) - remove references to the RPSL maintainer on objects - in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit. Kind regards, Job
Hi Job Thanks for the update. On 26/07/2015 15:55, Job Snijders wrote:
On Sun, Jul 19, 2015 at 04:59:39PM +0200, Job Snijders wrote:
I'd love to catch up with you and discuss some of the current db-wg topics face to face, possibly while holding a sparkling beverage.
Let's gather Tuesday July 21st somewhere in the Hilton from 18:00 to 19:00. I'll arrange a room or spot and follow-up with details.
My notes:
Attending: Tim Kleefass, Job Snijders, Tim Bruijnzeels, Shane Kerr, Andy Newton, Ruediger Volk
* Route object authorisation - rv@ objects to allowing anybody to create a route-object with his own origin asn. Shane Kerr in turn suggests to make the new, relaxed mechanism something to 'opt-out' from (very interesting!)
* RPSL utf8/whitespace - someone needs to create a list of all attributes and their expected encoding - by default the output of the whois.ripe.net server should be old-style ASCII (and through a %command you should be able to request the utf8 output)
* RPSL maintainer on out of region route objects - add business rule that no object can reference the RPSL maintainer (splot out error message)
Finally :) But this rule needs an exception to allow objects maintained by the RIPE NCC to reference this MNTNER. Many objects need to reference it as the "mnt-routes:" including 0/0, 0::, all AS-BLOCK objects covering out of region ranges of ASNs and any placeholder INET(6)NUM objects covering out of region ranges of address space.
- remove references to the RPSL maintainer on objects
In the interests of user friendliness I would hope you will contact the maintainers of all these objects first and allow them time to replace the references with their own MNTNER object. Otherwise you will create another set of locked objects where the maintainers will eventually have to contact Customer Services to gain access again.
- in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit.
This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex. The public password avoids the need for further complexity by allowing these object creations to follow the normal path for authorisation. cheers denis
Kind regards,
Job
On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote:
- in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit.
This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex.
I don't agree with your assessment. Don't forget that the responsibility for the Whois software code quality lays primiarily with RIPE NCC staff. I am confident they'll inform us about potential code complexity issues. Kind regards, Job
Hi Job On 26/07/2015 20:04, Job Snijders wrote:
On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote:
- in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit.
This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex.
I don't agree with your assessment. Don't forget that the responsibility for the Whois software code quality lays primiarily with RIPE NCC staff. I am confident they'll inform us about potential code complexity issues.
I understand where you are coming from. But keep in mind that the software is open source so anyone in the community can study this code (if they want to) and appreciate the complexity that already exists in both the software and data model. Also keep in mind the way this process works. The community asks for something, generally without any regard to how it will be implemented. The RIPE NCC has a lot of wonderful guys who like to give the community what they ask for. And as Shane often says, "it's software, you can do anything you like with software". Of course he is right, but there is always a cost. Given that the community/membership is, to a large extent, reluctant to even discuss the issue of simplifying the data model and bringing the software design into the 21st century, things just get more complex over time. Then the whole software has to be re-written again, as they have done twice already, just to keep it maintainable but without making any substantial improvements. I also think re-introducing and documenting the concept of "auth:none", after it was deprecated about 12 years ago, and at a time when security is a regular discussion topic, is bad PR for this industry. I know the public password achieves the same result, but at least with the password you have to know what to do with it and 'do something'. With "auth:none" you do nothing and things 'just work'. We should be fixing the issue of the public password not making cosmetic changes like this. cheers denis
Kind regards,
Job
On Mon, Jul 27, 2015 at 06:13:27PM +0200, denis wrote:
On 26/07/2015 20:04, Job Snijders wrote:
On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote:
- in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit.
This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex.
I don't agree with your assessment. Don't forget that the responsibility for the Whois software code quality lays primiarily with RIPE NCC staff. I am confident they'll inform us about potential code complexity issues.
I understand where you are coming from. But keep in mind that the software is open source so anyone in the community can study this code (if they want to) and appreciate the complexity that already exists in both the software and data model.
Also keep in mind the way this process works. The community asks for something, generally without any regard to how it will be implemented. The RIPE NCC has a lot of wonderful guys who like to give the community what they ask for. And as Shane often says, "it's software, you can do anything you like with software". Of course he is right, but there is always a cost.
Given that the community/membership is, to a large extent, reluctant to even discuss the issue of simplifying the data model and bringing the software design into the 21st century, things just get more complex over time. Then the whole software has to be re-written again, as they have done twice already, just to keep it maintainable but without making any substantial improvements.
I also think re-introducing and documenting the concept of "auth:none", after it was deprecated about 12 years ago, and at a time when security is a regular discussion topic, is bad PR for this industry. I know the public password achieves the same result, but at least with the password you have to know what to do with it and 'do something'. With "auth:none" you do nothing and things 'just work'. We should be fixing the issue of the public password not making cosmetic changes like this.
It should be noted that "auth: none" is not a proposal of mine, merely a short handed way of writing down what could be a method in the context of the RPSL maintainer. IMHO slapping the public "RPSL" password on something might as well don't require anything. I do not wish to reintroduce "auth: none"! But I'd like to see better auth model of out of region resources in the RIPE database. I guess I should have written something like "remove RPSL maintainer and use implicit authorisation" instead of "auth: none" :-) Kind regards, Job
On 27/07/2015 18:21, Job Snijders wrote:
On Mon, Jul 27, 2015 at 06:13:27PM +0200, denis wrote:
On 26/07/2015 20:04, Job Snijders wrote:
On Sun, Jul 26, 2015 at 07:39:36PM +0200, denis wrote:
- in essence re-introduce 'auth: none' for out of region objects, in doing so make the rpsl-maintainer implicit.
This is not a good idea. This 'implicitness' requires changes to the software to create exceptions for authorisation on creation of certain object types. The authorisation software is already nightmarishly complex.
I don't agree with your assessment. Don't forget that the responsibility for the Whois software code quality lays primiarily with RIPE NCC staff. I am confident they'll inform us about potential code complexity issues.
I understand where you are coming from. But keep in mind that the software is open source so anyone in the community can study this code (if they want to) and appreciate the complexity that already exists in both the software and data model.
Also keep in mind the way this process works. The community asks for something, generally without any regard to how it will be implemented. The RIPE NCC has a lot of wonderful guys who like to give the community what they ask for. And as Shane often says, "it's software, you can do anything you like with software". Of course he is right, but there is always a cost.
Given that the community/membership is, to a large extent, reluctant to even discuss the issue of simplifying the data model and bringing the software design into the 21st century, things just get more complex over time. Then the whole software has to be re-written again, as they have done twice already, just to keep it maintainable but without making any substantial improvements.
I also think re-introducing and documenting the concept of "auth:none", after it was deprecated about 12 years ago, and at a time when security is a regular discussion topic, is bad PR for this industry. I know the public password achieves the same result, but at least with the password you have to know what to do with it and 'do something'. With "auth:none" you do nothing and things 'just work'. We should be fixing the issue of the public password not making cosmetic changes like this.
It should be noted that "auth: none" is not a proposal of mine, merely a short handed way of writing down what could be a method in the context of the RPSL maintainer. IMHO slapping the public "RPSL" password on something might as well don't require anything.
noted :)
I do not wish to reintroduce "auth: none"! But I'd like to see better auth model of out of region resources in the RIPE database. I guess I should have written something like "remove RPSL maintainer and use implicit authorisation" instead of "auth: none" :-)
agreed, but I still think any changes like this are cosmetic and pointless. cheers denis
Kind regards,
Job
Thanks to Job for reporting this discussion, so that it has reached the mailing list.
* Route object authorisation - rv@ objects to allowing anybody to create a route-object with his own origin asn.
Does this relate to our mailing list discussion about registering new OriginAS? Can we please have some information about the nature of the objection? Perhaps the reporting is abbreviated, but the proposal so far is NOT "to allowing anybody to create a route-object". The registered "owner" of the address space is the only party entitled to add an authorised OriginAS. If the objection stands, I think it is the first, so we really need to understand it better. Steve Nash
participants (6)
-
denis -
Job Snijders -
Nigel Titley -
Piotr Strzyzewski -
snash -
Tim Bruijnzeels