RFC 6733, "Diameter Base Protocol", October 2012Source of RFC: dime (ops)
Errata ID: 4462
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
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.
DIME WG chairs report this is erroneous.