Subject: [AAA-WG]: Issue: DCC typing issues

From: <[email-masked]>
Date: Mon, 26 Jan 2004 08:02:05 +0200

DCC typing issues
Submitter name: Pasi Eronen
Date first submitted: 26.1.2004
Reference: 
Document: cc-02
Comment type: T/E
Priority: 1
Section: various
Rationale/Explanation of issues: 

I have to admit that I haven't fully read and understood the
document (it's long and quite complicated...), but here are 
anyway some nits:

- 4.1: RFC3588 says that unrecognized AVPs with 'M' bit cause 
  DIAMETER_AVP_UNSUPPORTED error, not DIAMETER_RATING_FAILED.
  If the intent is to override RFC3588, please say so explicitly.

- 8.8: Cost-Unit is specified as UTF8String without any guidance
  to its contents. Will this lead to interoperability (or other) 
  problems if e.g. one implementation uses "kilobyte" and 
  another "kB"? (hmm, is this 1000 or 1024 bytes... :-)

- 8.17: Should specify whether IPv4/IPv6 addresses are just
  octets or textual representation (and for IPv6, which 
  textual representation).

- 8.24: Service-Parameter-Type should probably specify how these
  values are allocated, or who is responsible for selecting them 
  (and ensuring that they are unique within some context).

- 8.25: Service-Parameter-Value should be OctetString rather than
  UTF8String if it's going to be used for BER-encoded ASN.1.

- 8.36: "The CC-Service-Specific-Units AVP (AVP Code 417) is of type 
  OctetString, and specifies the number of service specific units 
  (e.g. number of events, points) given in a selected service."

  IMHO "a number" would hint that OctetString is not probably the best
  choice here (and is e.g. 1 packet encoded as "0x01", "0x31" or
  perhaps "0x00 0x00 0x00 0x01"?). However, I'm not sure if this needs
  to be an integer or floating point (can we assume that
  service-specific units are scaled so that floats are not necessary?)

  (8.16 also says that "...the value of the CC-Service-Specific-Units
  AVP is set to FFFFFFFF to indicate free-of-charge.", which is 
  a bit strange if it's an OctetString.)

- A.7 "..with Unit-Type set to CREDIT_TYPE_SERVICE_SPECIFIC and
  Unit-Value set to the number of points..."; the spec doesn't 
  define a Unit-Type AVP (anymore?)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 26 Jan 2004 09:50:41 +0200

Assigned issue 14.

thanks,
John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext 
> Sent: 26 January, 2004 08:02
> To: [email-masked]
> Subject: [AAA-WG]: Issue: DCC typing issues
> 
> 
> DCC typing issues

---

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Tue, 27 Jan 2004 15:40:14 +0100

Hi Pasi,

Thank you very much for reviewing the draft.
Inline some answers to your comments.

Regards.......Harri

>   (and ensuring that they are unique within some context).
Yes, that is intention. The previous AVP, 8.23 Service-Parameter-Info AVP,
defines:
....The Service-Parameter-Type AVP defines the service parameter 
type and the Service-Parameter-Value AVP contains the parameter value. 
The actual contents of these AVPs are not within the scope of this 
document and SHOULD be defined in another Diameter application, 
standards written by other standardization bodies, or service specific 
documentation.....

Is this enough, or do you think that we need more specific statements
how to values of Service-Parameter-Type should be specified?

>   UTF8String if it's going to be used for BER-encoded ASN.1.
OK.
DCC issue 11 should fix this: 
http://danforsberg.info:8080/draft-ietf-aaa-diameter-cc/issue11
 
>   a bit strange if it's an OctetString.)
OK, the same DCC issue should fix this as well.

>   define a Unit-Type AVP (anymore?)
OK.
Should be:
...with CC-Service-Specific-Units containing the number of points...