Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 22 Jan 2001 17:26:52 +0100

Pat,

Please, see some minor comments inline.

Thanks,
Martin

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 11:29 PM
> > 
> > 
> > Section 2.0 - par.5
> > -------------------
> > "Session state (associated with a Session-Id) MUST be freed 
> upon receipt of
> > the Session-Termination-Request, 
> Session-Termination-Answer, expiration of
> > authorized service time in the Session-Timeout AVP, and 
> according to rules
> > established in a particular extension/application of DIAMETER."
> > 
> > I think this sentence is confusing me. Are you trying to 
> show the real
> > trigger for the session release, the STR (as in section 
> 3.5.2), or the
> > reasons why an STR could have been sent? It seems to me that the
> > "Session-Termination-Answer, expiration of authorized 
> service time in the
> > Session-Timeout AVP, and according to rules established in 
> a particular
> > extension/application of DIAMETER." part is more related to 
> original reasons
> > why an STR has been sent. Also, it is confusing to read 
> "authorized service
> > time in the Session-Timeout AVP" when you can also refer to 
> the reason that
> > the "authorization-lifetime-AVP" might have time-out as 
> well, which I assume
> > would trigger an STR. I need more info from you if you want 
> me to propose
> > something else.
> 
> I think that the confusion is largely in the quoted text. 
> What the above
> attempts to state is that servers that maintain state needs 
> to relinquish such
> state when: 1. A Session-Termination-Request is received,
> 2. A Session-Termination-Answer is received,
> 3. The session has timed out (which does NOT require sending 
> any termination 
>    messages), or
> 4. Any other rules specified in extensions.
> 
> Does this help? If so, I can itemize each condition in the 
> draft. I think this
> would read better anyway.

Yes, but it would help if you could also clarify the fact that resources in proxies and DIAMETER clients should be released only when a STA is received, and released in the Home AAA when a STA is about to be sent (or STR received).

> > 
> > Section 2.5 - par.1
> > -------------------
> > "...the Device-Reboot-Ind message MUST contain one 
> Host-IP-Address AVP for
> > each potential IP address that MAY be locally used when transmitting
> > DIAMETER messages."
> > 
> > Please, could you tell me briefly why we need to send all 
> IP addresses of
> > the device? I guess it is because the device is not 
> registered into a DNS
> > and we want to build an internal DNS inside the DIAMETER 
> server along with
> > the Host-Name AVP for message routing, right? Should we 
> have a dynamic or
> > static DNS in the server?
> 
> It was intended to fully support SCTP, which inherently 
> supports multi-homed
> servers.

Which means that it is suggested for a DIAMETER server to maintain a dynamic "DNS" containing all the IP addresses of the clients for SCTP to support multi-homing? This is then an AVP which is transport dependent, right? Should it really be an AVP Mandatory (M), as it is right now? 

> > Section 5.2.4
> > -------------
> > "...but MAY be able to satisfy the request in the future."
> > What does this mean exactly? Does it mean that a server 
> should be able to
> > resend the request in a few minutes without any specific 
> changes to the
> > message besides the timestamp for example? Should it be regarded as
> > temporary congestion? 
> 
> It is intended to contain errors that occur due to some 
> temporary condition,
> and the request can be tried again later. I am not sure how to express
> "future". A timestamp may not really help, since the server 
> may not know when
> the administrator will free up some disk space (as an example).
> 
> > If it is the case, then maybe we should think of
> > moving the DIAMETER_AUTHENTICATION_REJECTED and 
> DIAMETER_CONTRACTING_AVPS to
> > the permanent failure section. I think that permanent 
> result codes should be
> > used in the rejected message even if the originating server 
> can change AVPs
> > in the message which has been rejected the first time for 
> some reasons such
> > as unsupported mandatory AVPs, because it is no longer the 
> same message
> > anyway, and the first message was really considered as a 
> permanent failure
> > in this particular period of time. 
> yes, you are right. I will move these.

It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Jan 2001 08:48:10 -0800 (PST)

> Please, see some minor comments inline.

as are mine...

PatC

> Yes, but it would help if you could also clarify the fact that resources in
> proxies and DIAMETER clients should be released only when a STA is received,
> and released in the Home AAA when a STA is about to be sent (or STR
> received).

ok.
> Which means that it is suggested for a DIAMETER server to maintain a dynamic
> "DNS" containing all the IP addresses of the clients for SCTP to support
> multi-homing? This is then an AVP which is transport dependent, right?
> Should it really be an AVP Mandatory (M), as it is right now? 

AAA servers should not be DNS servers. This is really an implementation issue,
and the internals of the server shouldn't be discussed, IMHO. 

Yes, I think 'M' is correct.

> It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one.

I will check.

Thanks,

PatC