Subject: RE: [Dime] Invalid AVP within a Grouped AVP

From: "German Blanco \(E2/EEM\)" <[email-masked]>
Date: Wed, 1 Mar 2006 15:46:40 +0100

Hi Victor,

Your proposal of extending the definition of Failed-AVP sounds 
good to me too.
I am not that sure that it is needed to provide information 
about all the errors in the request, since just one is enough 
to reject the message and (hopefully :-) only a very small 
percentage of the requests will contain more than one error.

Regards,

German.

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: miércoles, 01 de marzo de 2006 14:38
> To: German Blanco (E2/EEM)
> Cc: Anders Kristensen; [email-masked]; [email-masked]
> Subject: Re: [Dime] Invalid AVP within a Grouped AVP
> 
> Hi,
> 
> >Wouldn't it be better to give to the peer that makes the 
> error as much information as possible?
> >
> >One way to do that would be to send the Failed-AVP with the 
> erroneous AVP, but inside the Grouped AVP.  That is, sending 
> a Diameter Answer with only the Grouped AVP that failed, 
> containing a Failed AVP with the AVP that caused the error.
> >
> >I believe that for an application, it would be very 
> interesting to know which is the part of the information that 
> was erroneous or missing in the request.  And since the 
> Grouped AVP will contain more than one information element, 
> it would be hard to guess which is the one that caused the 
> problem if the answer only refers to a problem in the Grouped AVP.
> >
> >You could argue that it may not be possible to include the 
> Failed-AVP inside the Grouped AVP, since the ABNF of the 
> Grouped AVP could avoid this possibility.  But since this 
> will be a revised version of Diameter, then it could also be 
> recommended or mandatory to allow the Failed AVP inside 
> Grouped AVPs.  Would that be feasible?
> >  
> >
> I think it maybe better to just extend the definition of 
> Failed-AVP to somehow provide inheritance information of each 
> offending avp belonging to a group (which maybe deep). This 
> is probably easier for a parser since the failed-avp occurs 
> only at the root level as it is now (instead of deep inside a 
> group). It also minimizes ABNF changes. Additionally, I also 
> think reason code(s) (i.e, avp not allowed, duplicate avp 
> etc) for the each offending AVP should be provided instead of 
> just relying on the value of result-code avp since each 
> offending AVPs could have different reasons for failing.
> 
> Regards,
> victor
> 
> >Thank you for bringing up this issue, I also think that it 
> would be a good idea to include it in the next RFC.
> >
> >German.
> 

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 01 Mar 2006 09:53:06 -0500

Hi German,

>percentage of the requests will contain more than one error.
This is probably true. I was just thinking of more enterprising 
implementations thats able to detect multiple avp failures.

regards,
victor

---

From: <[email-masked]>
Date: Thu, 9 Mar 2006 12:48:50 +0200

Hi all,

Feel free to draft text.  I think we should collect text and produce a Diameter-bis document after the Dallas meeting.

John 

>From: ext German Blanco (E2/EEM) [mailto:[email-masked]] 
>Sent: 01 March, 2006 16:47
>To: Victor Fajardo
>Cc: Anders Kristensen; Loughney John (Nokia-NRC/Helsinki); 
>[email-masked]
>Subject: RE: [Dime] Invalid AVP within a Grouped AVP
>
>
>Hi Victor,
>
>> erroneous AVP, but inside the Grouped AVP.  That is, sending a 
>> Diameter Answer with only the Grouped AVP that failed, containing a 
>> Failed AVP with the AVP that caused the error.
>> >
>> interesting to know which is the part of the information that was 
>> erroneous or missing in the request.  And since the Grouped AVP will 
>> contain more than one information element, it would be hard to guess 
>> which is the one that caused the problem if the answer only 
>refers to 
>> a problem in the Grouped AVP.
>> >
>> Failed-AVP inside the Grouped AVP, since the ABNF of the Grouped AVP 
>> could avoid this possibility.  But since this will be a revised 
>> version of Diameter, then it could also be recommended or 
>mandatory to 
>> allow the Failed AVP inside Grouped AVPs.  Would that be feasible?
>> >  
>> >
>Failed-AVP to 
>> somehow provide inheritance information of each offending avp 
>> belonging to a group (which maybe deep). This is probably 
>easier for a 
>> parser since the failed-avp occurs only at the root level as 
>it is now 
>> (instead of deep inside a group). It also minimizes ABNF changes. 
>> Additionally, I also think reason code(s) (i.e, avp not allowed, 
>> duplicate avp
>> etc) for the each offending AVP should be provided instead of just 
>> relying on the value of result-code avp since each offending AVPs 
>> could have different reasons for failing.
>> 
>> Regards,
>> victor
>>