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? 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. Mark.