Subject: RE: [Pana] Issue 149: General purpose notification for PANA

From: [email-masked]
Date: Fri, 17 Dec 2004 14:07:33 +0200

The liveness test is a potential interoperability problem.

See my response on the mailing list (and issue tracker) to 
issue114 for two possible choices for going onwards.

Br,
- Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Alper Yegin
> Sent: 16 December, 2004 21:13
> To: 'Yoshihiro Ohba'
> Cc: [email-masked]
> Subject: RE: [Pana] Issue 149: General purpose notification for PANA
> 
> 
> Hi Yoshi,
> 
> I'd perceive this similar to using any round-trip PANA message for
> liveness test, as we said for Issue 114. 
> 
> I'm inclined to recommend keeping PANA-ping with this explicit
> functionality.
> 
> Alper
>  
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]]
> > Sent: Tuesday, December 14, 2004 9:25 PM
> > To: Alper Yegin
> > Cc: 'Yoshihiro Ohba'; [email-masked]
> > Subject: Re: [Pana] Issue 149: General purpose notification for PANA
> > 
> > According to the suggested new defition of PUR, I think it 
> is possible
> > to send a PUR without carrying an IP-Address AVP or a
> > Notification-AVP.  If that is true, then I think PUR/PUA exchange
> > could also be used for peer liveness test instead of PANA-Ping
> > exchange.  Do we still need PANA-Ping message for peer 
> liveness test?
> > 
> > Regards,
> > Yoshihiro Ohba
> > 
> > 
> > On Thu, Dec 09, 2004 at 11:49:06AM -0800, Alper Yegin wrote:
> > >
> > > I think it is best if we didn't have to add one more PANA message
> just
> > > for carrying this AVP.
> > >
> > > We don't have to present PANA-Update as a message that 
> always alters
> > > state. One way to look at it is a message that is used for
> delivering
> > > attribute changes and notifications. This is more accommodating.
> > >
> > > Btw, there is also some value in carrying Notifications 
> on PUR, and
> > > hence making PUR bidirectional. This can come handy when networks
> need
> > > to deliver other authorization related bits between PAA 
> and PaC. We
> > > cannot get into what those bits should be (out-of scope), but
> providing
> > > a delivery tool is helpful.
> > >
> > > Based on these, following is my recommended text... As always,
> comments
> > > welcome.
> > >
> > >
> > >
> > > [1] Add to 4.1
> > >
> > >    o  Notification AVP: contains a displayable message.
> > >
> > > [2] Create new 8.3.19
> > >
> > > 8.3.19 Notification AVP
> > >
> > > The Notification AVP (AVP Code 19) is optionally used to convey a
> > >
> > > displayable message sent by either PaC or PAA. It can be 
> included in
> > > any message, whether it is a request or answer. In case a
> notification
> > > needs to be sent but there is no outgoing PANA message to deliver
> this
> > > AVP,
> > > PANA-Update-Request that only carries Notification AVP SHOULD be
> > > generated.
> > >
> > > Receipt or transmission of this AVP does not change PANA state.
> > >
> > > AVP data is of type OctetString and it contains UTF-8 encoded ISO
> > > 10646 characters [RFC2279].  The length of the displayable message
> is
> > > determined  by the AVP Length field. The message MUST NOT be null
> > > terminated.
> > >
> > > [3] 8.2.1 - 8.2.19
> > >
> > > Add [ Notification ] to ABNF of all messages.
> > >
> > > [4] Update 8.2.18
> > >
> > > New text:
> > >
> > > 8.2.18  PANA-Update-Request (PUR)
> > >
> > >    PANA-Update-Request (PUR) is sent either by the PaC or 
> the PAA to
> > >    deliver attribute updates and notifications. In the 
> scope of this
> > >    specification only the PaC IP address attribute can be updated
> > >    via this mechanism. IP-Address AVP can only be included in the
> PUR
> > >    messages sent by the PaC. PUR can be used to deliver just a
> > >    notification as well.
> > >
> > >
> > >          PANA-Update-Request ::= < PANA-Header: 10, REQ >
> > >                        < Session-Id >
> > >                        [ IP-Address ]
> > >                        [ Notification ]
> > >                     *  [ AVP ]
> > >                    0*1 < MAC >
> > >
> > > [5] update 8.2.19
> > >
> > > New text:
> > >
> > > 8.2.19  PANA-Update-Answer (PUA)
> > >
> > >    PANA-Update-Answer (PUA) is sent in response to a
> > > PANA-Update-Request.
> > >
> > >          PANA-Update-Answer ::= < PANA-Header: 10 >
> > >                        < Session-Id >
> > >                        [ Notification ]
> > >                     *  [ AVP ]
> > >                    0*1 < MAC >
> > >
> > >
> > > [6] 8.1
> > >
> > > Make PUR bi-directional on figure 9.
> > >
> > >
> > > [7] 5.5
> > >
> > > Since now PUR can carry a notification only, it is valid 
> to receive
> it
> > > at
> > > any state. Let's remove it from "unexpected message" 
> lists. [sure a
> PUR
> > > with IP-address AVP is not welcome in those states, but 
> this is not
> > > different than dealing with a valid message that carries 
> an invalid
> AVP.
> > > We
> > > don't get into that level of details in 5.5 anyways]
> > >
> > >
> > > [8] Figures 10, 11, 12:
> > >
> > > Please add "Notification" that has "1" for each PANA message type.
> > >
> > >
> > > [9] Add reference to RFC2229.
> > >
> > >
> > > Alper
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Yoshihiro Ohba [mailto:[email-masked]]
> > > > Sent: Tuesday, December 07, 2004 3:19 AM
> > > > To: Alper Yegin
> > > > Cc: [email-masked]
> > > > Subject: Re: [Pana] Issue 149: General purpose notification for
> PANA
> > > >
> > > > On Wed, Nov 17, 2004 at 01:29:45PM -0800, Alper Yegin wrote:
> > > > > http://danforsberg.info:8080/pana-issues/issue149
> > > > >
> > > > > I recommend we handle this issue by:
> > > > > - defining a Notification-AVP that can be carried in any (?)
> PANA
> > > > > message, and the content is a displayable message.
> > > > > - allowing PUR to be sent from both PaC and PAA, and 
> allow it to
> > > > > optionally carry IP-Address AVP and Notification-AVP.
> > > >
> > > > Hmm, making IP-Address AVP optional in PUR does not make much
> sense.
> > > > When PUR carries a Notification AVP but without an 
> IP-Address AVP,
> it
> > > > does not update anything...
> > > >
> > > > I'd prefer defining new messages for notification, e.g.,
> > > > PANA-Notification-Request/Answer.
> > > >
> > > > Yoshihiro Ohba
> > > >
> > > >
> > > > >
> > > > > Comments?
> > > > >
> > > > > Alper
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Pana mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/pana
> > >
> > >
> 
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

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