Re: [Dime] rfc3588bis version number

["Glen Zorn" <gwz at net-zen.net>]

Victor Fajardo [mailto://vfajardo at tari.toshiba.com] writes:

> If there are no more comments/objections/opinions, we will incorporate
> Mark's proposal into the next rev of bis. Here's a summary:
> 
> * Capabilities update will be kept in bis for backward compatibility
> but
> will be considered a 'noop' and text will be added that this feature is
> deprecated and that future work will properly cover this functionality.
> 
> * Fixes to TLS negotiation will be rolled back to retain backward
> compatibility but strong language regarding its vulnerability will be
> added. Additional text noting that fixes to this issue will be done in
> the new revision of diameter will be introduced.

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?

 
> 
> 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