On Mon, Apr 14, 2003 at 05:05:36PM +0200, Joao Luis Silva Damas wrote:
Some of us think that respecting the installed base and continuing with the same query syntax was the way to go. Others had different opinions.
I agree that the time to switch to a new syntax is not yet (the syntax needs to it be defined, ratified and go through a long migration process first). Compatibility with old syntax has to be high on the list of considerations when defining a new standard, but it certainly shouldn't be a show stopper. (It's always possible to leave the old syntax in for a few revisions with a "This syntax is deprecated, use the new syntax" warning).
Defining standard query language syntax / information presentation format across the registries is exactly why the IETF CRISP working group exists. Lets hope that as a few of their I-Ds get onto the RFC standards track we can finally get a registry structure that is so easy to use that people start keeping their objects up to date ;)
How you keep your objects up to date is actually standard.
True. Although RIPE allow multiple instances of the member: attribute in as-sets, which breaks compatibility with RFC2622. Was needed to maintain compatibility with the old as-macro object though.
Whether you keep your objects up to date or not has nothing to do with CRISP or any other standard but rather with perceived value, enforcement by your upstream and laziness (I won't detail the relative weight of the factors).
Enforcement by upstream was actually what I meant here. Defined standards and a good set of tools to build filters will lead to more people building filters based on registered policy, which should force people to overcome laziness and to keep things up to date. Of course the other factor to be taken into account in all this is that old Layer 8 chestnut "Finance". It's hard to convince the bean counters that you should deny a customer's prefix when he hasn't registered it if it means unpaid invoices... -- Russell Heilling http://www.ccie.org.uk/ PGP: finger russellh@bela.homeunix.net