Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard

[Curtis Villamizar <curtis@laptoy770.fictitious.org>]

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