Subject: RE: [Dime] Conflict with grouped & mandatory AVPs.

From: "Dan Warren" <[email-masked]>
Date: Thu, 11 Oct 2007 13:28:54 +0100

Interesting discussion, particularly for me since I was one of the
people that did a lot of the Cx and Sh work in 3GPP (you can Boo and
through rocks at me privately).  The intent was certainly to have
something like 'the Grouped AVP is Optional, but when it is included it
MUST include/comprehend the sub-AVP' which is why we included the 'M'.

I guess that doesn't really work with current definition and comes down
perhaps to the old chestnut of Mandatory inclusion vs Mandatory
comprehension.

So two questions;-

- if the Grouped AVP is optional and not recognised by the receiver,
could it be discarded silently even if it contains 'M' marked sub-AVPs?
>From the discussions so far I am guessing that the answer is either
'No', or 'n/a since the situation should never occur.

- For the intended convention of what we tried to achieve in 3GPP, what
should we have written?  I am guessing again it should be all Optional
and describe conditions for behaviour in the text associated with nodal
behaviour...

Dan 

> -----Original Message-----
> From: Philip Crocker [mailto:[email-masked]] 
> Sent: 11 October 2007 10:13
> To: Ralph Loader
> Cc: [email-masked]
> Subject: RE: [Dime] Conflict with grouped & mandatory AVPs.
> 
> Hi Ralph,
> 
> Thanks for your feedback.  I agree that it's best to keep the 
> 'M' bit set in a sub-AVP if that AVP has been defined as 
> mandatory (for one reason, it makes parsing an AVP simpler if 
> you can expect an AVP to have the same flags no matter where 
> the AVP is present in a message).
> 
> As a result, I'd propose the following text changes to 
> RFC3588-bis, which takes account of arbitrarily nested AVPs.
> 
> -  Edit RFC3588-bis section 4.1 to state that if an AVP with 
> the 'M' bit is unrecognised, this should cause the message to 
> be discarded if all Grouped AVPs in which that AVP is nested 
> within also have the 'M' bit set.
>  
> -  Remove the sentence from RFC3588-bis section 4.4 starting 
> "Further, if any of the AVPs encapsulated within...".
> 
> Regards,
> 
> Phil Crocker
> Network Protocols Division
> Data Connection Ltd. (DCL)
> 
> 
> -----Original Message-----
> From: Ralph Loader [mailto:[email-masked]]
> Sent: 10 October 2007 19:30
> To: Philip Crocker
> Cc: [email-masked]
> Subject: Re: [Dime] Conflict with grouped & mandatory AVPs.
> 
> 
> > In my opinion it is reasonable for a Diameter application 
> to be able 
> > to define an optional grouped AVP that reuses some 
> mandatory AVPs as 
> > sub-AVPs.  Does this seem reasonable to people?  If so, I would 
> > propose
> > rfc3588bis-08 is updated to this effect.
> 
> I take it that the intention is that the sub-AVP still has the M bit
> set, but that the receiver never generates an 'unknown mandatory AVP' 
> error for the sub-AVP.  (An alternative would be to not set the M bit
> when putting such a sub-AVP into an optional AVP).
> 
> Cheers,
> Ralph.
> 
> 
> 
> >  
> > Regards,
> >  
> > Phil Crocker
> > Network Protocols Division
> > Data Connection Ltd. (DCL)
> > 
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> > 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 
> 

Forthcoming GSMA Events:
 
GSMA Mobile Asia Congress
Macau
12 - 15 November 2007
www.mobileasiacongress.com
 
GSMA Mobile World Congress
Barcelona
11 - 14 February 2008
www.mobileworldcongress.com

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 759 2300 and highlight the error

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

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Oct 2007 09:09:27 -0400

Hi Dan,

> MUST include/comprehend the sub-AVP' which is why we included the 'M'.

I guess there's always confusion with what it means to be an optional 
AVP and how it relates to 'M' bit. From what I understand (folks can 
correct me if I'm wrong), the core idea was an optional AVP means it 
does not have to appear in a message (controlled by the ABNF) but it 
may/may not have the 'M' bit set if it does appear. If it has the 'M' 
bit set then the receiver has to understand the AVP and its contents. 
Given this and the scenario you stated above (and depending on whether 
your piggybacking your AVP to an existing application), it may have been 
better to set the 'M' bit for the grouped avp as well to be 'cleaner'.

Going back to the original discussion, I thinking a hierarchal approach 
is best given what we have now. So, if a grouped AVP does not have the 
'M' bit set then its member AVP does not have to be recognizable even if 
some/all of them have 'M' bit set. Note that this applies to nesting of 
grouped AVPs as well.

> 'No', or 'n/a since the situation should never occur.

We need to update the spec and say that if the parent grouped avp does 
not the 'M'-bit set then member AVPs need not be recognizable despite 
their M-bit settings.

> and describe conditions for behaviour in the text associated with nodal

The 'all optional' approach is useful maybe only in the case where your 
piggybacking your AVP to an existing application; i.e. your not defining 
a new app. But if you are defining a new app and the app will have to 
recognize these AVPs, it maybe best to control optionality of an AVP via 
the command ABNF.

best regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 11 Oct 2007 10:52:26 -0400

Hi Victor,Dan,

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Thursday, October 11, 2007 9:09 AM
> To: Dan Warren
> Cc: [email-masked]; Philip Crocker
[TOLGA]IMHO this really depends on the flexibility we want to provide.
For example, if I want to indicate "That you can process this grouped
AVP is optional but in case you want to do that please make sure that
you know the semantics associated with certain sub-AVPs in it" then I
would not set the M-bit for the grouped AVP but for the relevant
sub-AVPs.
> not the 'M'-bit set then member AVPs need not be recognizable despite
[TOLGA]If we want to provide the type of flexibility I mentioned above,
IMHO what we need to say is that a grouped AVP may be ignored it if its
M-bit is not set regardless of the M-bit setting of its sub-AVPs. So,
Dan, for your question, my answer would be "Yes".
> > and describe conditions for behaviour in the text associated with
nodal
[TOLGA]I think, if we update RFC3588 properly, the 3GPP usage for this
case should be fine.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Oct 2007 11:29:33 -0400

Hi Tolga,

>> your piggybacking your AVP to an existing application), it may have
>>     
> been
>   

I guess in the specific case where you really need to understand the 
contents of an AVP (whether grouped of not), it seems to make sense to 
have the M-bit set. Extending this to a hierarchal approach, the 
recognizability of inner AVP can be tied to its parent. The M-bit of the 
parent makes it easier to indicate this situation; i.e. you don't have 
to parse through inner AVPs to see which one has an M-bit or not to 
realize the recognizability of the entire group ... or I'm probably 
missing something :)

Also in 3GPP apps, I think maybe the use of the ABNF to indicate 
optionality should be considered or at least not confused with the M-bit 
settings.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 11 Oct 2007 12:20:23 -0400

Hi Victor,

> Sent: Thursday, October 11, 2007 11:30 AM
> To: Asveren, Tolga
> Cc: Dan Warren; [email-masked]; Philip Crocker
[TOLGA]IMHO, not extending the meaning of M-bit of a sub-AVP to its
parent is a better approach (or better said to have the flexibility to
do so). If we forbid this, there won't be a way to indicate the behavior
I described above. For example, if one wants to attach QoS-Capability
AVP to a message without M-bit set, this would indicate that receiver
does not really need to understand/process it. OTOH, QoS-Profile sub-AVP
will have M-bit set to indicate that in case the receiver is able to
process QoS-Capability AVP, it must know what to do with QoS-Profile
AVP. Setting M-bit of the QoS-Capability AVP (the parent AVP) would make
its processing mandatory, which may not be always the desired behavior.
> optionality should be considered or at least not confused with the
M-bit
[TOLGA]Yes, it is important to appreciate the difference between ABNF
semantics and M-bit. I think there is some room for improvement at
certain 3GPP specification regarding this issue but AFAIU what we
discuss now does not fall into this category. Is there any concrete
proposal for an ABNF based solution?

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 11 Oct 2007 14:04:24 -0400

Hi Tolga,

> its processing mandatory, which may not be always the desired behavior.

There maybe some confusion on what comments relates to where :) I guess 
your example above is what i meant with my original comment "whether we 
are piggybacking this AVP to an exsiting application". And given that we 
need to support this genericness, I agree we do need to remove some 
restrictions. However, commenting on applications/scenarios being from 
Dan, it may have been better to use the ABNF as optionality indicator 
rather than the M-bit in some of the 3gpp designs and use a hierarchal 
model.

regards,
victor

---

From: Himanshu Bahl <[email-masked]>
Date: Thu, 18 Oct 2007 12:44:55 +0530

Hi All,
I have been following this discussion and believe the situation of 
QoS-Capability AVP depicted below is a good example hence we should allow 
outer AVP as optional while inner(nested) AVPs can be mandatory ( i.e with 
M bit set). 
What has been the final accord on the issue ?

Thanks,
Himanshu
A R I C E N T

?That's the spirit - one part brave, three parts fool.?

Victor Fajardo <[email-masked]> 
10/11/2007 11:34 PM

To
"Asveren, Tolga" <[email-masked]>
cc
[email-masked], Dan Warren <[email-masked]>, Philip Crocker 
<[email-masked]>
Subject
Re: [Dime] Conflict with grouped & mandatory AVPs.

Hi Tolga,

regards,
victor

***********************  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://www1.ietf.org/mailman/listinfo/dime