Subject: [Dime] DiME Digest, Vol 9, Issue 30

From: "Rashmi Rath" <[email-masked]>
Date: Tue, 19 Sep 2006 16:17:07 +0530

Hi All,

I have a question.
In Disconnect Peer Request, If i put disconnect cause other than BUSY,
REBOOTING and DO_NOT_WANT_TO_TALK_TO_YOU, should it disconnect the peer
connection.

Thanks & Regds

Rashmi Rath
Software Engineer
IntelliNet Technologies

On 9/18/06, [email-masked] <[email-masked]> wrote:
>
> Send DiME mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www1.ietf.org/mailman/listinfo/dime
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DiME digest..."
>
>
> Today's Topics:
>
>   1. Re: Error Code issues for bis (Victor Fajardo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Sep 2006 11:34:18 -0400
> From: Victor Fajardo <[email-masked]>
> Subject: Re: [Dime] Error Code issues for bis
> To: Yoshihiro Ohba <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-2022-JP
>
> 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,
> >>
> >> 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
> >>
> >>
> >>> -----Original Message-----
> >>> From: ext Tolga Asveren [mailto:[email-masked]]
> >>> Sent: 15 September, 2006 15:50
> >>> To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
> >>> Subject: RE: [Dime] Error Code issues for bis
> >>>
> >>> 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
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>>> Sent: Thursday, September 14, 2006 11:34 PM
> >>>> To: [email-masked]; [email-masked]
> >>>> Subject: RE: [Dime] Error Code issues for bis
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Victor Fajardo [mailto:[email-masked]]
> >>>>>> Sent: Thursday, September 14, 2006 10:17 AM
> >>>>>> To: Tolga Asveren
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: Re: [Dime] Error Code issues for bis
> >>>>>>
> >>>>>>
> >>>>>> Hi Tolga,
> >>>>>>
> >>>>>> Comments inline:
> >>>>>>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> [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 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.
> >>>>>>
> >>>>>>
> >>>>>>>> I guess this would depend if the implementation is doing full
> >>>>>>>>
> >>>>>> or partial
> >>>>>>
> >>>>>>>> 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?
> >>>>>>>
> >>>>>>>
> >>>>>> 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
> >>>>>>
> >>>>> _______________________________________________
> >>>>> DiME mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/dime
> >>>>>
> >>>>>
> >>>
> >> _______________________________________________
> >> DiME mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/dime
> >>
> >>
> >>
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> >
> >
> >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
> End of DiME Digest, Vol 9, Issue 29
> ***********************************
>

-- 
Regards

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