Hi,
(I tailed down the Cc: list..)
On Sat, 27 Dec 2003, Randy Bush wrote:
> > OK, I now found that the doc did have an IETF Last Call
> > in late August/Early Sept.
>> and there were technical objections which have not been addressed
Thanks, Randy, for reminding about that.
Based on some off-list discussion, the technical objections being
referred to are the comments from Mark Prior on the list, one of them
copied below.
I'll try to summarize the loooo-ong thread somehow. Mark believes
that the current RPSLng proposition unnecessarily adds complexity to
the operators' use of the language, as e.g. IPv4 and IPv6 addresses,
peerings, etc. could all be facilitated by redefining the current
attributes etc. -- and whichever would be returned could be evaluated
based on the context. As the number of operators using the language
is extremely high (and we'd like it to be higher :-) compared to the
registry/tool implementations, Mark argues that optimizing for the
simplicity to the operators is the most important goal.
Curtis objects to this mainly based on the fact that this would break
the backward compatibility for the clients which do not expect to
receive IPv6 data back from their queries. This could be easily fixed
e.g. in tools like IRRToolSet, but that there are a probably a number
of hacks built on top of perl, telnetting to port 43, or whatever,
which might not be equally fortunate.
Workarounds to this seem to be adding some kind of version negotiation
or inclusion to the whois protocol (in the future, maybe using CRISP),
so that only the clients who signal "yes, I can process IPv6 records!"
would activate the IPv6 context processing. This could also be passed
to the whois server with an option, like '--use-rpslng' or '-6'. Or
maybe the client would state which records it wants to get, e.g.
'-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or
something, for "NEW", otherwise only v4 would be returned :) for
both). At least RIPE database allows the use of '-Vxxx' verstion
string to tell about the version of the client software.
The exact details of how this method would work out would need to be
fleshed out. Any takers?
Personally, when I was trying to form an opinion on this subject, I
found myself thinking that Mark's proposal addresses only IPv4/IPv6
case. It doesn't seem to address how one could specify different
unicast/multicast policies, or how to specify different v4/v6
policies. This is also one goal of RPSLng.. even though the major
operators who do have multicast or v6 often want their policies to be
the same.
How would this work out if a "more intelligence" model was adopted?
(I'm personally a bit unsure whether a "more intelligence in the
tools" -model would or would not make sense at this point, but I think
I can see both sides of the argument..)
Could we get some form of discussion and maybe consensus on what would
seem to be the right way forward? :-)
===========
Date: Tue, 23 Sep 2003 09:00:06 +0930
From: Mark Prior <mrp at mrp.net>
To: curtis at fictitious.org
Cc: Pekka Savola <pekkas at netcore.fi>, iesg at ietf.org, rpslng at ripe.net,
rps at ietf.org
Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard
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.
==========
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacypolicy. You can accept our cookies either by clicking here or by continuing to use the site.