Subject: [Pana] Review pana-pana-15a

From: "Alper Yegin" <[email-masked]>
Date: Thu, 5 Apr 2007 11:05:36 +0300

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-from-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-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Victor Fajardo <[email-masked]>
Date: Sat, 07 Apr 2007 15:56:45 -0400

Hi Alper,

I just have some minor editorial comments:

1. In page 10, 2nd paragraph:

"..successfully derived, the last PANA-Auth-Request message MUST contain"

for clarity, maybe better as:

"..successfully derived, the last PANA-Auth-Request message with 'C' 
(Complete) bit set MUST contain ..."

also maybe the same can be applied in other text such as 5.3.

2. Session Lifetime terminlogy, maybe we can add one sentence to the end of the description to make
it clear that session timeout is also used in post access phase.

  ...session lifetime can be updated by a new round of EAP
  authentication before it expires. <add>For PANA session in the
  authentication and authorization phase, it should be set to
  a value that allows the PaC to detect a failed session in
  a reasonable amount of time</add>.

regards,
victor

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 12 Apr 2007 10:30:18 +0200

Hi,

In the current draft, error request messages i.e. PANA-Notification-Request message with 'E' (Error) bit set, are sent after any received message that may cause an error.

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?

Lionel

> -----Message d'origine-----
> De : Alper Yegin [mailto:[email-masked]] 
> Envoyé : jeudi 5 avril 2007 10:06
> À : [email-masked]
> Objet : [Pana] Review pana-pana-15a
> 
> 
> PANA specification is reviewed based on the last round of AD 
> comments (thanks Yoshi!).
> 
> The spec is here: 
> 
> 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
> 
> 
> 
> 
> 
> 
>

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 12 Apr 2007 11:42:30 +0200

Hi,

In section 5.7 Session Lifetime, it is stated:

"The PAA MUST initiate the re-authentication phase before the current session lifetime expires."

I can't figure out why there is a "MUST" in that case.

As documented in the draft, 

- The session lifetime is not negociable between the PAA and the PaC.
- The session lifetime may be sent to the PaC. If not, the PaC considers the PANA session as unlimited.
- Both PaC and PAA may initiate a re-authentication procedure regardless of the session lifetime.

Could we just have the following principles:

- If the session lifetime is sent to the PaC:
The PaC should re-authenticate before the expiration of the session lifetime. Otherwise, the session is deleted by the PAA at the expiration of the session lifetime (and the PaC will purge related local state).
The PAA may initiate a re-authentication procedure before the expiration of the session lifetime. Otherwise, the session is deleted by the PAA at the expiration of the session lifetime (and the PaC will purge related local state).
Both PaC and PAA may initiate a re-authentication procedure regardless of the session lifetime.

- If the session lifetime is sent to the PaC: 
The PAA may initiate a re-authentication procedure before the expiration of the session lifetime. Otherwise, the session is deleted at the expiration of the session lifetime.
Both PaC and PAA may initiate a re-authentication procedure regardless of the session lifetime.

With these principles, it is up to the PaC to maintain active its PANA session when infomed by the network (PAA) of the authorized session lifetime.
There is no strong requirement for the PAA/network point of view to . It is therefore up to the network operator to configure the PAA expected behaviour.

Comments?

Lionel

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 12 Apr 2007 17:02:11 +0200

Hi again,

In Section 4.1, it is stated:

   "A Nonce AVP MUST be included in the first non-initial
   PANA-Auth-Request and PANA-Auth-Answer messages, and MUST NOT be
   included in any other message."

This wording is quite ambiguous as one may understand that the nonce is used in only once within a PANA session while it will be actually used during each re-authentication procedures. Besides, "first non-initial PANA-Auth-Request and PANA-Auth-Answer messages" is unclear.
I propose the following text:

   "A Nonce AVP MUST be included in the first PANA-Auth-Request and
   PANA-Auth-Answer messages following the initial PANA-Auth-Request
   and PANA-Auth-Answer messages (i.e. with 'S' (Start) bit set), and MUST
   NOT be included in any other message, except during re-authentication 
   procedures (see section 4.3)"

Any comment?

Lionel

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 12 Apr 2007 11:36:18 -0400

Hi Lionel,
> 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.

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

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 12 Apr 2007 17:47:42 +0200

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 ;)
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 ;)

> De : Victor Fajardo [mailto:[email-masked]] 
> Envoyé : jeudi 12 avril 2007 17:36
> À : MORAND Lionel RD-CORE-ISS
> Cc : [email-masked]
> 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 
> 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
> >
> >
> >   
> >> De : Alper Yegin [mailto:[email-masked]] Envoyé : jeudi 5 
> >> avril 2007 10:06 À : [email-masked] Objet : [Pana] Review 
> >> pana-pana-15a
> >>
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 12 Apr 2007 17:55:45 +0200

Hi,

There is a description of the PANA session attributes in the section 5.3:

   "PANA SA attributes as well as PANA session attributes are listed
   below:

   PANA Session attributes:

      *  Session Identifier

      *  IP address and UDP port number of the PaC.

      *  IP address and UDP port number of the PAA

      *  Sequence number of the last transmitted request

      *  Sequence number of the last received request

      *  Last transmitted message payload

      *  Retransmission interval

      *  Session lifetime

      *  PANA SA attributes "

A NAT may exist between the PaC and the PAA (that is already covered in section 6.1). Therefore, the PaC IP address/UDP port number should not be part of the PANA session attributes. Instead, we should have the source IP address and the UDP source port number of the last PaC-initiated PANA messages (to take into account the fact that the PaC may change its IP address cf. section 5.6). I don't have any concrete proposal for improving the current text... But maybe it is not needed if my comment is not valid at all ;)

Lionel

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 13:11:39 -0400

Hi Lionel,

When NAT exists between PaC and PAA, the IP address and port number of
the PaC will simply point to the ones used by NAT.  If the IP address
and/or port of PaC changes, the IP address and port number attributes
will be modified to the new ones based on the IP address update
procedure defined in Section 5.6.  Said that I don't see a problem
with containing IP address and port number in the PANA session
attributes.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 13:43:38 -0400

Hi Lionel,

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

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

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 13:49:35 -0400

> notification is received for a pending request.

Adding the explicit text is good, but it is only for protected error
messages.  For unprotected errors, there is a rule in Section 5.8
which prohibits terminating the request retransmission procedure:

"
   If an error request or answer message is sent unprotected (i.e.,
   without using an AUTH AVP) then the message MUST be processed such
   that the receiver does not change its PANA protocol state.
"

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Apr 2007 13:52:52 -0400

The proposed text works for me.

Yoshihiro Ohba

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 13 Apr 2007 10:30:23 +0200

Hi Yoshi,

Maybe I was confusing! I'm not saying that the IP address/port number should not be part of the PANA session attributes.
I'm just saying that the wording:

Might not be correct if you are considering NAT. But it is not a strong point for me. Just a Nice-to-Have if considered to be useful.

BR,

Lionel

> De : Yoshihiro Ohba [mailto:[email-masked]] 
> Envoyé : jeudi 12 avril 2007 19:12
> Objet : Re: [Pana] IP address of the PaC in the PANA session attribute
> 
> Hi Lionel,
> 
> When NAT exists between PaC and PAA, the IP address and port 
> number of the PaC will simply point to the ones used by NAT.  
> If the IP address and/or port of PaC changes, the IP address 
> and port number attributes will be modified to the new ones 
> based on the IP address update procedure defined in Section 
> 5.6.  Said that I don't see a problem with containing IP 
> address and port number in the PANA session attributes.
> 
> Yoshihiro Ohba
> 
> 
> > A NAT may exist between the PaC and the PAA (that is 
> already covered 
> > in section 6.1). Therefore, the PaC IP address/UDP port 
> number should 
> > not be part of the PANA session attributes. Instead, we should have 
> > the source IP address and the UDP source port number of the last 
> > PaC-initiated PANA messages (to take into account the fact that the 
> > PaC may change its IP address cf. section 5.6). I don't have any 
> > concrete proposal for improving the current text... But maybe it is 
> > not needed if my comment is not valid at all ;)
> > 
> > Lionel
> > 
> > > Envoy？ : jeudi 5 avril 2007 10:06
> > > ？ : [email-masked]

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 13 Apr 2007 11:35:36 +0200

Hi Yoshi,

> Envoyé : jeudi 12 avril 2007 19:44
> Cc : Victor Fajardo; [email-masked]
> > 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

> > > Envoy？ : jeudi 12 avril 2007 17:36
> > > ？ : MORAND Lionel RD-CORE-ISS
> > > Cc : [email-masked]
> > > 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).
> > > >
> > > 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 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
> > > >
> > > >
> > > >   
> > > >> De : Alper Yegin [mailto:[email-masked]] Envoy？ 
> : jeudi 5 
> > > >> avril 2007 10:06 ？ : [email-masked] Objet : [Pana] Review 
> > > >> pana-pana-15a
> > > >>
> > > >>

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 13 Apr 2007 10:18:31 -0400

Hi Lionel,

> 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?

The use of error notification maybe a little more simple for 
implementation processing because that single message can be treated as 
a catch all event or interruption as oppose to having a few more 
additional conditions testing for errors in every other incoming answer 
messages. In that sense, unifying error notification to a single message 
has some advantages.

best regards,
victor

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Apr 2007 10:29:23 -0400

> Might not be correct if you are considering NAT. But it is not a strong point for me. Just a Nice-to-Have if considered to be useful.

I think it is correct in that PAA considers NAT as PaC.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 13 Apr 2007 18:37:13 +0200

Hi all, I did my review and the document is a good shape to me...

only some minor comments

1.Introduction

...

"By the virtue of enabling transport of EAP
above IP, any authentication method that can be carried as an EAP
method is made available to PANA and hence to any link-layer
technology"...

I don't understand the conclusion in this sentence "hence to any 
link-layer ..."

Maybe it should be enough

"By the virtue of enabling transport of EAP
above IP, any authentication method that can be carried as an EAP
method is made available to PANA".

In section 4.1

In case of PAA is stateful... might it be possible that PAA sends nonces 
in the initial PANA-Auth-Req/Resp

 >From the text

"A Nonce AVP MUST be included in the first non-initial PANA-Auth-Request and PANA-Auth-Answer messages, 
and MUST NOT be included in any other message."

, it seems not

My question why it is not possible to include them in the initial 
PANA-Auth-Request/Resp?

Just the line before section 5.4

Key-ID AVP. ---> Key-Id AVP.

My best regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Apr 2007 13:22:52 -0400

Victor,

> notification is received for a pending request.

I have check the spec and there is some text sepcifying that behavior 
on Section 9:

"
   PANA retransmission timers are based on the model used in DHCPv6
   [RFC3315].  Variables used here are also borrowed from this
   specification.  PANA is a request/response-based protocol.  The
   message exchange terminates when the requester successfully receives
   the answer, a protected error message for the request is received, or
   the message exchange is considered to have failed according to the
   retransmission mechanism described below.
"

Isn't this sufficient?

Yoshihiro Ohba

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 13 Apr 2007 14:33:14 -0400

Hi,
>    retransmission mechanism described below.

I think this is ok.

-- victor

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 14 Apr 2007 00:12:12 -0400

> method is made available to PANA".

I don't think it is enough.  Your text only captures the virtue of
carrying EAP, not the virtue of carrying EAP *above IP*.

> "A Nonce AVP MUST be included in the first non-initial PANA-Auth-Request 
> and PANA-Auth-Answer messages, and MUST NOT be included in any other 
> message."
> 
> , it seems not
> 

If the initial PAR/PAN carries nonces, it makes PAA difficult to be
stateless in the initial exchange.

> Key-ID AVP. ---> Key-Id AVP.

OK.

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Apr 2007 09:32:11 +0300

In order to reduce the optionality, can we say:

- PAA MUST send lifetime (when infinity, it can send maxint).
- PaC SHOULD initiate re-auth before lifetime expires. A "should" because
PaC may choose not to extend the authorization. Or we can make it a must
with a conditional "if PaC wants to extend....".
- PAA MAY initiate re-auth. Now, this one does not have to be related to
lifetime expiry, given that we put that burden on the PaC. 

Does this make sense?

Alper

> -----Original Message-----
> From: MORAND Lionel RD-CORE-ISS [mailto:[email-masked]]
> Sent: Thursday, April 12, 2007 12:43 PM
> To: Alper Yegin; [email-masked]
> Subject: [Pana] PAA initiating Re-authentication
> 
> Hi,
> 
> The PaC should re-authenticate before the expiration of the session
> lifetime. Otherwise, the session is deleted by the PAA at the expiration
> of the session lifetime (and the PaC will purge related local state).
> The PAA may initiate a re-authentication procedure before the expiration
> of the session lifetime. Otherwise, the session is deleted by the PAA at
> the expiration of the session lifetime (and the PaC will purge related
> local state).
> The PAA may initiate a re-authentication procedure before the expiration
> of the session lifetime. Otherwise, the session is deleted at the
> expiration of the session lifetime.
> With these principles, it is up to the PaC to maintain active its PANA
> session when infomed by the network (PAA) of the authorized session
> lifetime.
> There is no strong requirement for the PAA/network point of view to . It
> is therefore up to the network operator to configure the PAA expected
> behaviour.
> 
> Comments?
> 
> Lionel
> 
>

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 19 Apr 2007 08:59:39 +0200

It makes sense! ;)
For the PaC behavior, i think that a "If PaC wants... then PaC MUST" is acceptable.
Ok for the behavior of the PAA. It MAY initiate the re-auth when it wants.

BR,

Lionel

> Envoyé : jeudi 19 avril 2007 08:32
> À : MORAND Lionel RD-CORE-ISS; [email-masked]
> Objet : RE: [Pana] PAA initiating Re-authentication 
> 
> 
> - PaC SHOULD initiate re-auth before lifetime expires. A 
> "should" because PaC may choose not to extend the 
> authorization. Or we can make it a must with a conditional 
> "if PaC wants to extend....".
> - PAA MAY initiate re-auth. Now, this one does not have to be 
> related to lifetime expiry, given that we put that burden on the PaC. 
> 
> Does this make sense?
> 
> Alper
> 
> 
> 
> 
> > From: MORAND Lionel RD-CORE-ISS 
> > [mailto:[email-masked]]
> > "The PAA MUST initiate the re-authentication phase before 
> the current 
> > session lifetime expires."
> > 
> > lifetime. Otherwise, the session is deleted by the PAA at the 
> > expiration of the session lifetime (and the PaC will purge 
> related local state).
> > The PAA may initiate a re-authentication procedure before the 
> > expiration of the session lifetime. Otherwise, the session 
> is deleted 
> > by the PAA at the expiration of the session lifetime (and 
> the PaC will 
> > purge related local state).
> > Both PaC and PAA may initiate a re-authentication procedure 
> regardless 
> > of the session lifetime.
> > 
> > The PAA may initiate a re-authentication procedure before the 
> > expiration of the session lifetime. Otherwise, the session 
> is deleted 
> > at the expiration of the session lifetime.
> > Both PaC and PAA may initiate a re-authentication procedure 
> regardless 
> > of the session lifetime.
> > 
> > 
> > There is no strong requirement for the PAA/network point of 
> view to . 
> > It is therefore up to the network operator to configure the PAA 
> > expected behaviour.
> > 
> > Comments?
> > 
> > Lionel
> > 
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Apr 2007 08:55:17 -0400

OK.  Let me propose text.

[1] In Section 3, change:

"
   o  Re-authentication phase: During the access phase, the PAA must
      initiate re-authentication before the PANA session lifetime
      expires.  EAP is carried by PANA to perform authentication.  This
      phase may be optionally triggered by both the PaC and the PAA
      without any respect to the session lifetime.  The session moves to
      this phase from the access phase, and returns back there upon
      successful re-authentication.
"

to:

"
      Re-authentication phase: During the access phase, the PAA may,
      and the PaC should, initiate re-authentication if they want to
      update the PANA session lifetime before the PANA
      session lifetime expires.  EAP is carried by PANA to perform
      authentication.  This phase may be optionally triggered by both
      the PaC and the PAA without any respect to the session lifetime.
      The session moves to this phase from the access phase, and
      returns back there upon successful re-authentication.
"

[2] In Section 4.3, 2nd paragraph, change:

"
   When the PaC wants to initiate re-authentication, it sends a
   PANA-Notification-Request message with 'A' bit set (a re-
   authentication request message) to the PAA.  
"

to:

"
   When the PaC initiates re-authentication, it sends a
   PANA-Notification-Request message with 'A' bit set (a re-
   authentication request message) to the PAA.  
"

[3] In Section 5.7, change:

"
   The authentication and authorization phase determines the PANA
   session lifetime when the network access authorization succeeds.  The
   Session-Lifetime AVP MAY be optionally included in the last
   PANA-Auth-Request message to inform the PaC about the valid lifetime
   of the PANA session.  It MUST be ignored when included in other PANA
   messages.

   When the Session-Lifetime AVP is not included in the last
   PANA-Auth-Request message then the PaC has no knowledge about a PANA
   session limitation and must therefore conclude that the session is
   not limited.

   The lifetime is a non-negotiable parameter that can be used by the
   PaC to manage PANA-related state.  The PaC does not have to perform
   any actions when the lifetime expires, other than purging local
   state.  The PAA MUST initiate the re-authentication phase before the
   current session lifetime expires.
"

to:

"
   The authentication and authorization phase determines the PANA
   session lifetime when the network access authorization succeeds.  The
   Session-Lifetime AVP MUST be included in the last PANA-Auth-Request
   message (i.e., with 'C' (Complete) bit set) in authentication and
   authorization phase or re-authentication phase to inform the PaC
   about the valid lifetime of the PANA session.  It MUST be ignored
   when included in other PANA messages.

   The lifetime is a non-negotiable parameter that can be used by the
   PaC to manage PANA-related state.  The PaC does not have to perform
   any actions when the lifetime expires, other than purging local
   state.  The PAA MAY, and the PaC SHOULD, initiate the
   re-authentication phase before the current session lifetime expires 
   if they want to update the session lifetime.
"

(I don't think we should define a value for "infinity", because the
maximum value of session lifetime is 2^32-1 (4,294,967,295) sec =
49,710 days!)

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 23 Apr 2007 16:16:34 +0300

>From proposed text for Section 5.7:

>    if they want to update the session lifetime.

I think we want to say:

	The lifetime is a non-negotiable parameter that can be used by the
	PaC to manage PANA-related state. PaC MUST initiate the re-
	authentication phase before the current session lifetime expires if
it 
	wants to extend the session.

I think it is OK to be silent about the PAA actions as we don't specify what
it should or should not be doing.

Alper