Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 28 Aug 2008 15:52:39 +0200

I reviewed draft-sun-dime-itu-t-rw-01 the normative reference:

   [Q.3303.3]
              ITU-T Recommendation Q.3303.3, "Resource control protocol
              no. 3 (rcp3): Protocol at the Rw interface between the
              Policy Decision Physical Entity (PD-PE) and the Policy
              Enforcement Physical Entity (PE-PE): Diameter", 2008.

I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. 

HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. 

* CCR Command 

The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. 

* CCA Command

The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. 

* RAA Command

The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. 

* ASR Command

The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. 

* ASA Command 

The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. 

The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. 

Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. 

Table 2 is missing indications about the M bit usage. 
Table 3 is missing indications about the P bit usage. 
Table 4 is missing indications about the P bit usage. 

A minor issue: 

The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified.
Furthermore the text refers to NASREQ and the specification does not use NASREQ. 

Ciao
Hannes
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime