Document: draft-ietf-aaa-diameter-cc-05
Reviewer: Joel Halpern
Date: June 14, 2004

Note: Review at Last Call

This document is in good shape, and appears to be ready for publication as a Proposed Standard RFC.


If there is a reason to revise this document, it may make sense to address some minor comments.
1) The document describes a set of charging behaviors that are supported.  It gradually introduces additional covered scenarios, resulting in a very powerful approach. However, it is reasonable to expect that even with that, there are cases not covered.  Which is fine.  What would be helpful is two short sentences.
1a) A sentence indicating that the scenarios covered while a subset of all possible cases are driven by end user requirements and that additional behaviors can be added to extend the coverage as needed in other documents.
1b) A sentence at the first description of the two behaviors indicating that these are described in more detail, with more variations, in section 5.  I was somewhat surprised (and pleased) to bind additional cases covered in 5.1.1 for example.
2) The section formatting is odd.  The last line of text of a section is adjacent with no white space to the next header line, which is followed by white-space before new text.  I think there ought to be a blank line before each section header.
3) There is an oddity in the diagram in section 5.1.1 in that Service-Id b has no access to either a quota or a credit pool, and neither does its containing Rating-Group 1.
4) In the first paragraph of section 5.3 the text notes that the client may send an intermediate interrogation before the Validity-Time of a current reservation expires.  Presumably the client MAY also send an intermediate Interrogation when the credit reservation is close to exhaustion, rather than waiting till exhaustion.  ANy reason not to say this?
5) In section 5.6.2, the text indicates that the server must respond to the ~out of credit~ intermediate request differently than it does to other intermediate requests.  The text then goes on to indicate that the absence of specific fields constitute a "hint" that this behavior is required.  If this absence ensures the proper response, then it is not a hint.  If it is only a hint, then the protocol needs a mechanism to ensure proper behavior.  My guess is that the word "hint" is badly chosen.
6) In table 1 in section 7, I tripped on the N/A abbrevation.  I read it as "Not Available" which would be an error case.  Looking at the action and next state, I am pretty sure that "Not Applicable" is what is intended.  Could we have a sentence in the explanations before the table indicating that N/A means "Not Applicable".
7) The term service is used to mean different things at different points.  For example, "Service-ID" refers to the identifier of a set of traffic to be charged as a service, used within a multi-service activity.  However, "Service-Parameter" (info, type, and value) refer to aspects of the entire communication service that the subscriber receives.  At other places service means the traffic, or the conceptual charging and control behavior.  I presume the authors have already looked for ways to iron out this ambiguity.  I class this as minor because although it bothers me, I can not suggest a resolution in English that will solve this problem.
8) This may be a browser rendition error, but the "Redirect-Max_Cache_Time line in the AVP Occurrence Table had a second column with 0*1 (where the * was some unidentifiable symbol.)
9) In flow IV, the MMSC is shown using direct debiting for charging a receiving user for receiving an MMS.  iven that the transfer can take an extended time, and can fail, either the text should talk about failure recovery, or direct debiting should not be used for this flow.


One comment for this list, which is already known to the authors and working group.
The Diameter specifications created their own formal language.  As such, it does not use standard ABNF.  I personally find the format hard to read (elements are bracketed with <>, (), and [] each meaning subtly different things.)
Given that the precedent for this has been established in Diameter base, I can not realistically object.  In fact, it would probably actually be worse to use a different format in this document.
My guess is that those who intensively implement Diameter will quickly learn this format.


Disclaimer: I build something that makes extensive use of RADIUS with proprietary Prepaid Control extensions.  I may know too much about the problem space.