Diameter Credit-Control Application
RFC 4006

New revision expected as promised by authors.
Will not appear untill after San DIego IETF though.
Ted's clearance of his DISCUSS was based on a revision-6-to-be.

[Ballot discuss]
> 12.1 Application Identifier 
>   
>    This specification assigns the value XXX [IANA please fill in XXX
>    (suggested value 4) and remove this note] to the Application
>    Identifier namespace defined in [DIAMBASE]. See section 1.3 for more
>    information. 

Please provide the name of the application identifier.

> 12.3 AVP Codes 
>     
>    This specification assigns the values XXX - YYY [IANA please fill in
>    XXX, YYY (suggested values 411, 457) and remove this note] from the
>    AVP code namespace defined in [DIAMBASE] See section 8 for the
>    assignment of the namespace in this specification. 

would be good to include a table with all the needed TBDs, refering to
the section where each is defined.


> 12.4 Result-Code AVP Values 

ditto.

> 12.5 CC-Request-Type AVP
>   
>    As defined in section 8.3, the CC-Request-Type AVP defines the values
>    X1-X3 [IANA please fill in X1-X3 (suggested value 1, 3) and remove
>    this note]. All remaining values are available for assignment via
>    Designated Expert [IANA].

Better:   
       

  12.5 CC-Request-Type AVP
   
  As defined in section 8.3, the CC-Request-Type AVP includes an Enumerated
  type  value. IANA is to create and maintain  a namespace for this
  AVP. [IANA please fill in X1-X3 (suggested value 1, 3) and remove
  this note]. All remaining values are available for assignment via
  Designated Expert [IANA].
   

i.e., make it clear that this is a name space that IANA must create
and maintain.

Similar comments    apply to other subsections.

BTW, IANA seemed to have raised similar issues in mail on June 15.

[Ballot discuss]
- The Subscription-Id-Type  AVPs are a very limited set and do not appear extensible:  what about
  this application for interoperating pres: uri's or other identifiers in future?  Another case like this
  is the User-Equipment-Identifier, which allows only 3GPP mobiles and wireless.  This is inappropriate
  in a general AAA document.
- The WG needed to think more broadly about SIP.  The SIP example works as expected in
  the 3GPP-enforced environment because the proxy can measure the quota, but in open
  environments, the proxy at best will see the BYE (and possibly might not see that).  Flow II must
  state in a careful final paragraph that the degree of credit control measuring of the media by
  the proxy depends on the business model design used in setting up the end system and proxies
  in the SIP network.
- Flow V and VII need a bigger SIP picture.  In V, the INVITE is to B, or to a B2BUA that is
  meant to intercept a price inquiry?  This is a new SIP service.  Flow VII describes use of a SIP
  controller, which is probably 3PCC, but that needs to be shown, the call establishment would
  need to be shown. 
- Recommendation on flows V and VII:  Jon and I should email you as to whether to clean them up,
  remove them, or annotate them.

[Ballot discuss]
- The Subscription-Id-Type  AVPs are a very limited set and do not appear extensible:  what about
  this application for interoperating pres: uri's or other identifiers in future?  Another case like this
  is the User-Equipment-Identifier, which allows only 3GPP mobiles and wireless.  This is inappropriate
  in a general AAA document.
- The WG needed to think more broadly about SIP.  The SIP example works as expected in
  the 3GPP-enforced environment because the proxy can measure the quota, but in open
  environments, the proxy at best will see the BYE (and possibly might not see that).  Flow II must
  state in a careful final paragraph that the degree of credit control measuring of the media by
  the proxy depends on the business model design used in setting up the end system and proxies
  in the SIP network.
- Flow V and VII need a bigger SIP picture.  In V, the INVITE is to B, or to a B2BUA that is
  meant to intercept a price inquiry?  This is a new SIP service.  Flow VII describes use of a SIP
  controller, which is probably 3PCC, but that needs to be shown, the call establishment would
  need to be shown. 
- Recommendation on flows V and VII:  Jon and I should email you as to whether to clean them up,
  remove them, or annotate them.

[Ballot discuss]
- The Subscription-Id-Type  AVPs are a very limited set and do not appear extensible:  what about
  this application for interoperating pres: uri's or other identifiers in future?  Another case like this
  is the User-Equipment-Identifier, which allows only 3GPP mobiles and wireless.  This is inappropriate
  in a general AAA document.
- The WG needed to obtain SIP reviewing along the way.  The SIP example works as expected in
  the 3GPP-enforced environment because the proxy can measure the quota, but in open
  environments, the proxy at best will see the BYE (and possibly might not see that).  Flow II must
  state in a careful final paragraph that the degree of credit control measuring of the media by
  the proxy depends on the business model design used in setting up the end system and proxies
  in the SIP network.
- Flow V and VII need a review by the SIPPING WG.  In V, the INVITE is to B, or to a B2BUA that is
  meant to intercept a price inquiry?  This is a new SIP service.  Flow VII describes use of a SIP
  controller, which is probably 3PCC, but that needs to be shown, the call establishment would
  need to be shown. 
- Recommendation on the SIP flows:  further review by the SIPPING WG as to whether to clean them up,
  remove them, otherwise annotate them.

[Ballot discuss]
I believe Section 4.1 needs some clean up to provide useful guidelines for
interoperability.  I read through it 3 or 4 times, and I believe I eventually
got the steps into a reasonable set of steps, but it is still hard for me to
be sure that it is the only reasonable reading.  The document needs clear
advice on when to reuse AVPs, how and when to define new ones, and
when to use the service-parameter-info as a container.  It may also need
to justify some choices based on other constraints (does a limit in the
AVP namespace suggest re-use of existing AVPs, for example?)

It is not clear to me what the client requirements are for 5.5.  If, for example,
a client is using this mechanism to manage voice minutes on a mobile phone,
does the potential for a Server-initiated RAR imply that the client must have
data traffic and this service enabled at all times, in case it receives such a request? 
Note that the "graceful service termination" redirect to a top-up server doesn't
obviate this requirement (at least in my reading), since it doesn't imply that
the server won't send an RAR.

Is it legal to combine a Tariff change with a service initiated re-auth?

[Ballot discuss]
I believe Section 4.1 needs some clean up to provide useful guidelines for
interoperability.  I read through it 3 or 4 times, and I believe I eventually
got the steps into a reasonable set of steps, but it is still hard for me to
be sure that it is the only reasonable reading.  The document needs clear
advice on when to reuse AVPs, how and when to define new ones, and
when to use the service-parameter-info as a container.  It may also need
to justify some choices based on other constraints (does a limit in the
AVP namespace suggest re-use of existing AVPs, for example?)

It is not clear to me what the client requirements are for 5.5.  If, for example,
a client is using this mechanism to manage voice minutes on a mobile phone,
does the potential for a Server-initiated RAR imply that the client must have
data traffic and this service enabled at all times, in case it receives such a request? 
Note that the "graceful service termination" redirect to a top-up server doesn't
obviate this requirement (at least in my reading), since it doesn't imply that
the server won't send an RAR.

[Ballot comment]
"credit fragmentation" is mentioned in this section:


  To avoid credit fragmentation and unnecessary load on the credit
  control server, it is possible for service units to be provided to
  multiple services or rating groups as a pool. This is achieved by
  providing the service units in the form of a quota for a particular
  service or rating group in the Multiple-Services-Credit-Control AVP,
  but also including a reference to a credit pool for that unit type. 

Some definition of credit fragmentation might be useful.

[Ballot discuss]
I believe Section 4.1 needs some clean up to provide useful guidelines for
interoperability.  I read through it 3 or 4 times, and I believe I eventually
got the steps into a reasonable set of steps, but it is still hard for me to
be sure that it is the only reasonable reading.  The document needs clear
advice on when to reuse AVPs, how and when to define new ones, and
when to use the service-parameter-info as a container.  It may also need
to justify some choices based on other constraints (does a limit in the
AVP namespace suggest re-use of existing AVPs, for example?)

[Ballot comment]
The document could use an editing pass by a native speaker of English.  I'm not sure how much of that the RFC Editor does, but such an effort is definitely needed here.

[Note]: 'GEN-ART review has some (minor) comments (resulting from review during IETF Last Call) that will be addressed by authors. They will do so when IESG comments (if any) are available so that one revision can address all comments at same time.' added by Bert Wijnen

[Note]: 'GEN-ART review has some (minor) comments (resulting from review during IETF Last Call) that will be addressed by authors.
They will do so when IESG comments (if any) are available so that one revision can address all comments at same time.' added by Bert Wijnen

IANA Last Call Comments:
Section 12.1
The name of the application identifier to be assigned should be
included in this section.

Sction 12.2
The name of the command code to be assigned should be
included in this section.

Section 12.3
We will use section 8 as the guide for assigning
AVP Codes (total values = 50)

Section 12.4
We will use section 9 as the guide for assigning
Result-Code AVP Values (total values = 5).

Sections 12.5-12.18
We will create sub-registries for AVP Specific Values

> > l. Section 8.46
> >    Is it SIP URL in this case, while it is SIP URI in sect 8.38?
>
> Should be SIP URI, we'll correct it.
>
but it still says URL in one place and URI in the other.
And 8.38 uses "Uniform Resource Indicator", while I believe that
URI stands for "Uniform Resource Indentifier" (see RFC2396)

WG Last Call had comments, new rev was posted on March 18th. Supposedly addresses all WG Last Call comments and should be ready for AD review. Checking with WG chairs.