Re: [Dime] rfc3588bis version number

[Mark Jones <Mark.Jones at bridgewatersystems.com>]

I agree with Victor's summary and the conclusion to keep 3588bis at version 1. I am not against adding a Diameter v2 work item to the charter but this was clearly not the intent for 3588bis. The 3588bis was started was started over 2 years ago and we made lots of compromises in how we addressed 3588 issues in order to ensure backwards compatibility. If we'd wanted a v2, we would have tackled those issues differently.

In addition, 3588bis is needed immediately to guide implementors towards a successful interop of v1. Moving to v2 now effectively orphans v1 just when other SDOs are completing specifications of their Diameter-based applications and operators are planning deployments.

Regards
Mark

> -----Original Message-----
> From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On 
> Behalf Of Victor Fajardo
> Sent: April 1, 2009 12:18 PM
> To: dime at ietf.org
> Subject: [Dime] rfc3588bis version number
> 
> As noted in IETF74, there were concerns on incrementing the version 
> number for rfc3588bis. The latest rev of the bis draft has 
> the diameter 
> header version number set to 2. The main reason for incrementing the 
> version number are the following non-backward compatible 
> fixes/changes 
> in bis:
> 
> * TLS negotiation are no longer done within the context of 
> CER/CEA. TLS 
> connectivity is now established prior to any diameter traffic 
> via a well 
> known port.
> 
> * Capabilities exchange in the open state is no longer supported.
> 
> The concerns folks have raised for incrementing the version number in 
> bis are as follows (pls correct me if I mis-state some of 
> these issues 
> or if I miss some issues):
> 
> * The version increment was very sudden and seems to have been done 
> without much discussion. The current changes in bis can be classified 
> into either clarifications and bug fixes (the changes above are 
> included). Both types of changes does not warrant a  version 
> increment 
> given that no new significant feature is being introduced 
> beyond these 
> two types.
> 
> * The changes above that triggered discussion of version 
> increment are 
> considered critical "bug fixes" anyway. The fixes should be 
> considered 
> as "updates/patches" that would require code change 
> regardless since it 
> leaves certain features of the original 3588 broken, un-secure or 
> inter-operable. An incremental approach is better: i.e., bis 
> as a patch 
> and a new separate document as 3588 version 2.
> 
> * Some clarifications may require code changes for some vendors 
> (although care was always been taken to advertised proposed 
> solutions on 
> the list so this should be rare) but the code changes would have been 
> required anyway for successful interop.
> 
> * If the version number is incremented, it would be unclear 
> what RFC3588 
> state would be. Whether the new version would deprecate 3588 
> or it would 
> be a completely separate branch/track that's very similar yet 
> slightly 
> different from 3588. It creates more ambigouity and does not seem to 
> warrant a version increment as well.
> 
> * Using bis to create a new revision of Diameter will open it up to 
> addition of new features that can further delay publication of needed 
> bug fixes and clarifications.
> 
> A possible middle-ground is to keep to the intent of bis as a 
> bug fixing 
> instrument and keep bis as version 1. With regards to the 
> changes above:
> 
> * The version number in the diamter header may not help the TLS 
> negotiation anyway because we only see the version number after the 
> first diameter message. So a bis implementation and an 
> original 3588 may 
> not be able to inter operate regardless of whether the 
> version number is 
> reved-up.
> 
> * The capabilities exchange in 3588 was never really clearly 
> specified 
> (only hinted on in the statemachine). One possible solution 
> is to keep 
> the open-state capabilities exchange in bis have it as a "NO 
> OP" process 
> just to make it backward compatible with 3588. Then make sure 
> we state 
> this is clearly stated and that we intend to rely on 
> draft-zorn-dime-capablities-update-00.txt 
> <http://www.ietf.org/internet-drafts/draft-zorn-dime-capabliti
> es-update-00.txt> 
> in the future. Other possible approaches are welcomed.
> 
> Comments appreciated.
> 
> regards,
> victor
> 
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>