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

From: "Philip Crocker" <[email-masked]>
Date: Wed, 10 Oct 2007 12:44:26 +0100

Hi all,
 
I have noticed what I think is a minor inconsistency between RFC3588 and
the IMS Cx / Dx reference points, regarding the relation between grouped
AVPs and mandatory AVPs.  It seems to me that RFC3588 is too strict
here, though I may have missed something (and my apologies if if this
has already been discussed before).
 
RFC3588 section 4.4 states that 'if any of the AVPs encapsulated within
a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself
MUST also include the 'M' bit set.'.  This is in keeping with RFC3588
section 4.1, which states that whenever an AVP with the M bit is
unrecognised, the whole message must be rejected.  As a result, it does
not make sense for an optional grouped AVP to contain a mandatory
sub-AVP that leads to the message being discarded, hence the requirement
for grouped AVPs at the start of this paragraph.
 
This position seems to be in conflict with the principle of AVP reuse,
where section 1.2 strongly recommends existing AVPs are reused wherever
possible.
 
Together these rules require any new non-mandatory Grouped AVP to define
non-mandatory sub-AVPs that are identical to pre-existing ones (except
for the M flag), which seems a little unnecessary.
 
Additionally, I have found examples where a Diameter application breaks
this statement in section 4.4 and defines an optional grouped AVP with
mandatory sub-AVPs.
 
* In IMS Sh & Cx reference points, the "Supported-Applications AVP" is
specified as MUST NOT have the 'M' bit set, whereas all its children
(incl. Auth-Application-Id) are specified as MUST have the 'M' bit set.
(Ref: 3GPP TS 29.229 6.3, RFC3588 4.5).
 
* A similar inconsistency exists with the IMS Sh & Cx
"Supported-Features" AVP.
 
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.
 
Regards,
 
Phil Crocker
Network Protocols Division
Data Connection Ltd. (DCL)

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 10 Oct 2007 08:35:23 -0400

Hi Philip,

I think this makes sense. IMHO we should move forward with the change
you proposed.

   Thanks,
   Tolga

> -----Original Message-----
> From: Philip Crocker [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2007 7:44 AM
> To: [email-masked]
> Subject: [Dime] Conflict with grouped & mandatory AVPs.
> 
> Hi all,
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 10 Oct 2007 12:17:58 -0400

Issues is in tracker: 
http://www.tschofenig.priv.at:8080/diameter-interop/issue64

regards,
victor

>> I have noticed what I think is a minor inconsistency between RFC3588
>>     
> and
>   
>> the IMS Cx / Dx reference points, regarding the relation between
>>     
> grouped
>   
>> RFC3588 section 4.4 states that 'if any of the AVPs encapsulated
>>     
> within
>   
>> unrecognised, the whole message must be rejected.  As a result, it
>>     
> does
>   
>> sub-AVP that leads to the message being discarded, hence the
>>     
> requirement
>   
>> where section 1.2 strongly recommends existing AVPs are reused
>>     
> wherever
>   
>> possible.
>>
>> Together these rules require any new non-mandatory Grouped AVP to
>>     
> define
>   
>> Additionally, I have found examples where a Diameter application
>>     
> breaks
>   
>> (incl. Auth-Application-Id) are specified as MUST have the 'M' bit
>>     
> set.
>   
>> In my opinion it is reasonable for a Diameter application to be able
>>     
> to
>   
>> sub-AVPs.  Does this seem reasonable to people?  If so, I would
>>     
> propose
>

---

From: Ralph Loader <[email-masked]>
Date: Thu, 11 Oct 2007 07:29:44 +1300

> 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.

---

From: "Philip Crocker" <[email-masked]>
Date: Thu, 11 Oct 2007 10:12:58 +0100

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

-----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.

> to define an optional grouped AVP that reuses some mandatory AVPs as 

Cheers,
Ralph.