Re: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)]

[Curtis Villamizar <]

In message <1074010929.3795.45.camel@localhost>, "Larry J. Blunk" writes
:
> On Fri, 2004-01-02 at 03:24, Pekka Savola wrote:
> > 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?
> 
>   I don't believe this would be particularly productive.  These
> are implementation details which are really outside the scope of
> the RPSLng work.  I don't see the objections to RPSLng as objective
> technical issues, but rather subjective preferences.


I'll agree with that.  So if any comments I made having to do with
transition and backwards compatibility are holding this up, comments
which I beleive I made as suggestions, then please consider those to
be resolved issues.


> > 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..)
> 
>    It is very difficult to judge the impact of such a model without
> having a complete census of the various tools in use by ISP's.  For
> example, C&W has an extensive set of in-house developed tools which
> interact with IRR's.  Is it fair to ask them to hack up their tools
> to fit this model?
> 
> > 
> > Could we get some form of discussion and maybe consensus on what would 
> > seem to be the right way forward? :-)
> 
>     I think we have already reached the point of "rough" consensus.
> Again, I view the expressed objections as subjective preferences rather
> than solid technical beefs with the specification.
> 
>   Regards,
>     Larry


I agree here too.  Perhaps Mark can tell us whether he has any
specific suggestions for changing the language from what is currently
proposed.

Curtis


> > ===========
> > Date: Tue, 23 Sep 2003 09:00:06 +0930
> > From: Mark Prior mrp@localhost
> > To: curtis@localhost
> > Cc: Pekka Savola pekkas@localhost, iesg@localhost, rpslng@localhost,
> >      rps@localhost
> > 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.
> > ==========
> 
> 
> _______________________________________________
> Rps mailing list
> Rps@localhost
> https://www1.ietf.org/mailman/listinfo/rps