RE: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt inrelationship to DCC (RFC4006)

["Asveren, Tolga" <tasveren at sonusnet.com>]

Mats,

AFAICR, in the text you quoted, first and second paragraph are referring to different changes. I think the second one is there because the failure category for certain error cases has changed in the bis.

You should be able to use E-bit for error codes in permanent failures category (in addition to what was already allowed in RFC3588).

    Thanks,
    Tolga

________________________________________
From: Mats Jörsmo (KA/EAB) [mailto:mats.jorsmo at ericsson.com] 
Sent: Monday, April 30, 2007 10:50 AM
To: dime at ietf.org
Subject: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt inrelationship to DCC (RFC4006)

Hi, 
Would appreciate some advice for a newbie in this area regarding chapter 7.1.5 (draft-ietf-dime-rfc3588bis-03.tx) 
http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-03#page-94 
.....'In error conditions where it is not possible or efficient to compose application specific answer grammar 
then answer messages with E-bit set and complying to the grammar described in 7.2 MAY also be used 
for  permanent errors. 
To provide backward compatibility with existing implementations that follow [RFC3588], 
some of the error values that have previously been used in this category by [RFC3588] will not be re-used.  
Therefore the error values enumerated here maybe non-sequential.' 

Does this mean that using the E-bit is applicable only for future error-codes to come or also for existing ones? 

Reason for asking is we would like to avoid the dummy values in the following scenario and instead use E-bit described in chapter 7.2 (draft-ietf-dime-rfc3588bis-03.tx)
If a CCR is received in the DCC server where one or several of the mandatory AVPs Auth-Application-Id, CC-Request-Type and CC-Request-Number are missing; 
In the CCA, Auth-Application-Id, CC-Request-Type and CC-Request-Number are filled with 'dummyvalues' and the the Failed-AVP AVP is included and filled with Auth-Application-Id, CC-Request-Type and CC-Request-Number where these AVPs are set to 'zero'
Example: 
Credit-Control-Answer 
        Session-Id = 123
        Result-Code = 5005
        Origin-Host = hostname
        Origin-Realm = realm
        Auth-Application-Id = 4 // Dummyvalue, we're only serving DCC
        CC-Request-Type = 4     // Dummyvalue, TERMINATION_REQUEST
        CC-Request-Number = 0   // Dummyvalue, 
        Failed-AVP { 
                Auth-Application-Id = 0 // Zero
                CC-Request-Type = 0     // Zero, violates AVP definition of CC-Request-Type
                CC-Request-Number = 0   // Zero 

Regards, 
///Mats J 



_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime