About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

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

  • To: Mark Prior < >
  • From: Curtis Villamizar < >
  • Date: Tue, 16 Sep 2003 16:09:36 -0400
  • Cc:
    Pekka Savola < >
  • Reply-to:

In message <3F67049B.2030403@localhost>, Mark Prior writes:
> Curtis Villamizar wrote:
> 
> > Since there is no version negotiation, we'd need a new set of queries
> > with version negotiation.  The old set could be assumed to be the old
> > versions.
> > 
> Well the obvious question to ask is why not add it (version negotiation 
> that is). This would require some codification of the exchange between a 
> client and a server but wouldn't this be a good thing anyway?

That's entirely an RtConfig issue but it would make RPSL transitions
easier.  Handling multiple protocol versions is not trivial though.

> > The next issue is you'd need a reliable means to translate the new
> > format into the old.  This does constrain the syntax somewhat, but
> > would allow ipv4,ipv6 policy to be specified and just the ipv4 part
> > returned to the old query.
> > 
> Ah but would an organisation using an old client write new syntax 
> objects anyway?

No but they may need to be able to read new objects that others have
written to figure out what's going on.

> > This boild down to just a "small matter of code".  RtConfig is open
> > source.  Would you like to contribute the changes?  :-)
> >  
> Given my lack of C++ skills (combined with my lack of gcc v2 compiler) 
> I'm not sure I would be too helpful in that regard :-) However I guess I 
> would be happy to assist updating RFC 2650.

I was kidding about writing code for RtConfig, but the point is that
keeping specification acheivable has always been an IETF goal.  In
this case we want to keep in mind the limited staff working on the
tools or we end up with nothing that works in a reasonable time.

> Mark.

Curtis




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community