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

[Jouni <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail]] 
> Sent: Wednesday, September 16, 2015 5:26 AM
> To: Keshab Upadhya; [e-mail]; 'RFC Errata System';
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:
>> 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]] Envoyé : jeudi 10 
>> septembre 2015 05:26 Ŕ : 'RFC Errata System'; [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]>; MORAND Lionel IMT/OLN Cc : 
>> [e-mail] <mailto:[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]]
>> 
>> Sent: Wednesday, September 2, 2015 9:09 AM
>> 
>> To: [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] 
>> <mailto:[e-mail]>
>> 
>> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] 
>> <mailto:[e-mail]>; [e-mail] 
>> <mailto:[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
>> 
>> --------------------------------------
>> 
>> Type: Technical
>> 
>> Reported by: Keshab Upadhya <[e-mail] 
>> <mailto:[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.