Subject: DIAMETER Base Protocol (Alpha 1) - Comments

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

Pat,

Here is a small contribution to your document, which I think is basically a great piece of work for DIAMETER. 

Section 1.0
-----------
In the second last paragraph, we have:
"Given that the server MAY send unsocilited messages to clients, it is possible for the server to also issue authentication requests."
Shouldn't it be AA-Challenge-Ind instead of authentication requests?

Should we make this document as independant as possible from the extension specifics, or do we want to keep this close relationship between the base and extension protocols? The thing is that we often read about authentication messages and so on in this document, which I don't think really belong here, right? Instead, this document should specify something as generic as a framework offering sessions in the implementing servers with certain APIs and caracteristics. What do you think? 

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.

Section 2.1
-----------
While looking at the DIAMETER header format, it came to me that it might be cleaner to put the Vendor-ID before the Command-Code, since the Command-Code is worthless without the Vendor-ID and finding it first would make more sense. And then I thought, since we might remove the PCC and add more flags, shouldn't we add a flag indicating if a Vendor-ID is present at all in the message, just like in the AVP header? And since we are there, maybe we could put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: reserved) for the Extension-ID or Vendor-ID when present in the message (referring to ML on "Capabilities Negotiation and proxies"), which then would mean that the command-code is per Extension-ID and Vendor-ID base, completely independent of the Base protocol command-code. Maybe an AVP for the command-code field would be a better idea, because it could include the indicator bits and also could be used in a MRI in the Failed-AVP AVP, making obsolete the Un!
recognized-Command-Code AVP which lacks the information on the Vendor-ID AVP and Extension-ID. 

Section 2.2.3 - par.1
---------------------
"... seven data types" should be replaced with "the following data types", since we actually have 10 and it might keep changing.

Section 2.2.5
-------------
It would be more useful, at least for me, to have a list of attributes sorted by name, instead AVP codes, which are meaningless to human normal reading.

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?

And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of the Vendor-ID AVP in the DRI. 

Section 5.0
-----------
The list of Error Types is a bit confusing with the one found in section 5.1 for MRI. I think it needs some rework. I can´t still figure out exactly how it should be, so maybe I'll come up with something later.

Section 5.1.2
-------------
I mentioned some ideas about this in the comments of section 2.1

Section 5.2.2
-------------
All other Result-Code starts a x001, so I thought it should also starts at 2001, instead of 2000.

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

Section 7.1.2
-------------
The 3rd paragraph should be removed.

Section 10.0
------------
About the shared secret, maybe we should also mention that it is used by the Encrypted-Payload AVP?

/Martin

---

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

> great piece of work for DIAMETER. 

Thanks, and I appreciate the comments below. Please see my comments inline.

PatC

> "Given that the server MAY send unsocilited messages to clients, it is
> possible for the server to also issue authentication requests." Shouldn't it
> be AA-Challenge-Ind instead of authentication requests?
> 
> Should we make this document as independant as possible from the extension
> specifics, or do we want to keep this close relationship between the base
> and extension protocols? The thing is that we often read about
> authentication messages and so on in this document, which I don't think
> really belong here, right? Instead, this document should specify something
> as generic as a framework offering sessions in the implementing servers with
> certain APIs and caracteristics. What do you think? 

Correct, and perhaps the quote paragraph needs to be changed to exclude
references to authentication requests. The individual extensions should
concern themselves with such text.

If we agree on this, then I believe it does provide a better framework, and
less coupling.

Comments?

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

> 
> Section 2.1
> -----------
> While looking at the DIAMETER header format, it came to me that it might be
> cleaner to put the Vendor-ID before the Command-Code, since the Command-Code
> is worthless without the Vendor-ID and finding it first would make more
> sense. And then I thought, since we might remove the PCC and add more flags,
> shouldn't we add a flag indicating if a Vendor-ID is present at all in the
> message, just like in the AVP header? And since we are there, maybe we could
> put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3:
> reserved) for the Extension-ID or Vendor-ID when present in the message
> (referring to ML on "Capabilities Negotiation and proxies"), which then
> would mean that the command-code is per Extension-ID and Vendor-ID base,
> completely independent of the Base protocol command-code. Maybe an AVP for
> the command-code field would be a better idea, because it could include the
> indicator bits and also could be used in a MRI in the Failed-AVP AVP, making
> obsolete the Un! recognized-Command-Code AVP which lacks the information on
> the Vendor-ID AVP and Extension-ID. 

hmmm... This is a good comment, but I would like to solicit comments from
other DIAMETER developers (and other people that also generally care). 

For this reason I am also adding the diameter mailing list,

> 
> Section 2.2.3 - par.1
> ---------------------
> "... seven data types" should be replaced with "the following data types",
> since we actually have 10 and it might keep changing.

yes, good suggestion.

> 
> Section 2.2.5
> -------------
> It would be more useful, at least for me, to have a list of attributes
> sorted by name, instead AVP codes, which are meaningless to human normal
> reading.

that works for me. Anyone object?

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

> 
> And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name
> AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of
> the Vendor-ID AVP in the DRI. 

So, if I understand, you are arguing in favor of the Vendor-ID, correct? Any
objections?

> 
> Section 5.0
> -----------
> The list of Error Types is a bit confusing with the one found in section 5.1
> for MRI. I think it needs some rework. I can´t still figure out exactly how
> it should be, so maybe I'll come up with something later.

Are the classes what you find troubling?

> Section 5.1.2

ok... consistency is good.

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

> Section 7.1.2

that darned cut and paste problem again :)

> Section 10.0
Absolutely.

Again, great comments. Looking forward to continuing some of these topics...