RE: summary of the discussions so far

["Peirens, Bart" <]

> While there is a limited number of software that we know are 
> working on the 
> registry (as opposed so smtp clients/servers for example), we 
> should not 
> design the new language spec on the specific behavior of one 
> specific software.
> 

wasn't RPSL exactly designed to avoid these complex migration periods of
 running dual database systems for a limited amount of time?

all 10.x parts of rfc2622 clearly state this as well.

===
10.4 Extensions by changing the syntax of existing RPSL attributes

   If all of the methods described above fail to provide the desired
   extension, it may be necessary to change the syntax of RPSL. Any
   change in RPSL syntax must provide backwards compatibility, and
   should be considered only as a last resort since full compatibility
   may not be achievable.  However, we require that the old syntax to be
   still valid.

===

exactly the fact that we had to run parallel systems for quite some
 months with the ripe-181 -> RPSL change shows that these 'limited'
 use is still considered a quite important amount....

> -----Original Message-----
> From: Marc Blanchet [
	    
	    
]
> Sent: Friday, October 26, 2001 2:54 AM
> To: Florent Parent; rpslng@localhost
> Subject: Re: summary of the discussions so far
> 
> 
> I think the discussion on the fact that current software 
> break may not be 
> the right way to discuss this.
> 
> I would recommend to:
> - think about being as compatible as possible with the 
> previous language 
> definition
> - but keep the design clean and right
> 
> I think the problem with compatibility will be essentially 
> similar whatever 
> we introduce new attributes or new objects.
> 
> However, the right way to think about this compatibility 
> issue is probably 
> more related to deployment of the new database.
> As an example,
> - having the old format being in one database instance
> - and having a new database instance containing the previous database 
> (synched) together with the new objects
> 
> old software connects to the first database instance
> new software connects to the second database instance
> 
> kill the old database after sometime.
> 
> That way, the issue of compatibility is more a deployment 
> issue than a 
> language compatibility level issue.
> 
> my 2 cents.
> 
> Marc.
> 
> 
> At/À 09:32 2001-10-23 -0400, Florent Parent you wrote/vous écriviez:
> 
> > >From the discussions so far, it seems that we need to carefully
> >consider the advantages/drawbacks of introducing new classes and
> >attributes to support multicast and IPv6.
> >
> >Adding new classes and attributes allows us to keep good backward
> >compatibility: The legacy tools should simply ignore the new objects
> >and attributes.
> >
> >On the other hand, one can argue that IPv6 addresses can be used in
> >the current attributes and these IPv6 objects should only be used by
> >tools that have been designed for them. This needs further 
> thoughts as
> >that there are cases where you need to distinguish between the afi
> >IPv4/IPv6 (ie. type of routes exchanged in import/export)
> >
> > >From the proposals and comments seen so far, I believe we 
> have these 2
> >"views":
> >
> >Don't break current software
> >Define new objects and attributes for IPv6
> >Define new attributes for multicast
> >
> >Allow IPv6 in current attributes
> >Let the software sort the address family (or identify the 
> address family)
> >May require some transition period for new tools
> >
> >------------------------------------------------------------
> >
> >Below, I've tried to summarize the different proposals, adding some
> >benefits (+) and drawbacks (-) for each. I find this a 
> useful exercise
> >to get a good idea on where the issues are. Please send me 
> any changes
> >required.
> >
> >Introducing a new attribute or new class is being considered a (-) in
> >the text below. How much of a drawback is left to be discussed.
> >
> >route
> >-----
> >New attribute to distinguish between unicast/multicast
> >New object route6 for IPv6
> >
> >+ route6 shouldn't break current software
> >- Adds new class and attribute
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6|ipv4-multicast|ipv6-multicast in attributes
> >
> >+ No new class or attribute
> >- current software can choke on new "afi" syntax in new objects
> >
> >Rely on the user software to determine what type of address in in the
> >route object.
> >
> >+ No changes in RPSL
> >- Can break current software that does not support IPv6
> >
> >
> >inet-rtr
> >--------
> >New attribute if6addr.
> >New attribute peer6.
> >
> >+ doean't break current software
> >- new attributes
> >
> >Rely on the user software to determine what type of address in in the
> >inet-rtr object.
> >
> >+ No changes in RPSL
> >- Current software can choke on unexpected IPv6 addresses
> >
> >route-set
> >---------
> >New attribute members6
> >
> >+ doean't break current software
> >- new attributes
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6 in members attribute
> >
> >+ no new attribute
> >- current software can choke on new "afi" syntax in new objects
> >
> >Just add IPv6 addresses in members attribute, rely on 
> software to sort
> >things out.
> >
> >+ No changes in RPSL
> >- Current software can choke on unexpected IPv6 addresses if they
> >   reference them
> >
> >aut-num
> >-------
> >New option "nlri_afi" or "afi" in BGP4 protocol spec
> >New attributes import6/export6 to specify IPv6 peering
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6
> >New attributes import6/export6 to specify IPv6 peering
> >
> >Allow IPv6 addresses in import/export attributes (peering) and use an
> >"address-family" identifier to indicate the type of routes exchanged
> >(ipv4|ipv6). Multicast can be specified as an "action" on the nlri.
> >
> >
> >--
> >Florent Parent
> >Viagénie inc.  http://www.viagenie.qc.ca
> >+1.418.656.9254 x 227
> 
> 
> -------------
> Marc Blanchet
> Viagenie
> http://www.viagenie.qc.ca
> tel: +1-418-656-9254 x225
> -------------
> IPv6 easy connectivity: http://www.freenet6.net
> RFC/W3C/IANA searchable repository: http://www.normos.org
> -------------
>