Subject: [AAA-WG]: Issue: DCC Format and coordination of the Service-Identifier

From: <[email-masked]>
Date: Wed, 10 Dec 2003 15:58:31 +0200

DCC Format and coordination of the Service-Identifier
Submitter name: Marco Stura
Submitter email address: [email-masked]
Date first submitted: 10.11.2003
Reference: 
Document: Diameter CCA-01
Comment type: T
Priority: 2
Section: 
Rationale/Explanation of issue:

We introduced the Service-Identifier AVP for multiple services in a single credit control session in the draf-01. Lately we also lifted the Service-Identifier AVP at command level
to enable identification of a given service for credit-control sessions as well.
We still need to define the format of the service identifier and add some coordination
considerations to facilitate interoperability.

Proposed changed:

Section 8.40, Service-Identifier AVP
Change FROM
The Service-Identifier AVP is of type UTF8String (AVP Code 439) and contains a unique identifier of a given service. This is an identifier allocated by the service provider and MUST uniquely identify a given service (e.g. Service [email-masked]). 
A usage example of this AVP is illustrated in Appendix A (Flow X). 

TO
The Service-Identifier AVP is of type UTF8String (AVP Code 439) and
contains a unique identifier of a service. This is an identifier
allocated by the service provider, by the service element manufacturer 
or by a standardization body and MUST uniquely identify a given service. 
The format of the service identifier is: "service-identifier" "@" "domain".

service-identifier = Token
                     The Token is an arbitrary string of characters and
                     digits.

domain = represents the entity that allocated the service-identifier.
         It can be ietf.org, 3gpp.org etc. if the identifier is 
         allocated by a standardization body, or it can be the FQDN
         of the service provider (e.g. provider.com) or of the vendor
         (e.g. vendor.com) if the identifier is allocated by a private
         entity.

Services that are for private use only, i.e. to one provider's own use, where 
no interoperability is deemed useful may define private identifiers without 
need of coordination. However, when interoperability is wanted, coordination 
of the identifiers via e.g. publication of informational RFC is RECOMMENDED to 
make Service-Identifier globally available.

A usage example of this AVP for multiple services in one user session is 
illustrated in Appendix A (Flow X).