Subject: [Dime] [Technical Errata Reported] RFC6733 (4462)

From: RFC Errata System <[email-masked]>
Date: Tue, 1 Sep 2015 18:09:23 -0700 (PDT)

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462

--------------------------------------
Type: Technical
Reported by: Keshab Upadhya <[email-masked]>

Section: 6.1.4 6.1.6

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: "Keshab Upadhya" <[email-masked]>
Date: Thu, 10 Sep 2015 11:25:53 +0800

Hi All,

Good day!

Could you please help on below request raised as conflict in RFC-6733?

Kindly consider this as an urgent request.

Thank you,

Regards,
Keshab.

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: Wednesday, September 2, 2015 9:09 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Technical Errata Reported] RFC6733 (4462)

The following errata report has been submitted for RFC6733, "Diameter Base
Protocol".

Section: 6.1.4 6.1.6

Original Text
-------------

6.1.6.  Request Routing

Corrected Text
--------------
6.1.6 -

conflicts with 6.1.4 -

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary.

---

From: <[email-masked]>
Date: Thu, 10 Sep 2015 15:14:41 +0000

Hi Keshab,

I'm not totally sure to understand your concern. 
The purpose of the section 6.1.4 is to give the conditions for processing locally a request (i.e. how to know that the receiving entity is the one that needs to answer to the request?) and nothing else.
The case you are referring to is covered in the section 6.1.6 and should not be part of section 6.1.4.

To make a long story short... 

if the Destination-Host is present, 
- if the identity is equal to the local host's identity --> process locally (section 6.1.4)
- if the identity is not equal to the local host's identity, check the peer table.
---- If it is the peer table, forward the request to the peer (sect 6.1.5)
---- if not, route the request based on Realm/application (section 6.1.6)

Let me know if it is OK for you.

Lionel

-----Message d'origine-----
De : Keshab Upadhya [mailto:[email-masked]] 
Envoyé : jeudi 10 septembre 2015 05:26
À : 'RFC Errata System'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : RE: [Technical Errata Reported] RFC6733 (4462)

Hi All,

Good day!

Thank you,

Regards,
Keshab.

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]]
Sent: Wednesday, September 2, 2015 9:09 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Technical Errata Reported] RFC6733 (4462)

The following errata report has been submitted for RFC6733, "Diameter Base Protocol".

Section: 6.1.4 6.1.6

Original Text
-------------

6.1.6.  Request Routing

Corrected Text
--------------
6.1.6 -

conflicts with 6.1.4 -

Notes
-----

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Keshab Upadhya" <[email-masked]>
Date: Mon, 14 Sep 2015 15:12:42 +0800

Hi Lionel,

Thank you for valuable feedback.

I believe your understanding is inline and primarily what you've summarized
below clarifies objectively, thank you.

Confusion with below statement of 6.1.6, paragraph 2:

"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)."

As per above statement if realm is present and if application is not locally
supported then below action will be taken place.

“---- if not, route the request based on Realm/application (section 6.1.6)”

What will happen if towards a server peer node where hostname is incorrect
and application id with realm locally supported?

Understanding from RFC - If we go with 6.1.4, such message shouldn’t be
processed locally but if we go with 6.1.6 message looks like should be
processed locally based on above given underlined statement, defines
contradiction of 6.1.4 & 6.1.6.

After giving a second though on specs in section 6.1.4, if following
altered–

Original -

      present

Altered -

   o  The Destination-Host AVP is not present in local peer routing table,
the Destination-Realm AVP

      present

It will eliminate the contradiction.

Please help enlighten us on this.

Thank you,

Keshab.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 10, 2015 11:15 PM
To: Keshab Upadhya; 'RFC Errata System'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Technical Errata Reported] RFC6733 (4462)

Hi Keshab,

The purpose of the section 6.1.4 is to give the conditions for processing
locally a request (i.e. how to know that the receiving entity is the one
that needs to answer to the request?) and nothing else.

The case you are referring to is covered in the section 6.1.6 and should not
be part of section 6.1.4.

- if the identity is equal to the local host's identity --> process locally
(section 6.1.4)

- if the identity is not equal to the local host's identity, check the peer
table.

Lionel

-----Message d'origine-----

De : Keshab Upadhya [ <mailto:[email-masked]> mailto:[email-masked]]
Envoyé : jeudi 10 septembre 2015 05:26 À : 'RFC Errata System';
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked];  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]; MORAND Lionel
IMT/OLN Cc :  <mailto:[email-masked]> [email-masked] Objet : RE: [Technical
Errata Reported] RFC6733 (4462)

Hi All,

Good day!

Thank you,

Regards,

Keshab.

-----Original Message-----

From: RFC Errata System [ <mailto:[email-masked]>
mailto:[email-masked]]

To:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked];  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]

Cc:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked];  <mailto:[email-masked]> [email-masked]

 <http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462>
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462

Type: Technical

Reported by: Keshab Upadhya < <mailto:[email-masked]> [email-masked]>

Section: 6.1.4 6.1.6

Original Text

-------------

      present.

6.1.6.  Request Routing

   semantics.

Corrected Text

--------------

6.1.6 -

conflicts with 6.1.4 -

 

Notes

-----

Instructions:

-------------

Stream              : IETF

Verifying Party     : IESG

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 15 Sep 2015 14:25:46 -0700

The proposed correction does not seem right. For routing to work all 
nodes within a realm must be peer, which in this case does not seem to 
hold. I would just return an error.

- Jouni

9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti:
> I believe your understanding is inline and primarily what you've
> summarized below clarifies objectively, thank you.
>
> "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)."
>
> As per above statement if realm is present and if application is not
> locally supported then below action will be taken place.
>
> What will happen if towards a server peer node where hostname is
> incorrect and application id with realm locally supported?
>
> *_Original -_*
>     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*
>
> *_Altered -_*
>     o *The Destination-Host AVP is not present _in local 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*
>
> The purpose of the section 6.1.4 is to give the conditions for
> processing locally a request (i.e. how to know that the receiving entity
> is the one that needs to answer to the request?) and nothing else.
>
> De : Keshab Upadhya [mailto:[email-masked]] Envoyé : jeudi 10
> septembre 2015 05:26 À : 'RFC Errata System'; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>; MORAND Lionel
> IMT/OLN Cc : [email-masked] <mailto:[email-masked]> Objet : RE: [Technical
> To: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
>
> Reported by: Keshab Upadhya <[email-masked] <mailto:[email-masked]>>
>
> Section: 6.1.4 6.1.6
>
> Original Text
>
> -------------
>
> 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.
>
> Instructions:
>
> -------------
>
> pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
>

---

From: "Keshab Upadhya" <[email-masked]>
Date: Wed, 16 Sep 2015 10:56:16 +0800

Hi Jouni,

Thank you for response.

Yes, return error looks like suitable option here as well however it's not
mentioned in RFC6733, 1.6.5 explicitly.

What will be recommended alteration and which section it will be applicable?
Kindly advice.

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 5:26 AM
To: Keshab Upadhya; [email-masked]; 'RFC Errata System';
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Technical Errata Reported] RFC6733 (4462)

The proposed correction does not seem right. For routing to work all nodes
within a realm must be peer, which in this case does not seem to hold. I
would just return an error.

- Jouni

9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti:
> *_application_* that is *_not_* locally supported, the message is 
> routed to the peer configured in the routing table (see Section 2.7)."
>
> Understanding from RFC - If we go with 6.1.4, such message shouldn’t 
> be processed locally but if we go with 6.1.6 message looks like should 
> be processed locally based on above given underlined statement, 
> defines contradiction of 6.1.4 & 6.1.6.
>
> processing locally a request (i.e. how to know that the receiving 
> entity is the one that needs to answer to the request?) and nothing else.
>
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; MORAND Lionel IMT/OLN Cc : 
> [email-masked] <mailto:[email-masked]> Objet : RE: [Technical Errata 
> Reported] RFC6733 (4462)
>
> Hi All,
>
> Good day!
>
> To: [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
>
> 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.
>
> Instructions:
>
> -------------
>
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>
> ______________________________________________________________________
> ___________________________________________________
>
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
>

---

From: Jouni <[email-masked]>
Date: Tue, 15 Sep 2015 21:37:44 -0700

Hi,

Section 6.1 does state DIAMETER_UNABLE_TO_DELIVER to which the request receiving process imho falls to. I am assuming your node you are talking about is an agent.

- Jouni

> On 15 Sep 2015, at 19:56, Keshab Upadhya <[email-masked]> wrote:
> 
> Hi Jouni,
> 
> Thank you for response.
> 
>> septembre 2015 05:26 Ŕ : 'RFC Errata System'; [email-masked]

---

From: "Keshab Upadhya" <[email-masked]>
Date: Wed, 16 Sep 2015 14:03:29 +0800

Hi Jouni,

Thank you.

This is for server peer (HSS) for local request processing and handling of unknown destination host in s6a.

If I understand correctly, a (s6a) request message lands with realm and app is supported by HSS but destination hostname is "unknown" and doesn't have routing details in peer routing table for given hostname, there will be an error (DIAMETER_UNABLE_TO_DELIVER ) returned based on RFC 6733 - 6.1 where clause of 6.1.4, 6.1.5 and 6.1.6 conditions are not fulfilled.

Kindly confirm.

Thank you.

-----Original Message-----
From: Jouni [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 12:38 PM
To: Keshab Upadhya
Cc: ext [email-masked]; RFC Errata System; Benoit Claise; joel jaeggli; [email-masked] list
Subject: Re: [Technical Errata Reported] RFC6733 (4462)

Hi,

- Jouni

> Yes, return error looks like suitable option here as well however it's 
> not mentioned in RFC6733, 1.6.5 explicitly.
> 
>> be processed locally but if we go with 6.1.6 message looks like 
>> should be processed locally based on above given underlined 
>> statement, defines contradiction of 6.1.4 & 6.1.6.
>> 
>> _____________________________________________________________________
>> _ ___________________________________________________
>> 
>> If you have received this email in error, please notify the sender 
>> and delete this message and its attachments.
>>

---

From: "Keshab Upadhya" <[email-masked]>
Date: Thu, 17 Sep 2015 13:37:17 +0800

Hi,

Please help with below query.

Thank you.

Regards,
Keshab.

-----Original Message-----
From: Keshab Upadhya [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 2:03 PM
To: 'Jouni'
Cc: 'ext [email-masked]'; 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; [email-masked] list'
Subject: RE: [Technical Errata Reported] RFC6733 (4462)

Hi Jouni,

Thank you.

Kindly confirm.

Thank you.

-----Original Message-----
From: Jouni [mailto:[email-masked]]
Sent: Wednesday, September 16, 2015 12:38 PM
To: Keshab Upadhya
Cc: ext [email-masked]; RFC Errata System; Benoit Claise; joel jaeggli; [email-masked] list
Subject: Re: [Technical Errata Reported] RFC6733 (4462)

Hi,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 22 Sep 2015 08:14:14 -0700

See inline.

> This is for server peer (HSS) for local request processing and handling of unknown destination host in s6a.

You should not have received such request in the first place. The 
routing infrastructure has issues in this case.

> If I understand correctly, a (s6a) request message lands with realm and app is supported by HSS but destination hostname is "unknown" and doesn't have routing details in peer routing table for give…

DIAMETER_UNABLE_TO_DELIVER would be the best choice here imho.

- JOuni

---

From: "Keshab Upadhya" <[email-masked]>
Date: Wed, 23 Sep 2015 10:31:02 +0800

Hi Jouni,

Thank you and appreciate your valuable feedback.

Yes, message landed under erroneous circumstances. Closely looking at RFC we don't have any specific quote for the "unknown" hostname.

Secondly, I still see there is a contradiction in RFC where local processing parameters against routing of request. If you can help us enlighten here.

6.1.4 -> point 2 says: if hostname not present, realm is known and app_id is supported by local host message should be processed locally.

6.1.6 -> a clause in para 2 says: routing of request is only applicable if realm and app_id is not supported by the local host. 

If I take " 6.1.4" not present of hostname means: “hostname AVP is missing or “null” or not present in peer routing table  of local host” – which one is applicable, secondly if not present in peer routing table of local host, it makes sense but if not it contradicts with "6.1.6", provided "unknown" hostname is not clear in 6.x section.

Thank you.

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2015 11:14 PM
To: Keshab Upadhya
Cc: [email-masked]; 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; [email-masked]
Subject: Re: [Technical Errata Reported] RFC6733 (4462)

See inline.

> From: Keshab Upadhya [ <mailto:[email-masked]> mailto:[email-masked]]

> Cc: 'ext  <mailto:[email-masked]> [email-masked]'; 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; [email-masked] list'

> This is for server peer (HSS) for local request processing and handling of unknown destination host in s6a.

You should not have received such request in the first place. The routing infrastructure has issues in this case.

- JOuni

> From: Jouni [ <mailto:[email-masked]> mailto:[email-masked]]

> Cc: ext  <mailto:[email-masked]> [email-masked]; RFC Errata System; Benoit Claise; 

> joel jaeggli;  <mailto:[email-masked]> [email-masked] list

>> On 15 Sep 2015, at 19:56, Keshab Upadhya < <mailto:[email-masked]> [email-masked]> wrote:

>> Yes, return error looks like suitable option here as well however 

>> it's not mentioned in RFC6733, 1.6.5 explicitly.

>> From: Jouni Korhonen [ <mailto:[email-masked]> mailto:[email-masked]]

>> To: Keshab Upadhya;  <mailto:[email-masked]> [email-masked]; 'RFC Errata System'; 

>>  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; 

>>  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]

>> Cc:  <mailto:[email-masked]> [email-masked]

>> nodes within a realm must be peer, which in this case does not seem 

>> to hold. I would just return an error.

>>> “---- if not, route the request based on Realm/application (section

>> 6.1.6)”

>>>     o *The Destination-Host AVP is not present, the 

>>> Destination-Realm

>>> AVP*

>>>     o *The Destination-Host AVP is not present _in local peer 

>>> routing table_, the Destination-Realm AVP*

>>> From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]]

>>> To: Keshab Upadhya; 'RFC Errata System';  <mailto:[email-masked]> [email-masked]; 

>>>  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; 

>>>  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; 

>>>  <mailto:[email-masked]> [email-masked]

>>> Cc:  <mailto:[email-masked]> [email-masked]

>>> The case you are referring to is covered in the section 6.1.6 and 

>>> should not be part of section 6.1.4.

>>> - if the identity is equal to the local host's identity --> process 

>>> locally (section 6.1.4)

>>> - if the identity is not equal to the local host's identity, check 

>>> the peer table.

>>> ---- If it is the peer table, forward the request to the peer (sect

>>> 6.1.5)

>>> ---- if not, route the request based on Realm/application (section

>>> 6.1.6)

>>> De : Keshab Upadhya [ <mailto:[email-masked]> mailto:[email-masked]] Envoyé : jeudi 10 

>>> septembre 2015 05:26 Ŕ : 'RFC Errata System';  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>; MORAND Lionel IMT/OLN Cc :

>>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]> Objet : RE: [Technical Errata 

>>> From: RFC Errata System [ <mailto:[email-masked]> mailto:[email-masked]]

>>> To:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>; 

>>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>; 

>>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>; 

>>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>

>>> Cc:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>;  <mailto:[email-masked]> [email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>

>>>  <http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462> http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462

>>> Reported by: Keshab Upadhya <[email-masked] 

>>> < <mailto:[email-masked]> mailto:[email-masked]>>

>>>     o  The Destination-Host AVP is not present, the 

>>> Destination-Realm AVP

>>>        contains a realm the server is configured to process locally, 

>>> and

>>>     Diameter request message routing is done via realms and 

>>> Application

>>>     (proxies, redirect agents, or relay agents) MUST include the 

>>> target

>>>     realm in the Destination-Realm AVP.  Request routing SHOULD rely 

>>> on

>>>     request message header to aid in the routing decision.  The 

>>> realm MAY

>>>     Network Access Identifier (NAI).  The realm portion of the NAI 

>>> is

>>>     applications, and they MAY have a list of externally supported 

>>> realms

>>>     and applications.  When a request is received that includes a 

>>> realm

>>>     Realm names and Application Ids are the minimum supported 

>>> routing

>>>     criteria, additional information may be needed to support 

>>> redirect

>>>     The Destination-Host AVP is not present, the Destination-Realm 

>>> AVP

>>>        contains a realm the server is configured to process locally, 

>>> and

>>> 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.

>>> ____________________________________________________________________

>>> _ _ ___________________________________________________

>>> confidentielles ou privilegiees et ne doivent donc pas etre 

>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu 

>>> ce message par erreur, veuillez le signaler a l'expediteur et le 

>>> detruire ainsi que les pieces jointes. Les messages electroniques 

>>> etant susceptibles d'alteration, Orange decline toute responsabilite 

>>> si ce message a ete altere, deforme ou falsifie. Merci.

>>> As emails may be altered, Orange is not liable for messages that 

>>> have been modified, changed or falsified.