In message <3F6F85FE.1020302@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
How is RPSLng not a superset of RPSL? Nothing has been removed from RPSL.
Superset is probably not the best word to describe what I want.
The issue is just how do you make transition easiest, supporting older RPSL only clients. If you just extend import rather than rename it mp-import and extend it, then old RPSL only clients will consider you autnum broken. If you include mp-import but forget to reflect you IPv4 policy in plain import then the old RPSL client will pick up a subset of you policy.
In either case, extending import, or adding mp-import and putting the extensions there, it would make for a smoother transition if the server code could recognize old clients and feed them with objects translated into plain RPSL.
I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context?
The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything.
I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with.
Having written plenty of small compilers I can understand why implementors would prefer to keep things simple for them. For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you? My reasoning for keeping mp-* is that for import you'd want the lack of newly attributes to mean what they meant in objects submitted a long time ago (for example ipv4-unicast only), but with a new mp-import defaults can be whatever case is thought to be most common. For other objects this seems to make sense too. For mp-peer, a default of ip-everything makes sense, keeping peer to mean ipv4-unicast.
Mark.
I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it. Curtis