Subject: Re: DIAMETER Base Protocol (Alpha 1) - Comments

From: Pat Calhoun <[email-masked]>
Date: Thu, 18 Jan 2001 15:15:45 -0800

Martin,

Thanks for the great comments. I am travelling at the moment, and will address
these tomorrow (just want to make sure that you don't think I am ignoring 
this e-mail).

PatC

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