RFC Errata
Found 19 records.
Status: Verified (8)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
Source of RFC: dime (ops)
Errata ID: 3805
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-12-09
Section 3 says:
Message Length
The Message Length field is three octets and indicates the length
of the Diameter message including the header fields and the padded
AVPs. Thus, the Message Length field is always a multiple of 4.
It should say:
Message Length
The Message Length field is three octets and indicates the number
of octets of the Diameter message, including the header fields and
the padded AVPs. Thus, the Message Length field is always a
multiple of 4 octets.
Notes:
the actual text does not indicate the unit of length unit, which may lead to confusion and IOT issues, especially if someone considers bits instead of bytes.
Errata ID: 3806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel
Date Reported: 2013-11-18
Verifier Name: Benoit Claise
Date Verified: 2013-11-19
Section 2.7 says:
Server Identifier
The identity of one or more servers to which the message is to be
routed. This identity MUST also be present in the Host Identity
field of the peer table (Section 2.6). When the Local Action is
set to RELAY or PROXY, this field contains the identity of the
server(s) to which the message MUST be routed. When the Local
Action field is set to REDIRECT, this field contains the identity
of one or more servers to which the message MUST be redirected.
It should say:
Peer Identifier
The identity of one or more peers to which the message is to be
routed. This identity MUST also be present in the Host Identity
field of the peer table (Section 2.6). When the Local Action is
set to RELAY or PROXY, this field contains the identity of the
peer(s) to which the message MUST be routed. When the Local
Action field is set to REDIRECT, this field contains the identity
of one or more peers to which the message MUST be redirected.
Notes:
The host identified in a Routing Table entry is not necessarily a "server". It can also be a Relay, a redirect or a proxy agent. Using "peer" instead of "server" is more appropriate.
Errata ID: 3942
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Benoit Claise
Date Reported: 2014-04-01
Verifier Name: Benoit Claise
Date Verified: 2014-04-01
Section 8 says:
When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization- Lifetime AVP to the answer message.
It should say:
When a Diameter server authorizes a user to implement network resources for a finite amount of time, and it is willing to extend the authorization via a future request, it MUST add the Authorization-Lifetime AVP to the answer message.
Notes:
Authorization-Lifetime was mispelled
Errata ID: 3997
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Korhonen
Date Reported: 2014-05-24
Verifier Name: Benoit Claise
Date Verified: 2014-06-04
Throughout the document, when it says:
Section 2.1.
The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer
Security (DTLS) [RFC6347], a Diameter node that initiates a
connection prior to any message exchanges MUST run on port 5658. It
is assumed that TLS is run on top of TCP when it is used, and DTLS is
run on top of SCTP when it is used.
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
connections on port 5658 (i.e., the peer complies only with RFC
3588), then the initiator MAY revert to using TCP or SCTP on port
3868. Note that this scheme is kept only for the purpose of backward
compatibility and that there are inherent security vulnerabilities
when the initial CER/CEA messages are sent unprotected (see
Section 5.6).
Diameter clients MUST support either TCP or SCTP; agents and servers
SHOULD support both.
A Diameter node MAY initiate connections from a source port other
than the one that it declares it accepts incoming connections on, and
it MUST always be prepared to receive connections on port 3868 for
TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections.
When DNS-based peer discovery (Section 5.2) is used, the port numbers
received from SRV records take precedence over the default ports
(3868 and 5658).
Section 4.3.1.
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
It should say:
Section 2.1.
The base Diameter protocol is run on port 3868 for both TCP [RFC0793]
and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer
Security (DTLS) [RFC6347], a Diameter node that initiates a
connection prior to any message exchanges MUST run on port 5868. It
is assumed that TLS is run on top of TCP when it is used, and DTLS is
run on top of SCTP when it is used.
If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
connections on port 5868 (i.e., the peer complies only with RFC
3588), then the initiator MAY revert to using TCP or SCTP on port
3868. Note that this scheme is kept only for the purpose of backward
compatibility and that there are inherent security vulnerabilities
when the initial CER/CEA messages are sent unprotected (see
Section 5.6).
Diameter clients MUST support either TCP or SCTP; agents and servers
SHOULD support both.
A Diameter node MAY initiate connections from a source port other
than the one that it declares it accepts incoming connections on, and
it MUST always be prepared to receive connections on port 3868 for
TCP or SCTP and port 5868 for TLS/TCP and DTLS/SCTP connections.
When DNS-based peer discovery (Section 5.2) is used, the port numbers
received from SRV records take precedence over the default ports
(3868 and 5868).
Section 4.3.1.
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5868 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
Notes:
RFC 6733 defined the Diameter port number for secure transport in IANA considerations Section 11.4. to be 5868. This is also in IANA port numbers registry "Service Name and Transport Protocol Port Number Registry". However, the RFC 6733 body text uses different port number in Sections 2.1. and 4.3.1. for secure transports. Since the IANA registry already contains the port number 5868 instead of the body text used value 5658, the values in Sections 2.1. and 4.3.1. should be 5868 instead of 5658.
Errata ID: 4615
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2016-02-05
Verifier Name: Benoit Claise
Date Verified: 2016-05-17
Section 7.1.5 says:
DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not
recognized or supported and was marked with the 'M' (Mandatory)
bit. A Diameter message with this error MUST contain one or more
Failed-AVP AVPs containing the AVPs that caused the failure.
It should say:
DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not
recognized or supported and was marked with the 'M' (Mandatory)
bit. A Diameter message with this error MUST contain one
Failed-AVP AVP containing the AVPs that caused the failure.
Notes:
The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure.
Errata ID: 4808
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Zbigniew Rapnicki
Date Reported: 2016-09-22
Verifier Name: Benoit Claise
Date Verified: 2017-01-04
Section 1.1.3 says:
This document obsoletes RFC 3588 but is fully backward compatible with that document.
It should say:
This document obsoletes RFC 3588.
Notes:
When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message.
Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message.
Similar case is for Vendor-Specific-Application-Id AVP definition.
Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP:
rfc3588:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }
rfc6733:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
{ Vendor-Id }
[ Auth-Application-Id ]
[ Acct-Application-Id ]
How this facts applies to the sentence about fully backward compatibility in the section 1.1.3?
Errata ID: 4887
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikhail Zaytsev
Date Reported: 2016-12-13
Verifier Name: Benoit Claise
Date Verified: 2017-01-03
Section 6.2 says:
When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter
application defining the command:
o The same Hop-by-Hop Identifier in the request is used in the
answer.
o The local host's identity is encoded in the Origin-Host AVP.
o The Destination-Host and Destination-Realm AVPs MUST NOT be
present in the answer message.
It should say:
When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter
application defining the command:
o The same Hop-by-Hop Identifier in the request is used in the
answer.
o The local host's identity is encoded in the Origin-Host AVP.
o The local realm's identity is encoded in the Origin-Realm AVP.
o The Destination-Host and Destination-Realm AVPs MUST NOT be
present in the answer message.
Notes:
Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions.
Errata ID: 4803
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Holger Freyther
Date Reported: 2016-09-13
Verifier Name: Benoit Claise
Date Verified: 2017-07-27
Section 3.2 says:
In section 3.2
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
In section 3.4
header = "<" "AVP-Header:" avpcode [vendor] ">"
It should say:
In section 3.2
header = "<Diameter Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
In section 3.4
header = "<" "AVP Header:" avpcode [vendor] ">"
Notes:
Background:
There was an initial errata (kept for background information at the bottom of this note). After some discussion with the dime WG, this errata was modified.
This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.
For commands, the header is defined as follow:
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
whereas "<Diameter Header:" is used when defining commands.
Same for Grouped AVP. It is defined as follow:
header = "<" "AVP-Header:" avpcode [vendor] ">"
whereas "<AVP Header:" is used when defining Grouped AVPs.
Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.
--> In section 3.2. Command Code Format Specification
OLD:
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
NEW:
header = "<Diameter Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
--> And in section 4.4
OLD:
header = "<" "AVP-Header:" avpcode [vendor] ">"
NEW:
header = "<" "AVP Header:" avpcode [vendor] ">"
=============================================================================
This initial errata is below:
Original text:
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]
Corrected text:
<Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF.
header = "<Diameter-Header:" command-id
[r-bit] [p-bit] [e-bit] [application-id]">"
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
command-def = "<" command-name ">" "::=" diameter-message
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
Status: Reported (2)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
Source of RFC: dime (ops)
Errata ID: 6171
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Valentin Micic
Date Reported: 2020-05-13
Section 6.1.3 says:
A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if the server finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
It should say:
A relay or proxy agent MUST check for forwarding loops when receiving requests. A loop is detected if a relay or proxy agent finds its own identity in a Route-Record AVP. When such an event occurs, the agent MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
Notes:
The term "server" used to identify party which is to detect its own identity as a part of Route-Record AVP is semantically too close to the term Diameter Server. If "relay or proxy agent MUST check", the question is what would be the consequence of such action if the (Diameter) "server" is to do the "detecting"?
Errata ID: 6832
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kshitij Dutt
Date Reported: 2022-02-03
Section 7.1.4 says:
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable to
commit it to stable storage due to a temporary lack of space.
It should say:
DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the request but was unable to
commit it to stable storage due to a temporary lack of space.
Notes:
Original text signifies accounting application explicitly. It can be any of Accounting or Authorization.
Status: Held for Document Update (3)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
Source of RFC: dime (ops)
Errata ID: 5084
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Priyatosh Mandal
Date Reported: 2017-08-11
Held for Document Update by: Benoit Claise
Date Held: 2017-09-17
Section 8.16 says:
By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0.
It should say:
By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions.
Notes:
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum
value it can have is 4294967295. If the system restarts many times and the value of
Origin-State-Id reaches the value which is same as its maximum value 4294967295.
Then what will happen for the next restart. At the next restart the value of Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after 4294967295-th
restart with respect to Origin-State-Id.
Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart
its value will be 0. For a special case for transition of value of Origin-State-Id from
4294967295 to 0, the peer should clear its session.
Errata ID: 4210
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2014-12-25
Held for Document Update by: Benoit Claise
Date Held: 2015-01-07
Section 5.4.3 says:
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST include this AVP in the Disconnect-Peer-Request
message to inform the peer of the reason for its intention to shut
down the transport connection. The following values are supported:
REBOOTING 0
A scheduled reboot is imminent. A receiver of a DPR with
above result code MAY attempt reconnection.
BUSY 1
The peer’s internal resources are constrained, and it has
determined that the transport connection needs to be closed.
A receiver of a DPR with above result code SHOULD NOT attempt
reconnection.
DO_NOT_WANT_TO_TALK_TO_YOU 2
The peer has determined that it does not see a need for the
transport connection to exist, since it does not expect any
messages to be exchanged in the near future. A receiver of a
DPR with above result code SHOULD NOT attempt reconnection.
It should say:
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST include this AVP in the Disconnect-Peer-Request
message to inform the peer of the reason for its intention to shut
down the transport connection. The following values are supported:
REBOOTING 0
A scheduled reboot is imminent. A receiver of a DPR with
above result code MAY attempt reconnection.
BUSY 1
The internal resources are constrained, and it has
determined that the transport connection needs to be closed.
A receiver of a DPR with above result code SHOULD NOT attempt
reconnection.
DO_NOT_WANT_TO_TALK_TO_YOU 2
The node has determined that it does not see a need for the
transport connection to exist, since it does not expect any
messages to be exchanged in the near future. A receiver of a
DPR with above result code SHOULD NOT attempt reconnection.
Notes:
A peer can either be a sender or receiver, depending on the contexst.
However in same section describing usage for the same AVP (description for cause), the 1st appearance represents the role of receiver, the 2nd and 3rd appearances has changed to the role of senders, it's confusing literally.
Errata ID: 4234
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2015-01-16
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-01-16
Section 5.4 says:
In the last sentence of first paragraph odf the section 5.4, it is said: When a Diameter node disconnects one of its transport connections, its peer cannot know the reason for the disconnect and will most likely assume that a connectivity problem occurred or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1. In the event that the disconnect was a result of either a shortage of internal resources or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect-Peer- Request message.
It should say:
the sentence should be: When a Diameter node disconnects one of its transport connections, its peer cannot know the reason for the disconnect and will most likely assume that a connectivity problem occurred or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1. In the event that the disconnect was a result of either a shortage of internal resources or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnect-Cause AVP contains the reason the Diameter node issued the Disconnect-Peer- Request message.
Notes:
The correct name of the AVP is "Disconnect-Cause AVP" and not "Disconnection-Reason AVP" that does not exist.
Status: Rejected (6)
RFC 6733, "Diameter Base Protocol", October 2012
Note: This RFC has been updated by RFC 7075, RFC 8553
Source of RFC: dime (ops)
Errata ID: 4209
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hans Liu
Date Reported: 2014-12-25
Rejected by: Benoit Claise
Date Rejected: 2015-01-23
Section 5.4.3 says:
BUSY 1
The peer’s internal resources are constrained, and it has
determined that the transport connection needs to be closed.
A receiver of a DPR with above result code SHOULD NOT attempt
reconnection.
It should say:
BUSY 1
The peer’s internal resources are constrained, and it has
determined that the transport connection needs to be closed.
A receiver of a DPR with above result code SHOULD either
connect to an alternate node, or attempt reconnection
after a time period.
Notes:
In most implementations, the Diameter node will continue to serve its peer after the resources recover and expect reconnection. If the Diameter node won't like reconnection from peer, DO_NOT_WANT_TO_TALK_TO_YOU can be used instead of BUSY.
--VERIFIER NOTES--
The text describing the "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" cases is consistent with the text found in the introduction of the section 5.4.
"In the event that the
disconnect was a result of either a shortage of internal resources or
simply that the node in question has no intentions of forwarding any
Diameter messages to the peer in the foreseeable future, a periodic
connection request would not be welcomed. The Disconnection-Reason
AVP contains the reason the Diameter node issued the Disconnect-Peer-
Request message.
The Disconnect-Peer-Request message is used by a Diameter node to
inform its peer of its intent to disconnect the transport layer and
that the peer shouldn't reconnect unless it has a valid reason to do
so (e.g., message to be forwarded). "
So the main purpose for sending a DPR with the causes "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" is actually to avoid the periodic reconnection attempts governed by the Tc timer.
These exceptions are mentioned in the section 2.1:
"When no transport connection exists with a peer, an attempt to
connect SHOULD be made periodically. This behavior is handled via
the Tc timer (see Section 12 for details), whose recommended value is
30 seconds. There are certain exceptions to this rule, such as when
a peer has terminated the transport connection stating that it does
not wish to communicate."
Now, it is true that there is no clear guideline on how to behave when receiving the cause "BUSY" and this explains why some implementations in the field still attempt to re-open the connection, as after a normal transport failure detection. But it does not mean that the text in the RFC6733 is wrong.
Finally, if it is an attempt to clarify/modify the behavior of the peer receiving DPR with the "BUSY" cause, I don't think that using errata would be the most appropriate way.
Errata ID: 4462
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-01
Rejected by: Stephen Farrell
Date Rejected: 2015-09-11
Section 6.1.4 6.1.6 says:
6.1.4. Processing Local Requests
A request is known to be for local consumption when one of the
following conditions occurs:
o The Destination-Host AVP contains the local host's identity;
o The Destination-Host AVP is not present, the Destination-Realm AVP
contains a realm the server is configured to process locally, and
the Diameter application is locally supported; or
o Both the Destination-Host and the Destination-Realm are not
present.
6.1.6. Request Routing
Diameter request message routing is done via realms and Application
Ids. A Diameter message that may be forwarded by Diameter agents
(proxies, redirect agents, or relay agents) MUST include the target
realm in the Destination-Realm AVP. Request routing SHOULD rely on
the Destination-Realm AVP and the Application Id present in the
request message header to aid in the routing decision. The realm MAY
be retrieved from the User-Name AVP, which is in the form of a
Network Access Identifier (NAI). The realm portion of the NAI is
inserted in the Destination-Realm AVP.
Diameter agents MAY have a list of locally supported realms and
applications, and they MAY have a list of externally supported realms
and applications. When a request is received that includes a realm
and/or application that is not locally supported, the message is
routed to the peer configured in the routing table (see Section 2.7).
Realm names and Application Ids are the minimum supported routing
criteria, additional information may be needed to support redirect
semantics.
It should say:
6.1.6 -
When a request is received that includes a realm
and/or application that is not locally supported, the message is
routed to the peer configured
conflicts with 6.1.4 -
The Destination-Host AVP is not present, the Destination-Realm AVP
contains a realm the server is configured to process locally, and
the Diameter application is locally supported
Notes:
please guide if 6.1.4 Local processing - "hostname not present" needs to be amended by "not present in host peer routing table". otherwise it conflicts with 6.1.6.
--VERIFIER NOTES--
DIME WG chairs report this is erroneous.
Errata ID: 4463
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-01
Rejected by: Stephen Farrell
Date Rejected: 2015-09-11
Section 6.1.7 says:
6.1.7. Predictive Loop Avoidance
It should say:
6.1.7. Predictive Loop Detection and termination
Notes:
one full cycle of loop execution happens before route record is identified and loop being realized. A scenario example where two Diameter Agents are configured to do precedence based routing to two different hss and where as if hss otherwise does loadshare using 4 different links each in such cases loop can even be reach stage 2 before being realized therefore it doesn't qualify the avoidance or prevention rather detection and termination. thanks.
--VERIFIER NOTES--
There is no need or benefit from this change.
Errata ID: 4473
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Keshab Upadhya
Date Reported: 2015-09-14
Rejected by: Stephen Farrell
Date Rejected: 2015-10-07
Section 6.1.4 says:
6.1.4. Processing Local Requests The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or
It should say:
6.1.4. Processing Local Requests The Destination-Host AVP is not present in peer routing table, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or
Notes:
6.1.4 - Processing Local Requests
The Destination-Host AVP is not present, the Destination-Realm AVP
contains a realm the server is configured to process locally, and
the Diameter application is locally supported
6.1.6 - Request Routing
When a request is received that includes a realm
and/or application that is not locally supported, the message is
routed to the peer configured
As given above 6.1.4 second rule contradicts with 6.1.6 para 2.
--VERIFIER NOTES--
DIME chairs recommended reject
Errata ID: 4931
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Luiz Solis
Date Reported: 2017-02-09
Rejected by: Benoit Claise
Date Rejected: 2017-02-10
Section 6.1.9 says:
Figure 6.1 provides an example of message routing using the procedures
listed in these sections.
(Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
(Origin-Realm=example.net) (Origin-Realm=example.net)
(Destination-Realm=example.com) (Destination-Realm=example.com)
(Route-Record=nas.example.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com)
Figure 6: Routing of Diameter messages
It should say:
Figure 6.1 provides an example of message routing using the procedures
listed in these sections.
(Origin-Host=nas.example.net) (Origin-Host=nas.example.net)
(Origin-Realm=example.net) (Origin-Realm=example.net)
(Destination-Realm=example.com) (Destination-Realm=example.com)
(Route-Record=nas.example.net)* (Route-Record=nas.example.net)
(Route-Record=drl.example.net)*
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com)
*Optional.
Figure 6: Routing of Diameter messages
Notes:
The relay or proxy agent should append their own identity optionally in an additional Route-Record AVP (282).
--VERIFIER NOTES--
The Route-Record is primarily used to detect loops:
6.1.3. Receiving Requests
A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if the server finds its own identity in
a Route-Record AVP. When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
How to populate the Route-Record is described twice:
Section 2.9:
As noted in Section 6.1.9, a relay or proxy agent MUST append a
Route-Record AVP to all requests forwarded. The AVP contains the
identity of the peer from which the request was received.
6.7.1. Route-Record AVP
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in
the Origin-Host of the Capabilities Exchange message.
Therefore, it's "rather clear" that a relay and a proxy MUST append a Route-Record to all requests forwarded with the identity of the peer from which the request was received
I think that Luis was maybe misled by the following text:
6.1.3. Receiving Requests
A relay or proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if the server finds its own identity in
a Route-Record AVP. When such an event occurs, the agent MUST answer
with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.
in which "find its own identity" might have been confusing out of context. But sections 2.9 and 6.7.1 should have clarified this misunderstanding.
Whatever the reason for the proposed errata, it can be safely rejected.
Errata ID: 6833
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kshitij Dutt
Date Reported: 2022-02-03
Rejected by: Rob Wilton
Date Rejected: 2023-10-02
Section 2.4 says:
The following Application Id values are defined:
Diameter common message 0
Diameter base accounting 3
Relay 0xffffffff
It should say:
The following Application Id values are defined:
Diameter common message 0
Diameter base accounting 3
Relay 0xffffff
Notes:
I presume relay application ID should be 0xffffff decimal equivalent of which is 16777215.
Instead 0xffffffff decimal translates to 4294967295.
This is assumption.
--VERIFIER NOTES--
The Application-ID field in the Diameter header is 32 bits long, hence the exist Application Id for "Relay" is correct.