RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (1)

RFC 4006, "Diameter Credit-Control Application", August 2005

Source of RFC: aaa (ops)

Errata ID: 3329

Status: Held for Document Update
Type: Editorial

Reported By: Kiran Jadhav
Date Reported: 2012-08-23
Held for Document Update by: Benoit Claise

Section 5.6.2 says:

" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

It should say:

" Note that the credit-control server may already have initiated the
above-described process for the first interrogation. However, the
user's account might be empty when this first interrogation is
performed. In this case, the subscriber can be offered a chance to
replenish the account and continue the service. The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit AVP. It immediately starts the graceful
service termination without sending any message to the server. An
example of this case is illustrated in Appendix A."

Notes:

In the sentence "The credit-control
client receives a Credit-Control-Answer or service specific
authorization answer with the Final-Unit-Indication and Validity-Time
AVPs but no Granted-Service-Unit." it is important that we add the letters "AVP" after Granted-Service-Units as it is not clear whether the sentence refers to "Not sending Granted-Service-Unit AVP at all" or "sending GSU=0 (Granted-Service-Unit AVP with value 0".

Different OCS vendors interpret the sentence above in a different way, some do not send the Granted-Service-Unit AVP at all, while some others send the Granted_Service-Unit=0. And this causes problem in the call scenario where FUI+Redirect is sent together with GSU=0. This causes the call to enter a loop and terminate with an error.

Status: Rejected (2)

RFC 4006, "Diameter Credit-Control Application", August 2005

Source of RFC: aaa (ops)

Errata ID: 4892

Status: Rejected
Type: Technical

Reported By: dengzhenjie
Date Reported: 2016-12-19
Rejected by: Benoit Claise
Date Rejected: 2017-01-03

Section 7 says:

   | PendingU | CC update answer received     | Terminate   | Idle     |
   |          | with result code equal to     | end user's  |          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | service     |          |

It should say:

   | PendingU | CC update answer received     | Grant     |   Idle   |
   |          | with result code equal to     | service to|          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | end user  |          |

Notes:

Note that in Section 9, It said:
when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011, it indicates that the credit-control server determines that the service can be granted to the end user but that no further credit-control is needed for the service (e.g., service is free of charge).
--VERIFIER NOTES--
This is not an erratum against 4006 but a proposed change in the draft RFC4006bis (https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00).

The original text quoted below is not in the RFC4006 but in the draft.

Hence this should be discussed on the dime mailing list.

Errata ID: 4890

Status: Rejected
Type: Editorial

Reported By: dengzhenjie
Date Reported: 2016-12-16
Rejected by: Benoit Claise
Date Rejected: 2017-01-03

Section 7 says:

   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |

It should say:

   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |

Notes:

the state machine in the table of ''client, event based'' is duplicated
--VERIFIER NOTES--
Yes, this is an editorial mistake. but this not related to the RFC4006 but to the current version of the draft https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/, version 00 as of today.

Report New Errata



Search RFCs
Advanced Search
×