Subject: [Dime] Error Code issues for bis

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 13 Sep 2006 13:20:56 -0400

Hi All,

There already is an item related with error codes in the issue tracker
"Inconsistent Result-code Error classification". I want to bring the use of
E-bit to the lists attention as well.

E-bit is used to indicate that the grammar will follow the definion in 7.2 .
The question is, what does qualify an error code to use that special
grammar? It looks to me, all errors defined in 7.1 can use this grammar. I
would exclude  DIAMETER_AUTHENTICATION_REJECTED,
DIAMETER_AUTHORIZATION_REJECTED (and maybe also
DIAMETER_REDIRECT_INDICATION), because they are not really errors from base
protocol point of view but rather some issues on application level. For
other error codes, why do we need the full set of AVPs (except special AVPs
which may be used for routing purposes like Proxy-Info AVP)?

This would could have a few advantages AFAICS:
i- An answer with E-bit not set needs to comply to the grammar of the
corresponding answer message definition. This may require adding some
mandatory AVPs which are part of the answer message grammar requiring
application logic involvement. With E-bit set, as soon as the decoding error
is detected, answer message can be generated.

ii-   For certain error codes, which are currently listed as not using error
answer grammar, it could not be possible to further decode a message, e.g.
DIAMETER_INVALID_AVP_LENGTH generated because of an AVP, whose length field
exceeds the message boundary. With error answer message grammar, the error
answer can be generated as soon as such a case is detected.

iii-  It would be clear when and why the special error answer grammer is
used.

This shouldn't create backward compatibility issues, because error answers
will be validated based on the grammer indicated with persence/absence of
E-bit.

I propose, we include that change as well as part of the bis effort.

    Thanks,
    Tolga

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

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 13 Sep 2006 14:18:30 -0400

Hi Tolga,

> which may be used for routing purposes like Proxy-Info AVP)?

This maybe an easy way of performing error handling with just sending 
the error grammar but it maybe to harsh (??). A node receiving a result 
code set to some non-protocol failure value may find it more useful to 
receive the application specific answer message rather than just the 
error message in 7.2 since the error may not be grave and the both 
end-point application can attempt to recover and continue on. An example 
would be when the result code is set to MISSING_AVP or INVALID_AVP_VALUE 
and the answer message carries a Failed-AVP. Depending on the 
application, the sender of the error may choose to continue processing 
the remainder of the request if the offending AVP is not crucial. The 
receiver of the error would view the error as a hint maybe able to 
compensate/recover and continue on also.

> is detected, answer message can be generated.

I guess this would depend if the implementation is doing full or partial 
parsing in the base protocol layer.

> I propose, we include that change as well as part of the bis effort.

In another note, there are also other issues with proposed text. Pls 
feel free to comment on the as well.

best regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 14 Sep 2006 09:55:50 -0400

Hi Victor,

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2006 2:19 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Dime] Error Code issues for bis
>
>
> Hi Tolga,
>
> Comments inline:
[TOLGA]This is an interesting point but if such an answer is generated, how
could the peer know the real result of the request processing? Let's say
Result-Code contains MISSING_AVP, how could the request originator determine
whether the request processing is done successfully? I also would exptect if
the request can be processed without an AVP, that AVP shouldn't be listed as
a mandatory AVP. Similarly for other error situations, if they don't prevent
request processing, they shouldn't be errors.
> parsing in the base protocol layer.
[TOLGA]I think I was not clear about this one. The message is parsed (or
parsed as much as possible depending the type of the error). Now an answer
message needs to be generated. If the grammar of the answer for that
specific command code is used, all mandatory AVPs which are specified in the
grammar need to be present. Those AVPs possibly could be filled without
application logic involvement, but I would think this would require to put
some dummy values there. In such a case, what is the point of inserting
them?

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 14 Sep 2006 10:17:11 -0400

Hi Tolga,

Comments inline:
> whether the request processing is done successfully? 

I was thinking through other avp's in the application specific answer 
grammar ... though that maybe stretching the success/failure 
significance of the result-code avp against other avps in the message so 
may not as advisable.

> some dummy values there. In such a case, what is the point of inserting

I was thinking in the case where the base protocol part of the 
implementation does only partial parsing of message header and avps it 
requires and leaves full parsing of the remaining application specific 
avps to the applications themselves. The scenario you mentioned fits 
well when the failure occurs during the partial parsing. During full 
parsing, application logic can be introduced.

best regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 14 Sep 2006 14:14:29 -0400

Hi Victor,

I had a look to Issue14. I already thought that use of E-bit is exclusively
for protocol errors based on "Note that these and only these erors MUST only
be used in answer messages whose 'E' bit is set." in 7.1.3. The proposed
text further supports this idea.

I see a value of using E-bit for permanent failures as I tried to explain
before. I think your concern is that people may choose not to use error
answer-message grammar defined in 7.2 for certain permanent failures. To
address both concerns, I suggest we allow use of E-bit for permanent
failures but leave it as an implementation choice to use it or not. This
again would be backward compatible AFAICS.

    Thanks,
    Tolga

> Sent: Thursday, September 14, 2006 10:17 AM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 14 Sep 2006 14:40:53 -0400

Hi Tolga,
> text further supports this idea.

Yes. I can't remember precisely but #14 may have been on of those 
"editorial" issue that was brought up during the interop.

> again would be backward compatible AFAICS.

Ok. Hopefully, we can try to get more feedback on this topic.

best regards,
victor

>>>> end-point application can attempt to recover and continue on.
>>>>         
>> An example
>>     
>>>> would be when the result code is set to MISSING_AVP or
>>>>         
>> INVALID_AVP_VALUE
>>     
>>> [TOLGA]This is an interesting point but if such an answer is
>>>       
>> generated, how
>>     
>>> Result-Code contains MISSING_AVP, how could the request
>>>       
>> originator determine
>>     
>>>> I guess this would depend if the implementation is doing full
>>>>         
>> or partial
>>     
>>> parsed as much as possible depending the type of the error).
>>>       
>> Now an answer
>>     
>>> specific command code is used, all mandatory AVPs which are
>>>       
>> specified in the
>>     
>>> application logic involvement, but I would think this would
>>>       
>> require to put
>>

---

From: <[email-masked]>
Date: Fri, 15 Sep 2006 06:33:59 +0300

Tolga,

If it is optional, that means you can't count that any implementations
will support it.

However, are you suggesting the E-bit could be used as a hint for 
permantant failures?

John 

>From: ext Tolga Asveren [mailto:[email-masked]] 
>Sent: 14 September, 2006 21:14
>To: [email-masked]
>Subject: RE: [Dime] Error Code issues for bis
>
>Hi Victor,
>
>I had a look to Issue14. I already thought that use of E-bit 
>is exclusively for protocol errors based on "Note that these 
>and only these erors MUST only be used in answer messages 
>whose 'E' bit is set." in 7.1.3. The proposed text further 
>supports this idea.
>
>I see a value of using E-bit for permanent failures as I tried 
>to explain before. I think your concern is that people may 
>choose not to use error answer-message grammar defined in 7.2 
>for certain permanent failures. To address both concerns, I 
>suggest we allow use of E-bit for permanent failures but leave 
>it as an implementation choice to use it or not. This again 
>would be backward compatible AFAICS.
>
>    Thanks,
>    Tolga
>
>
>
>> >> This maybe an easy way of performing error handling with just 
>> >> sending the error grammar but it maybe to harsh (??). A node 
>> >> receiving a result code set to some non-protocol failure 
>value may 
>> >> find it more useful to receive the application specific answer 
>> >> message rather than just the error message in 7.2 since the error 
>> >> may not be grave and the both end-point application can 
>attempt to recover and continue on.
>> An example
>> >> application, the sender of the error may choose to continue 
>> >> processing the remainder of the request if the offending 
>AVP is not 
>> >> crucial. The receiver of the error would view the error as a hint 
>> >> maybe able to compensate/recover and continue on also.
>> >>
>> > could the peer know the real result of the request 
>processing? Let's 
>> > say Result-Code contains MISSING_AVP, how could the request
>> originator determine
>> significance of the result-code avp against other avps in 
>the message 
>> so may not as advisable.
>>
>> > [TOLGA]I think I was not clear about this one. The message 
>is parsed 
>> > (or parsed as much as possible depending the type of the error).
>> Now an answer
>> > grammar need to be present. Those AVPs possibly could be filled 
>> > without application logic involvement, but I would think this would
>> require to put
>> > some dummy values there. In such a case, what is the point of 
>> > inserting them?
>> >
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 15 Sep 2006 08:49:37 -0400

John,

My only goal is being able to use the grammar described in 7.2 for permanent
answers as well. For certain situations it is impossible to continue
decoding a message, e.g. invalid AVP length for an AVP which is of type
OctetString. In such a case, it may not be possible to generate an answer
message based on the command's answer grammar, nor does it seem necessary to
me.

What I suggest is allowing E-bit to be set for permanent failures as well,
so that grammar in 7.2 can be used.

It is not important that all implementations follow that path, only the ones
which consider it necessary/usefull for certain cases can use it.

On receiver end, this shouldn't be a problem because if the E-bit is set,
receiver will decode the message based on 7.2 grammar, otherwise command
answer grammar will be used. this rule is already there in RFC3588.

After thinking a bit more, the only possible backward compatibility issue I
see is, if some implementation checks whether E-bit is set for an answer
with Result-Code other than Protocol Error. Considering that for some
Permanent Failures 7.2 grammar is really necessary, I believe that shouldn't
be a big issue.

     Thanks,
     Tolga

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 14, 2006 11:34 PM
> To: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Mon, 18 Sep 2006 05:33:31 +0300

Tolga,

I think that seems reasonable - does anyone else have comments
on this - supporting or otherwise?  It would be good to wrap
this issue up.

John 

>Sent: 15 September, 2006 15:50
>To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
>My only goal is being able to use the grammar described in 7.2 
>for permanent answers as well. For certain situations it is 
>impossible to continue decoding a message, e.g. invalid AVP 
>length for an AVP which is of type OctetString. In such a 
>case, it may not be possible to generate an answer message 
>based on the command's answer grammar, nor does it seem 
>necessary to me.
>
>What I suggest is allowing E-bit to be set for permanent 
>failures as well, so that grammar in 7.2 can be used.
>
>It is not important that all implementations follow that path, 
>only the ones which consider it necessary/usefull for certain 
>cases can use it.
>
>On receiver end, this shouldn't be a problem because if the 
>E-bit is set, receiver will decode the message based on 7.2 
>grammar, otherwise command answer grammar will be used. this 
>rule is already there in RFC3588.
>
>After thinking a bit more, the only possible backward 
>compatibility issue I see is, if some implementation checks 
>whether E-bit is set for an answer with Result-Code other than 
>Protocol Error. Considering that for some Permanent Failures 
>7.2 grammar is really necessary, I believe that shouldn't be a 
>big issue.
>
>     Thanks,
>     Tolga
>
>> >I had a look to Issue14. I already thought that use of E-bit is 
>> >exclusively for protocol errors based on "Note that these and only 
>> >these erors MUST only be used in answer messages whose 'E' bit is 
>> >set." in 7.1.3. The proposed text further supports this idea.
>> >
>> >I see a value of using E-bit for permanent failures as I tried to 
>> >explain before. I think your concern is that people may 
>choose not to 
>> >use error answer-message grammar defined in 7.2 for certain 
>permanent 
>> >failures. To address both concerns, I suggest we allow use of E-bit 
>> >for permanent failures but leave it as an implementation choice to 
>> >use it or not. This again would be backward compatible AFAICS.
>> >
>> >    Thanks,
>> >    Tolga
>> >
>> >
>> >
>> >> >> message rather than just the error message in 7.2 since the 
>> >> >> error may not be grave and the both end-point application can
>> >> >> crucial. The receiver of the error would view the error as a 
>> >> >> hint maybe able to compensate/recover and continue on also.
>> >> >>
>> >> avps to the applications themselves. The scenario you mentioned 
>> >> fits well when the failure occurs during the partial parsing. 
>> >> During full parsing, application logic can be introduced.
>> >>
>> >> best regards,
>> >> victor
>> >
>> >

---

From: Preeti Shandilya <[email-masked]>
Date: Mon, 18 Sep 2006 14:23:14 +0530

Hi !

I have little confusion regarding session timeout AVP

RFC 3588 mentions about Session Timeout AVP. According to RFC, at the expiry of the session timer, STR should be sent to peer node to clear the session.

Following specifications for Ro, Sh.Cx. Rf and CCA, do not refer to this AVP in the messages.

IETF Specifications

· RFC 4006, Diameter Credit Control, March 2005

3GPP Specifications

· 3GPP TS 32.225 and 3GPP TS 32.299 v650 : Diameter Ro Interface

· 3GPP TS 32.299 v650 : Diameter Rf Interface

· 3GPP TS 29.228: Cx and Dx interfaces : signaling flows and message contents

· 3GPP TS 29.229: Cx and Dx Interfaces based on the Diameter protocol; Protocol Details

· 3GPP TS 29.230: 3GPP specific codes and identifiers

· 3GPP TS 29.328: Sh interface : signaling flows and message content

· 3GPP TS 29.329: Sh interface; Protocol details

· 3GPP TS 32.240 v6.3.0 Telecommunication management; Charging management; Charging architecture and Principles

So is this AVP meant for future version of the specification ?

Regards

Preeti

***************** FSS-Restricted *************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) 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. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 18 Sep 2006 11:34:18 -0400

I've updated issue 14 to reflect the current opinion of which I also
agree. Pls review the text if it is appropriate or if other folks has
other opinions.

regards,
victor

> I support Tolga's proposal on using E-bit and grammar described in 7.2 
> for permanent errors in addition to protocol errors.
>
> Yoshihiro Ohba
>
> On Mon, Sep 18, 2006 at 05:33:31AM +0300, [email-masked] wrote:
>   
>> Tolga,
>>
>>>> If it is optional, that means you can't count that any 
>>>>         
>>> implementations 
>>>       
>>>> will support it.
>>>>
>>>>>> I was thinking through other avp's in the application
>>>>>>             
>>>>> specific answer
>>>>>           
>>>>>>> message needs to be generated. If the grammar of the
>>>>>>>               
>>>>> answer for that
>>>>>           
>>>>>> implementation does only partial parsing of message header
>>>>>>             
>>>>> and avps it
>>>>>           
>>>>>> requires and leaves full parsing of the remaining
>>>>>>             
>>>>> application specific
>>>>>           
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>
>
>