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

["Keshab Upadhya" <[e-mail]>]

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 -

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

 

Altered -

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

   o  Both the Destination-Host and the Destination-Realm are not

      present

 

It will eliminate the contradiction.

 

Please help enlighten us on this.

 

Thank you,

Keshab.

 

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

 

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:[e-mail]> mailto:[e-mail]]
Envoyé : jeudi 10 septembre 2015 05:26 À : 'RFC Errata System';
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail]; MORAND Lionel
IMT/OLN Cc :  <mailto:[e-mail]> [e-mail] Objet : RE: [Technical
Errata Reported] RFC6733 (4462)

 

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:[e-mail]>
mailto:[e-mail]]

Sent: Wednesday, September 2, 2015 9:09 AM

To:  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail]

Cc:  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail]

Subject: [Technical Errata Reported] RFC6733 (4462)

 

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>
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462

 

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

Type: Technical

Reported by: Keshab Upadhya < <mailto:[e-mail]> [e-mail]>

 

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

 

 

____________________________________________________________________________
_____________________________________________

 

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.