Subject: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 18 Jan 2001 11:22:47 +0100

Pat,

Comments making no sense to you are most probably related to my ignorance... However, I'd appreciate you help me out on this.

Section 3.0 - par.2
-------------------
It is weird to me that we refer to an Authorization-Lifetime AVP in the Base Protocol without having any authorization message in it. Now we have the Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow competing together. Should the Authorization-Lifetime AVP be included in a specific extension, such as NASREQ, or is it because it might be used by several extensions without any specific meaning to the base protocol itself, which happens to be pretty much the same as the Session-Timeout AVP? My understanding is that there is not much to do with the Authorization-Lifetime AVP in the base protocol, since the action to take upon its expiration is defined in the NASREQ extension anyway, which is very specific. I guess that something more generic would be a Session-Timeout AVP which could trigger an STI when it expires that could lead to another re-authentication or something else in order to avoid the session to terminate right away. Then the NASREQ extension!
 could possibly override that meaning by defining its own Authorization-Lifetime AVP which would trigger a more efficient an AA-Challenge-Ind instead.

Section 3.2 and 3.3
-------------------
Can the server return a bigger value?
What the value 0 means? The same as if it was not there?
Which one has priority?

Section 3.5
-----------
"Since the Session-Id is typically tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session termination messages are used to request that the service tied to the Session Id be terminated."

It seems to be against last paragraph of section 3.1, which is "Note that a Session-Id MAY be used by more than one extension (e.g. authentication for a specific service and accounting, both of which have separate extensions).

Section 3.5.2
-------------
What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I guess not, since the User-Name AVP is present. Can it be used in the server for any particular reason I don't see, since I think the active session should be aware of what's going on within itself, right?

Section 3.5.3
-------------
What is the purpose of the STA, since the session in the server and in the proxies should be released after the STR? What can the NAS or the server do if the STR is rejected and the resources are already released in the DIAMETER client and the proxies?

Section 3.5.4
-------------
AVP Code 293

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 19 Jan 2001 14:49:31 -0800 (PST)

> Pat,
> 
> Comments making no sense to you are most probably related to my ignorance...
> However, I'd appreciate you help me out on this.

and responses making no sense to you are most probably related to my
ignorance...

:)

> 
> 
> Section 3.0 - par.2
> -------------------
> It is weird to me that we refer to an Authorization-Lifetime AVP in the Base
> Protocol without having any authorization message in it. Now we have the
> Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow
> competing together.

No, they aren't intended to compete. Dave Mitton was the one that had come up
with the Authorization-Lifetime AVP in the solutions I-D. The
Authentication-Lifetime specifies how long before a re-auth should occur. The
Session-Time, on the other hand, states how long the session can occur. After
Session-Time, a session MUST be torn down. 

> Should the Authorization-Lifetime AVP be included in a
> specific extension, such as NASREQ, or is it because it might be used by
> several extensions without any specific meaning to the base protocol itself,
> which happens to be pretty much the same as the Session-Timeout AVP? My
> understanding is that there is not much to do with the
> Authorization-Lifetime AVP in the base protocol, since the action to take
> upon its expiration is defined in the NASREQ extension anyway, which is very
> specific. 
The reason why it is in the base protocol is to reduce duplicate AVPs in
extensions. I environ that all access methods will require some session
lifetime, so since it is used in many extensions, it seems appropriate to put
it in the base protocol.

> I guess that something more generic would be a Session-Timeout AVP
> which could trigger an STI when it expires that could lead to another
> re-authentication or something else in order to avoid the session to
> terminate right away. Then the NASREQ extension!
>  could possibly override that meaning by defining its own
> Authorization-Lifetime AVP which would trigger a more efficient an
> AA-Challenge-Ind instead.

Please read the above intended definitions of both AVPs and tell me if
additional changes are still required. Perhaps the actual definition of both
AVPs need some work. Is this sufficient?

> Section 3.2 and 3.3

bigger than what?

> What the value 0 means? The same as if it was not there?
0 and not present are the same. They mean infinity (and I fixed the text in
Authorization-Lifetime)

> 
> Section 3.5
> -----------
> "Since the Session-Id is typically tied to a particular service (i.e. Mobile
> IP, NASREQ, etc), the session termination messages are used to request that
> the service tied to the Session Id be terminated."
> 
> It seems to be against last paragraph of section 3.1, which is "Note that a
> Session-Id MAY be used by more than one extension (e.g. authentication for a
> specific service and accounting, both of which have separate extensions).

hmmmm.... I believe that section 3.5 should state that the Extension-Id is
used to identify which service should be terminated. Does this make more sense?
 > 
> Section 3.5.2
> -------------
> What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I
> guess not, since the User-Name AVP is present. Can it be used in the server
> for any particular reason I don't see, since I think the active session
> should be aware of what's going on within itself, right?

If the home server wishes for the NAS to reliquish resources, then the
User-name AVP doesn't really help since it would cause the packet to get
routed to the home server (loop). So something is needed for the message to
get routed to the NAS, and I envisioned was that the AVP would be used for
routing purposes (and eventually get to the NAS).

> 
> Section 3.5.3
> -------------
> What is the purpose of the STA, since the session in the server and in the
> proxies should be released after the STR? What can the NAS or the server do
> if the STR is rejected and the resources are already released in the
> DIAMETER client and the proxies?

The STA acks the STR. The sender of the STR should wait until the STA is
received before releases resources.

> Section 3.5.4
oops

Thanks!

PatC