Subject: [Dime] Question on the use of the M-bit

From: "German Blanco" <[email-masked]>
Date: Mon, 3 Mar 2008 14:46:04 +0100

Hello all,

I have a very simple question on the M-bit, please help.

My view is that the application may set this bit for an AVP in any
instance of any request independently. That is, the M-bit is set when
the peer is required to understand the AVP, with no other condition. 
For example, I have this AVP for nationality of people that I use only
for foreigners. In the authentication request of this application I send
the nationality AVP with the M-bit set if the person is a foreigner
since the Diameter application in the other peer needs to do something
special, but if the person is local then I send the nationality AVP with
the M-bit not set, since the default functionality will work. I also
think that since the following restrictions are not explicit anywhere
that I am aware, and they do not seem to serve any practical purpose,
they should be avoided if possible.

There are other people that think that the M-bit value is required to be
the same in every instance of request of an specific type for one
application. That is, they think that if the AVP has the M-bit set in
the authentication request of an application, then it must have the same
M-bit value every time this authentication request is sent.

And there are yet other people that think that the value must be the
same for every request of every type for one application.

I haven't met anyone that thinks that the value needs to be the same for
the AVP in all applications, but maybe I haven't search enough :-)

Please help me by telling me if I am wrong and why or if you think that
there are other reasons to support my view.

By the way, maybe this is worth a clarification in RFC3588bis.

Thanks,

German Blanco. 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Tom Taylor <[email-masked]>
Date: Mon, 03 Mar 2008 09:10:38 -0500

For what it's worth, I understood the M-bit from your point of view when I first 
worked with DIAMETER back in 1998. But I haven't been in close contact with 
implementation in the industry since then.

German Blanco wrote:
> ------------------------------------------------------------------------
>

---

From: "Schendel, Jens (NSN - DE/Berlin)" <[email-masked]>
Date: Mon, 3 Mar 2008 16:34:57 +0100

Hi,

so far I haven't seen dynamic M-bit setting in specifications (hence also not seen on interface implementations). Especially with respect to a Diameter server, I think that the application running on the server is basically expected to handle incoming AVP according to local service policies. From this point of view it makes no real difference if M-Bit was set or not. The server will use or ignore AVP according to service level agreement with the network operator. Hence I feel that such dynamic handling is usually not needed. May-be a point for Diameter design guidelines?
This also comes to the question what "unrecognized" in 3588(bis) means in the context of M-Bit handling. The server may syntactically recognize any AVP but may not or may not want to "recognize" it semantically... Also, the server internal processing can hardly be seen on the interface (in the successful answer case).
Thus I would additionally suggest adding a statement in 3588bis that for Diameter Server the AVP processing including M-bit evaluation depends on server's local service policies.

Jens 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von ext Tom Taylor
> Gesendet: Montag, 3. März 2008 15:11
> An: German Blanco
> Cc: [email-masked]
> Betreff: Re: [Dime] Question on the use of the M-bit
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Mar 2008 11:00:30 -0500

IMHO, what you need is an AVP indicated as optional in ABNF but with
M-bit set. That it is optional in ABNF indicates that it may not be
present. That it has M-bit set indicates that if present, it needs to be
understood/processed.

M-bit value for an AVP can change for different commands.

Thanks,

Tolga

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
German Blanco
Sent: Monday, March 03, 2008 8:46 AM
To: [email-masked]
Subject: [Dime] Question on the use of the M-bit

Hello all, 

Thanks, 

German Blanco.

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 03 Mar 2008 11:11:43 -0500

Hi,

Comments inline.

> Hi,
>
> so far I haven't seen dynamic M-bit setting in specifications (hence also not seen on interface implementations). Especially with respect to a Diameter server, I think that the application running on the server is basically expected to handle incoming AVP according to local service policies. From this point of view it makes no real difference if M-Bit was set or not. 

Typically, 'M' bit settings are design time (based on a app spec) rather 
than run-time decisions. Also, based on the current  base spec, it does 
matter if the 'M' bit is set or not. See Sec 4.1.

> The server will use or ignore AVP according to service level agreement with the network operator. Hence I feel that such dynamic handling is usually not needed. May-be a point for Diameter design guidelines?
>   

There's ongoing work with regards to extensibility that will likely 
include clarifying/updating M-bit usage/scope etc. See previous threads 
on 'Design Team on Diameter Extensibility'.

> This also comes to the question what "unrecognized" in 3588(bis) means in the context of M-Bit handling. The server may syntactically recognize any AVP but may not or may not want to "recognize" it semantically... 

"unrecognized" in the context of an M-bit means syntactically and 
semantically understood but the receiving entity. Despite the fact that 
you may not use it. Pls see Tolga's response for appropriate alternative.

regards,
victor

> Also, the server internal processing can hardly be seen on the interface (in the successful answer case).

>>> instance of any request independently. That is, the M-bit 
>>>       
>> is set when
>>     
>>> the peer is required to understand the AVP, with no other 
>>>       
>> condition. 
>>     
>>> For example, I have this AVP for nationality of people that 
>>>       
>> I use only
>>     
>>> for foreigners. In the authentication request of this 
>>>       
>> application I send
>>     
>>> since the Diameter application in the other peer needs to 
>>>       
>> do something
>>     
>>> special, but if the person is local then I send the 
>>>       
>> nationality AVP with
>>     
>>> think that since the following restrictions are not 
>>>       
>> explicit anywhere
>>     
>>> that I am aware, and they do not seem to serve any 
>>>       
>> practical purpose,
>>     
>>> There are other people that think that the M-bit value is 
>>>       
>> required to be
>>     
>>> application. That is, they think that if the AVP has the 
>>>       
>> M-bit set in
>>     
>>> the authentication request of an application, then it must 
>>>       
>> have the same
>>     
>>> I haven't met anyone that thinks that the value needs to be 
>>>       
>> the same for
>>     
>>> Please help me by telling me if I am wrong and why or if 
>>>       
>> you think that
>>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Mar 2008 11:17:12 -0500

Hi Jens,

Please see below for comments.

Thanks,
Tolga

> -----Original Message-----
> Schendel, Jens (NSN - DE/Berlin)
> Sent: Monday, March 03, 2008 10:35 AM
> To: ext Tom Taylor; German Blanco
> Cc: [email-masked]
> Subject: Re: [Dime] Question on the use of the M-bit
> 
> Hi,
> 
> so far I haven't seen dynamic M-bit setting in specifications (hence also
> not seen on interface implementations). Especially with respect to a
> Diameter server, I think that the application running on the server is
> basically expected to handle incoming AVP according to local service
> policies. From this point of view it makes no real difference if M-Bit was
> set or not. The server will use or ignore AVP according to service level
> agreement with the network operator. Hence I feel that such dynamic
> handling is usually not needed. May-be a point for Diameter design
> guidelines?
[TOLGA]I agree with your comments about dynamic M-bit setting. M-bit indicates that processing the AVP is required for the semantics of the application. I disagree about basing the decision to process AVPs on local policy decisions. If so, what would be the point to have M-bit at all?
> This also comes to the question what "unrecognized" in 3588(bis) means in
> the context of M-Bit handling. The server may syntactically recognize any
> AVP but may not or may not want to "recognize" it semantically... Also,
> the server internal processing can hardly be seen on the interface (in the
> successful answer case).
> Thus I would additionally suggest adding a statement in 3588bis that for
> Diameter Server the AVP processing including M-bit evaluation depends on
> server's local service policies.
> 
> Jens
>

---

From: "Schendel, Jens (NSN - DE/Berlin)" <[email-masked]>
Date: Mon, 3 Mar 2008 17:32:53 +0100

Hi Tolga, Victor, 

thanks for your responses. One comment inline.

Jens

> Von: ext Asveren, Tolga [mailto:[email-masked]] 
> Gesendet: Montag, 3. März 2008 17:17
> An: Schendel, Jens (NSN - DE/Berlin); ext Tom Taylor; German Blanco
> Cc: [email-masked]
> Betreff: RE: [Dime] Question on the use of the M-bit
> 
> Hi Jens,
> 
> [TOLGA]I agree with your comments about dynamic M-bit 
> setting. M-bit indicates that processing the AVP is required 
> for the semantics of the application. I disagree about basing 
> the decision to process AVPs on local policy decisions. If 
> so, what would be the point to have M-bit at all?

[JS] Yes, actually at least for the limited scope of server processing I do not see a need.

---

From: Preeti Shandilya <[email-masked]>
Date: Tue, 4 Mar 2008 10:20:33 +0530

I agree with you Tolga,  but RFC does not mention that 'AVP flag rule for 
the M bit can never be 'MAY'

So if M bit for any AVP is mentioned as MAY, this indicates that server 
must recognize this AVP, if M bit is set. Server should not generate any 
error if M bit is not set for the same AVP

So theoretically, it is possible that there can be an AVP which can have M 
bit set or M bit 'not set'. Although practically I don't see any scenario.

regards
Preeti

"Asveren, Tolga" <[email-masked]> 
Sent by: [email-masked]
03/03/2008 09:30 PM

To
"German Blanco" <[email-masked]>, <[email-masked]>
cc

Subject
Re: [Dime] Question on the use of the M-bit

IMHO, what you need is an AVP indicated as optional in ABNF but with M-bit 
set. That it is optional in ABNF indicates that it may not be present. 
That it has M-bit set indicates that if present, it needs to be 
understood/processed.

Thanks,
Tolga

Hello all, 
I have a very simple question on the M-bit, please help. 
My view is that the application may set this bit for an AVP in any 
instance of any request independently. That is, the M-bit is set when the 
peer is required to understand the AVP, with no other condition. 
For example, I have this AVP for nationality of people that I use only for 
foreigners. In the authentication request of this application I send the 
nationality AVP with the M-bit set if the person is a foreigner since the 
Diameter application in the other peer needs to do something special, but 
if the person is local then I send the nationality AVP with the M-bit not 
set, since the default functionality will work. I also think that since 
the following restrictions are not explicit anywhere that I am aware, and 
they do not seem to serve any practical purpose, they should be avoided if 
possible.
There are other people that think that the M-bit value is required to be 
the same in every instance of request of an specific type for one 
application. That is, they think that if the AVP has the M-bit set in the 
authentication request of an application, then it must have the same M-bit 
value every time this authentication request is sent.
And there are yet other people that think that the value must be the same 
for every request of every type for one application.
I haven't met anyone that thinks that the value needs to be the same for 
the AVP in all applications, but maybe I haven't search enough :-)
Please help me by telling me if I am wrong and why or if you think that 
there are other reasons to support my view. 
By the way, maybe this is worth a clarification in RFC3588bis. 
Thanks, 
German Blanco. _______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

***********************  Aricent-Unclassified   ***********************

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "German Blanco" <[email-masked]>
Date: Thu, 6 Mar 2008 11:30:10 +0100

Thank you all for your responses,
 
regarding the scenario, we do have at least an AVP in the Cx Interface
in 3GPP TS 29.228 and 29.229 that has the M-bit always set in the
requests and never in the answers of the same command.

German.

From: Preeti Shandilya [mailto:[email-masked]] 
Sent: martes, 04 de marzo de 2008 5:51
To: Asveren, Tolga
Cc: [email-masked]; [email-masked]; German Blanco
Subject: Re: [Dime] Question on the use of the M-bit

I agree with you Tolga,  but RFC does not mention that 'AVP flag rule
for the M bit can never be 'MAY' 

So theoretically, it is possible that there can be an AVP which can have
M bit set or M bit 'not set'. Although practically I don't see any
scenario. 

regards 
Preeti 

03/03/2008 09:30 PM 

To
	
Subject

  
Thanks, 
Tolga 

Hello all, 

Thanks, 

***********************  Aricent-Unclassified   *********************** 
"DISCLAIMER: This message is proprietary to Aricent  and is intended
solely for the use of 
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be 
circulated or used for any purpose other than for what it is intended.
If you have received this message in error, 
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by
this email including damage from virus."

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 06 Mar 2008 12:18:26 +0100

I should also mention that some of the rules for setting M-bits in Diameter might get changed or clarified as we progress with the work on our Diameter Extensibility story. 

Currently, I would be in favor of the following rules: 

* M-bit has to be set when the AVP is required in the ABNF
(means that it uses the {AVP} indication in the ABNF of a command)
Changes to the ABNF of a Command require a new Command Code to be registered. A new command code in an application requires a new Diameter application to be defined. 
* The AVP flag table column of SHOULD and SHOULD NOT has to be deleted. 
It does not make a lot of sense. 
* When an AVP has the M-bit then a new Diameter application has to be defined. When AVPs are imported from other applications then their flag 
setting needs to be re-evaluated. Hence, you do not necessarily inherit the AVP flag setting unless it makes sense todo so. The M-bit semantic is associated with the specific usage of the AVP rather than with the AVP itself. Usage in a different context might require different treatment. 
* When an AVP MAY have the M bit set then this has the same implication as having the M bit set with regard to the definition of a new Diameter application.  
* The M-bit has only relevance for end-to-end usage; There shouldn't be any rule on how intermediaries process AVPs with the M-bit set. They may, however, at any time reject a specific request but that may have very little todo with the usage of a certain M-bit. 

Anything missing? 

A note on the usage of the M-bit in the MAY column of the AVP flag table: This can be used to realize the concept of "mandatory to implement but optional to use" when the ABNF indicates that the AVP is non-required (i.e., [AVP]). In contrast when the ANBF says that an AVP is required (i.e., {AVP} + the M-bit is set automatically based on my rules above) then this is an AVP that must be implemented and must be used. 

Does this make sense? 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 6 Mar 2008 11:30:10 +0100
> Von: "German Blanco" <[email-masked]>
> An: "Preeti Shandilya" <[email-masked]>, "Asveren, Tolga" <[email-masked]>
> CC: [email-masked], [email-masked]

---

From: Preeti Shandilya <[email-masked]>
Date: Thu, 6 Mar 2008 17:24:26 +0530

Hi !

My comments inline.

regards
Preeti

"Hannes Tschofenig" <[email-masked]> 
Sent by: [email-masked]
03/06/2008 04:48 PM

To
"German Blanco" <[email-masked]>, [email-masked], 
Preeti Shandilya/HSS@HSS
cc
[email-masked], [email-masked], 
[email-masked]
Subject
Re: [Dime] Question on the use of the M-bit

I should also mention that some of the rules for setting M-bits in 
Diameter might get changed or clarified as we progress with the work on 
our Diameter Extensibility story. 

* M-bit has to be set when the AVP is required in the ABNF
(means that it uses the {AVP} indication in the ABNF of a command)
Changes to the ABNF of a Command require a new Command Code to be 
registered. A new command code in an application requires a new Diameter 
application to be defined. 

Preeti > I guess this shall lead to some interoperability issues. i.e new 
nodes shall mandatorily start expecting to have M bit set in the AVP when 
it receive request messages from peer nodes which are the older nodes.

Preeti > fine

* When an AVP has the M-bit then a new Diameter application has to be 
defined. When AVPs are imported from other applications then their flag 
setting needs to be re-evaluated. Hence, you do not necessarily inherit 
the AVP flag setting unless it makes sense todo so. The M-bit semantic is 
associated with the specific usage of the AVP rather than with the AVP 
itself. Usage in a different context might require different treatment. 

Preeti > This indicates that there can be an AVP which has M bit mandatory 
in one application while M bit not set in other application for the same 
AVP. Is the understanding correct ?

* When an AVP MAY have the M bit set then this has the same implication as 
having the M bit set with regard to the definition of a new Diameter 
application. 
* The M-bit has only relevance for end-to-end usage; There shouldn't be 
any rule on how intermediaries process AVPs with the M-bit set. They may, 
however, at any time reject a specific request but that may have very 
little todo with the usage of a certain M-bit. 

Preeti > I don't think that M bit shall be only for end-to-end usage. 
There can be proxy, redirect nodes which may act upon the M bit flag of an 
AVP. 

Anything missing? 

A note on the usage of the M-bit in the MAY column of the AVP flag table: 
This can be used to realize the concept of "mandatory to implement but 
optional to use" when the ABNF indicates that the AVP is non-required 
(i.e., [AVP]). In contrast when the ANBF says that an AVP is required 
(i.e., {AVP} + the M-bit is set automatically based on my rules above) 
then this is an AVP that must be implemented and must be used. 

Does this make sense? 

Ciao
Hannes

-------- Original-Nachricht --------

***********************  Aricent-Restricted   ***********************

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 13:28:53 +0100

Hannes,

Some comments inline.

> I should also mention that some of the rules for setting 
> M-bits in Diameter might get changed or clarified as we 
> progress with the work on our Diameter Extensibility story. 
> 
> Changes to the ABNF of a Command require a new Command Code 
> to be registered. A new command code in an application 
> requires a new Diameter application to be defined. 

Ok. I wonder if there is any existing specification that has
{ AVP } without M-bit set?

> * When an AVP has the M-bit then a new Diameter application 
> has to be defined. When AVPs are imported from other 
> applications then their flag 
> setting needs to be re-evaluated. Hence, you do not 
> necessarily inherit the AVP flag setting unless it makes 
> sense todo so. The M-bit semantic is associated with the 
> specific usage of the AVP rather than with the AVP itself. 
> Usage in a different context might require different treatment. 
> * When an AVP MAY have the M bit set then this has the same 
> implication as having the M bit set with regard to the 
> definition of a new Diameter application.  
> * The M-bit has only relevance for end-to-end usage; There 
> shouldn't be any rule on how intermediaries process AVPs with 
> the M-bit set. They may, however, at any time reject a 
> specific request but that may have very little todo with the 
> usage of a certain M-bit. 

Proxies need to understand the applications and sometimes process
the messages, thus M-bit is not only for end-to-end usage.

Cheers,
	Jouni

> Anything missing? 
> 
> 
> A note on the usage of the M-bit in the MAY column of the AVP 
> flag table: This can be used to realize the concept of 
> "mandatory to implement but optional to use" when the ABNF 
> indicates that the AVP is non-required (i.e., [AVP]). In 
> contrast when the ANBF says that an AVP is required (i.e., 
> {AVP} + the M-bit is set automatically based on my rules 
> above) then this is an AVP that must be implemented and must be used. 
> 
> Does this make sense? 
> 
> Ciao
> Hannes
>

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 06 Mar 2008 08:29:05 -0500

Hi Jouni,

> the messages, thus M-bit is not only for end-to-end usage.

For proxies, it MAY perform M-bit checks for applications/messages it is 
interested in just like end-points do. But I guess the point is that 
there is no hard rule that all intermediaries MUST do M-bit checks.

regards,
victor

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 6 Mar 2008 16:16:07 +0200

Hi Victor,

> there is no hard rule that all intermediaries MUST do M-bit checks.

Yes, I understand that. I just reacted to the strong statement
"has only relevance", which is not the case in all situations.
"MAY perform.." is much better.

Cheers,
	Jouni