From nobody Wed Sep 2 06:09:14 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3043F1B2CBE for ; Tue, 1 Sep 2015 18:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztBZ2Q0zwYSX for ; Tue, 1 Sep 2015 18:09:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B66321B2BC2 for ; Tue, 1 Sep 2015 18:09:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 059A2180474; Tue, 1 Sep 2015 18:09:23 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150902010923.059A2180474@rfc-editor.org> Date: Tue, 1 Sep 2015 18:09:23 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 06:09:13 -0700 Cc: rfc-editor@rfc-editor.org, dime@ietf.org, keshab@smsgt.com Subject: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 01:09:57 -0000 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 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 nobody Wed Sep 2 06:09:15 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055D31B3134 for ; Tue, 1 Sep 2015 18:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psGrkKQq8NPr for ; Tue, 1 Sep 2015 18:16:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1411B3128 for ; Tue, 1 Sep 2015 18:16:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 99B26181D1F; Tue, 1 Sep 2015 18:16:04 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150902011604.99B26181D1F@rfc-editor.org> Date: Tue, 1 Sep 2015 18:16:04 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 02 Sep 2015 06:09:13 -0700 Cc: rfc-editor@rfc-editor.org, dime@ietf.org, keshab@smsgt.com Subject: [Dime] [Technical Errata Reported] RFC6733 (4463) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 01:16:39 -0000 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=4463 -------------------------------------- Type: Technical Reported by: Keshab Upadhya Section: 6.1.7 Original Text ------------- 6.1.7. Predictive Loop Avoidance Corrected Text -------------- 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. 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 nobody Tue Sep 8 01:55:08 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1C1B4071 for ; Tue, 8 Sep 2015 01:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOSQCjSOVlq5 for ; Tue, 8 Sep 2015 01:55:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FBF1B4064 for ; Tue, 8 Sep 2015 01:55:04 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5A7AF1902A5 for ; Tue, 8 Sep 2015 10:55:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3C005384201 for ; Tue, 8 Sep 2015 10:55:00 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0248.002; Tue, 8 Sep 2015 10:55:00 +0200 From: To: "dime@ietf.org" Thread-Topic: NomCom 2015: Call for nominations Thread-Index: AQHQ6gWXjf35u1FSlEC5FJq5Acm3z54yTsUQ Date: Tue, 8 Sep 2015 08:54:59 +0000 Message-ID: <22033_1441702500_55EEA264_22033_2346_1_6B7134B31289DC4FAF731D844122B36E01D0C844@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <55EE8909.9040204@cisco.com> <55EE8A1B.3030903@cisco.com> In-Reply-To: <55EE8A1B.3030903@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.81516 Archived-At: Subject: [Dime] Fwd: NomCom 2015: Call for nominations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 08:55:07 -0000 SGksDQoNClRoZSBOb21jb20ncyBDYWxsIGZvciBOb21pbmF0aW9uIGlzIGFuIGltcG9ydGFudCBw aGFzZSBpbiB0aGUgbGlmZSBvZiB0aGUgSUVURiBjb21tdW5pdHkuDQpQbGVhc2UgY2hlY2sgdGhl IG9wZW4gcG9zaXRpb25zIChJQUIgbWVtYmVyIG9yIEFEKSBhbmQgY29uc2lkZXIgdG8gbm9taW5h dGUgeW91cnNlbGYgb3Igc29tZW9uZSBlbHNlIGZvciB0aGUgcG9zaXRpb25zIHRvIGJlIGZpbGxl ZCB0aGlzIHllYXIuDQoNClJlZ2FyZHMsDQoNCkxpb25lbCAmIEpvdW5pDQoNCi0tLS0tLS0tIEZv cndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiAJTm9tQ29tIDIwMTU6IENhbGwgZm9y IG5vbWluYXRpb25zDQpEYXRlOiAJV2VkLCAyNiBBdWcgMjAxNSAwMzoxMzoxMyAtMDcwMA0KRnJv bTogCU5vbUNvbSBDaGFpciAyMDE1IDxub21jb20tY2hhaXItMjAxNUBpZXRmLm9yZz4NClJlcGx5 LVRvOiAJaWV0ZkBpZXRmLm9yZywgbm9tY29tMTVAaWV0Zi5vcmcNClRvOiAJSUVURiBBbm5vdW5j ZW1lbnQgTGlzdCA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkNDOiAJaWV0ZkBpZXRmLm9yZw0K DQoNCg0KVGhlIDIwMTUtMTYgTm9taW5hdGluZyBDb21taXR0ZWUgKE5vbWNvbSkgaXMgc2Vla2lu ZyBub21pbmF0aW9ucyBmcm9tIG5vdyB1bnRpbCBPY3RvYmVyIDgsIDIwMTUuIFRoZSBvcGVuIHBv c2l0aW9ucyBiZWluZyBjb25zaWRlcmVkIGJ5IHRoaXMgeWVhcidzIE5vbWNvbSBjYW4gYmUgZm91 bmQgYXQgdGhlIGVuZCBvZiB0aGlzIGVtYWlsIGFuZCBhbHNvIG9uIHRoaXMgeWVhcidzIE5vbWNv bSB3ZWJzaXRlOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDE1Lw0K DQpOb21pbmF0aW9ucyBtYXkgYmUgbWFkZSBieSBzZWxlY3RpbmcgdGhlIE5vbWluYXRlIGxpbmsg YXQgdGhlIHRvcCBvZiB0aGUgTm9tY29tIDIwMTUgaG9tZSBwYWdlLCBvciBieSB2aXNpdGluZyB0 aGUgZm9sbG93aW5nIFVSTDoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20v MjAxNS9ub21pbmF0ZS8NCg0KICAge05vdGUgdGhhdCBub21pbmF0aW9ucyBtYWRlIHVzaW5nIHRo ZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnDQogICAgZGF0YXRyYWNrZXIgYWNjb3VudC4g WW91IGNhbiBjcmVhdGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQogICAgaWYgeW91 IGRvbid0IGhhdmUgb25lIGFscmVhZHkgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6DQog ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvICB9DQoNCklm IHlvdSBhcmUgdW5hYmxlIHRvIHVzZSB0aGUgd2ViIGZvcm0sIG5vbWluYXRpb25zIG1heSBpbnN0 ZWFkIGJlIG1hZGUgYnkgZW1haWwgdG9ub21jb20xNUBpZXRmLm9yZy4gSWYgdXNpbmcgZW1haWws IHBsZWFzZSBpbmNsdWRlIHRoZSB3b3JkICJOb21pbmF0ZSIgaW4gdGhlIFN1YmplY3QgYW5kIGlu ZGljYXRlIGluIHRoZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5hdGVkLCB0aGVpciBlbWFpbCBh ZGRyZXNzICh0byBjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhl IHBvc2l0aW9uIGZvciB3aGljaCB5b3UgYXJlIG1ha2luZyB0aGUgbm9taW5hdGlvbi4NCklmIHlv dSBhcmUgbm9taW5hdGluZyBzb21lb25lIG90aGVyIHRoYW4geW91cnNlbGYsIHBsZWFzZSB0ZWxs IHVzIGlmIHdlIG1heSB0ZWxsIHRoZSBub21pbmVlIHRoYXQgeW91IHdlcmUgdGhlIG9uZSB3aG8g bWFkZSB0aGUgbm9taW5hdGlvbi4NCklmIHlvdSB3aXNoIHRvIG5vbWluYXRlIHNvbWVvbmUgdmlh IGVtYWlsIGZvciBtb3JlIHRoYW4gb25lIHBvc2l0aW9uLCBwbGVhc2UgdXNlIHNlcGFyYXRlIGVt YWlscyB0byBkbyBzby4NCg0KU2VsZi1ub21pbmF0aW9uIGlzIHdlbGNvbWUhDQoNCk5vbUNvbSAy MDE1LTE2IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9yICJPcGVuIERpc2Nsb3N1cmUgb2YgV2ls bGluZyBOb21pbmVlcyIgZGVzY3JpYmVkIGluIEJDUCAxMC9SRkMgNzQzNy4gIEFzIHN0YXRlZCBp biBSRkMgNzQzNzogIlRoZSBsaXN0IG9mIG5vbWluZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJl ZCBmb3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBpbiB0aGUgY3VycmVudCBOb21jb20gY3ljbGUg aXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxpbmcgbm9taW5lZXMgZm9yIGVhY2ggcG9zaXRpb24g d2lsbCBiZSBsaXN0ZWQgaW4gYSBwdWJsaWNseSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3aXRo IGEgZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkgYWNjZXNzIHRoZSBsaXN0cy4gIEFkZGl0aW9uYWxs eSwgdGhlIG5vbWluYXRpb24gZm9ybSBhc2tzIGlmIHdlIG1heSBzaGFyZSB5b3VyIG93biBuYW1l IHdpdGggdGhlIG5vbWluZWUuIEluIGFsbCBvdGhlciB3YXlzLCB0aGUgY29uZmlkZW50aWFsaXR5 IHJlcXVpcmVtZW50cyBvZiBCQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsIGZlZWRiYWNrIGFu ZCBhbGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3 aWxsIG5vdCBiZSBkaXNjbG9zZWQuDQoNClRoZXJlIGlzIGEgZmllbGQgb24gdGhlIGZvcm0geW91 IGNhbiBtYXJrIGluIG9yZGVyIHRvIGFsbG93IHRoZSBOb21jb20gdG8gdGVsbCB0aGUgbm9taW5l ZSB0aGF0IHlvdSB3ZXJlIHRoZSBvbmUgd2hvIG1hZGUgdGhlIG5vbWluYXRpb24uIFRoaXMgaXMg YSBuZXcgdGhpbmcgdGhpcyB5ZWFyLCBhbmQgaXQgZGVmYXVsdHMgdG8g4oCcbm/igJ0gLSB3ZSB3 b27igJl0IHRlbGwuIEFmdGVyIHRoZSBub21pbmF0aW9uIGN5Y2xlLCB3ZSB3aWxsIGV2YWx1YXRl IHRoZSByZXN1bHQgb2YgdGhpcyBhbmQgcmVjb21tZW5kIHdoZXRoZXIgdGhlIG5leHQgTm9tY29t IHNob3VsZCBkbyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KDQpJbiBvcmRlciB0byBlbnN1cmUgdGlt ZSB0byBjb2xsZWN0IHN1ZmZpY2llbnQgY29tbXVuaXR5IGZlZWRiYWNrIGFib3V0IGVhY2ggb2Yg dGhlIHdpbGxpbmcgbm9taW5lZXMsIG5vbWluYXRpb25zIG11c3QgYmUgcmVjZWl2ZWQgYnkgdGhl IE5vbWNvbSBvbiBvciBiZWZvcmUgT2N0b2JlciA4LCAyMDE1Lg0KDQpQbGVhc2Ugc3VibWl0IHlv dXIgbm9taW5hdGlvbnMgYXMgZWFybHkgYXMgcG9zc2libGUgZm9yIHRoZSBzYWtlIG9mIHlvdXIg bm9taW5lZXMuIE5vdGUgdGhhdCBub21pbmF0aW9ucyBzaG91bGQgbm90IHdhaXQgZm9yIG1hbmFn ZW1lbnQgcGVybWlzc2lvbiwgYXMgaXQgaXMgZWFzaWVyIHRvIGRlY2xpbmUgdGhlIG5vbWluYXRp b24gdGhhbiBwdXQgb25lIGluIGxhdGUuICBXZSBoYXZlIHNldCB0aGUgcXVlc3Rpb25uYWlyZSBz dWJtaXNzaW9uIGRlYWRsaW5lIGZvciBPY3RvYmVyIDE1LCAyMDE1Lg0KDQpUaGUgTm9tY29tIGFw cG9pbnRzIGluZGl2aWR1YWxzIHRvIGZpbGwgdGhlIG9wZW4gc2xvdHMgb24gdGhlIElBT0MsIHRo ZSBJQUIsIGFuZCB0aGUgSUVTRy4gVGhlIGxpc3Qgb2YgcGVvcGxlIGFuZCBwb3N0cyB3aG9zZSB0 ZXJtcyBlbmQgd2l0aCB0aGUgTWFyY2ggMjAxNiBJRVRGIG1lZXRpbmcsIGFuZCB0aHVzIHRoZSBw b3NpdGlvbnMgZm9yIHdoaWNoIHRoaXMgTm9tY29tIGlzIHJlc3BvbnNpYmxlLCBmb2xsb3dzOg0K DQpJQUI6DQoqIE1hcnkgQmFybmVzDQoqIEpvZSBIaWxkZWJyYW5kDQoqIFRlZCBIYXJkaWUNCiog RXJpayBOb3JkbWFyaw0KKiBCcmlhbiBUcmFtbWVsbA0KKiBNYXJrIEJsYW5jaGV0DQoNCklFU0c6 DQotIEFsaXNzYSBDb29wZXIsIEFSVA0KLSBCYXJyeSBMZWliYSwgQVJUDQotIEJyaWFuIEhhYmVy bWFuLCBJbnRlcm5ldCAoKikNCi0gQmVub2l0IENsYWlzZSwgTyZNDQotIEFsaWEgQXRsYXMsIFJv dXRpbmcNCi0gS2F0aGxlZW4gTW9yaWFydHksIFNlY3VyaXR5DQotIE1hcnRpbiBTdGllbWVybGlu ZywgVHJhbnNwb3J0ICgqKQ0KDQoqLSBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgZG8gbm90IGlu dGVuZCB0byBhY2NlcHQgYSByZW5vbWluYXRpb24uIFRoaXMgaW5mb3JtYXRpb24gaXMgYWx3YXlz IHVwIHRvIGRhdGUgb24gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxNS8N Cg0KUGxlYXNlIGJlIHJlc291cmNlZnVsIGluIGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0 ZXMgZm9yIHRoZXNlIHBvc2l0aW9ucywgYXMgZGV2ZWxvcGluZyBvdXIgdGFsZW50IGlzIGEgdmVy eSBjcnVjaWFsIHJlcXVpcmVtZW50IGZvciB0aGUgSUVURiwgYW5kIGFsc28sIHBsZWFzZSBjb25z aWRlciBhY2NlcHRpbmcgYSBub21pbmF0aW9uLiAgWW91J2xsIGZpbmQgZXh0ZW5zaXZlIGluZm9y bWF0aW9uIGFib3V0IHNwZWNpZmljIHBvc2l0aW9ucywgZGV2ZWxvcGVkIGJ5IHRoZSBJQUIsIElF U0csIGFuZCBJQU9DLCB1bmRlciBpbmRpdmlkdWFsIHRhYnMgYXQ6DQoNCiAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTUvcmVxdWlyZW1lbnRzLw0KDQpJbiBhZGRpdGlv biB0byBub21pbmF0aW9ucywgdGhlIE5vbWNvbSBzZWVrcyBjb21tdW5pdHkgaW5wdXQgb24gdGhl IHBvc2l0aW9ucyB0aGVtc2VsdmVzLiAgV2UgbmVlZCBhbmQgd2VsY29tZSB0aGUgY29tbXVuaXR5 J3Mgdmlld3MgYW5kIGlucHV0IG9uIHRoZSBqb2JzIHdpdGhpbiBlYWNoIG9yZ2FuaXphdGlvbi4g SWYgeW91IGhhdmUgaWRlYXMgb24gdGhlIHBvc2l0aW9ucycgcmVzcG9uc2liaWxpdGllcyAobW9y ZSwgbGVzcywgZGlmZmVyZW50KSwgcGxlYXNlIGxldCB1cyBrbm93Lg0KDQpQbGVhc2Ugc2VuZCBz dWdnZXN0aW9ucyBhbmQgZmVlZGJhY2sgYWJvdXQgdGhpcyB0b25vbWNvbTE1QGlldGYub3JnLg0K DQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCBpbiBpZGVudGlmeWluZyBxdWFsaWZpZWQgbm9taW5l ZXMhDQoNCkhhcmFsZCBBbHZlc3RyYW5kDQpOb21jb20gQ2hhaXIgMjAxNS0xNg0Kbm9tY29tLWNo YWlyLTIwMTVAaWV0Zi5vcmcsaHRhK25vbWNvbUBhbHZlc3RyYW5kLm5vDQoNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From keshab@smsgt.com Wed Sep 9 20:26:29 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D611F1A1B4C for ; Wed, 9 Sep 2015 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxlRSd0Hny75 for ; Wed, 9 Sep 2015 20:26:28 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518721A8AAC for ; Wed, 9 Sep 2015 20:26:28 -0700 (PDT) Received: by gateway34.websitewelcome.com (Postfix, from userid 500) id B7DB83C3DB743; Wed, 9 Sep 2015 22:26:27 -0500 (CDT) Received: from cm5.websitewelcome.com (cm5.websitewelcome.com [192.185.178.233]) by gateway34.websitewelcome.com (Postfix) with ESMTP id B56803C3DB727 for ; Wed, 9 Sep 2015 22:26:27 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm5.websitewelcome.com with id FFSS1r00a1q3akG01FSTRH; Wed, 09 Sep 2015 22:26:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=pW+1v8+UnNv4iCLf5nbvgY+f2yHtBN7yQpSMwO7Sz68=; b=Mf/Met06CkqOFedrgGrKkc/idbjW8g1Kse83nmRpuZfweI72VlApfRiHmeRh0oiGXude/++jW+GeaVPodDkRc6ly+sIMaJyolmQnej7A/SWC+UzBhdbY9irq/m6SycpBB+VR9oMp3LzV6Tw15OXErNAB148uAl0Pi66T5JH9L9M=; Received: from [121.58.195.226] (port=50440 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZZsVF-000ASa-Df; Wed, 09 Sep 2015 22:26:25 -0500 From: "Keshab Upadhya" To: "'RFC Errata System'" , , , , , , , , References: <20150902010923.059A2180474@rfc-editor.org> In-Reply-To: <20150902010923.059A2180474@rfc-editor.org> Date: Thu, 10 Sep 2015 11:25:53 +0800 Message-ID: <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo450QZBKw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 121.58.195.226 X-Exim-ID: 1ZZsVF-000ASa-Df X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Keshab) [121.58.195.226]:50440 X-Source-Auth: allan X-Email-Count: 124 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: X-Mailman-Approved-At: Thu, 10 Sep 2015 08:16:40 -0700 Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 03:28:27 -0000 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:rfc-editor@rfc-editor.org] Sent: Wednesday, September 2, 2015 9:09 AM To: vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com; lionel.morand@orange.com Cc: keshab@smsgt.com; dime@ietf.org; rfc-editor@rfc-editor.org 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 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 nobody Thu Sep 10 08:16:43 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28101B309A for ; Thu, 10 Sep 2015 08:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32MKDz3PBEIr for ; Thu, 10 Sep 2015 08:14:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91A21B6A17 for ; Thu, 10 Sep 2015 08:14:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0415322C489; Thu, 10 Sep 2015 17:14:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C066035C048; Thu, 10 Sep 2015 17:14:41 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 17:14:41 +0200 From: To: Keshab Upadhya , 'RFC Errata System' , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "joelja@bogus.com" , "jouni.nospam@gmail.com" Thread-Topic: [Technical Errata Reported] RFC6733 (4462) Thread-Index: AQHQ5Rw8o3qK39fbU0W2KazOtgohFp41BQyAgADeBqA= Date: Thu, 10 Sep 2015 15:14:41 +0000 Message-ID: <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> In-Reply-To: <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.131516 Archived-At: X-Mailman-Approved-At: Thu, 10 Sep 2015 08:16:40 -0700 Cc: "dime@ietf.org" Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:14:46 -0000 Hi Keshab, I'm not totally sure to understand your concern.=20 The purpose of the section 6.1.4 is to give the conditions for processing l= ocally a request (i.e. how to know that the receiving entity is the one tha= t 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 no= t be part of section 6.1.4. To make a long story short...=20 if the Destination-Host is present,=20 - 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=A0: Keshab Upadhya [mailto:keshab@smsgt.com]=20 Envoy=E9=A0: jeudi 10 septembre 2015 05:26 =C0=A0: 'RFC Errata System'; vf0213@gmail.com; jari.arkko@ericsson.com; joh= n.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.c= om; jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc=A0: dime@ietf.org Objet=A0: 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:rfc-editor@rfc-editor.org] Sent: Wednesday, September 2, 2015 9:09 AM To: vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; gle= nzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.co= m; lionel.morand@orange.com Cc: keshab@smsgt.com; dime@ietf.org; rfc-editor@rfc-editor.org 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=3D6733&eid=3D4462 -------------------------------------- Type: Technical Reported by: Keshab Upadhya 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 conflict= s with 6.1.6. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary.=20 -------------------------------------- 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Thu Sep 10 13:28:44 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994321B30C2 for ; Thu, 10 Sep 2015 13:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuS2K7CIgjAk for ; Thu, 10 Sep 2015 13:28:41 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDAC1ACE14 for ; Thu, 10 Sep 2015 13:28:41 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:56289 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Za8SW-000AWd-4a for dime@ietf.org; Thu, 10 Sep 2015 13:28:41 -0700 From: Steve Donovan To: "dime@ietf.org" Message-ID: <55F1E7F7.5060109@usdonovans.com> Date: Thu, 10 Sep 2015 15:28:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: [Dime] DRMP: Different priority for answer message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 20:28:42 -0000 I have been notified of at least one use case (in NS/EP LTE Access Network GIR, Issue 2.0, January 2013) where there is the need for an answer message to have a different, higher, priority then the priority of the request message. "There is one use case (Advance-Priority-SPR) where the CCR does not contain a Priority-Level AVP with a PS value but the corresponding CCA does. In this case, the expectation is that the Answer be processed with a higher priority than the Request. More specifically the Answer is processed at the highest priority in the system, including non-PS Answers." My proposed solution, which would not require application level processing by agents, is as follows: - We keep the default that the priority carried in the request message applies to the transaction and, as a result, applies to the answer message. As a result, the default processing does not require the answer message to carry a Priority AVP. - We allow the DRMP AVP to optionally be carried in answer messages. - In the case that there is a DRMP AVP in an answer message, the priority in the answer message takes precedence over the priority specified in the request message. Thoughts? Regards, Steve From nobody Fri Sep 11 03:47:21 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51151B4778 for ; Fri, 11 Sep 2015 03:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AXsjh0fe0eU for ; Fri, 11 Sep 2015 03:47:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75851B474E for ; Fri, 11 Sep 2015 03:47:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4393E3242C9; Fri, 11 Sep 2015 12:47:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.10]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 264184C048; Fri, 11 Sep 2015 12:47:17 +0200 (CEST) Received: from OPEXCLILM6C.corporate.adroot.infra.ftgroup (10.114.31.21) by OPEXCLILM5C.corporate.adroot.infra.ftgroup (10.114.31.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 11 Sep 2015 12:47:17 +0200 Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0248.002; Fri, 11 Sep 2015 12:47:17 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DRMP: Different priority for answer message Thread-Index: AQHQ7AdLpXTUGxwi1U2qyA1r9aeRA543Ja5w Date: Fri, 11 Sep 2015 10:47:16 +0000 Message-ID: <15643_1441968437_55F2B135_15643_3524_1_6B7134B31289DC4FAF731D844122B36E01D1D671@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <55F1E7F7.5060109@usdonovans.com> In-Reply-To: <55F1E7F7.5060109@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.11.100316 Archived-At: Subject: Re: [Dime] DRMP: Different priority for answer message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 10:47:21 -0000 Hi Steve, I like the proposal. By default, the Priority in the request applies for the transaction, except= if the Priority AVP is in the answer. But it means that the priority AVP in the answer will take precedence whate= ver the value, higher or lower than the one received in the request. I thin= k that it is somehow assumed in your proposal but I just want to be sure. regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: jeudi 10 septembre 2015 22:29 =C0=A0: dime@ietf.org Objet=A0: [Dime] DRMP: Different priority for answer message I have been notified of at least one use case (in NS/EP LTE Access Network = GIR, Issue 2.0, January 2013) where there is the need for an answer message= to have a different, higher, priority then the priority of the request mes= sage. "There is one use case (Advance-Priority-SPR) where the CCR does not contai= n a Priority-Level AVP with a PS value but the corresponding CCA does. In t= his case, the expectation is that the Answer be processed with a higher pri= ority than the Request. More specifically the Answer is processed at the h= ighest priority in the system, including non-PS Answers." My proposed solution, which would not require application level processing = by agents, is as follows: - We keep the default that the priority carried in the request message appl= ies to the transaction and, as a result, applies to the answer message. As= a result, the default processing does not require the answer message to ca= rry a Priority AVP. - We allow the DRMP AVP to optionally be carried in answer messages. - In the case that there is a DRMP AVP in an answer message, the priority i= n the answer message takes precedence over the priority specified in the re= quest message. Thoughts? Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 nobody Fri Sep 11 05:57:52 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6A1B49AE; Fri, 11 Sep 2015 05:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V34YD4r6Vmyf; Fri, 11 Sep 2015 05:57:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 889891B4950; Fri, 11 Sep 2015 05:57:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DEB82181D1B; Fri, 11 Sep 2015 05:57:27 -0700 (PDT) To: keshab@smsgt.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150911125727.DEB82181D1B@rfc-editor.org> Date: Fri, 11 Sep 2015 05:57:27 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dime@ietf.org, iesg@ietf.org Subject: [Dime] [Errata Rejected] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 12:57:48 -0000 The following errata report has been rejected 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 -------------------------------------- Status: Rejected Type: Technical Reported by: Keshab Upadhya Date Reported: 2015-09-01 Rejected by: Stephen Farrell (IESG) 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. --VERIFIER NOTES-- DIME WG chairs report this is erroneous. -------------------------------------- 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 nobody Fri Sep 11 05:58:33 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346371B4A4A; Fri, 11 Sep 2015 05:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL4iVGFZ6Q-f; Fri, 11 Sep 2015 05:58:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id BC98C1B4A4B; Fri, 11 Sep 2015 05:58:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A816180206; Fri, 11 Sep 2015 05:58:14 -0700 (PDT) To: keshab@smsgt.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150911125814.1A816180206@rfc-editor.org> Date: Fri, 11 Sep 2015 05:58:14 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dime@ietf.org, iesg@ietf.org Subject: [Dime] [Errata Rejected] RFC6733 (4463) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 12:58:32 -0000 The following errata report has been rejected for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4463 -------------------------------------- Status: Rejected Type: Technical Reported by: Keshab Upadhya Date Reported: 2015-09-01 Rejected by: Stephen Farrell (IESG) Section: 6.1.7 Original Text ------------- 6.1.7. Predictive Loop Avoidance Corrected Text -------------- 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. -------------------------------------- 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 nobody Fri Sep 11 07:02:00 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21581B4CC3 for ; Fri, 11 Sep 2015 07:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHsj5PkyNg1J for ; Fri, 11 Sep 2015 07:01:57 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2211B4CAD for ; Fri, 11 Sep 2015 07:01:57 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60052 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZaOtk-000ByQ-3B; Fri, 11 Sep 2015 07:01:56 -0700 To: lionel.morand@orange.com, "dime@ietf.org" References: <55F1E7F7.5060109@usdonovans.com> <15643_1441968437_55F2B135_15643_3524_1_6B7134B31289DC4FAF731D844122B36E01D1D671@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <55F2DECF.7010106@usdonovans.com> Date: Fri, 11 Sep 2015 09:01:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <15643_1441968437_55F2B135_15643_3524_1_6B7134B31289DC4FAF731D844122B36E01D1D671@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] DRMP: Different priority for answer message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 14:01:58 -0000 Lionel, You are correct, I had focused on the priority in the answer message being higher but it would take priority both when higher and lower. Steve On 9/11/15 5:47 AM, lionel.morand@orange.com wrote: > Hi Steve, > > I like the proposal. > By default, the Priority in the request applies for the transaction, except if the Priority AVP is in the answer. > But it means that the priority AVP in the answer will take precedence whatever the value, higher or lower than the one received in the request. I think that it is somehow assumed in your proposal but I just want to be sure. > > regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : jeudi 10 septembre 2015 22:29 > À : dime@ietf.org > Objet : [Dime] DRMP: Different priority for answer message > > I have been notified of at least one use case (in NS/EP LTE Access Network GIR, Issue 2.0, January 2013) where there is the need for an answer message to have a different, higher, priority then the priority of the request message. > > "There is one use case (Advance-Priority-SPR) where the CCR does not contain a Priority-Level AVP with a PS value but the corresponding CCA does. In this case, the expectation is that the Answer be processed with a higher priority than the Request. More specifically the Answer is processed at the highest priority in the system, including non-PS Answers." > > My proposed solution, which would not require application level processing by agents, is as follows: > > - We keep the default that the priority carried in the request message applies to the transaction and, as a result, applies to the answer message. As a result, the default processing does not require the answer message to carry a Priority AVP. > > - We allow the DRMP AVP to optionally be carried in answer messages. > > - In the case that there is a DRMP AVP in an answer message, the priority in the answer message takes precedence over the priority specified in the request message. > > Thoughts? > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > 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 nobody Fri Sep 11 08:41:46 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327C71B4666 for ; Fri, 11 Sep 2015 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYeynEH-ksnG for ; Fri, 11 Sep 2015 08:41:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F431B47C8 for ; Fri, 11 Sep 2015 08:41:43 -0700 (PDT) Received: from localhost ([::1]:37939 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZaQSM-0006B9-LY; Fri, 11 Sep 2015 08:41:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-dime-drmp@tools.ietf.org, lionel.morand@orange.com X-Trac-Project: dime Date: Fri, 11 Sep 2015 15:41:42 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/91 Message-ID: <066.5cd36866b0450471e4d1318bdc01e524@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-drmp@tools.ietf.org, lionel.morand@orange.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20150911154143.83F431B47C8@ietfa.amsl.com> Resent-Date: Fri, 11 Sep 2015 08:41:43 -0700 (PDT) Resent-From: trac+dime@trac.tools.ietf.org Archived-At: Cc: dime@ietf.org Subject: [Dime] [dime] #91 (drmp): Handling of requests without Priority indication X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 15:41:45 -0000 #91: Handling of requests without Priority indication In the current version, we have the following text: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_0 priority. With PRIORITY_0 being the highest priority (PRIORITY_4 being the lowest priority). If I'm correct, this implies that request with no priority info at all would be handled with the highest priority. I think this is not correct. Current Diameter implementations make no use of priority info and using this mechanism should be a way to explicitly prioritize requests with priority indication compared to request without priority info. Otherwise, the priority indication would be only used to somehow enable the de-prioritization of some requests whereas all the other ones with no priority indication will have de facto the highest priority. This is more relevant from an agent point of view, in an early phase of deployment of this new priority mechanism, with few clients setting explicitly the priority in the requests and the rest of the clients not supporting the new feature and therefore no adding the priority info in the requests. Keeping the idea of 5-value priority indication, the value PRIORITY_0 should therefore be the lowest priority level or, if the current order is kept, request without priority indication should be handled as having PRIORITY_4. Another approach, which would enable explicit upgrade or downgrade of request priority handling, would be to define a range of e.g. 10 values for priority (e.g. 0 - 9) and to handle requests without priority indication as having the an intermediary value, e.g. value 4. It would mean that using the priority indication in the request, it will be possible to explicitly indicate if the current request should be handle with a higher or lower priority than existing requests without priority indication. It could be a way to indicate that a given request can be handled with a lower priority than all the other requests. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- lionel.morand@orange.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Sep 14 10:16:55 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398501B34D2 for ; Mon, 14 Sep 2015 00:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHCH2enKdZQA for ; Mon, 14 Sep 2015 00:12:53 -0700 (PDT) Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213211B2ADF for ; Mon, 14 Sep 2015 00:12:52 -0700 (PDT) Received: by gateway24.websitewelcome.com (Postfix, from userid 500) id 6CC791E16348; Mon, 14 Sep 2015 02:12:52 -0500 (CDT) Received: from cm5.websitewelcome.com (cm5.websitewelcome.com [192.185.178.233]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 6A1121E1632C for ; Mon, 14 Sep 2015 02:12:52 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm5.websitewelcome.com with id GvCr1r00C1q3akG01vCsSs; Mon, 14 Sep 2015 02:12:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=D8Vb9UdLA/jBhooqwwDOTg0fxq4K5Uv90c3e5G3H7ew=; b=NoFORCGxA7bMwMzgudGTPZTQg5p8HU9dhmVMtgI1rYqg0l/6LEE4QGt9deTyGk2k8ZaUPlpvuqWbYLZUpNpIO1RaMNzwgC7gCSjKbmkh7tbkSB+BFPHyXSHsLMf5oxIkHRZbtwxokVM+b/zB2AETDoIGfmlVuoPD42o9el7ZSh0=; Received: from [112.198.79.128] (port=47519 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZbNwX-0003ma-Dr; Mon, 14 Sep 2015 02:12:50 -0500 From: "Keshab Upadhya" To: , "'RFC Errata System'" , , , , , , , References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 14 Sep 2015 15:12:42 +0800 Message-ID: <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D0EEFF.D10548C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo4wKUwjtLAhJLB9+c8aLg8A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 112.198.79.128 X-Exim-ID: 1ZbNwX-0003ma-Dr X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Keshab) [112.198.79.128]:47519 X-Source-Auth: allan X-Email-Count: 49 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 10:16:53 -0700 Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 07:12:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D0EEFF.D10548C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lionel, =20 Thank you for valuable feedback. =20 I believe your understanding is inline and primarily what you've = summarized below clarifies objectively, thank you. =20 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)." =20 As per above statement if realm is present and if application is not = locally supported then below action will be taken place. =93---- if not, route the request based on Realm/application (section = 6.1.6)=94 =20 What will happen if towards a server peer node where hostname is = incorrect and application id with realm locally supported? =20 Understanding from RFC - If we go with 6.1.4, such message shouldn=92t = 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. =20 After giving a second though on specs in section 6.1.4, if following altered=96 =20 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 =20 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 =20 It will eliminate the contradiction. =20 Please help enlighten us on this. =20 Thank you, Keshab. =20 -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Thursday, September 10, 2015 11:15 PM To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com Cc: dime@ietf.org Subject: RE: [Technical Errata Reported] RFC6733 (4462) =20 Hi Keshab, =20 I'm not totally sure to understand your concern.=20 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. =20 To make a long story short...=20 =20 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) =20 Let me know if it is OK for you. =20 Lionel =20 -----Message d'origine----- De : Keshab Upadhya [ mailto:keshab@smsgt.com] Envoy=E9 : jeudi 10 septembre 2015 05:26 =C0 : 'RFC Errata System'; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; = bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc : dime@ietf.org Objet : RE: = [Technical Errata Reported] RFC6733 (4462) =20 Hi All, =20 Good day! =20 Could you please help on below request raised as conflict in RFC-6733? =20 Kindly consider this as an urgent request. =20 Thank you, =20 Regards, Keshab. =20 -----Original Message----- From: RFC Errata System [ mailto:rfc-editor@rfc-editor.org] Sent: Wednesday, September 2, 2015 9:09 AM To: vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; = bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com; lionel.morand@orange.com Cc: keshab@smsgt.com; dime@ietf.org; = rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC6733 (4462) =20 The following errata report has been submitted for RFC6733, "Diameter = Base Protocol". =20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 =20 -------------------------------------- Type: Technical Reported by: Keshab Upadhya < = keshab@smsgt.com> =20 Section: 6.1.4 6.1.6 =20 Original Text ------------- 6.1.4. Processing Local Requests =20 A request is known to be for local consumption when one of the following conditions occurs: =20 o The Destination-Host AVP contains the local host's identity; =20 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 =20 o Both the Destination-Host and the Destination-Realm are not present. =20 6.1.6. Request Routing =20 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. =20 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). =20 Realm names and Application Ids are the minimum supported routing criteria, additional information may be needed to support redirect semantics. =20 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 =20 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 =20 =20 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. =20 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.=20 =20 -------------------------------------- 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 =20 =20 _________________________________________________________________________= ___ _____________________________________________ =20 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. =20 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. ------=_NextPart_000_0064_01D0EEFF.D10548C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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.=A0 Processing Local = Requests

=A0=A0 A request is known = to be for local consumption when one of the

=A0=A0 following conditions = occurs:

=A0=A0 o=A0 The = Destination-Host AVP contains the local host's = identity;

=A0=A0 o=A0 The = Destination-Host AVP is not present, the Destination-Realm = AVP

=A0=A0=A0=A0=A0 = contains a realm the server is configured to process locally, = and

=A0=A0=A0=A0=A0the = Diameter application is locally supported; or

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

=A0=A0=A0=A0=A0 present

 

Altered -

6.1.4.=A0 Processing Local = Requests

=A0=A0 A request is known = to be for local consumption when one of the

=A0=A0 following conditions = occurs:

=A0=A0 o=A0 The = Destination-Host AVP contains the local host's = identity;

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

=A0=A0=A0=A0=A0 contains a realm the server is = configured to process locally, and

=A0=A0=A0=A0=A0the Diameter application is = locally supported; or

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

=A0=A0=A0=A0=A0 = present

 

It will eliminate the = contradiction.

 

Please = help enlighten us on this.

 

Thank = you,

Keshab.

 

-----Original Message-----
From: = lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: = Thursday, September 10, 2015 11:15 PM
To: Keshab Upadhya; 'RFC Errata = System'; vf0213@gmail.com; jari.arkko@ericsson.com; = john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; = joelja@bogus.com; jouni.nospam@gmail.com
Cc: = dime@ietf.org
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:keshab@smsgt.com] Envoy=E9 : jeudi 10 septembre 2015 05:26 =C0 : 'RFC = Errata System'; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com= ; bclaise@cisco.com<= /a>; joelja@bogus.com; jouni.nospam@gmail.com; MORAND Lionel IMT/OLN Cc : dime@ietf.org = 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:rfc-editor@rfc-edi= tor.org]

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

To: vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com= ; bclaise@cisco.com<= /a>; joelja@bogus.com; jouni.nospam@gmail.com; lionel.morand@orange.com<= /span>

Cc: keshab@smsgt.com; dime@ietf.org;= rfc-editor@rfc-editor.org=

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=3D6733&eid=3D4462

 

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

Type: Technical

Reported by: Keshab Upadhya <keshab@smsgt.com>

 

Section: 6.1.4 6.1.6

 

Original Text

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

6.1.4.=A0 Processing Local = Requests

 

=A0=A0 A request is known to be for local = consumption when one of the

=A0=A0 = following conditions occurs:

 

=A0=A0 = o=A0 The Destination-Host AVP contains the local host's = identity;

 

=A0=A0 o=A0 The Destination-Host AVP is not = present, the Destination-Realm AVP

=A0=A0=A0=A0=A0 contains a realm the server is = configured to process locally, and

=A0=A0=A0=A0=A0the Diameter application is locally = supported; or

 

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

=A0=A0=A0=A0=A0 = present.

 

6.1.6.=A0 Request Routing

 

=A0=A0 = Diameter request message routing is done via realms and = Application

=A0=A0 Ids. A Diameter = message that may be forwarded by Diameter agents

=A0=A0 (proxies, redirect agents, or relay agents) = MUST include the target

=A0=A0 = realm in the Destination-Realm AVP.=A0 Request routing SHOULD rely = on

=A0=A0 the Destination-Realm = AVP and the Application Id present in the

=A0=A0 request message header to aid in the routing = decision.=A0 The realm MAY

=A0=A0 = be retrieved from the User-Name AVP, which is in the form of = a

=A0=A0 Network Access Identifier = (NAI).=A0 The realm portion of the NAI is

=A0=A0 inserted in the Destination-Realm = AVP.

 

=A0=A0 Diameter agents MAY have a list of locally = supported realms and

=A0=A0 = applications, and they MAY have a list of externally supported = realms

=A0=A0 and applications.=A0 = When a request is received that includes a realm

=A0=A0 and/or application that is not locally = supported, the message is

=A0=A0 = routed to the peer configured in the routing table (see Section = 2.7).

 

=A0=A0 Realm names and Application Ids are the = minimum supported routing

=A0=A0 = criteria, additional information may be needed to support = redirect

=A0=A0 = semantics.

 

Corrected Text

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

6.1.6 -

=A0 = When a request is received that includes a realm

=A0=A0 and/or application that is not locally = supported, the message is

=A0=A0 = routed to the peer configured

 

conflicts with 6.1.4 -

=A0=A0 The Destination-Host AVP is not present, the = Destination-Realm AVP

=A0=A0=A0=A0=A0 contains a realm the server is = configured to process locally, and

=A0=A0=A0=A0=A0 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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = : Diameter Base Protocol

Publication Date=A0=A0=A0 : October = 2012

Author(s)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : V. = Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.

Category=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = PROPOSED STANDARD

Source=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = Diameter Maintenance and Extensions

Area=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = Operations and Management

Stream=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = IETF

Verifying Party=A0=A0=A0=A0 : = 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.

------=_NextPart_000_0064_01D0EEFF.D10548C0-- From nobody Mon Sep 14 10:16:56 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BCE1B510A for ; Mon, 14 Sep 2015 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqgrPQxHXoCs for ; Mon, 14 Sep 2015 00:58:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 872E01B4E3F for ; Mon, 14 Sep 2015 00:58:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1B9CA180204; Mon, 14 Sep 2015 00:58:21 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150914075821.1B9CA180204@rfc-editor.org> Date: Mon, 14 Sep 2015 00:58:21 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 10:16:53 -0700 Cc: rfc-editor@rfc-editor.org, dime@ietf.org, keshab@smsgt.com Subject: [Dime] [Technical Errata Reported] RFC6733 (4473) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 07:58:47 -0000 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=4473 -------------------------------------- Type: Technical Reported by: Keshab Upadhya Section: 6.1.4 Original Text ------------- 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 Corrected Text -------------- 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. 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 nobody Tue Sep 15 15:56:43 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F81B2A03 for ; Tue, 15 Sep 2015 14:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ybh1oLEKth for ; Tue, 15 Sep 2015 14:25:50 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C631B29C4 for ; Tue, 15 Sep 2015 14:25:50 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so190779217pac.2 for ; Tue, 15 Sep 2015 14:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=1112mUHoYCjz5SFBf7BMW/cmrm55BjcsFwCw3j/Nx38=; b=Q8YCwTRvMXBqUTgXkBJV0LzcAstyOsrKJ8WEYCIhHdw8CLB2AYOKhPdUbk9quRiCAY ngFP3TTM9EkYt6QOIYBh9L4qXC86588YG0heZ8JUwoU20LE/qjlFeEI9zP/uVLTPxJPv rVI5yOZQoZLJW6y6IbXaMa9oDIE5gYYrDlH69gqawHL4xpFSLdjk8zbYF5R9jP1o162+ 0S5NWfnrrZDyrONb+wWtsGgRtBV5GJVtBvRYGMYKJt8rhujoluNMyj4b862Jdfg8jwYm ttQvODwDENF9J5n9SGZ/D9gKKj2xe0oTxXYH1Id7moHLZjCInIYZbJDES4kBI/gZnkHN tt0w== X-Received: by 10.68.99.197 with SMTP id es5mr51388054pbb.112.1442352349842; Tue, 15 Sep 2015 14:25:49 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:7cae:10f7:3319:53f8? ([2601:647:4204:228b:7cae:10f7:3319:53f8]) by smtp.googlemail.com with ESMTPSA id df2sm23901545pad.19.2015.09.15.14.25.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 14:25:48 -0700 (PDT) To: Keshab Upadhya , lionel.morand@orange.com, 'RFC Errata System' , vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> From: Jouni Korhonen Message-ID: <55F88CDA.4080801@gmail.com> Date: Tue, 15 Sep 2015 14:25:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 15:56:42 -0700 Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 21:25:52 -0000 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: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Thursday, September 10, 2015 11:15 PM > To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com; > jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; > bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com > Cc: dime@ietf.org > 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:keshab@smsgt.com] Envoyé : jeudi 10 > septembre 2015 05:26 À : 'RFC Errata System'; vf0213@gmail.com > ; jari.arkko@ericsson.com > ; john.loughney@nokia.com > ; glenzorn@gmail.com > ; bclaise@cisco.com > ; joelja@bogus.com ; > jouni.nospam@gmail.com ; MORAND Lionel > IMT/OLN Cc : dime@ietf.org 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:rfc-editor@rfc-editor.org] > > Sent: Wednesday, September 2, 2015 9:09 AM > > To: vf0213@gmail.com ; jari.arkko@ericsson.com > ; john.loughney@nokia.com > ; glenzorn@gmail.com > ; bclaise@cisco.com > ; joelja@bogus.com ; > jouni.nospam@gmail.com ; > lionel.morand@orange.com > > Cc: keshab@smsgt.com ; dime@ietf.org > ; rfc-editor@rfc-editor.org > > > 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 > > > 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. > From nobody Tue Sep 15 21:31:03 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C691B3204 for ; Tue, 15 Sep 2015 19:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImfZgSXJcvFx for ; Tue, 15 Sep 2015 19:56:27 -0700 (PDT) Received: from gateway26.websitewelcome.com (gateway26.websitewelcome.com [192.185.84.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE631B3202 for ; Tue, 15 Sep 2015 19:56:27 -0700 (PDT) Received: by gateway26.websitewelcome.com (Postfix, from userid 1000) id B411DCB539702; Tue, 15 Sep 2015 21:56:26 -0500 (CDT) Received: from cm1.websitewelcome.com (cm.websitewelcome.com [192.185.0.102]) by gateway26.websitewelcome.com (Postfix) with ESMTP id AF051CB5392DE for ; Tue, 15 Sep 2015 21:56:26 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm1.websitewelcome.com with id HewR1r00G1q3akG01ewSe4; Tue, 15 Sep 2015 21:56:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=w3gWURoF0zdyU2xgpSyTI6QS1MPDcchOYhQGrTMCxiA=; b=MgP7gDLlmCbxSAqDExKW4jOczLv+CDS6BntAlQP8F+i0DRU2t59pK7ZpH9YUyhHGn89rRUZOZOnafnFPYmfKIl3bMSIJmDoGO3i8BgXOu5E3kp+EbmPda97Decb/ZP2z67MlYBt/kTO/eHIW2BzzEpytnEMBD6uHGDg1uzy4vkc=; Received: from [121.58.195.226] (port=49201 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1Zc2tU-000P50-FR; Tue, 15 Sep 2015 21:56:24 -0500 From: "Keshab Upadhya" To: "'Jouni Korhonen'" , , "'RFC Errata System'" , , , , , , References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> In-Reply-To: <55F88CDA.4080801@gmail.com> Date: Wed, 16 Sep 2015 10:56:16 +0800 Message-ID: <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo4wKUwjtLAhJLB98CRIxEQwDxKOsknNrJx9A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 121.58.195.226 X-Exim-ID: 1Zc2tU-000P50-FR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Keshab) [121.58.195.226]:49201 X-Source-Auth: allan X-Email-Count: 148 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 21:31:02 -0700 Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 02:56:30 -0000 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:jouni.nospam@gmail.com]=20 Sent: Wednesday, September 16, 2015 5:26 AM To: Keshab Upadhya; lionel.morand@orange.com; 'RFC Errata System'; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com Cc: dime@ietf.org 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=20 > 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=20 > 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=20 > locally supported then below action will be taken place. > > =93---- if not, route the request based on Realm/application (section 6.1.6)=94 > > What will happen if towards a server peer node where hostname is=20 > incorrect and application id with realm locally supported? > > Understanding from RFC - If we go with 6.1.4, such message shouldn=92t = > be processed locally but if we go with 6.1.6 message looks like should = > be processed locally based on above given underlined statement,=20 > defines contradiction of 6.1.4 & 6.1.6. > > After giving a second though on specs in section 6.1.4, if following=20 > altered=96 > > *_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=20 > 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=20 > 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: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Thursday, September 10, 2015 11:15 PM > To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com;=20 > jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;=20 > bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com > Cc: dime@ietf.org > 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=20 > processing locally a request (i.e. how to know that the receiving=20 > 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=20 > 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=20 > 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=20 > 6.1.5) > > ---- if not, route the request based on Realm/application (section=20 > 6.1.6) > > Let me know if it is OK for you. > > Lionel > > -----Message d'origine----- > > De : Keshab Upadhya [mailto:keshab@smsgt.com] Envoy=E9 : jeudi 10=20 > septembre 2015 05:26 =C0 : 'RFC Errata System'; vf0213@gmail.com=20 > ; jari.arkko@ericsson.com=20 > ; john.loughney@nokia.com=20 > ; glenzorn@gmail.com=20 > ; bclaise@cisco.com=20 > ; joelja@bogus.com=20 > ; jouni.nospam@gmail.com=20 > ; MORAND Lionel IMT/OLN Cc :=20 > dime@ietf.org Objet : RE: [Technical Errata=20 > 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:rfc-editor@rfc-editor.org] > > Sent: Wednesday, September 2, 2015 9:09 AM > > To: vf0213@gmail.com ;=20 > jari.arkko@ericsson.com ;=20 > john.loughney@nokia.com ;=20 > glenzorn@gmail.com ; bclaise@cisco.com=20 > ; joelja@bogus.com=20 > ; jouni.nospam@gmail.com=20 > ; lionel.morand@orange.com=20 > > > Cc: keshab@smsgt.com ; dime@ietf.org=20 > ; rfc-editor@rfc-editor.org=20 > > > Subject: [Technical Errata Reported] RFC6733 (4462) > > The following errata report has been submitted for RFC6733, "Diameter=20 > Base Protocol". > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 > > -------------------------------------- > > Type: Technical > > Reported by: Keshab Upadhya > > > 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=20 > AVP > > contains a realm the server is configured to process locally,=20 > 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=20 > Application > > Ids. A Diameter message that may be forwarded by Diameter agents > > (proxies, redirect agents, or relay agents) MUST include the=20 > target > > realm in the Destination-Realm AVP. Request routing SHOULD rely=20 > on > > the Destination-Realm AVP and the Application Id present in the > > request message header to aid in the routing decision. The realm=20 > 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=20 > realms > > and applications. When a request is received that includes a=20 > 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,=20 > and > > the Diameter application is locally supported > > Notes > > ----- > > please guide if 6.1.4 Local processing - "hostname not present" needs=20 > to be amended by "not present in host peer routing table". otherwise=20 > it conflicts with 6.1.6. > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > 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=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > 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=20 > been modified, changed or falsified. > > Thank you. > From nobody Tue Sep 15 21:37:54 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860C41B32BF for ; Tue, 15 Sep 2015 21:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL4oGeR32kXc for ; Tue, 15 Sep 2015 21:37:47 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49B71B331B for ; Tue, 15 Sep 2015 21:37:47 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so200862888pac.2 for ; Tue, 15 Sep 2015 21:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qfaa5YmJmd9iHNhInWRvGHZXmvEpvpq41OvdYhW5cOo=; b=vcYLrfQo6D6R73nKzJaf6E/JKExAe1NRDGSe3KRLr5P7KE9h0/cifuueW4hRqnHZuf LA/GUsZ6fWGKe/kY2rYIzXfot5uUGYCFntuk7dvrsUa2TR7TpRQ1cG7dLf2JYPXIWQg7 gQyi1Uxrcc2/NLApsQ/R0GR/GOVRY6n1FDk57xHM2oN+OFK8J0XCTxagu8OzJ8WKUn21 fvbKBfNL7i9VVt8809aaZtk4gByJVRc6VAZc3oYrbMVWsNLGtRcQGstw+KYGJl9QIqYU uaEox5AfXArADg9kzkND0mPPEf2TyVXka/JWkv73gvA6PkxWnD3JCIOeDec0QhQQRonq QX6g== X-Received: by 10.68.111.3 with SMTP id ie3mr56201766pbb.63.1442378267294; Tue, 15 Sep 2015 21:37:47 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:d188:6c63:84b1:fa6f? ([2601:647:4204:228b:d188:6c63:84b1:fa6f]) by smtp.gmail.com with ESMTPSA id lg7sm25029520pbc.1.2015.09.15.21.37.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Sep 2015 21:37:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> Date: Tue, 15 Sep 2015 21:37:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> To: Keshab Upadhya X-Mailer: Apple Mail (2.2104) Archived-At: Cc: joel jaeggli , RFC Errata System , "dime@ietf.org list" Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 04:37:50 -0000 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 wrote: >=20 > Hi Jouni, >=20 > Thank you for response. >=20 > Yes, return error looks like suitable option here as well however it's = not > mentioned in RFC6733, 1.6.5 explicitly. >=20 > What will be recommended alteration and which section it will be = applicable? > Kindly advice. >=20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Wednesday, September 16, 2015 5:26 AM > To: Keshab Upadhya; lionel.morand@orange.com; 'RFC Errata System'; > vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; > glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com > Cc: dime@ietf.org > Subject: Re: [Technical Errata Reported] RFC6733 (4462) >=20 >=20 > 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. >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > 9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti: >> Hi Lionel, >>=20 >> Thank you for valuable feedback. >>=20 >> I believe your understanding is inline and primarily what you've=20 >> summarized below clarifies objectively, thank you. >>=20 >> Confusion with below statement of 6.1.6, paragraph 2: >>=20 >> "When a request is received that includes a *_realm_* and/or >> *_application_* that is *_not_* locally supported, the message is=20 >> routed to the peer configured in the routing table (see Section = 2.7)." >>=20 >> As per above statement if realm is present and if application is not=20= >> locally supported then below action will be taken place. >>=20 >> =E2=80=9C---- if not, route the request based on Realm/application = (section > 6.1.6)=E2=80=9D >>=20 >> What will happen if towards a server peer node where hostname is=20 >> incorrect and application id with realm locally supported? >>=20 >> Understanding from RFC - If we go with 6.1.4, such message = shouldn=E2=80=99t=20 >> be processed locally but if we go with 6.1.6 message looks like = should=20 >> be processed locally based on above given underlined statement,=20 >> defines contradiction of 6.1.4 & 6.1.6. >>=20 >> After giving a second though on specs in section 6.1.4, if following=20= >> altered=E2=80=93 >>=20 >> *_Original -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present, the Destination-Realm=20= >> AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> *_Altered -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present _in local peer routing=20= >> table_, the Destination-Realm AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> It will eliminate the contradiction. >>=20 >> Please help enlighten us on this. >>=20 >> Thank you, >>=20 >> Keshab. >>=20 >> -----Original Message----- >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Thursday, September 10, 2015 11:15 PM >> To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com;=20 >> jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;=20= >> bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com >> Cc: dime@ietf.org >> Subject: RE: [Technical Errata Reported] RFC6733 (4462) >>=20 >> Hi Keshab, >>=20 >> I'm not totally sure to understand your concern. >>=20 >> The purpose of the section 6.1.4 is to give the conditions for=20 >> processing locally a request (i.e. how to know that the receiving=20 >> entity is the one that needs to answer to the request?) and nothing = else. >>=20 >> The case you are referring to is covered in the section 6.1.6 and=20 >> should not be part of section 6.1.4. >>=20 >> To make a long story short... >>=20 >> if the Destination-Host is present, >>=20 >> - if the identity is equal to the local host's identity --> process=20= >> locally (section 6.1.4) >>=20 >> - if the identity is not equal to the local host's identity, check = the=20 >> peer table. >>=20 >> ---- If it is the peer table, forward the request to the peer (sect=20= >> 6.1.5) >>=20 >> ---- if not, route the request based on Realm/application (section=20 >> 6.1.6) >>=20 >> Let me know if it is OK for you. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >>=20 >> De : Keshab Upadhya [mailto:keshab@smsgt.com] Envoy=C3=A9 : jeudi 10=20= >> septembre 2015 05:26 =C5=94 : 'RFC Errata System'; vf0213@gmail.com=20= >> ; jari.arkko@ericsson.com=20 >> ; john.loughney@nokia.com=20 >> ; glenzorn@gmail.com=20 >> ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; MORAND Lionel IMT/OLN Cc :=20 >> dime@ietf.org Objet : RE: [Technical Errata=20 >> Reported] RFC6733 (4462) >>=20 >> Hi All, >>=20 >> Good day! >>=20 >> Could you please help on below request raised as conflict in = RFC-6733? >>=20 >> Kindly consider this as an urgent request. >>=20 >> Thank you, >>=20 >> Regards, >>=20 >> Keshab. >>=20 >> -----Original Message----- >>=20 >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>=20 >> Sent: Wednesday, September 2, 2015 9:09 AM >>=20 >> To: vf0213@gmail.com ;=20 >> jari.arkko@ericsson.com ;=20 >> john.loughney@nokia.com ;=20 >> glenzorn@gmail.com ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; lionel.morand@orange.com=20 >> >>=20 >> Cc: keshab@smsgt.com ; dime@ietf.org=20 >> ; rfc-editor@rfc-editor.org=20 >> >>=20 >> Subject: [Technical Errata Reported] RFC6733 (4462) >>=20 >> The following errata report has been submitted for RFC6733, "Diameter=20= >> Base Protocol". >>=20 >> -------------------------------------- >>=20 >> You may review the report below and at: >>=20 >> http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 >>=20 >> -------------------------------------- >>=20 >> Type: Technical >>=20 >> Reported by: Keshab Upadhya > > >>=20 >> Section: 6.1.4 6.1.6 >>=20 >> Original Text >>=20 >> ------------- >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o The Destination-Host AVP is not present, the Destination-Realm=20= >> AVP >>=20 >> contains a realm the server is configured to process locally,=20= >> and >>=20 >> the Diameter application is locally supported; or >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present. >>=20 >> 6.1.6. Request Routing >>=20 >> Diameter request message routing is done via realms and=20 >> Application >>=20 >> Ids. A Diameter message that may be forwarded by Diameter agents >>=20 >> (proxies, redirect agents, or relay agents) MUST include the=20 >> target >>=20 >> realm in the Destination-Realm AVP. Request routing SHOULD rely=20= >> on >>=20 >> the Destination-Realm AVP and the Application Id present in the >>=20 >> request message header to aid in the routing decision. The realm=20= >> MAY >>=20 >> be retrieved from the User-Name AVP, which is in the form of a >>=20 >> Network Access Identifier (NAI). The realm portion of the NAI is >>=20 >> inserted in the Destination-Realm AVP. >>=20 >> Diameter agents MAY have a list of locally supported realms and >>=20 >> applications, and they MAY have a list of externally supported=20 >> realms >>=20 >> and applications. When a request is received that includes a=20 >> realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured in the routing table (see Section = 2.7). >>=20 >> Realm names and Application Ids are the minimum supported routing >>=20 >> criteria, additional information may be needed to support redirect >>=20 >> semantics. >>=20 >> Corrected Text >>=20 >> -------------- >>=20 >> 6.1.6 - >>=20 >> When a request is received that includes a realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured >>=20 >> conflicts with 6.1.4 - >>=20 >> The Destination-Host AVP is not present, the Destination-Realm AVP >>=20 >> contains a realm the server is configured to process locally,=20= >> and >>=20 >> the Diameter application is locally supported >>=20 >> Notes >>=20 >> ----- >>=20 >> please guide if 6.1.4 Local processing - "hostname not present" needs=20= >> to be amended by "not present in host peer routing table". otherwise=20= >> it conflicts with 6.1.6. >>=20 >> Instructions: >>=20 >> ------------- >>=20 >> This erratum is currently posted as "Reported". If necessary, please=20= >> use "Reply All" to discuss whether it should be verified or rejected.=20= >> When a decision is reached, the verifying party (IESG) can log in to=20= >> change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >>=20 >> RFC6733 (draft-ietf-dime-rfc3588bis-33) >>=20 >> -------------------------------------- >>=20 >> Title : Diameter Base Protocol >>=20 >> Publication Date : October 2012 >>=20 >> Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. = Zorn, Ed. >>=20 >> Category : PROPOSED STANDARD >>=20 >> Source : Diameter Maintenance and Extensions >>=20 >> Area : Operations and Management >>=20 >> Stream : IETF >>=20 >> Verifying Party : IESG >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20= >> que les pieces jointes. Les messages electroniques etant susceptibles=20= >> d'alteration, Orange decline toute responsabilite si ce message a ete=20= >> altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not=20= >> be distributed, used or copied without authorisation. >>=20 >> If you have received this email in error, please notify the sender = and=20 >> delete this message and its attachments. >>=20 >> As emails may be altered, Orange is not liable for messages that have=20= >> been modified, changed or falsified. >>=20 >> Thank you. From nobody Tue Sep 15 23:03:55 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E301B35A3 for ; Tue, 15 Sep 2015 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-wy20JggvM5 for ; Tue, 15 Sep 2015 23:03:51 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6181B359A for ; Tue, 15 Sep 2015 23:03:51 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 183DE5293BF3D; Wed, 16 Sep 2015 01:03:51 -0500 (CDT) Received: from cm2.websitewelcome.com (unknown [192.185.178.13]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 158085293BEE3 for ; Wed, 16 Sep 2015 01:03:51 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm2.websitewelcome.com with id Hi3p1r0141q3akG01i3qph; Wed, 16 Sep 2015 01:03:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Lp2AB8K8RcsLVC4I3qSYrQEbwFgPdiGsPrOu+Y4Ti38=; b=k0AWw/fdDEwJO7kuruHVP+777FRUBCpypSMBW9+odV/0Q7L6HbLj7q9zJwVpq6HHSxKgZiLYqbcFACIvqxovskcyBQ894wOkL3EtOEbenvAAyvBPTTGQ58/1Ud5TMT39wlnRYc2iFNyFiqlOrSYxw+FywUXb1jJc3XjcSO3AJqw=; Received: from [112.198.77.84] (port=64562 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1Zc5oo-000FXT-Bs; Wed, 16 Sep 2015 01:03:49 -0500 From: "Keshab Upadhya" To: "'Jouni'" References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> In-Reply-To: <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> Date: Wed, 16 Sep 2015 14:03:29 +0800 Message-ID: <00d501d0f045$70dd8600$52989200$@smsgt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo4wKUwjtLAhJLB98CRIxEQwDxKOskAlk4ZDsCWFaJxpy1iGlQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 112.198.77.84 X-Exim-ID: 1Zc5oo-000FXT-Bs X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Keshab) [112.198.77.84]:64562 X-Source-Auth: allan X-Email-Count: 24 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: Cc: 'joel jaeggli' , 'RFC Errata System' , dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 06:03:54 -0000 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:jouni.nospam@gmail.com]=20 Sent: Wednesday, September 16, 2015 12:38 PM To: Keshab Upadhya Cc: ext lionel.morand@orange.com; RFC Errata System; Benoit Claise; joel = jaeggli; dime@ietf.org list Subject: Re: [Technical Errata Reported] RFC6733 (4462) 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 wrote: >=20 > Hi Jouni, >=20 > Thank you for response. >=20 > Yes, return error looks like suitable option here as well however it's = > not mentioned in RFC6733, 1.6.5 explicitly. >=20 > What will be recommended alteration and which section it will be = applicable? > Kindly advice. >=20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Wednesday, September 16, 2015 5:26 AM > To: Keshab Upadhya; lionel.morand@orange.com; 'RFC Errata System';=20 > vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com;=20 > glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com > Cc: dime@ietf.org > Subject: Re: [Technical Errata Reported] RFC6733 (4462) >=20 >=20 > The proposed correction does not seem right. For routing to work all=20 > nodes within a realm must be peer, which in this case does not seem to = > hold. I would just return an error. >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > 9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti: >> Hi Lionel, >>=20 >> Thank you for valuable feedback. >>=20 >> I believe your understanding is inline and primarily what you've=20 >> summarized below clarifies objectively, thank you. >>=20 >> Confusion with below statement of 6.1.6, paragraph 2: >>=20 >> "When a request is received that includes a *_realm_* and/or >> *_application_* that is *_not_* locally supported, the message is=20 >> routed to the peer configured in the routing table (see Section = 2.7)." >>=20 >> As per above statement if realm is present and if application is not=20 >> locally supported then below action will be taken place. >>=20 >> =E2=80=9C---- if not, route the request based on Realm/application = (section > 6.1.6)=E2=80=9D >>=20 >> What will happen if towards a server peer node where hostname is=20 >> incorrect and application id with realm locally supported? >>=20 >> Understanding from RFC - If we go with 6.1.4, such message = shouldn=E2=80=99t=20 >> be processed locally but if we go with 6.1.6 message looks like=20 >> should be processed locally based on above given underlined=20 >> statement, defines contradiction of 6.1.4 & 6.1.6. >>=20 >> After giving a second though on specs in section 6.1.4, if following=20 >> altered=E2=80=93 >>=20 >> *_Original -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present, the Destination-Realm >> AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> *_Altered -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present _in local peer routing=20 >> table_, the Destination-Realm AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> It will eliminate the contradiction. >>=20 >> Please help enlighten us on this. >>=20 >> Thank you, >>=20 >> Keshab. >>=20 >> -----Original Message----- >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Thursday, September 10, 2015 11:15 PM >> To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com;=20 >> jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; = >> bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com >> Cc: dime@ietf.org >> Subject: RE: [Technical Errata Reported] RFC6733 (4462) >>=20 >> Hi Keshab, >>=20 >> I'm not totally sure to understand your concern. >>=20 >> The purpose of the section 6.1.4 is to give the conditions for=20 >> processing locally a request (i.e. how to know that the receiving=20 >> entity is the one that needs to answer to the request?) and nothing = else. >>=20 >> The case you are referring to is covered in the section 6.1.6 and=20 >> should not be part of section 6.1.4. >>=20 >> To make a long story short... >>=20 >> if the Destination-Host is present, >>=20 >> - if the identity is equal to the local host's identity --> process=20 >> locally (section 6.1.4) >>=20 >> - if the identity is not equal to the local host's identity, check=20 >> the peer table. >>=20 >> ---- If it is the peer table, forward the request to the peer (sect >> 6.1.5) >>=20 >> ---- if not, route the request based on Realm/application (section >> 6.1.6) >>=20 >> Let me know if it is OK for you. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >>=20 >> De : Keshab Upadhya [mailto:keshab@smsgt.com] Envoy=C3=A9 : jeudi 10=20 >> septembre 2015 05:26 =C5=94 : 'RFC Errata System'; vf0213@gmail.com=20 >> ; jari.arkko@ericsson.com=20 >> ; john.loughney@nokia.com=20 >> ; glenzorn@gmail.com=20 >> ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; MORAND Lionel IMT/OLN Cc : >> dime@ietf.org Objet : RE: [Technical Errata=20 >> Reported] RFC6733 (4462) >>=20 >> Hi All, >>=20 >> Good day! >>=20 >> Could you please help on below request raised as conflict in = RFC-6733? >>=20 >> Kindly consider this as an urgent request. >>=20 >> Thank you, >>=20 >> Regards, >>=20 >> Keshab. >>=20 >> -----Original Message----- >>=20 >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>=20 >> Sent: Wednesday, September 2, 2015 9:09 AM >>=20 >> To: vf0213@gmail.com ;=20 >> jari.arkko@ericsson.com ;=20 >> john.loughney@nokia.com ;=20 >> glenzorn@gmail.com ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; lionel.morand@orange.com=20 >> >>=20 >> Cc: keshab@smsgt.com ; dime@ietf.org=20 >> ; rfc-editor@rfc-editor.org=20 >> >>=20 >> Subject: [Technical Errata Reported] RFC6733 (4462) >>=20 >> The following errata report has been submitted for RFC6733, "Diameter = >> Base Protocol". >>=20 >> -------------------------------------- >>=20 >> You may review the report below and at: >>=20 >> http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 >>=20 >> -------------------------------------- >>=20 >> Type: Technical >>=20 >> Reported by: Keshab Upadhya > > >>=20 >> Section: 6.1.4 6.1.6 >>=20 >> Original Text >>=20 >> ------------- >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o The Destination-Host AVP is not present, the Destination-Realm=20 >> AVP >>=20 >> contains a realm the server is configured to process locally,=20 >> and >>=20 >> the Diameter application is locally supported; or >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present. >>=20 >> 6.1.6. Request Routing >>=20 >> Diameter request message routing is done via realms and=20 >> Application >>=20 >> Ids. A Diameter message that may be forwarded by Diameter agents >>=20 >> (proxies, redirect agents, or relay agents) MUST include the=20 >> target >>=20 >> realm in the Destination-Realm AVP. Request routing SHOULD rely=20 >> on >>=20 >> the Destination-Realm AVP and the Application Id present in the >>=20 >> request message header to aid in the routing decision. The realm=20 >> MAY >>=20 >> be retrieved from the User-Name AVP, which is in the form of a >>=20 >> Network Access Identifier (NAI). The realm portion of the NAI is >>=20 >> inserted in the Destination-Realm AVP. >>=20 >> Diameter agents MAY have a list of locally supported realms and >>=20 >> applications, and they MAY have a list of externally supported=20 >> realms >>=20 >> and applications. When a request is received that includes a=20 >> realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured in the routing table (see Section = 2.7). >>=20 >> Realm names and Application Ids are the minimum supported routing >>=20 >> criteria, additional information may be needed to support redirect >>=20 >> semantics. >>=20 >> Corrected Text >>=20 >> -------------- >>=20 >> 6.1.6 - >>=20 >> When a request is received that includes a realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured >>=20 >> conflicts with 6.1.4 - >>=20 >> The Destination-Host AVP is not present, the Destination-Realm AVP >>=20 >> contains a realm the server is configured to process locally,=20 >> and >>=20 >> the Diameter application is locally supported >>=20 >> Notes >>=20 >> ----- >>=20 >> please guide if 6.1.4 Local processing - "hostname not present" needs = >> to be amended by "not present in host peer routing table". otherwise=20 >> it conflicts with 6.1.6. >>=20 >> Instructions: >>=20 >> ------------- >>=20 >> This erratum is currently posted as "Reported". If necessary, please=20 >> 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=20 >> change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >>=20 >> RFC6733 (draft-ietf-dime-rfc3588bis-33) >>=20 >> -------------------------------------- >>=20 >> Title : Diameter Base Protocol >>=20 >> Publication Date : October 2012 >>=20 >> Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. = Zorn, Ed. >>=20 >> Category : PROPOSED STANDARD >>=20 >> Source : Diameter Maintenance and Extensions >>=20 >> Area : Operations and Management >>=20 >> Stream : IETF >>=20 >> Verifying Party : IESG >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not=20 >> be distributed, used or copied without authorisation. >>=20 >> If you have received this email in error, please notify the sender=20 >> and delete this message and its attachments. >>=20 >> As emails may be altered, Orange is not liable for messages that have = >> been modified, changed or falsified. >>=20 >> Thank you. From nobody Wed Sep 16 22:38:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BF1B3255 for ; Wed, 16 Sep 2015 22:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBz2Nne6Pkvy for ; Wed, 16 Sep 2015 22:38:09 -0700 (PDT) Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [192.185.200.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F72F1B323B for ; Wed, 16 Sep 2015 22:38:09 -0700 (PDT) Received: by gateway36.websitewelcome.com (Postfix, from userid 1000) id A11B3D1623CA7; Thu, 17 Sep 2015 00:38:08 -0500 (CDT) Received: from cm2.websitewelcome.com (unknown [192.185.178.13]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 9D92DD1624817 for ; Thu, 17 Sep 2015 00:38:08 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm2.websitewelcome.com with id J5e71r00S1q3akG015e8l9; Thu, 17 Sep 2015 00:38:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=WcxlNoC3KSw3ZmCPuvFhHKocQoRLKU6gkxPRIGYHcQ0=; b=T3VgKRG22v3Sdv7YsdqcsyMJji7htAmr67+LvIxwwZdjtNxh6/0n6DKA9+5A9ucG66dJHNbhwKxW6MDVYuXhb2Y0+TIme61zA7E2S6uFmmcws05LnN5DHyEQ4j1buxYY8lgvIgWvD3HkSacNw5pScSlHR4rCAftaigsBwODhZtE=; Received: from [222.127.111.146] (port=55353 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZcRsr-0009NA-KJ; Thu, 17 Sep 2015 00:38:06 -0500 From: "Keshab Upadhya" To: "'Jouni'" References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> In-Reply-To: Date: Thu, 17 Sep 2015 13:37:17 +0800 Message-ID: <000001d0f10a$ece43490$c6ac9db0$@smsgt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo4wKUwjtLAhJLB98CRIxEQwDxKOskAlk4ZDsCWFaJxpy1iGlQgAFsnsA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 222.127.111.146 X-Exim-ID: 1ZcRsr-0009NA-KJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (Keshab) [222.127.111.146]:55353 X-Source-Auth: allan X-Email-Count: 46 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: Cc: 'joel jaeggli' , 'RFC Errata System' , dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 05:38:12 -0000 Hi, Please help with below query. Thank you. Regards, Keshab. -----Original Message----- From: Keshab Upadhya [mailto:keshab@smsgt.com]=20 Sent: Wednesday, September 16, 2015 2:03 PM To: 'Jouni' Cc: 'ext lionel.morand@orange.com'; 'RFC Errata System'; 'Benoit = Claise'; 'joel jaeggli'; 'dime@ietf.org list' Subject: RE: [Technical Errata Reported] RFC6733 (4462) 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:jouni.nospam@gmail.com] Sent: Wednesday, September 16, 2015 12:38 PM To: Keshab Upadhya Cc: ext lionel.morand@orange.com; RFC Errata System; Benoit Claise; joel = jaeggli; dime@ietf.org list Subject: Re: [Technical Errata Reported] RFC6733 (4462) 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 wrote: >=20 > Hi Jouni, >=20 > Thank you for response. >=20 > Yes, return error looks like suitable option here as well however it's = > not mentioned in RFC6733, 1.6.5 explicitly. >=20 > What will be recommended alteration and which section it will be = applicable? > Kindly advice. >=20 > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Wednesday, September 16, 2015 5:26 AM > To: Keshab Upadhya; lionel.morand@orange.com; 'RFC Errata System';=20 > vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com;=20 > glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com > Cc: dime@ietf.org > Subject: Re: [Technical Errata Reported] RFC6733 (4462) >=20 >=20 > The proposed correction does not seem right. For routing to work all=20 > nodes within a realm must be peer, which in this case does not seem to = > hold. I would just return an error. >=20 > - Jouni >=20 >=20 >=20 >=20 >=20 > 9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti: >> Hi Lionel, >>=20 >> Thank you for valuable feedback. >>=20 >> I believe your understanding is inline and primarily what you've=20 >> summarized below clarifies objectively, thank you. >>=20 >> Confusion with below statement of 6.1.6, paragraph 2: >>=20 >> "When a request is received that includes a *_realm_* and/or >> *_application_* that is *_not_* locally supported, the message is=20 >> routed to the peer configured in the routing table (see Section = 2.7)." >>=20 >> As per above statement if realm is present and if application is not=20 >> locally supported then below action will be taken place. >>=20 >> =E2=80=9C---- if not, route the request based on Realm/application = (section > 6.1.6)=E2=80=9D >>=20 >> What will happen if towards a server peer node where hostname is=20 >> incorrect and application id with realm locally supported? >>=20 >> Understanding from RFC - If we go with 6.1.4, such message = shouldn=E2=80=99t=20 >> be processed locally but if we go with 6.1.6 message looks like=20 >> should be processed locally based on above given underlined=20 >> statement, defines contradiction of 6.1.4 & 6.1.6. >>=20 >> After giving a second though on specs in section 6.1.4, if following=20 >> altered=E2=80=93 >>=20 >> *_Original -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present, the Destination-Realm >> AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> *_Altered -_* >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o *The Destination-Host AVP is not present _in local peer routing=20 >> table_, the Destination-Realm AVP* >>=20 >> * contains a realm the server is configured to process locally, = and* >>=20 >> * the Diameter application is locally supported; or* >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present >>=20 >> It will eliminate the contradiction. >>=20 >> Please help enlighten us on this. >>=20 >> Thank you, >>=20 >> Keshab. >>=20 >> -----Original Message----- >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: Thursday, September 10, 2015 11:15 PM >> To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com;=20 >> jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; = >> bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com >> Cc: dime@ietf.org >> Subject: RE: [Technical Errata Reported] RFC6733 (4462) >>=20 >> Hi Keshab, >>=20 >> I'm not totally sure to understand your concern. >>=20 >> The purpose of the section 6.1.4 is to give the conditions for=20 >> processing locally a request (i.e. how to know that the receiving=20 >> entity is the one that needs to answer to the request?) and nothing = else. >>=20 >> The case you are referring to is covered in the section 6.1.6 and=20 >> should not be part of section 6.1.4. >>=20 >> To make a long story short... >>=20 >> if the Destination-Host is present, >>=20 >> - if the identity is equal to the local host's identity --> process=20 >> locally (section 6.1.4) >>=20 >> - if the identity is not equal to the local host's identity, check=20 >> the peer table. >>=20 >> ---- If it is the peer table, forward the request to the peer (sect >> 6.1.5) >>=20 >> ---- if not, route the request based on Realm/application (section >> 6.1.6) >>=20 >> Let me know if it is OK for you. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >>=20 >> De : Keshab Upadhya [mailto:keshab@smsgt.com] Envoy=C3=A9 : jeudi 10=20 >> septembre 2015 05:26 =C5=94 : 'RFC Errata System'; vf0213@gmail.com=20 >> ; jari.arkko@ericsson.com=20 >> ; john.loughney@nokia.com=20 >> ; glenzorn@gmail.com=20 >> ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; MORAND Lionel IMT/OLN Cc : >> dime@ietf.org Objet : RE: [Technical Errata=20 >> Reported] RFC6733 (4462) >>=20 >> Hi All, >>=20 >> Good day! >>=20 >> Could you please help on below request raised as conflict in = RFC-6733? >>=20 >> Kindly consider this as an urgent request. >>=20 >> Thank you, >>=20 >> Regards, >>=20 >> Keshab. >>=20 >> -----Original Message----- >>=20 >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>=20 >> Sent: Wednesday, September 2, 2015 9:09 AM >>=20 >> To: vf0213@gmail.com ;=20 >> jari.arkko@ericsson.com ;=20 >> john.loughney@nokia.com ;=20 >> glenzorn@gmail.com ; bclaise@cisco.com=20 >> ; joelja@bogus.com=20 >> ; jouni.nospam@gmail.com=20 >> ; lionel.morand@orange.com=20 >> >>=20 >> Cc: keshab@smsgt.com ; dime@ietf.org=20 >> ; rfc-editor@rfc-editor.org=20 >> >>=20 >> Subject: [Technical Errata Reported] RFC6733 (4462) >>=20 >> The following errata report has been submitted for RFC6733, "Diameter = >> Base Protocol". >>=20 >> -------------------------------------- >>=20 >> You may review the report below and at: >>=20 >> http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 >>=20 >> -------------------------------------- >>=20 >> Type: Technical >>=20 >> Reported by: Keshab Upadhya > > >>=20 >> Section: 6.1.4 6.1.6 >>=20 >> Original Text >>=20 >> ------------- >>=20 >> 6.1.4. Processing Local Requests >>=20 >> A request is known to be for local consumption when one of the >>=20 >> following conditions occurs: >>=20 >> o The Destination-Host AVP contains the local host's identity; >>=20 >> o The Destination-Host AVP is not present, the Destination-Realm=20 >> AVP >>=20 >> contains a realm the server is configured to process locally,=20 >> and >>=20 >> the Diameter application is locally supported; or >>=20 >> o Both the Destination-Host and the Destination-Realm are not >>=20 >> present. >>=20 >> 6.1.6. Request Routing >>=20 >> Diameter request message routing is done via realms and=20 >> Application >>=20 >> Ids. A Diameter message that may be forwarded by Diameter agents >>=20 >> (proxies, redirect agents, or relay agents) MUST include the=20 >> target >>=20 >> realm in the Destination-Realm AVP. Request routing SHOULD rely=20 >> on >>=20 >> the Destination-Realm AVP and the Application Id present in the >>=20 >> request message header to aid in the routing decision. The realm=20 >> MAY >>=20 >> be retrieved from the User-Name AVP, which is in the form of a >>=20 >> Network Access Identifier (NAI). The realm portion of the NAI is >>=20 >> inserted in the Destination-Realm AVP. >>=20 >> Diameter agents MAY have a list of locally supported realms and >>=20 >> applications, and they MAY have a list of externally supported=20 >> realms >>=20 >> and applications. When a request is received that includes a=20 >> realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured in the routing table (see Section = 2.7). >>=20 >> Realm names and Application Ids are the minimum supported routing >>=20 >> criteria, additional information may be needed to support redirect >>=20 >> semantics. >>=20 >> Corrected Text >>=20 >> -------------- >>=20 >> 6.1.6 - >>=20 >> When a request is received that includes a realm >>=20 >> and/or application that is not locally supported, the message is >>=20 >> routed to the peer configured >>=20 >> conflicts with 6.1.4 - >>=20 >> The Destination-Host AVP is not present, the Destination-Realm AVP >>=20 >> contains a realm the server is configured to process locally,=20 >> and >>=20 >> the Diameter application is locally supported >>=20 >> Notes >>=20 >> ----- >>=20 >> please guide if 6.1.4 Local processing - "hostname not present" needs = >> to be amended by "not present in host peer routing table". otherwise=20 >> it conflicts with 6.1.6. >>=20 >> Instructions: >>=20 >> ------------- >>=20 >> This erratum is currently posted as "Reported". If necessary, please=20 >> 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=20 >> change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >>=20 >> RFC6733 (draft-ietf-dime-rfc3588bis-33) >>=20 >> -------------------------------------- >>=20 >> Title : Diameter Base Protocol >>=20 >> Publication Date : October 2012 >>=20 >> Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. = Zorn, Ed. >>=20 >> Category : PROPOSED STANDARD >>=20 >> Source : Diameter Maintenance and Extensions >>=20 >> Area : Operations and Management >>=20 >> Stream : IETF >>=20 >> Verifying Party : IESG >>=20 >> _____________________________________________________________________ >> _ ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> 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. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not=20 >> be distributed, used or copied without authorisation. >>=20 >> If you have received this email in error, please notify the sender=20 >> and delete this message and its attachments. >>=20 >> As emails may be altered, Orange is not liable for messages that have = >> been modified, changed or falsified. >>=20 >> Thank you. From nobody Tue Sep 22 08:14:21 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5721AC3DC for ; Tue, 22 Sep 2015 08:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8kQufXMmpJL for ; Tue, 22 Sep 2015 08:14:16 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E8B1A9240 for ; Tue, 22 Sep 2015 08:14:16 -0700 (PDT) Received: by pacgz1 with SMTP id gz1so9164509pac.3 for ; Tue, 22 Sep 2015 08:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=FVogcwa9mxC7WdmmqKKpW5iq+KjG+oeQHLT3U5RMxDQ=; b=ISD2ou/QLzhfdjVURW2SEHpsRNkqexaAsqBvzQy31U6YFVUbJ3tTXv8xGK2kmI7hOH yAi0icxCPoXreHbgXt+S9Dno5gVxBx0oFc4dZlnncVwjjQwuaEEogwSjWbXRB1uPxLkB W9rCGfXQEqnapmaMXstMCirHtdEsrX1Gf/OSRbtXzU3rjpPVsMnWh5PQQZrnvth6QYpz zBoVA6G+gdqct5VRazYOhMp7dUmY3TnIPPs0lxJeYA9axGwJ7MX7z8f8QHpsjhEkkXAF pVzMc7ReOJmJsnClYOhZZNB72dRaEXeVXBh4ksphbXb+sWtWNRP+miihEyvic8vBJFEa 2qJQ== X-Received: by 10.66.190.135 with SMTP id gq7mr32052222pac.65.1442934856432; Tue, 22 Sep 2015 08:14:16 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:ccc5:843b:ab02:c88f? ([2601:647:4204:228b:ccc5:843b:ab02:c88f]) by smtp.googlemail.com with ESMTPSA id fu4sm2878958pbb.59.2015.09.22.08.14.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Sep 2015 08:14:14 -0700 (PDT) To: Keshab Upadhya References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> <000001d0f10a$ece43490$c6ac9db0$@smsgt.com> From: Jouni Korhonen Message-ID: <56017046.1060305@gmail.com> Date: Tue, 22 Sep 2015 08:14:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <000001d0f10a$ece43490$c6ac9db0$@smsgt.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'joel jaeggli' , 'RFC Errata System' , dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 15:14:20 -0000 See inline. 9/16/2015, 10:37 PM, Keshab Upadhya kirjoitti: > Hi, > > Please help with below query. > > Thank you. > > Regards, > Keshab. > > -----Original Message----- > From: Keshab Upadhya [mailto:keshab@smsgt.com] > Sent: Wednesday, September 16, 2015 2:03 PM > To: 'Jouni' > Cc: 'ext lionel.morand@orange.com'; 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; 'dime@ietf.org list' > Subject: RE: [Technical Errata Reported] RFC6733 (4462) > > Hi Jouni, > > Thank you. > > 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 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. DIAMETER_UNABLE_TO_DELIVER would be the best choice here imho. - JOuni > > Kindly confirm. > > Thank you. > > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com] > Sent: Wednesday, September 16, 2015 12:38 PM > To: Keshab Upadhya > Cc: ext lionel.morand@orange.com; RFC Errata System; Benoit Claise; joel jaeggli; dime@ietf.org list > Subject: Re: [Technical Errata Reported] RFC6733 (4462) > > 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 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:jouni.nospam@gmail.com] >> Sent: Wednesday, September 16, 2015 5:26 AM >> To: Keshab Upadhya; lionel.morand@orange.com; 'RFC Errata System'; >> vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; >> glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com >> Cc: dime@ietf.org >> 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: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >>> Sent: Thursday, September 10, 2015 11:15 PM >>> To: Keshab Upadhya; 'RFC Errata System'; vf0213@gmail.com; >>> jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; >>> bclaise@cisco.com; joelja@bogus.com; jouni.nospam@gmail.com >>> Cc: dime@ietf.org >>> 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:keshab@smsgt.com] Envoyé : jeudi 10 >>> septembre 2015 05:26 Å” : 'RFC Errata System'; vf0213@gmail.com >>> ; jari.arkko@ericsson.com >>> ; john.loughney@nokia.com >>> ; glenzorn@gmail.com >>> ; bclaise@cisco.com >>> ; joelja@bogus.com >>> ; jouni.nospam@gmail.com >>> ; MORAND Lionel IMT/OLN Cc : >>> dime@ietf.org 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:rfc-editor@rfc-editor.org] >>> >>> Sent: Wednesday, September 2, 2015 9:09 AM >>> >>> To: vf0213@gmail.com ; >>> jari.arkko@ericsson.com ; >>> john.loughney@nokia.com ; >>> glenzorn@gmail.com ; bclaise@cisco.com >>> ; joelja@bogus.com >>> ; jouni.nospam@gmail.com >>> ; lionel.morand@orange.com >>> >>> >>> Cc: keshab@smsgt.com ; dime@ietf.org >>> ; rfc-editor@rfc-editor.org >>> >>> >>> 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 >> > >>> >>> 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. > From nobody Tue Sep 22 19:31:17 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9111B2DA3 for ; Tue, 22 Sep 2015 19:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, URG_BIZ=0.573] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNUBGbpOwaUB for ; Tue, 22 Sep 2015 19:31:11 -0700 (PDT) Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [192.185.196.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F0D1B2D9E for ; Tue, 22 Sep 2015 19:31:10 -0700 (PDT) Received: by gateway36.websitewelcome.com (Postfix, from userid 1000) id 39F82EA696B78; Tue, 22 Sep 2015 21:31:10 -0500 (CDT) Received: from cm2.websitewelcome.com (unknown [192.185.178.13]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 34A8BEA6982C6 for ; Tue, 22 Sep 2015 21:31:10 -0500 (CDT) Received: from gator4074.hostgator.com ([192.185.4.85]) by cm2.websitewelcome.com with id LSX91r0021q3akG01SXAhG; Tue, 22 Sep 2015 21:31:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smsgt.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=RPkizT7eTs7JfTEh/cA623BBPvnxijmoH0glGoFyDn0=; b=MY8aVcKEY/du3SF3CxdBMLlfju8NM8fpH2zHDj210W0XvMkrrf+kQi3Z0gihB9WE2NIrGtdKpGyNHLAG0IojUVkAdSP4VnK12FSGwCqG+Q/faSc3+blQCpiC4kmaV+zS5zUM661Dtmg1Bvx3d4GOuzEfINa1x1byzwHPcnqdzwI=; Received: from mail2.tektite.com.ph ([122.53.85.44]:36971 helo=Keshab) by gator4074.hostgator.com with smtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZeZpr-0007EW-C7; Tue, 22 Sep 2015 21:31:08 -0500 From: "Keshab Upadhya" To: "'Jouni Korhonen'" References: <20150902010923.059A2180474@rfc-editor.org> <00fc01d0eb78$69cdeb10$3d69c130$@smsgt.com> <29295_1441898081_55F19E61_29295_1538_5_6B7134B31289DC4FAF731D844122B36E01D1A7A5@OPEXCLILM43.corporate.adroot.infra.ftgroup> <006301d0eebc$c2dc1550$48943ff0$@smsgt.com> <55F88CDA.4080801@gmail.com> <009a01d0f02b$445e6000$cd1b2000$@smsgt.com> <25E5B468-27E4-406E-8182-4C034B42FE08@gmail.com> <000001d0f10a$ece43490$c6ac9db0$@smsgt.com> <56017046.1060305@gmail.com> In-Reply-To: <56017046.1060305@gmail.com> Date: Wed, 23 Sep 2015 10:31:02 +0800 Message-ID: <006601d0f5a7$e5acb930$b1062b90$@smsgt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D0F5EA.F3DBE010" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJjReiBNFWUJ68CiMoyGb3CJoxo4wKUwjtLAhJLB98CRIxEQwDxKOskAlk4ZDsCWFaJxgH1t8iYAnRsxYqcnPI9oA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4074.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smsgt.com X-BWhitelist: no X-Source-IP: 122.53.85.44 X-Exim-ID: 1ZeZpr-0007EW-C7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: mail2.tektite.com.ph (Keshab) [122.53.85.44]:36971 X-Source-Auth: allan X-Email-Count: 140 X-Source-Cap: YWxsYW47YWxsYW47Z2F0b3I0MDc0Lmhvc3RnYXRvci5jb20= Archived-At: Cc: 'joel jaeggli' , 'RFC Errata System' , dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4462) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 02:31:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01D0F5EA.F3DBE010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jouni, =20 Thank you and appreciate your valuable feedback. =20 Yes, message landed under erroneous circumstances. Closely looking at = RFC we don't have any specific quote for the "unknown" hostname. =20 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. =20 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.=20 =20 If I take " 6.1.4" not present of hostname means: =E2=80=9Chostname AVP = is missing or =E2=80=9Cnull=E2=80=9D or not present in peer routing = table of local host=E2=80=9D =E2=80=93 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. =20 Thank you. =20 -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Tuesday, September 22, 2015 11:14 PM To: Keshab Upadhya Cc: lionel.morand@orange.com; 'RFC Errata System'; 'Benoit Claise'; = 'joel jaeggli'; dime@ietf.org Subject: Re: [Technical Errata Reported] RFC6733 (4462) =20 See inline. =20 9/16/2015, 10:37 PM, Keshab Upadhya kirjoitti: > Hi, >=20 > Please help with below query. >=20 > Thank you. >=20 > Regards, > Keshab. >=20 > -----Original Message----- > From: Keshab Upadhya [ = mailto:keshab@smsgt.com] > Sent: Wednesday, September 16, 2015 2:03 PM > To: 'Jouni' > Cc: 'ext lionel.morand@orange.com'; = 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; 'dime@ietf.org = list' > Subject: RE: [Technical Errata Reported] RFC6733 (4462) >=20 > Hi Jouni, >=20 > Thank you. >=20 > This is for server peer (HSS) for local request processing and = handling of unknown destination host in s6a. =20 You should not have received such request in the first place. The = routing infrastructure has issues in this case. =20 > 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. =20 DIAMETER_UNABLE_TO_DELIVER would be the best choice here imho. =20 - JOuni =20 =20 >=20 > Kindly confirm. >=20 > Thank you. >=20 > -----Original Message----- > From: Jouni [ = mailto:jouni.nospam@gmail.com] > Sent: Wednesday, September 16, 2015 12:38 PM > To: Keshab Upadhya > Cc: ext lionel.morand@orange.com; = RFC Errata System; Benoit Claise;=20 > joel jaeggli; dime@ietf.org list > Subject: Re: [Technical Errata Reported] RFC6733 (4462) >=20 > Hi, >=20 > 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. >=20 > - Jouni >=20 >=20 >=20 >=20 >> On 15 Sep 2015, at 19:56, Keshab Upadhya < = keshab@smsgt.com> wrote: >>=20 >> Hi Jouni, >>=20 >> Thank you for response. >>=20 >> Yes, return error looks like suitable option here as well however=20 >> it's not mentioned in RFC6733, 1.6.5 explicitly. >>=20 >> What will be recommended alteration and which section it will be = applicable? >> Kindly advice. >>=20 >> -----Original Message----- >> From: Jouni Korhonen [ = mailto:jouni.nospam@gmail.com] >> Sent: Wednesday, September 16, 2015 5:26 AM >> To: Keshab Upadhya; = lionel.morand@orange.com; 'RFC Errata System';=20 >> vf0213@gmail.com; = jari.arkko@ericsson.com; = john.loughney@nokia.com;=20 >> glenzorn@gmail.com; = bclaise@cisco.com; = joelja@bogus.com >> Cc: dime@ietf.org >> Subject: Re: [Technical Errata Reported] RFC6733 (4462) >>=20 >>=20 >> The proposed correction does not seem right. For routing to work all=20 >> nodes within a realm must be peer, which in this case does not seem=20 >> to hold. I would just return an error. >>=20 >> - Jouni >>=20 >>=20 >>=20 >>=20 >>=20 >> 9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti: >>> Hi Lionel, >>>=20 >>> Thank you for valuable feedback. >>>=20 >>> I believe your understanding is inline and primarily what you've=20 >>> summarized below clarifies objectively, thank you. >>>=20 >>> Confusion with below statement of 6.1.6, paragraph 2: >>>=20 >>> "When a request is received that includes a *_realm_* and/or >>> *_application_* that is *_not_* locally supported, the message is=20 >>> routed to the peer configured in the routing table (see Section = 2.7)." >>>=20 >>> As per above statement if realm is present and if application is not = >>> locally supported then below action will be taken place. >>>=20 >>> =E2=80=9C---- if not, route the request based on Realm/application = (section >> 6.1.6)=E2=80=9D >>>=20 >>> What will happen if towards a server peer node where hostname is=20 >>> incorrect and application id with realm locally supported? >>>=20 >>> Understanding from RFC - If we go with 6.1.4, such message = shouldn=E2=80=99t=20 >>> be processed locally but if we go with 6.1.6 message looks like=20 >>> should be processed locally based on above given underlined=20 >>> statement, defines contradiction of 6.1.4 & 6.1.6. >>>=20 >>> After giving a second though on specs in section 6.1.4, if following = >>> altered=E2=80=93 >>>=20 >>> *_Original -_* >>>=20 >>> 6.1.4. Processing Local Requests >>>=20 >>> A request is known to be for local consumption when one of the >>>=20 >>> following conditions occurs: >>>=20 >>> o The Destination-Host AVP contains the local host's identity; >>>=20 >>> o *The Destination-Host AVP is not present, the=20 >>> Destination-Realm >>> AVP* >>>=20 >>> * contains a realm the server is configured to process locally, = and* >>>=20 >>> * the Diameter application is locally supported; or* >>>=20 >>> o Both the Destination-Host and the Destination-Realm are not >>>=20 >>> present >>>=20 >>> *_Altered -_* >>>=20 >>> 6.1.4. Processing Local Requests >>>=20 >>> A request is known to be for local consumption when one of the >>>=20 >>> following conditions occurs: >>>=20 >>> o The Destination-Host AVP contains the local host's identity; >>>=20 >>> o *The Destination-Host AVP is not present _in local peer=20 >>> routing table_, the Destination-Realm AVP* >>>=20 >>> * contains a realm the server is configured to process locally, = and* >>>=20 >>> * the Diameter application is locally supported; or* >>>=20 >>> o Both the Destination-Host and the Destination-Realm are not >>>=20 >>> present >>>=20 >>> It will eliminate the contradiction. >>>=20 >>> Please help enlighten us on this. >>>=20 >>> Thank you, >>>=20 >>> Keshab. >>>=20 >>> -----Original Message----- >>> From: lionel.morand@orange.com [ = mailto:lionel.morand@orange.com] >>> Sent: Thursday, September 10, 2015 11:15 PM >>> To: Keshab Upadhya; 'RFC Errata System'; = vf0213@gmail.com;=20 >>> jari.arkko@ericsson.com; = john.loughney@nokia.com;=20 >>> glenzorn@gmail.com; = bclaise@cisco.com; = joelja@bogus.com;=20 >>> jouni.nospam@gmail.com >>> Cc: dime@ietf.org >>> Subject: RE: [Technical Errata Reported] RFC6733 (4462) >>>=20 >>> Hi Keshab, >>>=20 >>> I'm not totally sure to understand your concern. >>>=20 >>> The purpose of the section 6.1.4 is to give the conditions for=20 >>> processing locally a request (i.e. how to know that the receiving=20 >>> entity is the one that needs to answer to the request?) and nothing = else. >>>=20 >>> The case you are referring to is covered in the section 6.1.6 and=20 >>> should not be part of section 6.1.4. >>>=20 >>> To make a long story short... >>>=20 >>> if the Destination-Host is present, >>>=20 >>> - if the identity is equal to the local host's identity --> process=20 >>> locally (section 6.1.4) >>>=20 >>> - if the identity is not equal to the local host's identity, check=20 >>> the peer table. >>>=20 >>> ---- If it is the peer table, forward the request to the peer (sect >>> 6.1.5) >>>=20 >>> ---- if not, route the request based on Realm/application (section >>> 6.1.6) >>>=20 >>> Let me know if it is OK for you. >>>=20 >>> Lionel >>>=20 >>> -----Message d'origine----- >>>=20 >>> De : Keshab Upadhya [ = mailto:keshab@smsgt.com] Envoy=C3=A9 : jeudi 10=20 >>> septembre 2015 05:26 =C5=94 : 'RFC Errata System'; = vf0213@gmail.com=20 >>> < mailto:vf0213@gmail.com>; = jari.arkko@ericsson.com=20 >>> < mailto:jari.arkko@ericsson.com>; = john.loughney@nokia.com=20 >>> < mailto:john.loughney@nokia.com>; = glenzorn@gmail.com=20 >>> < mailto:glenzorn@gmail.com>; = bclaise@cisco.com=20 >>> < mailto:bclaise@cisco.com>; = joelja@bogus.com=20 >>> < mailto:joelja@bogus.com>; = jouni.nospam@gmail.com=20 >>> < mailto:jouni.nospam@gmail.com>; = MORAND Lionel IMT/OLN Cc : >>> dime@ietf.org < = mailto:dime@ietf.org> Objet : RE: [Technical Errata=20 >>> Reported] RFC6733 (4462) >>>=20 >>> Hi All, >>>=20 >>> Good day! >>>=20 >>> Could you please help on below request raised as conflict in = RFC-6733? >>>=20 >>> Kindly consider this as an urgent request. >>>=20 >>> Thank you, >>>=20 >>> Regards, >>>=20 >>> Keshab. >>>=20 >>> -----Original Message----- >>>=20 >>> From: RFC Errata System [ = mailto:rfc-editor@rfc-editor.org] >>>=20 >>> Sent: Wednesday, September 2, 2015 9:09 AM >>>=20 >>> To: vf0213@gmail.com < = mailto:vf0213@gmail.com>;=20 >>> jari.arkko@ericsson.com < = mailto:jari.arkko@ericsson.com>;=20 >>> john.loughney@nokia.com < = mailto:john.loughney@nokia.com>;=20 >>> glenzorn@gmail.com < = mailto:glenzorn@gmail.com>; = bclaise@cisco.com=20 >>> < mailto:bclaise@cisco.com>; = joelja@bogus.com=20 >>> < mailto:joelja@bogus.com>; = jouni.nospam@gmail.com=20 >>> < mailto:jouni.nospam@gmail.com>; = lionel.morand@orange.com=20 >>> < mailto:lionel.morand@orange.com> >>>=20 >>> Cc: keshab@smsgt.com < = mailto:keshab@smsgt.com>; = dime@ietf.org=20 >>> < mailto:dime@ietf.org>; = rfc-editor@rfc-editor.org=20 >>> < = mailto:rfc-editor@rfc-editor.org> >>>=20 >>> Subject: [Technical Errata Reported] RFC6733 (4462) >>>=20 >>> The following errata report has been submitted for RFC6733,=20 >>> "Diameter Base Protocol". >>>=20 >>> -------------------------------------- >>>=20 >>> You may review the report below and at: >>>=20 >>> = http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4462 >>>=20 >>> -------------------------------------- >>>=20 >>> Type: Technical >>>=20 >>> Reported by: Keshab Upadhya >> < mailto:keshab@smsgt.com>> >>>=20 >>> Section: 6.1.4 6.1.6 >>>=20 >>> Original Text >>>=20 >>> ------------- >>>=20 >>> 6.1.4. Processing Local Requests >>>=20 >>> A request is known to be for local consumption when one of the >>>=20 >>> following conditions occurs: >>>=20 >>> o The Destination-Host AVP contains the local host's identity; >>>=20 >>> o The Destination-Host AVP is not present, the=20 >>> Destination-Realm AVP >>>=20 >>> contains a realm the server is configured to process locally, = >>> and >>>=20 >>> the Diameter application is locally supported; or >>>=20 >>> o Both the Destination-Host and the Destination-Realm are not >>>=20 >>> present. >>>=20 >>> 6.1.6. Request Routing >>>=20 >>> Diameter request message routing is done via realms and=20 >>> Application >>>=20 >>> Ids. A Diameter message that may be forwarded by Diameter agents >>>=20 >>> (proxies, redirect agents, or relay agents) MUST include the=20 >>> target >>>=20 >>> realm in the Destination-Realm AVP. Request routing SHOULD rely = >>> on >>>=20 >>> the Destination-Realm AVP and the Application Id present in the >>>=20 >>> request message header to aid in the routing decision. The=20 >>> realm MAY >>>=20 >>> be retrieved from the User-Name AVP, which is in the form of a >>>=20 >>> Network Access Identifier (NAI). The realm portion of the NAI=20 >>> is >>>=20 >>> inserted in the Destination-Realm AVP. >>>=20 >>> Diameter agents MAY have a list of locally supported realms and >>>=20 >>> applications, and they MAY have a list of externally supported=20 >>> realms >>>=20 >>> and applications. When a request is received that includes a=20 >>> realm >>>=20 >>> and/or application that is not locally supported, the message is >>>=20 >>> routed to the peer configured in the routing table (see Section = 2.7). >>>=20 >>> Realm names and Application Ids are the minimum supported=20 >>> routing >>>=20 >>> criteria, additional information may be needed to support=20 >>> redirect >>>=20 >>> semantics. >>>=20 >>> Corrected Text >>>=20 >>> -------------- >>>=20 >>> 6.1.6 - >>>=20 >>> When a request is received that includes a realm >>>=20 >>> and/or application that is not locally supported, the message is >>>=20 >>> routed to the peer configured >>>=20 >>> conflicts with 6.1.4 - >>>=20 >>> The Destination-Host AVP is not present, the Destination-Realm=20 >>> AVP >>>=20 >>> contains a realm the server is configured to process locally, = >>> and >>>=20 >>> the Diameter application is locally supported >>>=20 >>> Notes >>>=20 >>> ----- >>>=20 >>> please guide if 6.1.4 Local processing - "hostname not present"=20 >>> needs to be amended by "not present in host peer routing table".=20 >>> otherwise it conflicts with 6.1.6. >>>=20 >>> Instructions: >>>=20 >>> ------------- >>>=20 >>> 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. >>>=20 >>> -------------------------------------- >>>=20 >>> RFC6733 (draft-ietf-dime-rfc3588bis-33) >>>=20 >>> -------------------------------------- >>>=20 >>> Title : Diameter Base Protocol >>>=20 >>> Publication Date : October 2012 >>>=20 >>> Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. = Zorn, Ed. >>>=20 >>> Category : PROPOSED STANDARD >>>=20 >>> Source : Diameter Maintenance and Extensions >>>=20 >>> Area : Operations and Management >>>=20 >>> Stream : IETF >>>=20 >>> Verifying Party : IESG >>>=20 >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>> etant susceptibles d'alteration, Orange decline toute responsabilite = >>> si ce message a ete altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not = >>> be distributed, used or copied without authorisation. >>>=20 >>> If you have received this email in error, please notify the sender=20 >>> and delete this message and its attachments. >>>=20 >>> As emails may be altered, Orange is not liable for messages that=20 >>> have been modified, changed or falsified. >>>=20 >>> Thank you. >=20 ------=_NextPart_000_0067_01D0F5EA.F3DBE010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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: = =E2=80=9Chostname AVP is missing or =E2=80=9Cnull=E2=80=9D or not = present in peer routing table =C2=A0of local host=E2=80=9D =E2=80=93 = 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:jouni.nospam@gmail.com]
Sent: Tuesday, September 22, 2015 = 11:14 PM
To: Keshab Upadhya
Cc: lionel.morand@orange.com; 'RFC = Errata System'; 'Benoit Claise'; 'joel jaeggli'; = dime@ietf.org
Subject: Re: [Technical Errata Reported] RFC6733 = (4462)

 

See inline.

 

9/16/2015, 10:37 PM, Keshab Upadhya = kirjoitti:

> = Hi,

> 

> Please help with below query.

> 

> Thank you.

> 

> Regards,

> Keshab.

> 

> -----Original Message-----

> From: Keshab Upadhya [mailto:keshab@smsgt.com]

> Sent: Wednesday, = September 16, 2015 2:03 PM

> = To: 'Jouni'

> Cc: 'ext lionel.morand@orange.com<= /span>'; 'RFC Errata System'; 'Benoit Claise'; 'joel jaeggli'; = 'dime@ietf.org list'

> Subject: = RE: [Technical Errata Reported] RFC6733 (4462)

> 

> Hi Jouni,

> 

> Thank you.

> 

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

 

DIAMETER_UNABLE_TO_DELIVER would be the best choice = here imho.

 

- JOuni

 

 

> 

> Kindly confirm.

> 

> Thank you.

> 

> -----Original Message-----

> From: Jouni [mailto:jouni.nospam@gmail= .com]

> Sent: = Wednesday, September 16, 2015 12:38 PM

> To: Keshab Upadhya

> Cc: ext lionel.morand@orange.com<= /span>; RFC Errata System; Benoit Claise;

> joel jaeggli; dime@ietf.org = list

> Subject: Re: [Technical = Errata Reported] RFC6733 (4462)

> 

> 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 = <keshab@smsgt.com> 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:jouni.nospam@gmail= .com]

>> Sent: = Wednesday, September 16, 2015 5:26 AM

>> To: Keshab Upadhya; lionel.morand@orange.com<= /span>; 'RFC Errata System';

>> vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com;

>> glenzorn@gmail.com= ; bclaise@cisco.com<= /a>; joelja@bogus.com

>> Cc: dime@ietf.org<= o:p>

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

>>> 

>>> =E2=80=9C---- if not, route the = request based on Realm/application (section

>> 6.1.6)=E2=80=9D

>>> 

>>> 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=E2=80=99t

>>> 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=E2=80=93

>>> 

>>> *_Original -_*

>>> 

>>> 6.1.4.=C2=A0 Processing Local = Requests

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 A request is = known to be for local consumption when one of the

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 following = conditions occurs:

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The = Destination-Host AVP contains the local host's = identity;

>>> 

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

>>> Destination-Realm

>>> AVP*

>>> 

>>> *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = contains a realm the server is configured to process locally, = and*

>>> 

>>> *=C2=A0=C2=A0=C2=A0=C2=A0 the Diameter = application is locally supported; or*

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 Both = the Destination-Host and the Destination-Realm are not

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= present

>>> 

>>> *_Altered -_*

>>> 

>>> 6.1.4.=C2=A0 Processing Local = Requests

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 A request is = known to be for local consumption when one of the

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 following = conditions occurs:

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The = Destination-Host AVP contains the local host's = identity;

>>> 

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

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

>>> 

>>> *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = contains a realm the server is configured to process locally, = and*

>>> 

>>> *=C2=A0=C2=A0=C2=A0=C2=A0 the Diameter = application is locally supported; or*

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 Both = the Destination-Host and the Destination-Realm are not

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= present

>>> 

>>> It will eliminate the = contradiction.

>>> 

>>> Please help enlighten us on = this.

>>> 

>>> Thank you,

>>> 

>>> Keshab.

>>> 

>>> -----Original = Message-----

>>> From: lionel.morand@orange.com<= /span> [mailto:lionel.morand@oran= ge.com]

>>> = Sent: Thursday, September 10, 2015 11:15 PM

>>> To: Keshab Upadhya; 'RFC Errata = System'; vf0213@gmail.com;

>>> jari.arkko@ericsson.com; john.loughney@nokia.com;

>>> glenzorn@gmail.com= ; bclaise@cisco.com<= /a>; joelja@bogus.com;

>>> jouni.nospam@gmail.com

>>> Cc: dime@ietf.org<= o:p>

>>> 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:keshab@smsgt.com] Envoy=C3=A9 : jeudi 10

>>> septembre 2015 05:26 =C5=94 : 'RFC = Errata System'; vf0213@gmail.com

>>> <mailto:vf0213@gmail.com>; jari.arkko@ericsson.com

>>> <mailto:jari.arkko@ericsso= n.com>; john.loughney@nokia.com

>>> <mailto:john.loughney@noki= a.com>; glenzorn@gmail.com=

>>> <mailto:glenzorn@gmail.com= >; bclaise@cisco.com<= /a>

>>> <mailto:bclaise@cisco.com<= /span>>; joelja@bogus.com

>>> <mailto:joelja@bogus.com>; jouni.nospam@gmail.com

>>> <mailto:jouni.nospam@gmail= .com>; MORAND Lionel IMT/OLN Cc :

>>> dime@ietf.org = <mailto:dime@ietf.org> 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:rfc-editor@rfc-edi= tor.org]

>>> 

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

>>> 

>>> To: vf0213@gmail.com <mailto:vf0213@gmail.com>;

>>> jari.arkko@ericsson.com <mailto:jari.arkko@ericsso= n.com>;

>>> john.loughney@nokia.com <mailto:john.loughney@noki= a.com>;

>>> glenzorn@gmail.com= <mailto:glenzorn@gmail.com= >; bclaise@cisco.com<= /a>

>>> <mailto:bclaise@cisco.com<= /span>>; joelja@bogus.com

>>> <mailto:joelja@bogus.com>; jouni.nospam@gmail.com

>>> <mailto:jouni.nospam@gmail= .com>; lionel.morand@orange.com<= /span>

>>> <mailto:lionel.morand@oran= ge.com>

>>> 

>>> Cc: keshab@smsgt.com <mailto:keshab@smsgt.com>; dime@ietf.org =

>>> <mailto:dime@ietf.org>; rfc-editor@rfc-editor.org=

>>> <mailto:rfc-editor@rfc-edi= tor.org>

>>> 

>>> 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=3D6733&eid=3D4462

>>> 

>>> = --------------------------------------

>>> 

>>> Type: Technical

>>> 

>>> Reported by: Keshab Upadhya = <keshab@smsgt.com

>>> = <mailto:keshab@smsgt.com>>

>>> 

>>> Section: 6.1.4 6.1.6

>>> 

>>> Original Text

>>> 

>>> -------------

>>> 

>>> 6.1.4.=C2=A0 Processing Local = Requests

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 A request is = known to be for local consumption when one of the

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 following = conditions occurs:

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The = Destination-Host AVP contains the local host's = identity;

>>> 

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

>>> Destination-Realm AVP

>>> 

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

>>> and

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = the Diameter application is locally supported; or

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 Both = the Destination-Host and the Destination-Realm are not

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= present.

>>> 

>>> 6.1.6.=C2=A0 Request = Routing

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 Diameter = request message routing is done via realms and

>>> Application

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 Ids. A = Diameter message that may be forwarded by Diameter = agents

>>> 

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

>>> target

>>> 

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

>>> on

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 the = Destination-Realm AVP and the Application Id present in = the

>>> 

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

>>> realm = MAY

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 be retrieved = from the User-Name AVP, which is in the form of a

>>> 

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

>>> is

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 inserted in = the Destination-Realm AVP.

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 Diameter = agents MAY have a list of locally supported realms and

>>> 

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

>>> realms

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 and = applications.=C2=A0 When a request is received that includes a =

>>> = realm

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 and/or = application that is not locally supported, the message = is

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 routed to the = peer configured in the routing table (see Section 2.7).

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 Realm names = and Application Ids are the minimum supported

>>> routing

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 criteria, = additional information may be needed to support

>>> redirect

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 = semantics.

>>> 

>>> Corrected Text

>>> 

>>> --------------

>>> 

>>> 6.1.6 -

>>> 

>>>=C2=A0=C2=A0=C2=A0 When a request is = received that includes a realm

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 and/or = application that is not locally supported, the message = is

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0 routed to the = peer configured

>>> 

>>> conflicts with 6.1.4 = -

>>> 

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

>>> AVP

>>> 

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

>>> and

>>> 

>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : Diameter Base Protocol

>>> 

>>> Publication Date=C2=A0=C2=A0=C2=A0 : = October 2012

>>> 

>>> = Author(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.

>>> 

>>> = Category=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : PROPOSED STANDARD

>>> 

>>> = Source=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 : Diameter Maintenance and Extensions

>>> 

>>> = Area=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : Operations and Management

>>> 

>>> = Stream=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 : IETF

>>> 

>>> Verifying = Party=C2=A0=C2=A0=C2=A0=C2=A0 : 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.

> 

------=_NextPart_000_0067_01D0F5EA.F3DBE010-- From nobody Wed Sep 23 06:48:58 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C271B30CB for ; Wed, 23 Sep 2015 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_50VcccgqAz for ; Wed, 23 Sep 2015 06:48:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C4B1B30CC for ; Wed, 23 Sep 2015 06:48:49 -0700 (PDT) Received: from localhost ([::1]:50413 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZekPf-0001iD-R1; Wed, 23 Sep 2015 06:48:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-dime-drmp@tools.ietf.org, jean-jacques.trottin@alcatel-lucent.com X-Trac-Project: dime Date: Wed, 23 Sep 2015 13:48:47 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/92 Message-ID: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 92 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-drmp@tools.ietf.org, jean-jacques.trottin@alcatel-lucent.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20150923134849.80C4B1B30CC@ietfa.amsl.com> Resent-Date: Wed, 23 Sep 2015 06:48:49 -0700 (PDT) Resent-From: trac+dime@trac.tools.ietf.org Archived-At: Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:48:55 -0000 #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which appear to be not enough. In 3GPP, levels of priorities are also defined outside Diameter with, in particular, sixteen levels in Policy Control for the ARP (Allocation and Retention Priority)information element. So it would be better that the DRMP AVP also allow 16 values which is future proof and leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain priorities which are higher or lower than the normal priority corresponding to the case where the DRMP AVP is not present (existing situation); this also drives to consider a larger range of levels with an intermediate value corresponding to the normal priority. -- -------------------------------------+------------------------------------- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Sep 23 06:58:37 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A701B3259 for ; Wed, 23 Sep 2015 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O1eYeVdZotU for ; Wed, 23 Sep 2015 06:58:33 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064CE1B3246 for ; Wed, 23 Sep 2015 06:58:32 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8NDnPBH020040; Wed, 23 Sep 2015 09:58:31 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1x2uq3hsnq-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2015 09:58:31 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NDwU9O019093; Wed, 23 Sep 2015 09:58:30 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NDwG1C018773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Sep 2015 09:58:20 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 23 Sep 2015 13:58:08 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.4]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 09:58:08 -0400 From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "draft-ietf-dime-drmp@tools.ietf.org" , "jean-jacques.trottin@alcatel-lucent.com" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ9gacicybpqthaEmGc5qbwlXau55KIzrA Date: Wed, 23 Sep 2015 13:58:07 +0000 Message-ID: References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> In-Reply-To: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.90.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509230197 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:58:35 -0000 I have stated previously that I believe 5 levels are adequate, as I do not = see action on more than that. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Wednesday, September 23, 2015 9:49 AM To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucen= t.com Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which = appear to be not enough. In 3GPP, levels of priorities are also defined ou= tside Diameter with, in particular, sixteen levels in Policy Control for t= he ARP (Allocation and Retention Priority)information element. So it would= be better that the DRMP AVP also allow 16 values which is future proof an= d leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain = priorities which are higher or lower than the normal priority correspondin= g to the case where the DRMP AVP is not present (existing situation); this= also drives to consider a larger range of levels with an intermediate val= ue corresponding to the normal priority. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 23 07:45:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F691A6F51; Wed, 23 Sep 2015 07:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNELdXU3SscP; Wed, 23 Sep 2015 07:45:08 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA7A1A1B6C; Wed, 23 Sep 2015 07:45:07 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-85.messagelabs.com!1443019505!9044855!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1146 invoked from network); 23 Sep 2015 14:45:05 -0000 Received: from amer-mta101.csc.com (HELO amer-mta111.csc.com) (20.137.2.87) by server-14.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Sep 2015 14:45:05 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta111.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t8NEj4cN017460; Wed, 23 Sep 2015 10:45:04 -0400 In-Reply-To: References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> To: "DOLLY, MARTIN C" MIME-Version: 1.0 X-KeepSent: F36A8D38:499D2638-85257EC9:00503FE5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 23 Sep 2015 10:45:03 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.3FP5|July 31, 2013) at 09/23/2015 10:45:05 AM, Serialize complete at 09/23/2015 10:45:05 AM Content-Type: multipart/alternative; boundary="=_alternative 0051078585257EC9_=" Archived-At: Cc: DiME , pat_mcgregor@msn.com, "draft-ietf-dime-drmp@tools.ietf.org" , Richard F Kaczmarek , "dime@ietf.org" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 14:45:11 -0000 This is a multipart message in MIME format. --=_alternative 0051078585257EC9_= Content-Type: text/plain; charset="US-ASCII" I have consulted with a couple of other people here, and we agree that 5 is probably sufficient for this. You typically only need more priority levels when you are dealing with resources with long holding times (which includes some of the resources ARP is used for). With regard to the situation where the priority value is not present, assigning a "default priority" within the existing levels seems to work well . Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "DOLLY, MARTIN C" To: "dime@ietf.org" , "draft-ietf-dime-drmp@tools.ietf.org" , "jean-jacques.trottin@alcatel-lucent.com" Date: 09/23/2015 10:00 AM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" I have stated previously that I believe 5 levels are adequate, as I do not see action on more than that. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Wednesday, September 23, 2015 9:49 AM To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which appear to be not enough. In 3GPP, levels of priorities are also defined outside Diameter with, in particular, sixteen levels in Policy Control for the ARP (Allocation and Retention Priority)information element. So it would be better that the DRMP AVP also allow 16 values which is future proof and leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain priorities which are higher or lower than the normal priority corresponding to the case where the DRMP AVP is not present (existing situation); this also drives to consider a larger range of levels with an intermediate value corresponding to the normal priority. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 0051078585257EC9_= Content-Type: text/html; charset="US-ASCII" I have consulted with a couple of other people here, and we agree that 5 is probably sufficient  for this.

You typically only need more priority levels when you are dealing with resources with long holding times (which includes some of the resources ARP is used for).

With regard to the situation where the priority value is not present, assigning a "default priority" within the existing levels seems to work well .

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        "dime@ietf.org" <dime@ietf.org>, "draft-ietf-dime-drmp@tools.ietf.org" <draft-ietf-dime-drmp@tools.ietf.org>, "jean-jacques.trottin@alcatel-lucent.com" <jean-jacques.trottin@alcatel-lucent.com>
Date:        09/23/2015 10:00 AM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounces@ietf.org>



I have stated previously that I believe 5 levels are adequate, as I do not see action on more than that.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
Sent: Wednesday, September 23, 2015 9:49 AM
To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities which  appear to be not enough. In 3GPP, levels of priorities are also defined  outside Diameter with, in particular, sixteen levels in Policy Control for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AVP also allow 16 values which is future  proof and leaves more flexibility on their allocation.
Another point also addressed in #91 ticket is that the range can contain  priorities which are higher or lower than the normal priority  corresponding to the case where the DRMP AVP is not present (existing  situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the normal priority.

--
-------------------------------------+----------------------------------
-------------------------------------+---
Reporter:  jean-jacques.trottin     |      Owner:  draft-ietf-dime-
 @alcatel-lucent.com                |  drmp@tools.ietf.org
    Type:  defect                   |     Status:  new
Priority:  major                    |  Milestone:
Component:  drmp                     |    Version:
Severity:  Active WG Document       |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 0051078585257EC9_=-- From nobody Thu Sep 24 09:15:48 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9CC1B2A04 for ; Thu, 24 Sep 2015 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbhjPNOoCLD9 for ; Thu, 24 Sep 2015 09:15:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC63C1B29F4 for ; Thu, 24 Sep 2015 09:15:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DCBA23F7CAE7 for ; Thu, 24 Sep 2015 16:15:34 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8OGFbRG020653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Sep 2015 18:15:38 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 24 Sep 2015 18:15:37 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ9gaeF2wYh1HO3kaZWEnZZ6A32Z5KAiqAgAANHYCAAaDZsA== Date: Thu, 24 Sep 2015 16:15:37 +0000 Message-ID: References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D45DAC9FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 16:15:47 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D45DAC9FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Janet, Martin Thanks for your feedback I understand the difference with cases dealing with resources with long hol= ding times (eg ARPs in 3GPP) driving to your conclusion that 5 levels shoul= d be enough. I would like to pursue the discussion on the following points - A Priority level may be associated to a certain type of UE/user ( e= .g. public safety with firemen or first responders, governmental users or g= old/ silver customers of the operator). It can also depend of the type of r= equest in an application, some requests having a higher or lower priority.= This multiples the number of cases. That being said, a given level of prio= rity may correspond to a high priority user with lower priority request a= nd a lower priority user with higher priority request. This is a matter o= f operator policy out the IETF scope. We only have to state if the number = of priority levels is sufficient according to operator views. It would be= good to have some other operator views. - For requests without priority DRMP AVP which correspond to the exis= ting client situation (the "normal" traffic) and which may continue to coex= ist with clients supporting DRMP for a while, we have to state if this defa= ult case correspond to a given level of priority with the two following dis= cussed possibilities: o The default case has the lowest priority but this exclude to introduce = lower priorities (eg for some MTC devices) o The default case correspond to an intermediate value (cf Lionel's mail)= . If we have 5 levels (0,1,2,3,4) and the value 2 is default one, it woul= d mean only two higher DRMP priority levels than the default one. Is it suf= ficient? - About the case with no DRMP AVP in the request, the mapping to a gi= ven DRMP level may be something optional as a Diameter node can do some f= urther analysis at application level (eg if it finds a Session-Priority AVP= in a Cx message or a Reservation-Priority in a RX message or another crite= ria) to decide the request handling . Thanks for your feedback Best regards JJacques De : Janet P Gunn [mailto:jgunn6@csc.com] Envoy=E9 : mercredi 23 septembre 2015 16:45 =C0 : DOLLY, MARTIN C Cc : dime@ietf.org; DiME; draft-ietf-dime-drmp@tools.ietf.org; TROTTIN, JEA= N-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; pat_mcgregor@msn.com Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels I have consulted with a couple of other people here, and we agree that 5 is= probably sufficient for this. You typically only need more priority levels when you are dealing with reso= urces with long holding times (which includes some of the resources ARP is = used for). With regard to the situation where the priority value is not present, assig= ning a "default priority" within the existing levels seems to work well . Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: "dime@ietf.org" >, "draft-ietf-dime-drmp@tools.ietf.org" >, "jean-jacques.trottin@alcatel-lucent.com" > Date: 09/23/2015 10:00 AM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ I have stated previously that I believe 5 levels are adequate, as I do not = see action on more than that. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Wednesday, September 23, 2015 9:49 AM To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which a= ppear to be not enough. In 3GPP, levels of priorities are also defined out= side Diameter with, in particular, sixteen levels in Policy Control for th= e ARP (Allocation and Retention Priority)information element. So it would = be better that the DRMP AVP also allow 16 values which is future proof and= leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain p= riorities which are higher or lower than the normal priority corresponding= to the case where the DRMP AVP is not present (existing situation); this = also drives to consider a larger range of levels with an intermediate valu= e corresponding to the normal priority. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D29D45DAC9FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Janet, Martin

 

Thanks  for your feedback

 

I understand the difference with cases = dealing with resources with long holding times (eg ARPs in 3GPP) = driving to your conclusion that 5 levels should be enough.

 

I would like to pursue the discussion on = the following points

 

-     =   A Priority level may be associate= d to a certain type of UE/user ( e.g. public safety with firemen or first r= esponders, governmental users or gold/ silver customers of the operator). It can also depend of the type of request in an applicat= ion, some requests having a  higher or lower priority. This multiples = the number of cases. That being said, a given level of priority may corresp= ond  to a high priority  user with lower priority request and a lower priority user with higher  priority requ= est.  This is a matter of operator policy out the IETF scope. = We only have to state if the number  of  priority levels is suffi= cient according to  operator views. It would be good to have some othe= r operator views.

 

-     =   For requests without priority D= RMP AVP which correspond to the existing client situation (the “norma= l” traffic) and which may continue to coexist with clients supporting DRMP for a while, we have to state if this default case correspond to a gi= ven level of priority with the two following discussed possibilities:<= /o:p>

o   The default case has the lowest= priority but this exclude to introduce lower priorities (eg for some MTC d= evices)

o   The default case correspond to = an intermediate value (cf Lionel’s mail). If we have  5 levels (= 0,1,2,3,4) and the value 2  is default one, it would mean only two higher DRMP priority levels than the default one. Is it sufficient?

 

-     =   About the case with no DRMP AVP= in the request, the mapping to a given DRMP level may be something  o= ptional as a Diameter node  can do some further analysis at application level (eg if it finds a Session-Priority AVP in a Cx message o= r a Reservation-Priority in a RX message or another criteria) to decide the= request handling .

 

Thanks for your feedback

 <= /p>

Best regards

 

JJacques

 <= /p>

De : Jane= t P Gunn [mailto:jgunn6@csc.com]
Envoy=E9 : mercredi 23 septembre 2015 16:45
=C0 : DOLLY, MARTIN C
Cc : dime@ietf.org; DiME; draft-= ietf-dime-drmp@tools.ietf.org; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richar= d F Kaczmarek; pat_mcgregor@msn.com
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 

I have consulted with a couple of other p= eople here, and we agree that 5 is probably sufficient  for this.

You typically only need more priority levels when you are dealin= g with resources with long holding times (which includes some of the resour= ces ARP is used for).

With regard to the situation where the priority value is not pre= sent, assigning a "default priority" within the existing levels s= eems to work well .

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        &= quot;DOLLY, MARTIN C" <md3135@att= .com>
To:        &= quot;dime@ietf.org" <dime@ietf.org>, "draft-ietf-di= me-drmp@tools.ietf.org" <draft-ietf-dime-drmp@tools.ietf.org>, "jean-jacques.trottin@al= catel-lucent.com" <jean-jacque= s.trottin@alcatel-lucent.com>
Date:        0= 9/23/2015 10:00 AM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounce= s@ietf.org>




I have stated previously that I believ= e 5 levels are adequate, as I do not see action on more than that.
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org= ] On Behalf Of dime issue tracker
Sent: Wednesday, September 23, 2015 9:49 AM
To: draft-ietf-d= ime-drmp@tools.ietf.org; jean-jacques.tro= ttin@alcatel-lucent.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities whic= h  appear to be not enough. In 3GPP, levels of priorities are also def= ined  outside Diameter with, in particular, sixteen levels in Policy C= ontrol for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AV= P also allow 16 values which is future  proof and leaves more flexibil= ity on their allocation.
Another point also addressed in #91 ticket is that the range can contai= n  priorities which are higher or lower than the normal priority  = ;corresponding to the case where the DRMP AVP is not present (existing &nbs= p;situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the norm= al priority.

--
-------------------------------------+-----------------------------= -----
-------------------------------------+---
Reporter:  jean-jacques.trottin     |     &nbs= p;Owner:  draft-ietf-dime-
 @alcatel-lucent.com             &nb= sp;  |  drmp@tools.ietf.or= g
    Type:  defect           &nb= sp;       |     Status:  new
Priority:  major               =      |  Milestone:
Component:  drmp               =       |    Version:
Severity:  Active WG Document       |   Keywor= ds:
-------------------------------------+-----------------------------= -----
-------------------------------------+---

Ticket URL: <http://trac.tools.i= etf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--_000_E194C2E18676714DACA9C3A2516265D29D45DAC9FR712WXCHMBA12z_-- From nobody Fri Sep 25 00:46:48 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005AE1B29AE for ; Fri, 25 Sep 2015 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbE6vC9tq6Wh for ; Fri, 25 Sep 2015 00:46:45 -0700 (PDT) Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B445E1B29AA for ; Fri, 25 Sep 2015 00:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1443167205; x=1474703205; h=from:to:date:subject:mime-version; bh=HoCRAaywwUfmVw+VkCCIPTetWyu3O+qNF8pV7QH5IF0=; b=jcLqF581+DuleMXjfEThNL97YcAGkJ8QYbd6E2xf6gKOkQMTt6+ukTaK 5bhy5BdusXMLijhlFoAQLfovNEole8QDhTdMzwnM2B5DN09KzHhscREyL I/3NQTlekINkLN3OTSLn0q7Tt8a935Vu4obmRSPqO+tsdbH7WBGZ3v3fb s=; X-Host: taurus.sdc.vzwcorp.com Received: from ohdub02exhub01.uswin.ad.vzwcorp.com ([10.97.42.201]) by vanguard.verizonwireless.com with ESMTP; 25 Sep 2015 00:46:44 -0700 Received: from OHDUB02EXCV43.uswin.ad.vzwcorp.com ([fe80::7823:7c58:b820:863c]) by OHDUB02EXHUB01.uswin.ad.vzwcorp.com ([10.97.42.201]) with mapi; Fri, 25 Sep 2015 03:46:44 -0400 From: "Lee, Jay" To: "dime@ietf.org" Date: Fri, 25 Sep 2015 03:46:43 -0400 Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AdD3Ze1yhLyKz8Z/SICFkW2yPTZNCw== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD46CAB168565540B56D65D1C472DD6101A2E90CD3OHDUB02EXCV43_" MIME-Version: 1.0 Message-Id: <20150925074645.B445E1B29AA@ietfa.amsl.com> Archived-At: Subject: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 07:46:47 -0000 --_000_CD46CAB168565540B56D65D1C472DD6101A2E90CD3OHDUB02EXCV43_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I support JJacques's proposal on extending the range of priority levels up = to 16. Verizon prefers having 7-8 priority levels, and having another 8 pri= ority levels for future use is fine with us. So Verizon supports a total of= 16 priority levels, as JJacques proposed. Thanks, Jay --_000_CD46CAB168565540B56D65D1C472DD6101A2E90CD3OHDUB02EXCV43_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I supp= ort JJacques’s proposal on extending the range of priority levels up = to 16. Verizon prefers having 7-8 priority levels, and having another 8 pri= ority levels for future use is fine with us. So Verizon supports a total of= 16 priority levels, as JJacques proposed.

 

Thanks,

 

Jay

 

= --_000_CD46CAB168565540B56D65D1C472DD6101A2E90CD3OHDUB02EXCV43_-- From nobody Fri Sep 25 07:31:52 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4FC1A1B1D for ; Fri, 25 Sep 2015 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8t1PSlU6NxO for ; Fri, 25 Sep 2015 07:31:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EBD1A1B23 for ; Fri, 25 Sep 2015 07:31:43 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 9317E2AC661; Fri, 25 Sep 2015 16:31:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.10]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6B3F6384061; Fri, 25 Sep 2015 16:31:40 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 16:31:40 +0200 From: To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: Re : [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ957kW3vnGur3rEyFMS3PYGO9HA== Date: Fri, 25 Sep 2015 14:31:39 +0000 Message-ID: <27705_1443191500_56055ACC_27705_5526_1_6B7134B31289DC4FAF731D844122B36E01D2B232@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01D2B232OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.25.135416 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 14:31:50 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01D2B232OPEXCLILM43corp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As discussed in another issue report, I also think that it should be possib= le to create levels allowing requests with lower priority than regular requ= ests and other with higher priority. With requests without priority indicat= ion being handled as if there had a priority in the middle of the range. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Pour : "dime@ietf.org" Objet : [Dime] [dime] #92 (drmp): Range of priority levels Date : jeu., sept. 24, 2015 12:15 Hi Janet, Martin Thanks for your feedback I understand the difference with cases dealing with resources with long hol= ding times (eg ARPs in 3GPP) driving to your conclusion that 5 levels shoul= d be enough. I would like to pursue the discussion on the following points - A Priority level may be associated to a certain type of UE/user ( e= .g. public safety with firemen or first responders, governmental users or g= old/ silver customers of the operator). It can also depend of the type of r= equest in an application, some requests having a higher or lower priority.= This multiples the number of cases. That being said, a given level of prio= rity may correspond to a high priority user with lower priority request a= nd a lower priority user with higher priority request. This is a matter o= f operator policy out the IETF scope. We only have to state if the number = of priority levels is sufficient according to operator views. It would be= good to have some other operator views. - For requests without priority DRMP AVP which correspond to the exis= ting client situation (the =93normal=94 traffic) and which may continue to = coexist with clients supporting DRMP for a while, we have to state if this = default case correspond to a given level of priority with the two following= discussed possibilities: o The default case has the lowest priority but this exclude to introduce = lower priorities (eg for some MTC devices) o The default case correspond to an intermediate value (cf Lionel=92s mai= l). If we have 5 levels (0,1,2,3,4) and the value 2 is default one, it wo= uld mean only two higher DRMP priority levels than the default one. Is it s= ufficient? - About the case with no DRMP AVP in the request, the mapping to a gi= ven DRMP level may be something optional as a Diameter node can do some f= urther analysis at application level (eg if it finds a Session-Priority AVP= in a Cx message or a Reservation-Priority in a RX message or another crite= ria) to decide the request handling . Thanks for your feedback Best regards JJacques De : Janet P Gunn [mailto:jgunn6@csc.com] Envoy=E9 : mercredi 23 septembre 2015 16:45 =C0 : DOLLY, MARTIN C Cc : dime@ietf.org; DiME; draft-ietf-dime-drmp@tools.ietf.org; TROTTIN, JEA= N-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; pat_mcgregor@msn.com Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels I have consulted with a couple of other people here, and we agree that 5 is= probably sufficient for this. You typically only need more priority levels when you are dealing with reso= urces with long holding times (which includes some of the resources ARP is = used for). With regard to the situation where the priority value is not present, assig= ning a "default priority" within the existing levels seems to work well . Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: "dime@ietf.org" >, "draft-ietf-dime-drmp@tools.ietf.org" >, "jean-jacques.trottin@alcatel-lucent.com" > Date: 09/23/2015 10:00 AM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" > ________________________________ I have stated previously that I believe 5 levels are adequate, as I do not = see action on more than that. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Wednesday, September 23, 2015 9:49 AM To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which a= ppear to be not enough. In 3GPP, levels of priorities are also defined out= side Diameter with, in particular, sixteen levels in Policy Control for th= e ARP (Allocation and Retention Priority)information element. So it would = be better that the DRMP AVP also allow 16 values which is future proof and= leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain p= riorities which are higher or lower than the normal priority corresponding= to the case where the DRMP AVP is not present (existing situation); this = also drives to consider a larger range of levels with an intermediate valu= e corresponding to the normal priority. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E01D2B232OPEXCLILM43corp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As discussed in another issue report, I also think that it should be p= ossible to create levels allowing requests with lower priority than regular= requests and other with higher priority. With requests without priority in= dication being handled as if there had a priority in the middle of the range.

Regards,

Lionel

Envoy=E9 depuis mon mobile Orange

----- Reply message -----
De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trot= tin@alcatel-lucent.com>
Pour : "dime@ietf.org" <dime@ietf.org>
Objet : [Dime] [dime] #92 (drmp): Range of priority levels
Date : jeu., sept. 24, 2015 12:15

Hi Janet, Martin

 

Thanks  for your feedback<= /p>

 

I understand the difference with cases= dealing with resources with long holding times (eg ARPs in 3GPP)= driving to your conclusion that 5 levels should be enough.

 

I would like to pursue the discussion on= the following points

 

-       A Priority level may be associated to a ce= rtain type of UE/user ( e.g. public safety with firemen or first responders= , governmental users or gold/ silver customers of the operator). It can also depend of the type of request in an application, so= me requests having a  higher or lower priority. This multiples the num= ber of cases. That being said, a given level of priority may correspond &nb= sp;to a high priority  user with lower priority request and a lower priority user with higher  priority request.  This is a matter of operator policy out the IETF sco= pe. We only have to state if the number  of  priority levels is sufficient according to  operator views. It would be good to have som= e other operator views.

&n= bsp;

-       For requests without priority DRMP AVP w= hich correspond to the existing client situation (the =93normal=94 traffic)= and which may continue to coexist with clients supporting DRMP for a while, we have to state if this default case correspond to a gi= ven level of priority with the two following discussed possibilities:

= o&n= bsp;  The default case has the lowest priority= but this exclude to introduce lower priorities (eg for some MTC devices)

= o&n= bsp;  The default case correspond to an interm= ediate value (cf Lionel=92s mail). If we have  5 levels (0,1,2,3,4) an= d the value 2  is default one, it would mean only two higher DRMP priority levels than the default one. Is it sufficient?

&n= bsp;

-       About the case with no DRMP AVP in the r= equest, the mapping to a given DRMP level may be something  optional a= s a Diameter node  can do some further analysis at application level (eg if it finds a Session-Priority AVP in a Cx message or a Reservat= ion-Priority in a RX message or another criteria) to decide the request han= dling .

 

Thanks for your feedback

 

Best regards

 

JJacques

 

De : Ja= net P Gunn [mailto:jgunn6@csc.com]
Envoy=E9 : mercredi 23 septembre 2015 16:45
=C0 : DOLLY, MARTIN C
Cc : dime@ietf.org; DiME; draft= -ietf-dime-drmp@tools.ietf.org; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richa= rd F Kaczmarek; pat_mcgregor@msn.com
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

I have consulted with a couple of other = people here, and we agree that 5 is probably sufficient  for this.

You typically only need more priority levels when you are deali= ng with resources with long holding times (which includes some of the resou= rces ARP is used for).

With regard to the situation where the priority value is not pr= esent, assigning a "default priority" within the existing levels = seems to work well .

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        md3135@= att.com>
To:        = "dime@ietf.org" <dime@ietf.org>, "draft-ietf-di= me-drmp@tools.ietf.org" <draft-ietf-dime-drmp@tools.ietf.org>, "jean-jacques.trottin@al= catel-lucent.com" <jean-jacque= s.trottin@alcatel-lucent.com>
Date:        Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bou= nces@ietf.org>




I have stated previously that I believ= e 5 levels are adequate, as I do not see action on more than that.
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org= ] On Behalf Of dime issue trackerdraft-ietf-d= ime-drmp@tools.ietf.org; jean-jacques.tro= ttin@alcatel-lucent.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities whic= h  appear to be not enough. In 3GPP, levels of priorities are also def= ined  outside Diameter with, in particular, sixteen levels in Policy C= ontrol for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AV= P also allow 16 values which is future  proof and leaves more flexibil= ity on their allocation.
Another point also addressed in #91 ticket is that the range can contai= n  priorities which are higher or lower than the normal priority  = ;corresponding to the case where the DRMP AVP is not present (existing &nbs= p;situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the norm= al priority.

--
-------------------------------------+-----------------------------= -----
-------------------------------------+---
Reporter:  jean-jacques.trottin     |     &nbs= p;Owner:  draft-ietf-dime-
 @alcatel-lucent.com             &nb= sp;  |  drmp@tools.ietf.or= g
    Type:  defect           &nb= sp;       |     Status:  new
Priority:  major               =      |  Milestone:
Component:  drmp               =       |    Version:
Severity:  Active WG Document       |   Keywor= ds:
-------------------------------------+-----------------------------= -----
-------------------------------------+---

Ticket URL: <http://trac.tools.i= etf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dimeDiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E01D2B232OPEXCLILM43corp_-- From paperpony@gmail.com Thu Sep 24 12:35:49 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4138B1A8866 for ; Thu, 24 Sep 2015 12:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwCWBl2KeO-s for ; Thu, 24 Sep 2015 12:35:48 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D694A1A885F for ; Thu, 24 Sep 2015 12:35:47 -0700 (PDT) Received: by vkgd64 with SMTP id d64so43582247vkg.0 for ; Thu, 24 Sep 2015 12:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XAGMHNPhJZR/RN/d/khv8ZIlM8citwvuEGBFRecegiQ=; b=zkIYzjgUWWjvOho/MKAu9RsVONdFx3zpewqEytVNZpHd5co1jMEqLLulCrTeX5TrNB nJpT4FVq6YUsmS4OWKc49/LoMbuIW7OynBQKvM4HdgEvpxBEV4Naa6zU1SBXDZ8Jip98 9ocJZ+LmB+x4sKfaxwpiiheqOJHqFY3Vp2mjYenZJ1AynVm7mWHg+C8ubVt1Sx888d4B jlH1ukM4o6cQreN+p6HUa5GB7GlkTgaaRGeD6LOK6W6drWPOxpif6J/WUzKz/X0GRGH7 UhBurP4aBDBjPBT1Qbf1jgBPEX5p3b8mdbqbKu209klfcgI2CYNawW5ksS/ES+7+6di8 smRQ== MIME-Version: 1.0 X-Received: by 10.31.108.91 with SMTP id h88mr750758vkc.57.1443123346972; Thu, 24 Sep 2015 12:35:46 -0700 (PDT) Received: by 10.31.13.205 with HTTP; Thu, 24 Sep 2015 12:35:46 -0700 (PDT) Date: Thu, 24 Sep 2015 12:35:46 -0700 Message-ID: From: Jay Lee To: dime@ietf.org Content-Type: multipart/alternative; boundary=001a11478f4476a246052083561c Archived-At: X-Mailman-Approved-At: Fri, 25 Sep 2015 08:53:26 -0700 Subject: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 19:51:33 -0000 --001a11478f4476a246052083561c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Verizon supports JJacques=E2=80=99s proposal on extending range of priority= levels up to 16. We prefer having have 7-8 priority levels, and also having another 8 priority levels for future us, so 16 priority levels are fine with us. Thanks, Jay --001a11478f4476a246052083561c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,

=C2=A0

Verizon supports JJacques=E2=80=99s proposal on exte= nding range of priority levels up to 16. We prefer having have 7-8 priority levels, and also having another 8= priority levels for future us, so 16 priority levels are fine with us.


=C2=A0

Thanks,

=C2=A0

Jay

--001a11478f4476a246052083561c-- From nobody Wed Sep 30 12:49:39 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01661A89F1 for ; Wed, 30 Sep 2015 12:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAkis4z-jV6a for ; Wed, 30 Sep 2015 12:49:35 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074AD1A89C4 for ; Wed, 30 Sep 2015 12:49:34 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:57391 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZhNNa-002kUE-Lp for dime@ietf.org; Wed, 30 Sep 2015 12:49:34 -0700 To: dime@ietf.org References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> <27705_1443191500_56055ACC_27705_5526_1_6B7134B31289DC4FAF731D844122B36E01D2B232@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <560C3CC9.8010606@usdonovans.com> Date: Wed, 30 Sep 2015 14:49:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <27705_1443191500_56055ACC_27705_5526_1_6B7134B31289DC4FAF731D844122B36E01D2B232@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------070504080305040300070004" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 19:49:38 -0000 This is a multi-part message in MIME format. --------------070504080305040300070004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I believe there are two proposals here. First, to increase the number of priority levels to 16. Second, to make the default priority the middle of the range, so this would presumably make the default value 8. Is this correct? Are there objections to these changes? Regards, Steve On 9/25/15 9:31 AM, lionel.morand@orange.com wrote: > As discussed in another issue report, I also think that it should be > possible to create levels allowing requests with lower priority than > regular requests and other with higher priority. With requests without > priority indication being handled as if there had a priority in the > middle of the range. > > Regards, > > Lionel > > Envoyé depuis mon mobile Orange > > ----- Reply message ----- > De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > > Pour : "dime@ietf.org" > Objet : [Dime] [dime] #92 (drmp): Range of priority levels > Date : jeu., sept. 24, 2015 12:15 > > Hi Janet, Martin > > Thanks for your feedback > > I understand the difference with cases dealing with resources with > long holding times (eg ARPs in 3GPP) driving to your conclusion that 5 > levels should be enough. > > I would like to pursue the discussion on the following points > > -A Priority level may be associated to a certain type of UE/user ( > e.g. public safety with firemen or first responders, governmental > users or gold/ silver customers of the operator). It can also depend > of the type of request in an application, some requests having a > higher or lower priority. This multiples the number of cases. That > being said, a given level of priority may correspond to a high > priority user with lower priority request and a lower priority user > with higher priority request. This is a matter of operator policy > out the IETF scope. We only have to state if the number of priority > levels is sufficient according to operator views. It would be good to > have some other operator views. > > -For requests without priority DRMP AVP which correspond to the > existing client situation (the “normal” traffic) and which may > continue to coexist with clients supporting DRMP for a while, we have > to state if this default case correspond to a given level of priority > with the two following discussed possibilities: > > oThe default case has the lowest priority but this exclude to > introduce lower priorities (eg for some MTC devices) > > oThe default case correspond to an intermediate value (cf Lionel’s > mail). If we have 5 levels (0,1,2,3,4) and the value 2 is default > one, it would mean only two higher DRMP priority levels than the > default one. Is it sufficient? > > -About the case with no DRMP AVP in the request, the mapping to a > given DRMP level may be something optional as a Diameter node can do > some further analysis at application level (eg if it finds a > Session-Priority AVP in a Cx message or a Reservation-Priority in a RX > message or another criteria) to decide the request handling . > > Thanks for your feedback > > Best regards > > JJacques > > *De :*Janet P Gunn [mailto:jgunn6@csc.com] > *Envoyé :* mercredi 23 septembre 2015 16:45 > *À :* DOLLY, MARTIN C > *Cc :* dime@ietf.org; DiME; draft-ietf-dime-drmp@tools.ietf.org; > TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; > pat_mcgregor@msn.com > *Objet :* Re: [Dime] [dime] #92 (drmp): Range of priority levels > > I have consulted with a couple of other people here, and we agree that > 5 is probably sufficient for this. > > You typically only need more priority levels when you are dealing with > resources with long holding times (which includes some of the > resources ARP is used for). > > With regard to the situation where the priority value is not present, > assigning a "default priority" within the existing levels seems to > work well . > > Janet > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind CSC to any order or other contract unless pursuant > to explicit written agreement or government initiative expressly > permitting the use of e-mail for such purpose. > > > > From: "DOLLY, MARTIN C" > > To: "dime@ietf.org " >, "draft-ietf-dime-drmp@tools.ietf.org > " > >, > "jean-jacques.trottin@alcatel-lucent.com > " > > > Date: 09/23/2015 10:00 AM > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > Sent by: "DiME" > > > ------------------------------------------------------------------------ > > > > > I have stated previously that I believe 5 levels are adequate, as I do > not see action on more than that. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker > Sent: Wednesday, September 23, 2015 9:49 AM > To: draft-ietf-dime-drmp@tools.ietf.org > ; > jean-jacques.trottin@alcatel-lucent.com > > Cc: dime@ietf.org > Subject: [Dime] [dime] #92 (drmp): Range of priority levels > > #92: Range of priority levels > > The ietf-dime-drmp draft currently mentions 5 levels of priorities > which appear to be not enough. In 3GPP, levels of priorities are also > defined outside Diameter with, in particular, sixteen levels in > Policy Control for the ARP (Allocation and Retention > Priority)information element. So it would be better that the DRMP AVP > also allow 16 values which is future proof and leaves more > flexibility on their allocation. > Another point also addressed in #91 ticket is that the range can > contain priorities which are higher or lower than the normal priority > corresponding to the case where the DRMP AVP is not present (existing > situation); this also drives to consider a larger range of levels > with an intermediate value corresponding to the normal priority. > > -- > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- > @alcatel-lucent.com | drmp@tools.ietf.org > > Type: defect | Status: new > Priority: major | Milestone: > Component: drmp | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+---------------------------------- > -------------------------------------+--- > > Ticket URL: > dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > 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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------070504080305040300070004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I believe there are two proposals here.

First, to increase the number of priority levels to 16.

Second, to make the default priority the middle of the range, so this would presumably make the default value 8.

Is this correct?

Are there objections to these changes?

Regards,

Steve

On 9/25/15 9:31 AM, lionel.morand@orange.com wrote:
As discussed in another issue report, I also think that it should be possible to create levels allowing requests with lower priority than regular requests and other with higher priority. With requests without priority indication being handled as if there had a priority in the middle of the range.

Regards,

Lionel

Envoyé depuis mon mobile Orange

----- Reply message -----
De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
Pour : "dime@ietf.org" <dime@ietf.org>
Objet : [Dime] [dime] #92 (drmp): Range of priority levels
Date : jeu., sept. 24, 2015 12:15

Hi Janet, Martin

 

Thanks  for your feedback

 

I understand the difference with cases dealing with resources with long holding times (eg ARPs in 3GPP) driving to your conclusion that 5 levels should be enough.

 

I would like to pursue the discussion on the following points

 

-       A Priority level may be associated to a certain type of UE/user ( e.g. public safety with firemen or first responders, governmental users or gold/ silver customers of the operator). It can also depend of the type of request in an application, some requests having a  higher or lower priority. This multiples the number of cases. That being said, a given level of priority may correspond  to a high priority  user with lower priority request and a lower priority user with higher  priority request.  This is a matter of operator policy out the IETF scope. We only have to state if the number  of  priority levels is sufficient according to  operator views. It would be good to have some other operator views.

 

-       For requests without priority DRMP AVP which correspond to the existing client situation (the “normal” traffic) and which may continue to coexist with clients supporting DRMP for a while, we have to state if this default case correspond to a given level of priority with the two following discussed possibilities:

o   The default case has the lowest priority but this exclude to introduce lower priorities (eg for some MTC devices)

o   The default case correspond to an intermediate value (cf Lionel’s mail). If we have  5 levels (0,1,2,3,4) and the value 2  is default one, it would mean only two higher DRMP priority levels than the default one. Is it sufficient?

 

-       About the case with no DRMP AVP in the request, the mapping to a given DRMP level may be something  optional as a Diameter node  can do some further analysis at application level (eg if it finds a Session-Priority AVP in a Cx message or a Reservation-Priority in a RX message or another criteria) to decide the request handling .

 

Thanks for your feedback

 

Best regards

 

JJacques

 

De : Janet P Gunn [mailto:jgunn6@csc.com]
Envoyé : mercredi 23 septembre 2015 16:45
À : DOLLY, MARTIN C
Cc : dime@ietf.org; DiME; draft-ietf-dime-drmp@tools.ietf.org; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richard F Kaczmarek; pat_mcgregor@msn.com
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

I have consulted with a couple of other people here, and we agree that 5 is probably sufficient  for this.

You typically only need more priority levels when you are dealing with resources with long holding times (which includes some of the resources ARP is used for).

With regard to the situation where the priority value is not present, assigning a "default priority" within the existing levels seems to work well .

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        "dime@ietf.org" <dime@ietf.org>, "draft-ietf-dime-drmp@tools.ietf.org" <draft-ietf-dime-drmp@tools.ietf.org>, "jean-jacques.trottin@alcatel-lucent.com" <jean-jacques.trottin@alcatel-lucent.com>
Date:        09/23/2015 10:00 AM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounces@ietf.org>




I have stated previously that I believe 5 levels are adequate, as I do not see action on more than that.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker
Sent: Wednesday, September 23, 2015 9:49 AM
To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities which  appear to be not enough. In 3GPP, levels of priorities are also defined  outside Diameter with, in particular, sixteen levels in Policy Control for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AVP also allow 16 values which is future  proof and leaves more flexibility on their allocation.
Another point also addressed in #91 ticket is that the range can contain  priorities which are higher or lower than the normal priority  corresponding to the case where the DRMP AVP is not present (existing  situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the normal priority.

--
-------------------------------------+----------------------------------
-------------------------------------+---
Reporter:  jean-jacques.trottin     |      Owner:  draft-ietf-dime-
 @alcatel-lucent.com                |  drmp@tools.ietf.org
    Type:  defect                   |     Status:  new
Priority:  major                    |  Milestone:
Component:  drmp                     |    Version:
Severity:  Active WG Document       |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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.



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------070504080305040300070004-- From nobody Wed Sep 30 13:15:59 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6AD1A8A4D for ; Wed, 30 Sep 2015 13:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQFMBpbzhMn4 for ; Wed, 30 Sep 2015 13:15:51 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E11E1A8A52 for ; Wed, 30 Sep 2015 13:15:51 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8UKESfG004086; Wed, 30 Sep 2015 16:15:49 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 1x5qr8j07n-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2015 16:15:49 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UKFmdP010866; Wed, 30 Sep 2015 16:15:48 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UKFafV010691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2015 16:15:44 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 30 Sep 2015 20:15:17 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.4]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 16:15:17 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ9gacicybpqthaEmGc5qbwlXau55KIzrAgAtjD5WAAAcDUA== Date: Wed, 30 Sep 2015 20:15:16 +0000 Message-ID: References: <081.b70b3dea6f29d62d9ab549868a75dbb7@trac.tools.ietf.org> <27705_1443191500_56055ACC_27705_5526_1_6B7134B31289DC4FAF731D844122B36E01D2B232@OPEXCLILM43.corporate.adroot.infra.ftgroup> <560C3CC9.8010606@usdonovans.com> In-Reply-To: <560C3CC9.8010606@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.173.37] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615C0734CMISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-30_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509300246 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:15:57 -0000 --_000_E42CCDDA6722744CB241677169E8365615C0734CMISOUT7MSGUSRDB_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I can support this. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 3:49 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I believe there are two proposals here. First, to increase the number of priority levels to 16. Second, to make the default priority the middle of the range, so this would= presumably make the default value 8. Is this correct? Are there objections to these changes? Regards, Steve On 9/25/15 9:31 AM, lionel.morand@orange.com wrote: As discussed in another issue report, I also think that it should be possib= le to create levels allowing requests with lower priority than regular requ= ests and other with higher priority. With requests without priority indicat= ion being handled as if there had a priority in the middle of the range. Regards, Lionel Envoy=E9 depuis mon mobile Orange ----- Reply message ----- De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Pour : "dime@ietf.org" Objet : [Dime] [dime] #92 (drmp): Range of priority levels Date : jeu., sept. 24, 2015 12:15 Hi Janet, Martin Thanks for your feedback I understand the difference with cases dealing with resources with long hol= ding times (eg ARPs in 3GPP) driving to your conclusion that 5 levels shoul= d be enough. I would like to pursue the discussion on the following points - A Priority level may be associated to a certain type of UE/user ( e= .g. public safety with firemen or first responders, governmental users or g= old/ silver customers of the operator). It can also depend of the type of r= equest in an application, some requests having a higher or lower priority.= This multiples the number of cases. That being said, a given level of prio= rity may correspond to a high priority user with lower priority request a= nd a lower priority user with higher priority request. This is a matter o= f operator policy out the IETF scope. We only have to state if the number = of priority levels is sufficient according to operator views. It would be= good to have some other operator views. - For requests without priority DRMP AVP which correspond to the exis= ting client situation (the "normal" traffic) and which may continue to coex= ist with clients supporting DRMP for a while, we have to state if this defa= ult case correspond to a given level of priority with the two following dis= cussed possibilities: o The default case has the lowest priority but this exclude to introduce = lower priorities (eg for some MTC devices) o The default case correspond to an intermediate value (cf Lionel's mail)= . If we have 5 levels (0,1,2,3,4) and the value 2 is default one, it woul= d mean only two higher DRMP priority levels than the default one. Is it suf= ficient? - About the case with no DRMP AVP in the request, the mapping to a gi= ven DRMP level may be something optional as a Diameter node can do some f= urther analysis at application level (eg if it finds a Session-Priority AVP= in a Cx message or a Reservation-Priority in a RX message or another crite= ria) to decide the request handling . Thanks for your feedback Best regards JJacques De : Janet P Gunn [mailto:jgunn6@csc.com] Envoy=E9 : mercredi 23 septembre 2015 16:45 =C0 : DOLLY, MARTIN C Cc : dime@ietf.org; DiME; draft-ietf-dime-drmp@tools.= ietf.org; TROTTIN, JEAN-JACQUES= (JEAN-JACQUES); Richard F Kaczmarek; pat_mcgregor@msn.com Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels I have consulted with a couple of other people here, and we agree that 5 is= probably sufficient for this. You typically only need more priority levels when you are dealing with reso= urces with long holding times (which includes some of the resources ARP is = used for). With regard to the situation where the priority value is not present, assig= ning a "default priority" within the existing levels seems to work well . Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: "dime@ietf.org" >, "draft-ietf-dime-drmp@tools.ietf.org" >, "jean-jacques.trottin@alcatel-lucent.com" > Date: 09/23/2015 10:00 AM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ I have stated previously that I believe 5 levels are adequate, as I do not = see action on more than that. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker Sent: Wednesday, September 23, 2015 9:49 AM To: draft-ietf-dime-drmp@tools.ietf.org; jean-jacques.trottin@alcatel-lucent.com Cc: dime@ietf.org Subject: [Dime] [dime] #92 (drmp): Range of priority levels #92: Range of priority levels The ietf-dime-drmp draft currently mentions 5 levels of priorities which a= ppear to be not enough. In 3GPP, levels of priorities are also defined out= side Diameter with, in particular, sixteen levels in Policy Control for th= e ARP (Allocation and Retention Priority)information element. So it would = be better that the DRMP AVP also allow 16 values which is future proof and= leaves more flexibility on their allocation. Another point also addressed in #91 ticket is that the range can contain p= riorities which are higher or lower than the normal priority corresponding= to the case where the DRMP AVP is not present (existing situation); this = also drives to consider a larger range of levels with an intermediate valu= e corresponding to the normal priority. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | drmp@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: drmp | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E42CCDDA6722744CB241677169E8365615C0734CMISOUT7MSGUSRDB_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, I can support this.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 3:49 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=

 

I believe there are t= wo proposals here.

First, to increase the number of priority levels to 16.

Second, to make the default priority the middle of the range, so this would= presumably make the default value 8.

Is this correct?

Are there objections to these changes?

Regards,

Steve

On 9/25/15 9:31 AM, lionel.morand@orange.com wrote:

As discussed in another issue report, I also think that it should be= possible to create levels allowing requests with lower priority than regul= ar requests and other with higher priority. With requests without priority indication being handled as if there had a prior= ity in the middle of the range.

 

Regards,

 

Lionel

 

Envoy=E9 depuis mon mobile Orange

 

----- Reply message -----
De : "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
Pour : "dime@ietf.org" = <dime@ietf.org>
Objet : [Dime] [dime] #92 (drmp): Range of priority levels
Date : jeu., sept. 24, 2015 12:15

 

Hi Janet, Martin

 

Thanks  for your feedback

 

I understand the difference with cases dealing with resources with long holding times (eg ARPs in 3GPP) driving to y= our conclusion that 5 levels should be enough.

 

I would like to pursue the discussion on the followin= g points

 

-     &nb= sp; A Priority level may be associated to a certain type of UE/user ( e.g= . public safety with firemen or first responders, governmental users or gol= d/ silver customers of the operator). It can also depend of the type of request in an application, some requests having= a  higher or lower priority. This multiples the number of cases. That= being said, a given level of priority may correspond  to a high prior= ity  user with lower priority request and a lower priority user with higher  priority request.  Th= is is a matter of operator policy out the IETF scope. We only have to state= if the number  of  priority levels is sufficient according to  operator views. It would be good to have some other operator view= s.

 

-     &nb= sp; For requests without priority DRMP AVP which correspond to the exis= ting client situation (the “normal” traffic) and which may cont= inue to coexist with clients supporting DRMP for a while, we have to state if this default case correspond to a given level of prior= ity with the two following discussed possibilities:

o   The default case has the lowest priority but this exclude to introd= uce lower priorities (eg for some MTC devices)

o   The default case correspond to an intermediate value (cf LionelR= 17;s mail). If we have  5 levels (0,1,2,3,4) and the value 2  is = default one, it would mean only two higher DRMP priority levels than the default one. Is it sufficient?

 

-     &nb= sp; About the case with no DRMP AVP in the request, the mapping to a gi= ven DRMP level may be something  optional as a Diameter node  can= do some further analysis at application level (eg if it finds a Session-Priority AVP in a Cx message or a Reservation-Priority = in a RX message or another criteria) to decide the request handling .

 

Thanks for your feedback

 

Best regards

 

JJacques

 

De : Janet P Gunn [mailto:jgunn6@csc.com]
Envoy=E9 : mercredi 23 septembre 2015 16:45
=C0 : DOLLY, MARTIN C
Cc : dime@ietf.org; DiME; draft-ietf-dime-drmp= @tools.ietf.org; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Richard F Kaczma= rek; pat_mcgregor@msn.com
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

I have consulted with a couple of other people here, = and we agree that 5 is probably sufficient  for this.

Y= ou typically only need more priority levels when you are dealing with resou= rces with long holding times (which includes some of the resources ARP is u= sed for).

W= ith regard to the situation where the priority value is not present, assign= ing a "default priority" within the existing levels seems to work= well .

J= anet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C&quo= t; <md3135@att.com>
To:        "dime@ietf.org" <di= me@ietf.org>, "draft-ietf-di= me-drmp@tools.ietf.org" <draft-ietf-dime-drmp@tools.ietf.org>, "jean-jacques.trottin@al= catel-lucent.com" <jean-jacque= s.trottin@alcatel-lucent.com>
Date:        09/23/2015 10:00 AM
Subject:        Re: [Dime] [dime] #92 = (drmp): Range of priority levels
Sent by:        "DiME" <<= a href=3D"mailto:dime-bounces@ietf.org">dime-bounces@ietf.org>




I have stated previously that I believ= e 5 levels are adequate, as I do not see action on more than that.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org= ] On Behalf Of dime issue tracker
Sent: Wednesday, September 23, 2015 9:49 AM
To: draft-ietf-d= ime-drmp@tools.ietf.org; jean-jacques.tro= ttin@alcatel-lucent.com
Cc: dime@ietf.org
Subject: [Dime] [dime] #92 (drmp): Range of priority levels

#92: Range of priority levels

The ietf-dime-drmp draft currently mentions 5 levels of priorities whic= h  appear to be not enough. In 3GPP, levels of priorities are also def= ined  outside Diameter with, in particular, sixteen levels in Policy C= ontrol for  the ARP (Allocation and Retention Priority)information element. So it  would be better that the DRMP AV= P also allow 16 values which is future  proof and leaves more flexibil= ity on their allocation.
Another point also addressed in #91 ticket is that the range can contai= n  priorities which are higher or lower than the normal priority  = ;corresponding to the case where the DRMP AVP is not present (existing &nbs= p;situation); this also drives to consider a larger range of levels with an  intermediate value corresponding to the norm= al priority.

--
-------------------------------------+-----------------------------= -----
-------------------------------------+---
Reporter:  jean-jacques.trottin     |     &nbs= p;Owner:  draft-ietf-dime-
 @alcatel-lucent.com             &nb= sp;  |  drmp@tools.ietf.or= g
    Type:  defect           &nb= sp;       |     Status:  new
Priority:  major               =      |  Milestone:
Component:  drmp               =       |    Version:
Severity:  Active WG Document       |   Keywor= ds:
-------------------------------------+-----------------------------= -----
-------------------------------------+---

Ticket URL: <http://trac.tools.i= etf.org/wg/dime/trac/ticket/92>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime

 

--_000_E42CCDDA6722744CB241677169E8365615C0734CMISOUT7MSGUSRDB_-- From nobody Wed Sep 30 13:27:39 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD8E1A8A57 for ; Wed, 30 Sep 2015 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw_9MD1SJdsa for ; Wed, 30 Sep 2015 13:27:36 -0700 (PDT) Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFF61A8A56 for ; Wed, 30 Sep 2015 13:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1443644856; x=1475180856; h=from:to:subject:date:mime-version; bh=8ehzCDy2IqJ3/KWmZAtblZMHFgWnXeloYpWJQIsKW4k=; b=D0akAG/ZAogMg5LDX+OJ5y12xJyawg+3irsTKDWfw81MIyNsvDGbHIPQ tbKbdc510SEjlGZRkz3HSVSFrvLp8Ps30B8HuQ/pwrF0enGnxW3wfkIoO TIYXzKr6NT8GvdrCRMHiFztSaanu+gvMMtcvXHQ2ZHVOgcGquDg3Wv7Hy A=; X-Host: terra.sdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by vanguard.verizonwireless.com with ESMTP; 30 Sep 2015 13:27:35 -0700 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Wed, 30 Sep 2015 13:27:35 -0700 From: "Lee, Jay" To: "dime@ietf.org" Thread-Topic: Re: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AdD7vGQQB0J1F9yaSjuAhrCWPOpGxQ== Date: Wed, 30 Sep 2015 20:27:35 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048001052ACASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20150930202736.3FFF61A8A56@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:27:38 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048001052ACASAC1EXP009uswin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay --_000_C026C31E3CD6CA43953D6D95AB48048001052ACASAC1EXP009uswin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve and all,

 

For the first proposal, as I indicated, I support in= creasing the number of priority levels up to 16.

 

I am also fine with the second proposal. My question= is: do we need to mandate this feature, as individual operators have diffe= rent situations? Perhaps some flexibility should be allowed? Instead of man= dating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic&#= 8217; without a particular high or low priority. Then each operator can map= this default to a value (e.g., 8 or something else) that they feel appropr= iate.

 

Thanks,

 

Jay

--_000_C026C31E3CD6CA43953D6D95AB48048001052ACASAC1EXP009uswin_-- From nobody Wed Sep 30 13:36:00 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400CB1A8A7C for ; Wed, 30 Sep 2015 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kifgyfyb-jKe for ; Wed, 30 Sep 2015 13:35:54 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6171A8A7D for ; Wed, 30 Sep 2015 13:35:54 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:57454 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZhO6R-003QqK-3r for dime@ietf.org; Wed, 30 Sep 2015 13:35:54 -0700 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B9218047A22@ESESSMB101.ericsson.se> <55C0B9D2.4080208@usdonovans.com> <087A34937E64E74E848732CFF8354B921804A3FE@ESESSMB101.ericsson.se> <55C28B01.1010800@usdonovans.com> From: Steve Donovan Message-ID: <560C47A6.4040109@usdonovans.com> Date: Wed, 30 Sep 2015 15:35:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55C28B01.1010800@usdonovans.com> Content-Type: multipart/alternative; boundary="------------060206050507080204050606" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] Host report containing rate abatement algorithm (was Re: PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:35:59 -0000 This is a multi-part message in MIME format. --------------060206050507080204050606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit All, I haven't received any feedback on this analysis. As such, I'm planning to update the rate draft to reflect the recommendation that we limit support for the rate algorithm to peer reports. Please let me know if there are concerns with this approach. Steve On 8/5/15 5:15 PM, Steve Donovan wrote: > There is an open question in the rate draft as to whether or not the > rate abatement algorithm should be supported in host overload reports > with the implication that the server is controlling the maximum rate > of Diameter traffic sent to the server from a single client. > > The draft outlines use of the rate algorithm in peer reports (which > are defined in the agent overload draft). This can be used in both > agent based and non agent based networks to effectively control the > rate arriving at the overloaded server as the server explicitly knows > the identity of all peers and can allocate traffic between them. The > peers also know what traffic would normally be sent to the endpoint > and can effectively apply abatement strategies to control the traffic > actually sent to that endpoint. > > The question is whether it makes sense to support the rate algorithm > in host and realm reports. I'm ignoring realm reports for the time > being but I suspect similar considerations exist for realm reports as > for host reports. > > My concerns with this scenario are the following: > > First, the overloaded server doesn't have full knowledge of all > sources (client endpoints) of traffic. This however can be learned by > the server remembering the identity of all clients sending it > traffic. There currently isn't a requirement that the server remember > the source of all clients supporting DOIC so this would be new > functionality. > > Second, endpoints (clients) do not know where all of the Diameter > requests it generates will be routed. Clients send two types of > traffic, host routed and realm routed requests. What does a client do > when it receives a Host:Rate report indicating a maximum rate to be > sent to the server from that client? All that the client can do to > influence the amount of traffic sent to the overloaded server is to > apply abatement treatment to host routed requests targeted for that > server. This is unlikely to match the servers expectation when > sending the Host:Rate report. I guess the client could throttle a > percentage of the realm routed requests based on an algorithm > including usual percentage of realm routed requests and number of > servers that might eventually handle those requests but this seems > pretty convoluted and unlikely to accurately control traffic sent to > the server. > > We addressed this issue with Host:Loss reports by splitting the > abatement handling between the endpoint (which handles abatement of > host routed requests) and last-hop agents (which handle abatement of > realm routed requests). This works because the loss algorithm is > stateless. If we keep this split for Host:Rate reports then there is > the need for shared information between clients and agents to control > the amount of traffic sent to a server. The actual rate of traffic > sent to the server would be the sum of all host routed requests > allowed by all clients plus the sum of all realm routed requests > allowed by all agents. I personally don't think we want to try to > specify how this exchange of state would work and how it would then be > used to make throttling decisions. > > My recommendation, if it isn't obvious from the above, is that we > limit support for the rate algorithm to peer reports. If we come up > with an elegant way of addressing the above concerns sometime in the > future then that could be a new extension draft. > > Regards, > > Steve > > > On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote: >> >> Hello Steve, >> >> Thanks for your response. >> >> See my comments below >> >> Best regards >> >> /MCruz >> >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan >> *Sent:* martes, 04 de agosto de 2015 15:11 >> *To:* dime@ietf.org >> *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload >> + Rate Algorithm drafts) >> >> Maria Cruz, >> >> Thank you for the reviews. See my comments inline. >> >> Regards, >> >> Steve >> >> On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote: >> >> Hello all, >> >> I would like to expand a bit on the need for a PEER report by an >> abatement algorithm, what I do not think is correct. >> >> This is being commented in previous question “[Dime] DA overload >> comment on 3.2 Diameter end-point use cases”, but I would like to >> provide some reflections as well on the RATE draft in this respect. >> >> Therefore my comments affect both >> draft-ietf-dime-doic-rate-controland draft-ietf-dime-agent-overload. >> >> I will split my comment to make it is easier to reply and act upon: >> >> a)*RATE draft, PEER usage: * >> >> In Rate draft, draft-ietf-dime-doic-rate-control-01, it is >> somehow assumed that the Report Type to be used is “Peer”, in >> fact, we still have an Open Issue about whether it is applicable >> to Host and Realm report. See clause 3, “Interaction with DOIC >> report types”: >> >> 3. Interaction with DOIC report types >> >> As of the publication of this specification there are two DOIC >> report >> >> types defined with the specification of a third in progress: >> >> 1. Host - Overload of a specific Diameter Application at a >> specific >> >> Diameter Node as defined in [I-D.ietf-dime-ovli]. >> >> 2. Realm - Overload of a specific Diameter Application at a >> specific >> >> Diameter Realm as defined in [I-D.ietf-dime-ovli]. >> >> 3. Peer - Overload of a specific Diameter peer as defined in >> >> [I-D.ietf-dime-agent-overload]. >> >> The rate algorithm MAY be selected by reporting nodes for any of >> >> these report types. >> >> Editor's note: It needs to be validated that use of the rate >> >> algorithm applies to the host and realm report types. >> >> In my opinion, Rate should work with Host and Realm, and as well >> with Peer. But whatever it is required should be described in >> DOIC (host and Realm), and Agent Overload (Peer). >> >> I understand there is a different thing with Rate comparing with >> the Default algorithm: the reporting node needs to keep track of >> the “target”, since only some Reacting nodes will use Rate. But >> this does not imply that Host and Realm will not be able to be >> used. Apart from that, any specifics about the Peer Report Type >> usage needs to be covered in Agent Overload draft. >> >> SRD> I agree that the current writing of the draft is focused on the >> use of the rate algorithm in a peer report. I intentionally put the >> editor's note in the document to make sure that we have the >> discussion on whether or not there is reason to also allow use of the >> rate algorithm in host and realm reports. >> >> SRD> It is, however, not clear to me how rate would be an effective >> overload control mechanism in host reports, at least not in the >> general sense. Any time that a Diameter application allows for realm >> routed requests to be sent by a client it becomes impossible for a >> client to know the rate of requests that will arrive at a specific >> server. I'd like to see some thought put into how this would work >> before indicating support for it in the rate draft. >> MCRUZ> I do not understand your concern. A rate of message will be >> ensure in the reacting node either for a particular host or for a >> realm. Could you clarify please? >> >> >> SRD> I agree there may be times that a reporting nodes sends both >> rate and loss reports. I would expect this to be in transition >> periods as an operator turns on rate control. It seems, however, >> more likely that an operator would turn on rate between a reporting >> node and the first hop agents first and, if needed, have the agent >> translate rate OLRs into loss OLRs for reacting nodes that do not >> support rate. >> MCRUZ> Not sure how this is related to the discussion here >> >> b)*AGENT draft, requirement on the PEER usage: to be removed* >> >> It seems that in Agent Overload draft it is implied that Rate >> requires Peer Report Type, what I do not think is right. >> >> See in draft-ietf-dime-agent-overload-01, clause 3.2: >> >> 3.2. Diameter Endpoint Use Cases >> >> This section outlines use cases for the peer report feature involving >> >> Diameter Clients and Diameter Servers. >> >> 3.2.1. Hop-by-hop Abatement Algorithms >> >> It is envisioned that abatement algorithms will be defined that will >> >> support the option for Diameter Endpoints to send peer reports. For >> >> instance, it is envisioned that one usage scenario for the rate >> >> algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked >> >> on by the DIME working group as this is written, will involve >> >> abatement being done on a hop-by-hop basis. >> >> This rate deployment scenario would involve Diameter Endpoints >> >> generating peer reports and selecting the rate algorithm for >> >> abatement of overload conditions. >> >> I think this paragraph should be removed from Agent Overload draft. >> >> SRD> I don't see why. This is an explanation of how peer might be >> used, not a prescription that it must happen. >> MCRUZ> “this section outlines use cases for the peer report feature >> involving Clients and Servers”. Why is this needed? I think the Agent >> draft should cover only Agent overload use cases, nothing else. >> >> c)*RATE draft, PEER references* >> >> On the other hand, there are some other references to PEER Report >> behavior along draft, that in my opinion should be removed, this >> should be described only in Agent Overload draft. >> >> See following text: >> >> 4. Capability Announcement >> >> … >> >> For peer reports the selected algorithm is reflected in the OC- >> >> Peer-Algo AVP sent as part of the OC-Supported-Features AVP >> >> included answer messages for transaction where the request >> >> contained an OC-Supported-Features AVP. This is per the >> >> procedures defined in [I-D.ietf-dime-agent-overload]. >> >> SRD> This is explicitly referring back to the agent overload draft, >> where, I agree, the behavior is to be defined. >> MCRUZ> then do you agree about removal? >> >> Editor's Node: The peer report specification is still under >> >> development and, as such, the above paragraph is subject to >> >> change. >> >> 5.3. Reporting Node Maintenance of Overload Control State >> >> … >> >> o For Peer reports the target is the DiameterID of the Diameter Peer >> >> from which the request was received. >> >> 6.2. OC-OLR AVP >> >> This extension defines the OC-Maximum-Rate AVP to be an optional part >> >> of the OC-OLR AVP. >> >> OC-OLR ::= < AVP Header: TBD2 > >> >> < OC-Sequence-Number > >> >> < OC-Report-Type > >> >> [ OC-Reduction-Percentage ] >> >> [ OC-Validity-Duration ] >> >> [ OC-Source-ID ] >> >> [ OC-Abatement-Algorithm ] >> >> [ OC-Maximum-Rate ] >> >> * [ AVP ] >> >> This extension makes no changes to the other AVPs that are part of >> >> the OC-OLR AVP. >> >> This extension does not define new overload report types. The >> >> existing report types of host and realm defined in >> >> [I-D.ietf-dime-ovli] apply to the rate control algorithm. The peer >> >> report type defined in [I-D.ietf-dime-agent-overload] also applies to >> >> the rate control algorithm. >> >> For the last paragraph, remove at least Agent Overload draft is approved. >> >> SRD> I don't understand what is being proposed but the rate algorithm >> has a dependency on the agent overload draft because at least one of >> the report types it needs to support is peer, and peer is defined in >> the agent overload draft. >> MCRUZ> my point is that what belongs to Agent overload’s draft shall >> be only in Agent overload’s draft. I highlighted paragraphs above >> that belongs to Agent overload’s draft. >> >> Best regards >> >> /MCruz >> >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan >> *Sent:* lunes, 20 de julio de 2015 17:08 >> *To:* dime@ietf.org >> *Subject:* Re: [Dime] DA overload comment on 3.2 Diameter end-point >> use cases >> >> JJacques, >> >> Thanks for the comment. >> >> I would assume that the Diameter endpoint (server for this >> discussion) would send either a peer report or a host report. There >> would be no reason for the server to send both. >> >> A host report is processed and passed on by agents. >> >> A peer report is consumed by agents and, most likely, a new peer >> report is generated by the agent. >> >> The peer report is envisioned to be used for multiple reasons. The >> first is defined in the agent overload draft to allow agents to >> communicate overload state. The second is for overload abatement >> algorithms that require peer-to-peer semantics. The first case of >> this second usage is the rate overload abatement algorithm. >> >> Regards, >> >> Steve >> >> On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: >> >> Hi >> >> About DA overload (draft-ietf-dime-agent-overload), I have a >> comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. >> I do not well see the reasons why a server would send “peer >> overload” reports in addition to the ovli OLRs specified in >> draft-ietf-dime-ovli , as it creates overlap. The DA is aware >> that it is a peer of the server; so the DA can handle the >> received ovli OLRs from the server as peer OLRs if it wants. So I >> would limit the draft-ietf-dime-agent-overload only to DA >> overload and the associated peer overload report to be generated >> by DA only . >> >> Best regards >> >> JJacques >> >> >> >> >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dime >> >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------060206050507080204050606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit All,

I haven't received any feedback on this analysis.  As such, I'm planning to update the rate draft to reflect the recommendation that we limit support for the rate algorithm to peer reports.

Please let me know if there are concerns with this approach.

Steve

On 8/5/15 5:15 PM, Steve Donovan wrote:
There is an open question in the rate draft as to whether or not the rate abatement algorithm should be supported in host overload reports with the implication that the server is controlling the maximum rate of Diameter traffic sent to the server from a single client.

The draft outlines use of the rate algorithm in peer reports (which are defined in the agent overload draft).  This can be used in both agent based and non agent based networks to effectively control the rate arriving at the overloaded server as the server explicitly knows the identity of all peers and can allocate traffic between them.  The peers also know what traffic would normally be sent to the endpoint and can effectively apply abatement strategies to control the traffic actually sent to that endpoint.

The question is whether it makes sense to support the rate algorithm in host and realm reports.  I'm ignoring realm reports for the time being but I suspect similar considerations exist for realm reports as for host reports. 

My concerns with this scenario are the following:

First, the overloaded server doesn't have full knowledge of all sources (client endpoints) of traffic.  This however can be learned by the server remembering the identity of all clients sending it traffic.  There currently isn't a requirement that the server remember the source of all clients supporting DOIC so this would be new functionality.

Second, endpoints (clients) do not know where all of the Diameter requests it generates will be routed.  Clients send two types of traffic, host routed and realm routed requests.  What does a client do when it receives a Host:Rate report indicating a maximum rate to be sent to the server from that client?  All that the client can do to influence the amount of traffic sent to the overloaded server is to apply abatement treatment to host routed requests targeted for that server.  This is unlikely to match the servers expectation when sending the Host:Rate report.  I guess the client could throttle a percentage of the realm routed requests based on an algorithm including usual percentage of realm routed requests and number of servers that might eventually handle those requests but this seems pretty convoluted and unlikely to accurately control traffic sent to the server.

We addressed this issue with Host:Loss reports by splitting the abatement handling between the endpoint (which handles abatement of host routed requests) and last-hop agents (which handle abatement of realm routed requests).  This works because the loss algorithm is stateless.  If we keep this split for Host:Rate reports then there is the need for shared information between clients and agents to control the amount of traffic sent to a server.  The actual rate of traffic sent to the server would be the sum of all host routed requests allowed by all clients plus the sum of all realm routed requests allowed by all agents.  I personally don't think we want to try to specify how this exchange of state would work and how it would then be used to make throttling decisions.

My recommendation, if it isn't obvious from the above, is that we limit support for the rate algorithm to peer reports.  If we come up with an elegant way of addressing the above concerns sometime in the future then that could be a new extension draft.

Regards,

Steve


On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:

Hello Steve,

Thanks for your response.

See my comments below

Best regards

/MCruz

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: dime@ietf.org
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

 

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:

Hello all,

 

I would like to expand a bit on the need for a PEER report by an abatement algorithm, what I do not think is correct.

This is being commented in previous question “[Dime] DA overload comment on 3.2 Diameter end-point use cases”, but I would like to provide some reflections as well on the RATE draft in this respect.

 

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-ietf-dime-agent-overload.

I will split my comment to make it is easier to reply and act upon:

 

a)      RATE draft, PEER usage:

In Rate draft,   draft-ietf-dime-doic-rate-control-01, it is somehow assumed that the Report Type to be used is “Peer”, in fact, we still have an Open Issue about whether it is applicable to Host and Realm report.  See clause 3, “Interaction with DOIC report types”:

 

3.  Interaction with DOIC report types

 

   As of the publication of this specification there are two DOIC report

   types defined with the specification of a third in progress:

 

   1.  Host - Overload of a specific Diameter Application at a specific

       Diameter Node as defined in [I-D.ietf-dime-ovli].

 

   2.  Realm - Overload of a specific Diameter Application at a specific

       Diameter Realm as defined in [I-D.ietf-dime-ovli].

 

   3.  Peer - Overload of a specific Diameter peer as defined in

       [I-D.ietf-dime-agent-overload].

 

   The rate algorithm MAY be selected by reporting nodes for any of

   these report types.

 

      Editor's note: It needs to be validated that use of the rate

      algorithm applies to the host and realm report types.

 

In my opinion, Rate should work with Host and Realm, and as well  with Peer. But whatever it is required should be described in DOIC (host and Realm), and Agent Overload (Peer).

I understand there is a different thing with Rate comparing with the Default algorithm: the reporting node needs to keep track of the “target”, since only some Reacting nodes will use Rate. But this does not imply that Host and Realm will not be able to be used. Apart from that, any specifics about the Peer Report Type usage needs to be covered in Agent Overload draft.

SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.
MCRUZ> I do not understand your concern. A rate of message will be ensure in the reacting node either for a particular host or for a realm. Could you clarify please?


SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.
MCRUZ> Not sure how this is related to the discussion here

 

 

b)      AGENT draft, requirement on the PEER usage: to be removed

It seems that in Agent Overload draft it is implied that Rate requires Peer Report Type, what I do not think is right.

See in draft-ietf-dime-agent-overload-01 , clause 3.2:

 

3.2.  Diameter Endpoint Use Cases

 

   This section outlines use cases for the peer report feature involving

   Diameter Clients and Diameter Servers.

 

3.2.1.  Hop-by-hop Abatement Algorithms

 

   It is envisioned that abatement algorithms will be defined that will

   support the option for Diameter Endpoints to send peer reports.  For

   instance, it is envisioned that one usage scenario for the rate

   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked

   on by the DIME working group as this is written, will involve

   abatement being done on a hop-by-hop basis.

 

   This rate deployment scenario would involve Diameter Endpoints

   generating peer reports and selecting the rate algorithm for

   abatement of overload conditions.

 

I think this paragraph should be removed from Agent Overload draft.

SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.
MCRUZ> “this section outlines use cases for the peer report feature involving Clients and Servers”. Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.

 

c)       RATE draft, PEER references

 

On the other hand, there are some other references to PEER Report behavior along draft, that in my opinion should be removed, this should be described only in Agent Overload draft.

See following text:

 

4.  Capability Announcement

…

      For peer reports the selected algorithm is reflected in the OC-

      Peer-Algo AVP sent as part of the OC-Supported-Features AVP

      included answer messages for transaction where the request

      contained an OC-Supported-Features AVP.  This is per the

      procedures defined in [I-D.ietf-dime-agent-overload].

SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.
MCRUZ> then do you agree about removal?

 

      Editor's Node: The peer report specification is still under

      development and, as such, the above paragraph is subject to

      change.

 

5.3.  Reporting Node Maintenance of Overload Control State

…

   o  For Peer reports the target is the DiameterID of the Diameter Peer

      from which the request was received.

 

 

6.2.  OC-OLR AVP

 

   This extension defines the OC-Maximum-Rate AVP to be an optional part

   of the OC-OLR AVP.

 

      OC-OLR ::= < AVP Header: TBD2 >

                 < OC-Sequence-Number >

                 < OC-Report-Type >

                 [ OC-Reduction-Percentage ]

                 [ OC-Validity-Duration ]

                 [ OC-Source-ID ]

                 [ OC-Abatement-Algorithm ]

                 [ OC-Maximum-Rate ]

               * [ AVP ]

 

 

   This extension makes no changes to the other AVPs that are part of

   the OC-OLR AVP.

 

   This extension does not define new overload report types.  The

   existing report types of host and realm defined in

   [I-D.ietf-dime-ovli] apply to the rate control algorithm.  The peer

   report type defined in [I-D.ietf-dime-agent-overload] also applies to

   the rate control algorithm.  

 

For the last paragraph, remove at least Agent Overload draft is approved.

SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belongs to Agent overload’s draft shall be only in Agent overload’s draft. I highlighted paragraphs above that belongs to Agent overload’s draft.

 

Best regards

/MCruz

 

 

 

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 20 de julio de 2015 17:08
To: dime@ietf.org
Subject: Re: [Dime] DA overload comment on 3.2 Diameter end-point use cases

 

JJacques,

Thanks for the comment.

I would assume that the Diameter endpoint (server for this discussion) would send either a peer report or a host report.  There would be no reason for the server to send both.

A host report is processed and passed on by agents.

A peer report is consumed by agents and, most likely, a new peer report is generated by the agent.

The peer report is envisioned to be used for multiple reasons.  The first is defined in the agent overload draft to allow agents to communicate overload state.  The second is for overload abatement algorithms that require peer-to-peer semantics.  The first case of this second usage is the rate overload abatement algorithm.

Regards,

Steve

On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi

 

About DA overload (draft-ietf-dime-agent-overload), I have a comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well see the reasons  why a server would send “peer overload” reports in addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA is aware that it is a peer of the server; so the DA can handle the received ovli OLRs from the server as peer OLRs if it wants. So I would limit the draft-ietf-dime-agent-overload only to DA overload  and the associated peer overload report to be generated by DA only .

 

Best regards

 

JJacques 





_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

 




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

 




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------060206050507080204050606-- From nobody Wed Sep 30 13:38:33 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF06A1A8A95 for ; Wed, 30 Sep 2015 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDm0M1WHWqL7 for ; Wed, 30 Sep 2015 13:38:29 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8AB1A8A91 for ; Wed, 30 Sep 2015 13:38:27 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:57456 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZhO8v-003Szv-QG for dime@ietf.org; Wed, 30 Sep 2015 13:38:27 -0700 To: dime@ietf.org References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> From: Steve Donovan Message-ID: <560C4841.2090005@usdonovans.com> Date: Wed, 30 Sep 2015 15:38:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150930202736.3FFF61A8A56@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000004070503000006080302" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:38:30 -0000 This is a multi-part message in MIME format. --------------000004070503000006080302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: > > Hi Steve and all, > > For the first proposal, as I indicated, I support increasing the > number of priority levels up to 16. > > I am also fine with the second proposal. My question is: do we need to > mandate this feature, as individual operators have different > situations? Perhaps some flexibility should be allowed? Instead of > mandating it, we can include the statement that when there is no DRMP > AVP, this correspond to ‘normal traffic’ without a particular high or > low priority. Then each operator can map this default to a value > (e.g., 8 or something else) that they feel appropriate. > > Thanks, > > Jay > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------000004070503000006080302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I'm okay with Jay's proposal on not specifying a default value.

Steve

On 9/30/15 3:27 PM, Lee, Jay wrote:

Hi Steve and all,

 

For the first proposal, as I indicated, I support increasing the number of priority levels up to 16.

 

I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate.

 

Thanks,

 

Jay



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------000004070503000006080302-- From nobody Wed Sep 30 13:39:58 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88871A8AA4 for ; Wed, 30 Sep 2015 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu5pVp9WlS2z for ; Wed, 30 Sep 2015 13:39:54 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60431A8AA5 for ; Wed, 30 Sep 2015 13:39:54 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8UKcnvf002032; Wed, 30 Sep 2015 16:39:53 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 1x8eyf4p71-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2015 16:39:53 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UKdqUw010995; Wed, 30 Sep 2015 16:39:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8UKdlKp010911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2015 16:39:50 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 30 Sep 2015 20:39:31 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.4]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 16:39:31 -0400 From: "DOLLY, MARTIN C" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/9rJF0RiKFeUmgaN+GamRGwp5ViKUw Date: Wed, 30 Sep 2015 20:39:30 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> In-Reply-To: <560C4841.2090005@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.173.37] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615C07483MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-30_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509300251 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:39:56 -0000 --_000_E42CCDDA6722744CB241677169E8365615C07483MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E42CCDDA6722744CB241677169E8365615C07483MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Me as well<= /span>

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=

 

I'm okay with Jay's p= roposal on not specifying a default value.

Steve

On 9/30/15 3:27 PM, Lee, Jay wrote:

Hi Steve and all,

 

For the first proposal, as I indicated, I support in= creasing the number of priority levels up to 16.

 

I am also fine with the second proposal. My question= is: do we need to mandate this feature, as individual operators have diffe= rent situations? Perhaps some flexibility should be allowed? Instead of man= dating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic&#= 8217; without a particular high or low priority. Then each operator can map= this default to a value (e.g., 8 or something else) that they feel appropr= iate.

 

Thanks,

 

Jay




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime

 

--_000_E42CCDDA6722744CB241677169E8365615C07483MISOUT7MSGUSRDB_-- From nobody Wed Sep 30 13:53:57 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1981A8ACD; Wed, 30 Sep 2015 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKWp2MCKNCeR; Wed, 30 Sep 2015 13:53:49 -0700 (PDT) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72291A8ACA; Wed, 30 Sep 2015 13:53:48 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-170.messagelabs.com!1443646363!32186002!1 X-Originating-IP: [20.137.2.180] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24267 invoked from network); 30 Sep 2015 20:52:44 -0000 Received: from amer-mta103.csc.com (HELO amer-mta113.csc.com) (20.137.2.180) by server-9.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2015 20:52:44 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta113.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t8UKqha9022714; Wed, 30 Sep 2015 16:52:43 -0400 In-Reply-To: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> To: "DOLLY, MARTIN C" MIME-Version: 1.0 X-KeepSent: BBCB1153:5AB4B36F-85257ED0:0072958E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 30 Sep 2015 16:52:42 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.3FP5|July 31, 2013) at 09/30/2015 04:52:43 PM, Serialize complete at 09/30/2015 04:52:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0072B04F85257ED0_=" Archived-At: Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 20:53:56 -0000 This is a multipart message in MIME format. --=_alternative 0072B04F85257ED0_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U2FtZSBoZXJlLiAgVGhlICJkZWZhdWx0IHByaW9yaXR5IiBzaG91bGQgYmUgYSBtYXR0ZXIgb2Yg bG9jYWwgcG9saWN5Lg0KDQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgDQpkZWxldGUgd2l0aG91 dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBp biANCmRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNo YWxsIG5vdCBvcGVyYXRlIHRvIA0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRy YWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCANCndyaXR0ZW4gYWdyZWVtZW50IG9yIGdv dmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIA0KZS1t YWlsIGZvciBzdWNoIHB1cnBvc2UuDQoNCg0KDQpGcm9tOiAgICJET0xMWSwgTUFSVElOIEMiIDxt ZDMxMzVAYXR0LmNvbT4NClRvOiAgICAgU3RldmUgRG9ub3ZhbiA8c3Jkb25vdmFuQHVzZG9ub3Zh bnMuY29tPiwgImRpbWVAaWV0Zi5vcmciIA0KPGRpbWVAaWV0Zi5vcmc+DQpEYXRlOiAgIDA5LzMw LzIwMTUgMDQ6NDAgUE0NClN1YmplY3Q6ICAgICAgICBSZTogW0RpbWVdIFtkaW1lXSAjOTIgKGRy bXApOiBSYW5nZSBvZiBwcmlvcml0eSBsZXZlbHMNClNlbnQgYnk6ICAgICAgICAiRGlNRSIgPGRp bWUtYm91bmNlc0BpZXRmLm9yZz4NCg0KDQoNCk1lIGFzIHdlbGwNCiANCkZyb206IERpTUUgW21h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpT ZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAzMCwgMjAxNSA0OjM4IFBNDQpUbzogZGltZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzkyIChkcm1wKTogUmFuZ2Ugb2YgcHJp b3JpdHkgbGV2ZWxzDQogDQpJJ20gb2theSB3aXRoIEpheSdzIHByb3Bvc2FsIG9uIG5vdCBzcGVj aWZ5aW5nIGEgZGVmYXVsdCB2YWx1ZS4NCg0KU3RldmUNCk9uIDkvMzAvMTUgMzoyNyBQTSwgTGVl LCBKYXkgd3JvdGU6DQpIaSBTdGV2ZSBhbmQgYWxsLA0KIA0KRm9yIHRoZSBmaXJzdCBwcm9wb3Nh bCwgYXMgSSBpbmRpY2F0ZWQsIEkgc3VwcG9ydCBpbmNyZWFzaW5nIHRoZSBudW1iZXIgb2YgDQpw cmlvcml0eSBsZXZlbHMgdXAgdG8gMTYuDQogDQpJIGFtIGFsc28gZmluZSB3aXRoIHRoZSBzZWNv bmQgcHJvcG9zYWwuIE15IHF1ZXN0aW9uIGlzOiBkbyB3ZSBuZWVkIHRvIA0KbWFuZGF0ZSB0aGlz IGZlYXR1cmUsIGFzIGluZGl2aWR1YWwgb3BlcmF0b3JzIGhhdmUgZGlmZmVyZW50IHNpdHVhdGlv bnM/IA0KUGVyaGFwcyBzb21lIGZsZXhpYmlsaXR5IHNob3VsZCBiZSBhbGxvd2VkPyBJbnN0ZWFk IG9mIG1hbmRhdGluZyBpdCwgd2UgDQpjYW4gaW5jbHVkZSB0aGUgc3RhdGVtZW50IHRoYXQgd2hl biB0aGVyZSBpcyBubyBEUk1QIEFWUCwgdGhpcyBjb3JyZXNwb25kIA0KdG8g4oCYbm9ybWFsIHRy YWZmaWPigJkgd2l0aG91dCBhIHBhcnRpY3VsYXIgaGlnaCBvciBsb3cgcHJpb3JpdHkuIFRoZW4g ZWFjaCANCm9wZXJhdG9yIGNhbiBtYXAgdGhpcyBkZWZhdWx0IHRvIGEgdmFsdWUgKGUuZy4sIDgg b3Igc29tZXRoaW5nIGVsc2UpIHRoYXQgDQp0aGV5IGZlZWwgYXBwcm9wcmlhdGUuDQogDQpUaGFu a3MsDQogDQpKYXkNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQogX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQo= --=_alternative 0072B04F85257ED0_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNhbWUgaGVyZS4gJm5ic3A7VGhlICZxdW90 O2RlZmF1bHQgcHJpb3JpdHkmcXVvdDsNCnNob3VsZCBiZSBhIG1hdHRlciBvZiBsb2NhbCBwb2xp Y3kuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5l dDxicj4NCjxicj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZQ0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQg a2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCmRlbGl2ZXJ5LiBO T1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRl IHRvDQpiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1 YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4NCmFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRp dmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwNCmZvciBzdWNoIHB1cnBv c2UuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1 ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0RPTExZLCBNQVJUSU4N CkMmcXVvdDsgJmx0O21kMzEzNUBhdHQuY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg Y29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3RldmUgRG9ub3Zh biAmbHQ7c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tJmd0OywNCiZxdW90O2RpbWVAaWV0Zi5vcmcm cXVvdDsgJmx0O2RpbWVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xv cj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA5LzMwLzIwMTUgMDQ6 NDAgUE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtEaW1lXSBbZGltZV0NCiM5MiAoZHJtcCk6IFJh bmdlIG9mIHByaW9yaXR5IGxldmVsczwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtEaU1FJnF1b3Q7 DQombHQ7ZGltZS1ib3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD4NCjxicj4NCjxociBub3NoYWRl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli cmkiPk1lIGFzIHdlbGw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFj ZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij48Yj5Gcm9tOjwvYj4gRGlNRSBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmciPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5tYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnPC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5TdGV2ZSBEb25vdmFuPGI+PGJyPg0KU2VudDo8L2I+IFdlZG5lc2RheSwg U2VwdGVtYmVyIDMwLCAyMDE1IDQ6MzggUE08Yj48YnI+DQpUbzo8L2I+IGRpbWVAaWV0Zi5vcmc8 Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzkyIChkcm1wKTogUmFuZ2Ug b2YgcHJpb3JpdHkgbGV2ZWxzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkknbSBva2F5 IHdpdGggSmF5J3MgcHJvcG9zYWwgb24gbm90IHNwZWNpZnlpbmcNCmEgZGVmYXVsdCB2YWx1ZS48 YnI+DQo8YnI+DQpTdGV2ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ T24gOS8zMC8xNSAzOjI3IFBNLCBMZWUsIEpheSB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPkhpIFN0ZXZlIGFuZCBhbGwsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPkZvciB0aGUgZmlyc3QgcHJvcG9zYWwsIGFzIEkgaW5kaWNhdGVkLA0KSSBzdXBw b3J0IGluY3JlYXNpbmcgdGhlIG51bWJlciBvZiBwcmlvcml0eSBsZXZlbHMgdXAgdG8gMTYuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkkgYW0gYWxzbyBmaW5lIHdpdGggdGhlIHNlY29u ZCBwcm9wb3NhbC4NCk15IHF1ZXN0aW9uIGlzOiBkbyB3ZSBuZWVkIHRvIG1hbmRhdGUgdGhpcyBm ZWF0dXJlLCBhcyBpbmRpdmlkdWFsIG9wZXJhdG9ycw0KaGF2ZSBkaWZmZXJlbnQgc2l0dWF0aW9u cz8gUGVyaGFwcyBzb21lIGZsZXhpYmlsaXR5IHNob3VsZCBiZSBhbGxvd2VkPw0KSW5zdGVhZCBv ZiBtYW5kYXRpbmcgaXQsIHdlIGNhbiBpbmNsdWRlIHRoZSBzdGF0ZW1lbnQgdGhhdCB3aGVuIHRo ZXJlIGlzDQpubyBEUk1QIEFWUCwgdGhpcyBjb3JyZXNwb25kIHRvIOKAmG5vcm1hbCB0cmFmZmlj 4oCZIHdpdGhvdXQgYSBwYXJ0aWN1bGFyDQpoaWdoIG9yIGxvdyBwcmlvcml0eS4gVGhlbiBlYWNo IG9wZXJhdG9yIGNhbiBtYXAgdGhpcyBkZWZhdWx0IHRvIGEgdmFsdWUNCihlLmcuLCA4IG9yIHNv bWV0aGluZyBlbHNlKSB0aGF0IHRoZXkgZmVlbCBhcHByb3ByaWF0ZS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5KYXk8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5EaU1FIG1haWxpbmcgbGlzdDwvZm9udD4NCjxicj48 YSBocmVmPW1haWx0bzpEaU1FQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IkNvdXJpZXIgTmV3Ij48dT5EaU1FQGlldGYub3JnPC91PjwvZm9udD48L2E+DQo8YnI+PGEgaHJl Zj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZTwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRGlNRSBtYWlsaW5n IGxpc3Q8YnI+DQpEaU1FQGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU+PHR0Pjxmb250IHNpemU9Mj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0072B04F85257ED0_=--