Re: [Dime] rfc3588bis version number

[Julien Bournelle <julien.bournelle at gmail.com>]

Hi,

 I second lionel's comments. I thought this version Bis was about
correcting bugs and clarify some process and not about adding new
functionalities to the protocol.

 So, I would prefer to stick with Version 1 in the header.

 Regards,

 Julien

On Wed, Apr 1, 2009 at 11:52 PM,  <lionel.morand at orange-ftgroup.com> wrote:
> Hi Victor,
>
> Thanks for the good summary of the discussion!
>
> I can just re-assess what I said during the meeting.
>
> In my understanding, the current scope of the work was "limited" to fix bugs and clarify procedures/texts in the existing RFC 3588 (along with Diameter application design guidelines draft).
> It was not foreseen to add "new features" to the set of Diameter base protocol functionalities and backward compatibility was THE leitmotiv. For example, some "proposed improvments" was recently rejected because of non-backward compatibility issues.
>
> If there are issues that are required to be fixed in a way that is not backward compatible with current Diameter base implementations, I think that the rationale to accept them is that they are actually "issues"! IMHO, solving issues takes precedence over keeping unchanged something wrong...
>
> But this is not a reason to change the version. It is a reason to update the specification of the current version. Without these changes, the current implementation is just "incomplete" or "unstable" or "whatever": these solutions should be deemed required.
>
> IETF, 3GPP, Wimax and other SDOs, as well as vendors are waiting for this RFC 3588bis document for a while. We cannot take the liberty of delaying again the publication of this document. And it is too late to open a discussion on a v2 version, starting with a clear definition of the new scope of the functional requirements and a clear version negociation handling at the Diameter base protocol level.
>
> Whatever the final position taken about the issues and the proposed solutions, the final document should describe the (new) recommended implementation of the Diameter base protocol (i.e. v1).
>
> For the two current issues/solutions, I would recommend to use separate threads, in order to separate the discussions: version number, TLS negociation and Capabilities Exchange.
>
> BR,
>
> Lionel
>
>
>
>> -----Message d'origine-----
>> De : dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] De
>> la part de Victor Fajardo
>> Envoyé : mercredi 1 avril 2009 18:18
>> À : dime at ietf.org
>> Objet : [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
>>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>