Re: [Dime] rfc3588bis version number

[Victor Fajardo <vfajardo at tari.toshiba.com>]

Hi,

> > If these are really the only two problems, is such a drastic 
> > approach really necessary?  It seems to me that the problems 
> > could be fairly easily solved with appropriate weasel-wording 
> > - no, I mean clever usage of standards language ;-).  For 
> > example, something like 
> >
> > Implementations MAY {old way of doing X}; however, 
> > implementations SHOULD {new way of doing X.
> >
> > If one way or the other is required, say so w/a MUST.  
> > Doesn't this work?
> >     
>
> If keeping track of the previous way of doing is something foreseen, I would go for this approach.
>   

I don't mind going with Glen's approach. It would work in our give case. 
Any other thoughts ?

-- victor

> I was assuming that having a new RFC number obsoleting the previous one had the same purpose. It is a hint for vendors for checking what should be fixed in their pre-existing Diameter implementation and up to them to do the necessary changes. And the Diameter vendor newbees, they are not bothered by "old stuff". At least, it was the way of doing for MIPv4 for instance that has been be updated something like four times, a standard solution without any version number...
>
> Lionel
>
>   
> >  
> >     
> > > regards,
> > > victor
> > >
> > >       
> > > > > I fully support Sebastien. If bis is not given a new version 
> > > > > number, there are different protocols in the wild which 
> > > > >           
> > claim to be 
> >     
> > > > > the very same protocol. These protocols are not 
> > > > >           
> > interoperable with 
> >     
> > > > > each
> > > > >           
> > > other,
> > >       
> > > > > and their differences are subtle. I suspect implementation
> > > > >           
> > > nightmares
> > >       
> > > > > dead ahead.
> > > > >
> > > > >
> > > > >           
> > > > Version 1 is already out in the wild and two independent
> > > >         
> > > implementations of RFC3588 may not interoperate. So we 
> > >       
> > spent 18 months 
> >     
> > > on bug fixes in 3588bis to greatly improve the odds that they can 
> > > interoperate. Implementers finding contradictions or ambiguities in
> > > RFC3588 have been able to turn to 3588bis for clarification. 
> > > Throughout that time Victor was strict in enforcing solutions that 
> > > were backwards compatible.
> > >       
> > > > Recently we discover two issues (TLS negotiation and capabilities
> > > >         
> > > update) and find we can not fix them without breaking backwards 
> > > compatibility. Given that no one noticed these problems 
> > >       
> > until now, I 
> >     
> > > strongly suspect these are not critical features of the 
> > >       
> > Diameter base 
> >     
> > > protocol. For Capabilities Update, we chose to deprecate 
> > >       
> > the feature 
> >     
> > > in bis rather than fix it and Glen captured a solution in a 
> > >       
> > separate 
> >     
> > > draft. If offered the choice at that point, I believe the 
> > >       
> > majority of 
> >     
> > > delegates would have been preferred a similar approach for TLS 
> > > negotiation rather than bump the version.
> > >       
> > > >         
> > > > > I acknowledge that it's a pity that the plan not to introduce 
> > > > > incompatible changes in bis couldn't be upheld. But 
> > > > >           
> > regardless of 
> >     
> > > > > that:
> > > > > these *are* two different protocols, and they *really really
> > > > > should* be
> > > > > easily distinguishable from each other.
> > > > >
> > > > >
> > > > >           
> > > > The original plan for 3588bis was sound and is still required. IMO
> > > >         
> > > the decision to address TLS negotiation in bis knowing that the fix 
> > > was not backwards compatible was our error. I vote we 
> > >       
> > deprecate this 
> >     
> > > feature in 3588bis, move the proposed solution to a new draft 
> > > (Diameter
> > > v2 if required) and get 3588bis out the door.
> > >       
> > > > Regards
> > > > Mark
> > > > _______________________________________________
> > > > DiME mailing list
> > > > DiME at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/dime
> > > >
> > > >
> > > >
> > > >         
> > > _______________________________________________
> > > DiME mailing list
> > > DiME at ietf.org
> > > https://www.ietf.org/mailman/listinfo/dime
> > >       
> > _______________________________________________
> > DiME mailing list
> > DiME at ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >
> >     
>
>
>
>