Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics

From: <[email-masked]>
Date: Tue, 2 Sep 2014 09:00:28 +0000

Hi, some comments below.

Regards,

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

---- Maria Cruz Bartolome a écrit ----

> Dear JJ, all,
> 
> See comments inline for some clarifications in the draft.
> Best regards
> /MCruz
> 
> -----Original Message-----
> From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: viernes, 29 de agosto de 2014 17:50
> To: Steve Donovan; [email-masked]
> Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics
> 
> Hi Steve and  all
> 
> M-bit on which I am cautious as often at the origin  of interoperability issues, is mentioned in different  places  in the 03 draft (sections 4.3, 6 and 6.8) with rules according to the following:
> 
> - when DOIC is supporting in an existing application, Mbit SHOULD not be set in DOIC AVPS (cf 6.8)
> - a new application can incorporate the DOIC mechanism as mandatory (cf 6), in this case the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set
> [MCruz] Fine
Lionel: OK

> 
> Some (non fundamental) remarks hereafter:
> a) We can have a new application where DOIC is not mandatory (when reading 6), but in 6.8 it is stated "when reused in newly defined Diameter applications, the DOC (note: to be DOIC)  related AVPs SHOULD have the M-bit set". If DOIC is optional for this new application, Mbit is not  set at least for the OC-Supported-features AVP in the requests, so to be ignored by a non DOIC supporting node receiving the request. May be to clarify.
> [MCruz] Agree to clarify in the draft
Lionel: optional to use does not mean optional to understand. So I think that the "SHOULD" is correct here for new application incorporating DOIC.

> 
> b) We have text with general statements about DOIC AVPs and some text in 6 (not contradictory)  related to OC-Feature-Vector and OC-OLR . I think that, in 6, OC-Supported-Feature could be added, or even replace OC-Feature-Vector AVP which is a sub AVP of OC-Supported features and so already addressed in 4.3. 
> [MCruz] Agree to use OC-Supported-Features
Lionel: OK 

> 
> c) About "existing commands" in 6, sometimes an application which can be a new one can reuse an existing command defined in another application, the Mbit rule here is attached to the application, so, to avoid misinterpretation,  may be better to write "commands of an existing application" in 6.
> [MCruz] Agree to be clarified.
Lionel: one small clarification: the M-bit setting is tight to the application AND the command. The same AVP can be with the M-bit set for one command and the M-bit for another command defined for the same application, as clarified in rfc6733.

> 
> d) About an intermediate  proxy DA for an application but not supporting DOIC for this application (as not needed), how  does it behave when transferring  requests with OC-Supported-Features or OLR AVPs with Mbit set, is it clear that the DA transfers the DOIC AVPs and not reject them for AVP unsupported?    
> [MCruz] If the proxy DA supports application X, when DOIC AVPs are sent in application X responses, with M-bit set, isn't that the application will reject them?
Lionel: a proxy used in the path of Diameter EAP exchanges between clients and remote servers will not reject commands because it is not performing EAP authentication itself. As soon as the DOIC AVPs are supported by the application, there is no reason for the proxy to reject them, except if there is a specific policy to do it.

> 
> e) in 4.3, it is written "NOT RECOMMENDED", I think better to write " M-bit in sub-AVPs SHOULD not be set" 
> [MCruz] Agree
Lionel: even better: "SHOULD NOT" :-)

> 
> I hereafter remind the verison03  extracts mentioning M-bit In 4.3
>    More specifically, the sub-AVPs inside the
>    OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.
>    However, when overload control AVPs are piggybacked on top of an
>    existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED
> 
> in 6 
>    When added to existing commands,both OC-Feature-Vector and OC-OLR
>    AVPs SHOULD have the M-bit flag cleared to avoid backward
>    compatibility issues
> 
>    A new application specification can incorporate the overload control
>    mechanism specified in this document by making it mandatory to
>    implement for the application and referencing this specification
>    normatively.  In such a case, the OC-Feature-Vector and OC-OLR AVPs
>    reused in newly defined Diameter applications SHOULD have the M-bit
>    flag set.  However, it is the responsibility of the Diameter
>    application designers to define how overload control mechanisms works
>    on that application.
> 
> In 6.8 
>    As described in the Diameter base protocol [RFC6733], the M-bit
>    setting for a given AVP is relevant to an application and each
>    command within that application that includes the AVP.
> 
>    The Diameter overload control AVPs SHOULD always be sent with the
>    M-bit cleared when used within existing Diameter applications to
>    avoid backward compatibility issues.  Otherwise, when reused in newly
>    defined Diameter applications, the DOC related AVPs SHOULD have the
>    M-bit set.
> 
> Best regards
> 
> JJacques 
> 
> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Jouni Envoyé : jeudi 31 juillet 2014 20:49 À : <[email-masked]> Cc : [email-masked]; Ben Campbell Objet : Re: [Dime] Issue #48 - M-bit gives wrong sementics
> 
> 
> OK++;
> 
> On Jul 31, 2014, at 8:41 PM, <[email-masked]> <[email-masked]> wrote:
> 
> > Ok for me.
> > 
> > Envoyé depuis mon Sony Xperia SP d'Orange
> > 
> > ---- Ben Campbell a écrit ----
> > 
> > 
> > No objection
> > 
> > On Jul 31, 2014, at 11:52 AM, Steve Donovan <[email-masked]> wrote:
> > 
> >> All,
> >> 
> >> The proposal coming out of the meeting in Toronto was to close this issue with no changes to the existing text.
> >> 
> >> Let me know if there are objections to doing so, otherwise I'll close the issue.
> >> 
> >> Regards,
> >> 
> >> Steve
> >> 
> >> _______________________________________________
> >> DiME mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dime
> > 
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dime
> > 
> > ______________________________________________________________________
> > ___________________________________________________
> > 
> > Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> > exploites ou copies sans autorisation. Si vous avez recu ce message 
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> > 
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> > Thank you.
> > 
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Sep 2014 09:09:42 -0500

JJ,

To make sure that the proposed changes are well understood, can you 
please open a new issue and include the proposed changes.  It would be 
helpful to have the before and after text in the issue write-up. This 
will give everyone a chance to review the wording prior to it being 
incorporated into the draft.

Regards,

Steve