RFC Errata
Found 3 records.
Status: Held for Document Update (1)
RFC 4006, "Diameter Credit-Control Application", August 2005
Note: This RFC has been obsoleted by RFC 8506
Source of RFC: aaa (ops)
Errata ID: 3329
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Note: This RFC has been obsoleted by RFC 8506
Source of RFC: aaa (ops)
Errata ID: 4892
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.