Hi Yoshi,
> -----Message d'origine----- > De : Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 12 avril 2007 19:44 > À : MORAND Lionel RD-CORE-ISS > Cc : Victor Fajardo; [EMAIL PROTECTED] > Objet : Re: [Pana] Use of Error Request message > > Hi Lionel, > > On Thu, Apr 12, 2007 at 05:47:42PM +0200, MORAND Lionel > RD-CORE-ISS wrote: > > Hi Victor, > > > > I can agree though it is quite strange to have a Request/Answer > > messages protocols and to see a PANA-Notification-Request > message in > > response to PANA-Auth-Request ;) > > To me error messages are sort of "interruptions", so I don't > see it strange to send an error request in response to a > request or an answer. I was just saying that in the principle of Diameter (that was in my understanding the reference protocol for the PANA protoco design), the logic was: a Request message associated with an Answer message with a Result-Code (Success or Failure), and the Failure including error cases. The only case where this mechanism is not useful is when errors occur in the answer message handling. > > > The proposed modification doesn't change the principle of the error > > handling mechanism. But I think it could be seen more > consistent. At > > least for me ;) > > From my Diameter parser implementation experience, defining > two types of ABNF for answer messages depending on 'E' bit > settings is more complex. I believe the way currently PANA > is defined is much simpler. It is not to define two types of ABNF. It is to define the Result-Code AVP and Failed-AVP AVP as optional AVPs of the PANA-Auth-Answer and PANA-Termination-Answer messages. I was proposing to reuse the 'E' bit just to characterize error answers if needed, as a hint. About complexity, do you mean that it is easier for the implementation to parse a Notification message to find the optional Failed-Message-Header AVP to find the message that causes the error? Lionel > > Yoshihiro Ohba > > > > > > > > > > > > -----Message d'origine----- > > > De : Victor Fajardo [mailto:[EMAIL PROTECTED] > > > Envoy？ : jeudi 12 avril 2007 17:36 > > > ？ : MORAND Lionel RD-CORE-ISS > > > Cc : [EMAIL PROTECTED] > > > Objet : Re: [Pana] Use of Error Request message > > > > > > Hi Lionel, > > > > I propose to limit the use of this specific mechanism to > > > the handling of errors due to PANA answer messages > received by the > > > peer. In that specific case, it is actually the only way for > > > providing error notification to the originator of the > answer message > > > (if needed). > > > > > > > > On the other hand, for the handling of PANA request > > > messages, it is easier to always rely on PANA answer messages for > > > providing error notification to the originator of the request, as > > > done e.g. with Diameter. > > > > The 'E' bit would be set in the answer message header in > > > order to distinguish error notification from "normal" answer > > > messages (some PANA answer messages being used just as > ack messages). > > > > When the 'E' bit is set in answer message, the Result-Code > > > AVP would have to be present as well as the Failed-AVP > AVP if needed. > > > > > > > > Any comment? > > > > > > > > > > The proposal should work though I'm not sure what the additional > > > benefit would be except maybe the savings of not having > to send the > > > notification answer message in the latter case. However, > maybe such > > > optimization is not so relevant since error conditions > are not the > > > norm. I generally like the current scheme (use error notification > > > messages) because it keeps things simple by centralizing error > > > indications for all cases. > > > > > > As a side note, one minor suggestion for 5.8 is to include small > > > text explicitly terminating the request retransmission procedure > > > when error notification is received for a pending request. > > > > > > regards, > > > victor > > > > Lionel > > > > > > > > > > > > > > > >> -----Message d'origine----- > > > >> De : Alper Yegin [mailto:[EMAIL PROTECTED] Envoy？ > : jeudi 5 > > > >> avril 2007 10:06 ？ : [EMAIL PROTECTED] Objet : [Pana] Review > > > >> pana-pana-15a > > > >> > > > >> > > > >> PANA specification is reviewed based on the last round of > > > AD comments > > > >> (thanks Yoshi!). > > > >> > > > >> The spec is here: > > > >> > > > >> > http://www.panasec.org/docs/editing/draft-ietf-pana-pana-15a.txt > > > >> > > > >> And it's diff with the version that predates last round of AD > > > >> comments > > > >> (-13): > > > >> > > > >> http://www.panasec.org/docs/editing/draft-ietf-pana-pana-15a-f > > > >> rom-3.diff.htm > > > >> l > > > >> > > > >> Please review the document and register your feedback by > > > the end of > > > >> April 12, Thursday. > > > >> > > > >> Upon collecting and resolving any issues, the document > > > will proceed > > > >> to IETF last call. > > > >> > > > >> Thanks > > > >> > > > >> Alper > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Pana mailing list > > > >> [EMAIL PROTECTED] > > > >> https://www1.ietf.org/mailman/listinfo/pana > > > >> > > > >> > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > [EMAIL PROTECTED] > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > [EMAIL PROTECTED] > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > > Pana mailing list > > [EMAIL PROTECTED] > > https://www1.ietf.org/mailman/listinfo/pana > > > > >
_______________________________________________ Pana mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/pana
