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

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Dec 2004 06:19:27 -0500

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 09 Dec 2004 11:49:06 -0800

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
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Dec 2004 00:25:28 -0500

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Dec 2004 11:12:42 -0800

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

> Sent: Tuesday, December 14, 2004 9:25 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 Dec 2004 01:26:13 -0500

I basicaly agree with the proposed text.  I have some comments in
line.

>    o  Notification AVP: contains a displayable message.

OK.

> Receipt or transmission of this AVP does not change PANA state.

Transmission of this AVP will change PANA state to prepare for
retransmitting the PUR.  So I think we should say:

"
Receipt of this AVP does not change PANA state.
"

> determined  by the AVP Length field. The message MUST NOT be null 

OK.

>          PANA-Update-Request ::= < PANA-Header: 10, REQ >

OK.

>          PANA-Update-Answer ::= < PANA-Header: 10 >

OK.

> Make PUR bi-directional on figure 9.

OK.

> don't get into that level of details in 5.5 anyways]

I think we should not allow PUR in the discovery and handshake phase
because there is no session id assigned yet in this phase.  

For the same reason, PANA-Reauth-Request and PANA-Error-Request should
not be allowed in the discovery and handshake phase, which are
currently.

> Please add "Notification" that has "1" for each PANA message type.

OK.

> [9] Add reference to RFC2229.

I guess "RFC2229" should read "RFC2279".

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 23 Dec 2004 11:44:50 -0800

Thanks Yoshi.

Agreed to all.

Here is the updated text changes.

[1] Add to 4.1

[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. 

[3] 8.2.1 - 8.2.19

[4] Update 8.2.18

New text:

[5] update 8.2.19

New text:

[6] 8.1

[7] 5.5

[This is not related to PUR.... but came up during review...]

Change:

    *  In the discovery and handshake phase:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

To:

    *  In the discovery and handshake phase:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

         +  PANA-Reauth-Request.

         +  PANA-Error-Request.

[8] Figures 10, 11, 12:

[9] Add reference to RFC2279.

Alper

> Sent: Tuesday, December 21, 2004 10:26 PM
> To: Alper Yegin