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