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

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 18 Sep 2008 22:16:23 -0500

Hannes,

I understood your concern on the modification of the ABNF of existing
Diameter Credit control commands e.g. CCR/CCA. However, those changes
are made originally by 3GPP 29.212 Gx interface. The ITU-T Q.3303.3 just
reuses what are defined by Gx interface in order to avoid the
interoperability problem with other SDOs (e.g. including WiMAX and 3GPP2
since both them are based on 3GPP Gx). 

Regarding the indications of "M"/"P" bits, all them are copied from
other specs. I will try to fix it for this spec if possible. Same to the
NASREQ issue.

Thanks for the review and comments, although they are more related to
the ITU-T spec instead of this IETF I-D.

Rgs,
Dong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Thursday, August 28, 2008 9:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01

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
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime