Subject: [AAA-WG]: FW: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments

From: <[email-masked]>
Date: Tue, 3 Aug 2004 19:48:44 +0300

Text sent to clear Ted's comments.  Attached are the responses.

John

_____________________________________-

Hello,

thank you for your comments. We agree that the specification is not very clear
in some parts and some clarification is certainly useful to better understand
the message we wanted to give.

Please see the answers and proposals for improved text below and let us
know whether these corrections and clarifications will address your concerns.

Best Regards,
Harri Hakala
Leena Mattila
Juha-Pekka Koskinen
Marco Stura
John Loughney
--------------------------------------------------------------------------
Ted Hardie:

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

Answer:

Agree. The section needs some re-structuring to give better guidance.
Proposal for the text (replaces old section 4.1):

4.1 Service-Specific Rating Input and Interoperability 

   The Diameter Credit-Control Application defines the framework for 
   credit control; it provides generic credit control mechanisms 
   supporting multiple service applications. The Credit Control 
   Application, therefore, does not define AVPs that could be used as 
   input in the rating process. Listing the possible services that could 
   use this Diameter application is seen as out of scope for this 
   generic mechanism as well. 
    
   Furthermore, it is not assumed that any arbitrary Diameter credit-
   control client will be able to communicate with any Diameter
   credit-control server, but the connections reflect the business
   relationships between the organizations hosting the Diameter peers.
   Therefore, it is reasonable to expect that there will exist a service
   level agreement between providers of the credit-control client and
   the credit-control server covering the charging, services offered,
   roaming agreements, agreed rating input, etc.

4.1.1 Specifying Rating Input AVPs

   There are two ways for providing rating input to the credit control 
   server, either by using AVPs or by including them in the Service-
   Parameter-Info AVP. The general principles for sending rating 
   parameters are:

   1a. The service SHOULD re-use existing AVPs, if the  service can use
       AVPs defined in existing Diameter applications (e.g. NASREQ for
       network access services). Re-use of existing AVPs is strongly
       recommendated in [DIAMBASE].

       For AVPs of type Enumerated the service may require a new value
       to be defined. Allocation of new AVP values is done as specified
       in [DIAMBASE], section 1.2.

   1b. New AVPs can be defined if the existing AVPs do not provide
       sufficient rating information. In such a case, the procedures 
       defined in [DIAMBASE] for creating new AVPs MUST be followed.

   1c. For services specific only to one vendor's implementation
       where no interoperatbility is deemed useful, a Vendor-Specific AVP
       code for Private use can be used. Where a Vendor-Specific AVP is
       implemented by more than one vendor, allocation of global AVPs
       are encouraged instead, refer to [DIAMBASE].

   2.  The Service-Parameter-Info AVP MAY be used as a container to pass
       legacy rating information in its original encoded form (e.g. 
       ASN.1 BER). This method can be used to avoid unnecessary data 
       format conversions from an existing format to an AVP format. In 
       that case the rating input is embedded in the Service-Parameter-Info 
       AVP as defined in section 8.42.

   New service applications SHOULD favor the use of explicitly defined
   AVPs as described in items 1a and 1b, to simplify interoperability. 

4.1.2 Application Support

   Since the Application-Id of the Diameter Credit Control Application does
   not uniquely identify the service being monitored, an additional mechanism
   is needed. The service application MUST be identified using the
   Service-Identifier AVP at command level. A server receiving a request for 
   a service application it does not support will reject the request as 
   defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique 
   identifier for a given service as defined in section 8.28. 

   Thus, the combination of the Diameter Credit Control Application-Id and
   the Service-Identifier AVP in the Credit-Control-Request command uniquely
   defines the service within the context of the Diameter Credit Control, 
   and hence provides interoperability between Diameter credit control 
   clients and server. 

   Introducing new, non-rating related AVPs, that imply new credit control
   mechanisms, require definition of a new version of the Diameter 
   Credit Control Application and corresponding Application Identifier. 

4.1.3 Documentation of the Service-Specific Information
 
   The service specific rating input AVPs, the contents of the Service-
   Parameter-Info AVP or Service-Identifier AVP are not within the scope 
   of this document. To facilitate interoperability, it is RECOMMENDED 
   that the rating input and the values of the service identifiers are 
   coordinated via an informational RFC or other permanent and readily 
   available reference such as the specification of another cooperative 
   standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. 
   However, private services may be deployed that are subject
   to agreements between providers of the credit control server and
   client, in this case vendor specific AVPs can be used. 
    
   This specification, together with the above service specific documents,
   governs the credit control message. The rule is that service specific
   documents only define what existing AVPs or new AVPs are used as
   input to the rating process (i.e. they do not define new 
   credit control applications), and thus need to be included in the 
   Credit-Control-Request command by a Diameter Credit Control Client 
   supporting a given service as *[AVP]. Should Service-Parameter-Info
   be used, then the service specific document MUST specify the exact
   content of this grouped AVP.

4.1.4 Handling of Unsupported/Incorrect Rating Input 

   Diameter credit control implementations are required to support the 
   Mandatory rating AVPs defined in service specific documentation of 
   the services they support according to the 'M' bit rules in [DIAMBASE]. 
    
   In case a rating input required for the rating process is incorrect 
   in the Credit control request, or the credit control server does not 
   support the requested service, the Credit control answer MUST contain 
   error code DIAMETER_RATING_FAILED. A CCR message with this error MUST 
   contain one or more Failed-AVP AVPs containing the missing and/or 
   unsupported AVPs that caused the failure. A Diameter credit control 
   client receiving error code DIAMETER_RATING_FAILED in answer to a 
   request MUST NOT send such similar requests in the future.

4.1.5 RADIUS Vendor-Specific Rating Attributes
    
   When service specific documents include RADIUS vendor specific 
   attributes that could be used as input in the rating process, the 
   rules described in [NASREQ] for formatting the Diameter AVP MUST be 
   followed. For example, the AVP code used is the vendor attribute type 
   code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID 
   MUST be set to the IANA Vendor identification value. The Diameter AVP 
   data field contains only the attribute value of the RADIUS attribute. 

----------------------------------------------------------------------

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? 

Answer:
      The client needs to support the RAR/RAA messages and needs to
      initiate a credit re-authorization by sending a CCR request
      upon reception of the RAR. This is explained in the third
      and subsequent paragraphs and it is visible in the client 
      state machine. This is the only requirement to the client, 
      and it is according to the base protocol.

      Concerning the voice minutes, this is handled by requesting
      credit authorization (or re-authorization) with the CCR request. 
      The server returns the time quota in the corresponding CCA
      message within the Granted-Service-Unit AVP, the time quota
      is monitored by the client. At any time the server may request
      credit re-authorization by issuing a RAR request.

      Performing tariff time changes with the server initiated 
      re-authorization is actually possible although cumbersome.
      Tariff changes typically occur at the same time for all the
      active sessions, therefore, the server would need to issue
      a RAR for all the active sessions at the same time. This
      abviously creates a huge storm of credit re-authorization
      that would potentially overload the system. In real networks,
      where million of users are active, this mechanism for tariff
      change is actually not gonna work. The DCCA defines a more
      effective tariff change mechanism where huge storm of
      credit re-authorization when tariff change occurs is avoided
      (see for instance sect. 5.1).

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

Answer:
We'd propose to modify the above paragraph as follows:

   To avoid a situation where several parallel, and typically also
   small, credit reservations must be made on the same account (i.e.
   credit fragmentation) and also to avoid unnecessary load on the credit 
   control server, it is possible to provide service units as a pool 
   that applies to multiple services or rating groups. 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. 
----------------------------------------------------------------------

Subject: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 29 Jun 2004 13:44:11 +0300

Hello,

thank you for your comments. We agree that the specification is not very clear
in some parts and some clarification is certainly useful to better understand
the message we wanted to give.

Please see the answers and proposals for improved text below and let us
know whether these corrections and clarifications will address your concerns.

Best Regards,
Harri Hakala
Leena Mattila
Juha-Pekka Koskinen
Marco Stura
John Loughney
--------------------------------------------------------------------------
Ted Hardie:

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

Answer:

Agree. The section needs some re-structuring to give better guidance.
Proposal for the text (replaces old section 4.1):

4.1 Service-Specific Rating Input and Interoperability 

   The Diameter Credit-Control Application defines the framework for 
   credit control; it provides generic credit control mechanisms 
   supporting multiple service applications. The Credit Control 
   Application, therefore, does not define AVPs that could be used as 
   input in the rating process. Listing the possible services that could 
   use this Diameter application is seen as out of scope for this 
   generic mechanism as well. 
    
   Furthermore, it is not assumed that any arbitrary Diameter credit-
   control client will be able to communicate with any Diameter
   credit-control server, but the connections reflect the business
   relationships between the organizations hosting the Diameter peers.
   Therefore, it is reasonable to expect that there will exist a service
   level agreement between providers of the credit-control client and
   the credit-control server covering the charging, services offered,
   roaming agreements, agreed rating input, etc.

4.1.1 Specifying Rating Input AVPs

   There are two ways for providing rating input to the credit control 
   server, either by using AVPs or by including them in the Service-
   Parameter-Info AVP. The general principles for sending rating 
   parameters are:

   1a. The service SHOULD re-use existing AVPs, if the  service can use
       AVPs defined in existing Diameter applications (e.g. NASREQ for
       network access services). Re-use of existing AVPs is strongly
       recommendated in [DIAMBASE].

       For AVPs of type Enumerated the service may require a new value
       to be defined. Allocation of new AVP values is done as specified
       in [DIAMBASE], section 1.2.

   1b. New AVPs can be defined if the existing AVPs do not provide
       sufficient rating information. In such a case, the procedures 
       defined in [DIAMBASE] for creating new AVPs MUST be followed.

   1c. For services specific only to one vendor's implementation
       where no interoperatbility is deemed useful, a Vendor-Specific AVP
       code for Private use can be used. Where a Vendor-Specific AVP is
       implemented by more than one vendor, allocation of global AVPs
       are encouraged instead, refer to [DIAMBASE].

   2.  The Service-Parameter-Info AVP MAY be used as a container to pass
       legacy rating information in its original encoded form (e.g. 
       ASN.1 BER). This method can be used to avoid unnecessary data 
       format conversions from an existing format to an AVP format. In 
       that case the rating input is embedded in the Service-Parameter-Info 
       AVP as defined in section 8.42.

   New service applications SHOULD favor the use of explicitly defined
   AVPs as described in items 1a and 1b, to simplify interoperability. 

4.1.2 Application Support

   Since the Application-Id of the Diameter Credit Control Application does
   not uniquely identify the service being monitored, an additional mechanism
   is needed. The service application MUST be identified using the
   Service-Identifier AVP at command level. A server receiving a request for 
   a service application it does not support will reject the request as 
   defined in sub-section 4.1.4. The Service-Identifier AVP MUST be a unique 
   identifier for a given service as defined in section 8.28. 

   Thus, the combination of the Diameter Credit Control Application-Id and
   the Service-Identifier AVP in the Credit-Control-Request command uniquely
   defines the service within the context of the Diameter Credit Control, 
   and hence provides interoperability between Diameter credit control 
   clients and server. 

   Introducing new, non-rating related AVPs, that imply new credit control
   mechanisms, require definition of a new version of the Diameter 
   Credit Control Application and corresponding Application Identifier. 

4.1.3 Documentation of the Service-Specific Information
 
   The service specific rating input AVPs, the contents of the Service-
   Parameter-Info AVP or Service-Identifier AVP are not within the scope 
   of this document. To facilitate interoperability, it is RECOMMENDED 
   that the rating input and the values of the service identifiers are 
   coordinated via an informational RFC or other permanent and readily 
   available reference such as the specification of another cooperative 
   standardization body (e.g. 3GPP, OMA and 3GPP2) SHOULD be used. 
   However, private services may be deployed that are subject
   to agreements between providers of the credit control server and
   client, in this case vendor specific AVPs can be used. 
    
   This specification, together with the above service specific documents,
   governs the credit control message. The rule is that service specific
   documents only define what existing AVPs or new AVPs are used as
   input to the rating process (i.e. they do not define new 
   credit control applications), and thus need to be included in the 
   Credit-Control-Request command by a Diameter Credit Control Client 
   supporting a given service as *[AVP]. Should Service-Parameter-Info
   be used, then the service specific document MUST specify the exact
   content of this grouped AVP.

4.1.4 Handling of Unsupported/Incorrect Rating Input 

   Diameter credit control implementations are required to support the 
   Mandatory rating AVPs defined in service specific documentation of 
   the services they support according to the 'M' bit rules in [DIAMBASE]. 
    
   In case a rating input required for the rating process is incorrect 
   in the Credit control request, or the credit control server does not 
   support the requested service, the Credit control answer MUST contain 
   error code DIAMETER_RATING_FAILED. A CCR message with this error MUST 
   contain one or more Failed-AVP AVPs containing the missing and/or 
   unsupported AVPs that caused the failure. A Diameter credit control 
   client receiving error code DIAMETER_RATING_FAILED in answer to a 
   request MUST NOT send such similar requests in the future.

4.1.5 RADIUS Vendor-Specific Rating Attributes
    
   When service specific documents include RADIUS vendor specific 
   attributes that could be used as input in the rating process, the 
   rules described in [NASREQ] for formatting the Diameter AVP MUST be 
   followed. For example, the AVP code used is the vendor attribute type 
   code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID 
   MUST be set to the IANA Vendor identification value. The Diameter AVP 
   data field contains only the attribute value of the RADIUS attribute. 

----------------------------------------------------------------------

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? 

Answer:
      The client needs to support the RAR/RAA messages and needs to
      initiate a credit re-authorization by sending a CCR request
      upon reception of the RAR. This is explained in the third
      and subsequent paragraphs and it is visible in the client 
      state machine. This is the only requirement to the client, 
      and it is according to the base protocol.

      Concerning the voice minutes, this is handled by requesting
      credit authorization (or re-authorization) with the CCR request. 
      The server returns the time quota in the corresponding CCA
      message within the Granted-Service-Unit AVP, the time quota
      is monitored by the client. At any time the server may request
      credit re-authorization by issuing a RAR request.

      Performing tariff time changes with the server initiated 
      re-authorization is actually possible although cumbersome.
      Tariff changes typically occur at the same time for all the
      active sessions, therefore, the server would need to issue
      a RAR for all the active sessions at the same time. This
      abviously creates a huge storm of credit re-authorization
      that would potentially overload the system. In real networks,
      where million of users are active, this mechanism for tariff
      change is actually not gonna work. The DCCA defines a more
      effective tariff change mechanism where huge storm of
      credit re-authorization when tariff change occurs is avoided
      (see for instance sect. 5.1).

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

Answer:
We'd propose to modify the above paragraph as follows:

   To avoid a situation where several parallel, and typically also
   small, credit reservations must be made on the same account (i.e.
   credit fragmentation) and also to avoid unnecessary load on the credit 
   control server, it is possible to provide service units as a pool 
   that applies to multiple services or rating groups. 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. 
----------------------------------------------------------------------

Subject: RE: Diameter Credit Control - IESG Evaluation, Ted Hardie's comments
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 30 Jun 2004 16:15:03 +0300

Hi,

Answers & clarifications to your follow up comments.

Best regards,
DCC authors.

> >    Furthermore, it is not assumed that any arbitrary 
> Diameter credit-
> >    control client will be able to communicate with any Diameter
> >    credit-control server, but the connections reflect the business
> >    relationships between the organizations hosting the 
> Diameter peers.
> 
> The sentence above concerns me, as I believe it could be read
> over-broadly as "interoperability between clients and servers
> is not a goal".  Based on the text below, it seems that an
> arbitrary client should be able to talk to an arbitrary server,
> and that the parties should be able to exchange error messages
> when one references a service the other does not understand (I'm
> looking at 4.1.4, in particular).  Is there some way to make clearer
> that the business relationships that extend credit may affect
> the availability of specific AVPs and the interchanges between
> peers, without implying that the clients and servers may not
> be interoperable?

The intention of the above sentence was to indicate that it is not assumed
or preferred that one can plug in an arbitrary credit control client and
start to interchange credit control messages with any credit control
server, although it could be protocol wise possible. Meaning that an 
arbitrary credit control client can send credit control messages to 
any credit control server, but most probably these messages would be
rejected, since they carry unsupported services/AVPs. But it is true
that one can interpret that sentence in several ways. 

Would this be better:

    Furthermore, it is reasonable to expect that there will exist a service
    level agreement between providers of the credit-control client and
    the credit-control server covering the charging, services offered,
    roaming agreements, agreed rating input (i.e. AVPs), etc.

    Therefore, it is assumed that a Diameter credit control server will
    provide service only for Diameter credit-control clients which have
    agreed beforehand the content of credit control messages. Protocol wise, 
    it is naturally possible that any arbitrary Diameter credit-control
    client can interchange credit control messages with any Diameter 
    credit control server, but with a higher likelihood that unsupported 
    services/AVPs could be present in the credit-control message causing
    the server to reject the request with an appropriate result-code.

> >    1c. For services specific only to one vendor's implementation
> >        where no interoperatbility is deemed useful, a 
> Vendor-Specific AVP
> >
> 
> interoperatbility-->interoperability
> 
> I also would suggest removing "where no interoperability is deemed
> useful", as I believe "specific only to one vendor's implementation"
> covers the ground without raising the question of what level of 
> interoperability
> is meant.

OK

> >Answer:
> >       The client needs to support the RAR/RAA messages and needs to
> >       initiate a credit re-authorization by sending a CCR request
> >       upon reception of the RAR. This is explained in the third
> >       and subsequent paragraphs and it is visible in the client
> >       state machine. This is the only requirement to the client,
> >       and it is according to the base protocol.
> 
> I guess what is confusing me is the Server MAY here.  If a
> client does not react at all to RAR (possibly because the
> credit control application is attached to a data interface
> that is not active and/or cannot be activated by the
> network), I assume that Graceful Service Termination
> proceeds.  The question is, was the client's failure
> to respond a protocol error?  If so, is there any way for
> the client to negotiate with the server the use of RAR/RAA
> messages, so that it can decline their use in cases where
> keeping the data channel open would be onerous?

The client MUST support the server initiated re-authorization, the server
MAY use it or not. Therefore, the assumption is exactly what you are
pointing out i.e. the client MUST immediately respond with RAA followed
by CCR[Update].

Perhaps we could include the MUST keyword in the 3d paragraph as follow:

   If a credit re-authorization is not already ongoing (i.e. the credit 
   control session is in OPEN state), a credit control client that 
   receives such a RAR message with Session-Id equal to a currently 
   active credit control session MUST acknowledge the request by sending 
   the Re-Auth-Answer (RAA) message and MUST initiate the credit re-
   authorization towards the server by sending a Credit-Control-Request 
   message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. 

In case the data interface is not active and/or cannot be activated
by the network, it means that a transport connection failure will be
detected by the client e.g. upon expiration of the validity-timer
in case the GST is ongoing. The client will typically stop the GST
and disconnect the user (I think this is visible in sect. 5.5 9th
paragraph, here copied).

   If a communication failure occurs during the graceful service 
   termination procedure, the service element SHOULD always terminate 
   the ongoing service session.

> Ah, I see the section now; thanks for the pointer.  As an aside,
> 5.1 is pretty long, and sections like this might be less obvious
> to the reader as a result; you might consider giving 5.1.x
> subheadings to break it up a bit.

We will add subheadings 5.1.x

Subject: RE: Last Call: 'Diameter Credit-control Application' to Proposed Standard + IESG Evaluation, IANA comments
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 29 Jun 2004 16:58:41 +0300

Hello,

thank you for your comments regarding the IANA parts. Since we
received similar comments during IETF Last Call from IANA and during IESG
Evaluation from Thomas Narten we'd like to answer both reviews in one combined
mail in order to keep all the involved parties in the loop.

Please see the answers and proposals for improved text below and let us
know whether these corrections and clarifications will address your concerns.

Best Regards,
Harri Hakala
Leena Mattila
Juha-Pekka Koskinen
Marco Stura
John Loughney
===========================================================================

----Original Message-----
From: Michelle S. Cotton [mailto:[email-masked]]
Sent: 15. kesäkuuta 2004 20:37
To: [email-masked]; [email-masked]
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF);
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: Last Call: 'Diameter Credit-control Application' to
Proposed Standard

IESG:

The IANA has reviewed the following Internet-Draft which is 
in Last Call: <draft-ietf-aaa-diameter-cc-05.txt>, and has 
the following comments with regards to the publication of 
this document:

Section 12.1
The name of the application identifier to be assigned should be
included in this section.

Answer:
The draft will be updated as follows:

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

Additionally, the above suggested application id value 4 is mentioned also in sections
1.3 and 5.5. Should IANA allocate another value than the proposed 4 these
sections must be updated accordingly. Therefore we also will add IANA-notes
in those sections as follows:

1.3 Advertising application support  
     
   Diameter nodes conforming to this specification MUST advertise 
   support by including the value of XXX [IANA please fill in XXX 
   (suggested value 4 in section 12.1) and remove this note] in the
   Auth-Application-Id of the Capabilities-Exchange-Request and 
   Capabilities-Exchange-Answer command [DIAMBASE].  

5.5 Server-Initiated Credit Re-Authorization 

   The Diameter Credit Control Application supports server-initiated re-
   authorization. The credit control server MAY optionally initiate the 
   credit re-authorization by issuing a Re-Auth-Request (RAR) as defined 
   in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in 
   the RAR message is set to XXX [IANA please fill in XXX (suggested 
   value 4 in section 12.1) and remove this note] to indicate the Diameter 
   Credit Control Application and the Re-Auth-Request-Type is set to 
   AUTHORIZE_ONLY. 

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

Answer:
The draft will be updated as follows:

12.2 Command Codes  
        
   This specification uses the value XXX [IANA please fill in XXX (suggested 
   value 272) and remove this note] from the Command code namespace 
   defined in [DIAMBASE] for the Credit-Control Request (CCR) and Credit-
   Control-Answer (CCA) commands.   

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

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

Sections 12.5-12.18
We will create sub-registries for AVP Specific Values
Answer:
OK. These sections will also be clarified as suggested by Thomas Narten below.

Michelle Cotton
(on behalf of the IANA)

===========================================================================

Thomas Narten wrote:

> 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.
Answer:
The text will be modified as proposed above (see comments from IANA).
--------------------------------------------------------------------------

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

Answer:
When reviewing the draft the IANA indicated that they will use section 8 
as the guide when allocating the AVP code values. In section 8 there is a
summary table listing all new AVP codes defined in this specification 
including references to appropriate section. Thus, we assume that no 
additional summary table is required by the IANA.
--------------------------------------------------------------------------

> 12.4 Result-Code AVP Values ditto. 

ANSWER:
When reviewing the draft the IANA indicated that they will use section 9 as
the guide for assiging the Result-Code AVP values. Therefore we assume that
no additional summary table is required by the IANA. 
--------------------------------------------------------------------------

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

Answer:
We will update the specification according to the suggested text.
--------------------------------------------------------------------------

BTW, IANA seemed to have raised similar issues in mail on June 15. 
Answer:
Yes, and therefore we've combined the answer to keep the proposed updates
coordinated.
===========================================================================