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