From nobody Sat Aug 12 14:08:04 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983631323A6 for ; Thu, 10 Aug 2017 21:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uSHPO92Hz__n for ; Thu, 10 Aug 2017 21:05:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9290A132440 for ; Thu, 10 Aug 2017 21:05:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E8570B81789; Thu, 10 Aug 2017 21:04:56 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: priyatos@cdot.in, dime@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170811040456.E8570B81789@rfc-editor.org> Date: Thu, 10 Aug 2017 21:04:56 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 12 Aug 2017 14:08:03 -0700 Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 04:05:14 -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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum value it can have is 4294967295. If the system restarts many times and the value of Origin-State-Id reaches the value which is same as its maximum value 4294967295. Then what will happen for the next restart. At the next restart the value of Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart its value will be 0. For a special case for transition of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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 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 Sun Aug 13 21:57:09 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61E12420B for ; Sun, 13 Aug 2017 21:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_SPF_HELO_TEMPERROR=0.01] autolearn=no autolearn_force=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 E8qPj5Aw-C_j for ; Sun, 13 Aug 2017 21:17:46 -0700 (PDT) Received: from sandesh.cdotd.ernet.in (unknown [196.1.105.47]) by ietfa.amsl.com (Postfix) with SMTP id 663DB1241F5 for ; Sun, 13 Aug 2017 21:17:42 -0700 (PDT) Received: from mail.cdot.in (webmail.cdotd.ernet.in [196.1.105.198]) by sandesh.cdotd.ernet.in (Postfix) with ESMTP id 48C7F1DDE2F2; Mon, 14 Aug 2017 09:46:42 +0530 (IST) Received: from cdot.in (localhost [127.0.0.1]) by mail.cdot.in (8.14.7/8.13.8) with ESMTP id v7E4GdLl082393; Mon, 14 Aug 2017 09:46:39 +0530 From: "Priyatosh Mandal" To: RFC Errata System , vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com Cc: dime@ietf.org Date: Mon, 14 Aug 2017 09:46:39 +0530 Message-Id: <20170814041602.M44812@cdot.in> In-Reply-To: <20170811040456.E8570B81789@rfc-editor.org> References: <20170811040456.E8570B81789@rfc-editor.org> X-Mailer: OpenWebMail 2.54 X-OriginatingIP: 196.1.110.232 (priyatos) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.341611924206035" Archived-At: X-Mailman-Approved-At: Sun, 13 Aug 2017 21:57:04 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 04:17:50 -0000 This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.341611924206035 Content-Type: text/plain; charset=utf-8 Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device  clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum value it can have is 4294967295. If the system restarts many times and the value of Origin-State-Id reaches the value which is same as its maximum value 4294967295. Then what will happen for the next restart. At the next restart the value of Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart its value will be 0. For a special case for transition of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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   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 Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the  opinions ------=OPENWEBMAIL_ATT_0.341611924206035 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Err= ata System wrote
The=20 following errata report has been submitted for RFC6733,=20
=20 "Diameter Base Protocol".=20
=20
=20 --------------------------------------=20
=20 You may review the report below and at:=20
=20 http= ://www.rfc-editor.org/errata/eid5084=20
=20
=20 --------------------------------------=20
=20 Type: Technical=20
=20 Reported by: Priyatosh Mandal <priyatos@cdot.in>=20
=20
=20 Section: 8.16=20
=20
=20 Original Text=20
=20 -------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20= =20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20=20
=20 MUST either not include Origin-State-Id in any message or set its value=20= =20
=20 to 0.=20
=20
=20 Corrected Text=20
=20 --------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20= =20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20=20
=20 MUST either not include Origin-State-Id in any message or set its value=20= =20
=20 to 0.=20=20
=20 As a special case when the value of Origin-State-Id changes from=20=20
=20 4294967295 to 0, then also the access device =C2=A0clear all the sessions.= =20
=20
=20 Notes=20
=20 -----=20
=20 Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the= =20 maximum=20=20
=20 value it can have is 4294967295. If the system restarts many times and the = value=20 of=20
=20 Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.=20 =20
=20 Then what will happen for the next restart. At the next restart the value o= f=20 Origin-State-Id=20=20
=20 will be 0 if we try to increase the value of Origin-State-Id.=20
=20 It is not defined in the RFC 6733, that how the system should behave after= =20 4294967295-th=20=20
=20 restart with respect to Origin-State-Id.=20
=20
=20 Generally when the peer receives an increased value of Origin-State-Id, the= n it=20 clear all sessions.=20
=20 If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after=20 another restart=20=20
=20 its value will be 0. For a special case for transition of value of=20 Origin-State-Id from=20=20
=20 4294967295 to 0, the peer should clear its session.=20
=20
=20 Instructions:=20
=20 -------------=20
=20 This erratum is currently posted as "Reported". If necessary, ple= ase=20
=20 use "Reply All" to discuss whether it should be verified or=20
=20 rejected. When a decision is reached, the verifying party =C2=A0=20
=20 can log in to change the status and edit the report, if necessary.=20=20
=20
=20 --------------------------------------=20
=20 RFC6733 (draft-ietf-dime-rfc3588bis-33)=20
=20 --------------------------------------=20
=20 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Diameter Base Prot= ocol=20
=20 Publication Date =C2=A0 =C2=A0: October 2012=20
=20 Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : V. Fajardo, Ed., J. Arkko, J= .=20 Loughney, G. Zorn, Ed.=20
=20 Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: PROPOSED STANDARD=20
=20 Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Maintenan= ce=20 and Extensions=20
=20 Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Operations an= d=20 Management=20
=20 Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF=20
=20 Verifying Party =C2=A0 =C2=A0 : IESG=20


Priyatosh=20
Ext: 8517=20
Mob: 9810480266=20
---------------------------------------------------------------------------= -----=20
::Disclaimer::=20=20
---------------------------------------------------------------------------= -----=20 =20
The contents of this email and any attachment(s) are confidential and inten= ded=20
for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20=20
Any views or opinions presented in this email are solely those of the autho= r=20=20
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 opinions
------=OPENWEBMAIL_ATT_0.341611924206035-- From nobody Mon Aug 14 05:54:40 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D065D132125 for ; Mon, 14 Aug 2017 02:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wL1dULZwQ1QQ for ; Mon, 14 Aug 2017 02:40:17 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51DA1320D9 for ; Mon, 14 Aug 2017 02:40:16 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 Aug 2017 05:40:15 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 14 Aug 2017 05:40:14 -0400 From: Yuval Lifshitz To: Priyatosh Mandal , RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "warren@kumari.net" , "jouni.nospam@gmail.com" , "lionel.morand@orange.com" CC: "dime@ietf.org" , Yuval Lifshitz Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTE68Zz05SCldUd0iJEvC11dVdbKKDg/CAgAAWA2A= Date: Mon, 14 Aug 2017 09:40:13 +0000 Message-ID: References: <20170811040456.E8570B81789@rfc-editor.org> <20170814041602.M44812@cdot.in> In-Reply-To: <20170814041602.M44812@cdot.in> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AC9B54wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 14 Aug 2017 05:54:38 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 09:40:20 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49A8AC9B54wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHJpeWF0b3NoLA0KVGhpbmsgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiBtYXkgYmUgbW9yZSBj b3JyZWN0Og0K4oCmDQpBcyBhIHNwZWNpYWwgY2FzZSB3aGVuIHRoZSB2YWx1ZSBvZiBPcmlnaW4t U3RhdGUtSWQgY2hhbmdlcyBmcm9tDQo0Mjk0OTY3Mjk1IHRvIDAsIG90aGVyIERpYW1ldGVyIGVu dGl0aWVzIE1BWSBpbmZlciB0aGF0IGFsbCBzZXNzaW9ucyB3ZXJlIGNsZWFyZWQuDQoNCkJlc3Qg UmVnYXJkcywNCg0KWXV2YWwNCg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUHJpeWF0b3NoIE1hbmRhbA0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMTQsIDIwMTcgNzoxNyBBTQ0KVG86IFJGQyBFcnJhdGEgU3lzdGVtOyB2ZjAyMTNAZ21haWwu Y29tOyBqYXJpLmFya2tvQGVyaWNzc29uLmNvbTsgam9obi5sb3VnaG5leUBub2tpYS5jb207IGds ZW56b3JuQGdtYWlsLmNvbTsgYmNsYWlzZUBjaXNjby5jb207IHdhcnJlbkBrdW1hcmkubmV0OyBq b3VuaS5ub3NwYW1AZ21haWwuY29tOyBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20NCkNjOiBkaW1l QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVk XSBSRkM2NzMzICg1MDg0KQ0KDQpEZWFyIEFsbCwNCktpbmRseSB2ZXJpZnkgdGhpcy4NCg0KUmVn YXJkcywNClByaXlhdG9zaCBNYW5kYWwNCg0KT24gVGh1LCAxMCBBdWcgMjAxNyAyMTowNDo1NiAt MDcwMCAoUERUKSwgUkZDIEVycmF0YSBTeXN0ZW0gd3JvdGUNClRoZSBmb2xsb3dpbmcgZXJyYXRh IHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzY3MzMsDQoiRGlhbWV0ZXIgQmFzZSBQ cm90b2NvbCIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3Ug bWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvZXJyYXRhL2VpZDUwODQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClR5cGU6IFRlY2huaWNhbA0KUmVwb3J0ZWQgYnk6IFByaXlhdG9zaCBNYW5kYWwgPHBy aXlhdG9zQGNkb3QuaW48bWFpbHRvOnByaXlhdG9zQGNkb3QuaW4+Pg0KDQpTZWN0aW9uOiA4LjE2 DQoNCk9yaWdpbmFsIFRleHQNCi0tLS0tLS0tLS0tLS0NCkJ5IGluY2x1ZGluZyBPcmlnaW4tU3Rh dGUtSWQgaW4gYSBtZXNzYWdlLCBpdCBhbGxvd3Mgb3RoZXIgRGlhbWV0ZXINCmVudGl0aWVzIHRv IGluZmVyIHRoYXQgc2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIGEgbG93ZXIgT3JpZ2luLVN0YXRl LUlkDQphcmUgbm8gbG9uZ2VyIGFjdGl2ZS4NCklmIGFuIGFjY2VzcyBkZXZpY2UgZG9lcyBub3Qg aW50ZW5kIGZvciBzdWNoIGluZmVyZW5jZXMgdG8gYmUgbWFkZSwgaXQNCk1VU1QgZWl0aGVyIG5v dCBpbmNsdWRlIE9yaWdpbi1TdGF0ZS1JZCBpbiBhbnkgbWVzc2FnZSBvciBzZXQgaXRzIHZhbHVl DQp0byAwLg0KDQpDb3JyZWN0ZWQgVGV4dA0KLS0tLS0tLS0tLS0tLS0NCkJ5IGluY2x1ZGluZyBP cmlnaW4tU3RhdGUtSWQgaW4gYSBtZXNzYWdlLCBpdCBhbGxvd3Mgb3RoZXIgRGlhbWV0ZXINCmVu dGl0aWVzIHRvIGluZmVyIHRoYXQgc2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIGEgbG93ZXIgT3Jp Z2luLVN0YXRlLUlkDQphcmUgbm8gbG9uZ2VyIGFjdGl2ZS4NCklmIGFuIGFjY2VzcyBkZXZpY2Ug ZG9lcyBub3QgaW50ZW5kIGZvciBzdWNoIGluZmVyZW5jZXMgdG8gYmUgbWFkZSwgaXQNCk1VU1Qg ZWl0aGVyIG5vdCBpbmNsdWRlIE9yaWdpbi1TdGF0ZS1JZCBpbiBhbnkgbWVzc2FnZSBvciBzZXQg aXRzIHZhbHVlDQp0byAwLg0KQXMgYSBzcGVjaWFsIGNhc2Ugd2hlbiB0aGUgdmFsdWUgb2YgT3Jp Z2luLVN0YXRlLUlkIGNoYW5nZXMgZnJvbQ0KNDI5NDk2NzI5NSB0byAwLCB0aGVuIGFsc28gdGhl IGFjY2VzcyBkZXZpY2UgIGNsZWFyIGFsbCB0aGUgc2Vzc2lvbnMuDQoNCk5vdGVzDQotLS0tLQ0K T3JpZ2luLVN0YXRlLUlkIGlzIGRlZmluZWQgYXMgVW5zaWduZWQzMiBpbiBSRkMgNjczMywgU2Vj dGlvbiA4LjE2LiBTbyB0aGUgbWF4aW11bQ0KdmFsdWUgaXQgY2FuIGhhdmUgaXMgNDI5NDk2NzI5 NS4gSWYgdGhlIHN5c3RlbSByZXN0YXJ0cyBtYW55IHRpbWVzIGFuZCB0aGUgdmFsdWUgb2YNCk9y aWdpbi1TdGF0ZS1JZCByZWFjaGVzIHRoZSB2YWx1ZSB3aGljaCBpcyBzYW1lIGFzIGl0cyBtYXhp bXVtIHZhbHVlIDQyOTQ5NjcyOTUuDQpUaGVuIHdoYXQgd2lsbCBoYXBwZW4gZm9yIHRoZSBuZXh0 IHJlc3RhcnQuIEF0IHRoZSBuZXh0IHJlc3RhcnQgdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1J ZA0Kd2lsbCBiZSAwIGlmIHdlIHRyeSB0byBpbmNyZWFzZSB0aGUgdmFsdWUgb2YgT3JpZ2luLVN0 YXRlLUlkLg0KSXQgaXMgbm90IGRlZmluZWQgaW4gdGhlIFJGQyA2NzMzLCB0aGF0IGhvdyB0aGUg c3lzdGVtIHNob3VsZCBiZWhhdmUgYWZ0ZXIgNDI5NDk2NzI5NS10aA0KcmVzdGFydCB3aXRoIHJl c3BlY3QgdG8gT3JpZ2luLVN0YXRlLUlkLg0KDQpHZW5lcmFsbHkgd2hlbiB0aGUgcGVlciByZWNl aXZlcyBhbiBpbmNyZWFzZWQgdmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkLCB0aGVuIGl0IGNsZWFy IGFsbCBzZXNzaW9ucy4NCklmIHRoZSB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQgcmVhY2hlcyBp dHMgbWF4aW11bSBpLmUuLCA0Mjk0OTY3Mjk1LCB0aGVuIGFmdGVyIGFub3RoZXIgcmVzdGFydA0K aXRzIHZhbHVlIHdpbGwgYmUgMC4gRm9yIGEgc3BlY2lhbCBjYXNlIGZvciB0cmFuc2l0aW9uIG9m IHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZCBmcm9tDQo0Mjk0OTY3Mjk1IHRvIDAsIHRoZSBwZWVy IHNob3VsZCBjbGVhciBpdHMgc2Vzc2lvbi4NCg0KSW5zdHJ1Y3Rpb25zOg0KLS0tLS0tLS0tLS0t LQ0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVj ZXNzYXJ5LCBwbGVhc2UNCnVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hv dWxkIGJlIHZlcmlmaWVkIG9yDQpyZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQs IHRoZSB2ZXJpZnlpbmcgcGFydHkNCmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5k IGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KUkZDNjczMyAoZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMzMp DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGUgICAgICAgICAg ICAgICA6IERpYW1ldGVyIEJhc2UgUHJvdG9jb2wNClB1YmxpY2F0aW9uIERhdGUgICAgOiBPY3Rv YmVyIDIwMTINCkF1dGhvcihzKSAgICAgICAgICAgOiBWLiBGYWphcmRvLCBFZC4sIEouIEFya2tv LCBKLiBMb3VnaG5leSwgRy4gWm9ybiwgRWQuDQpDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9T RUQgU1RBTkRBUkQNClNvdXJjZSAgICAgICAgICAgICAgOiBEaWFtZXRlciBNYWludGVuYW5jZSBh bmQgRXh0ZW5zaW9ucw0KQXJlYSAgICAgICAgICAgICAgICA6IE9wZXJhdGlvbnMgYW5kIE1hbmFn ZW1lbnQNClN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQpWZXJpZnlpbmcgUGFydHkgICAgIDog SUVTRw0KDQoNClByaXlhdG9zaA0KRXh0OiA4NTE3DQpNb2I6IDk4MTA0ODAyNjYNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo6OkRpc2NsYWltZXI6Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudChzKSBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0KZm9yIHRoZSBuYW1lZCByZWNpcGllbnQocykgb25seS4g SXQgc2hhbGwgbm90IGF0dGFjaCBhbnkgbGlhYmlsaXR5IG9uIEMtRE9ULg0KQW55IHZpZXdzIG9y IG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIGVtYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhl IGF1dGhvcg0KYW5kICBtYXkgIG5vdCAgbmVjZXNzYXJpbHkgIHJlZmxlY3QgIHRoZSAgIG9waW5p b25zDQo= --_000_C43C255C7106314F8D13D03FA20CFE49A8AC9B54wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFByaXlhdG9zaCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpbmsgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiBt YXkgYmUgbW9yZSBjb3JyZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igKY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+QXMgYSBzcGVjaWFsIGNhc2Ugd2hlbiB0aGUgdmFsdWUgb2YgT3JpZ2lu LVN0YXRlLUlkIGNoYW5nZXMgZnJvbQ0KPGJyPg0KNDI5NDk2NzI5NSB0byAwLCBvdGhlciBEaWFt ZXRlciBlbnRpdGllcyBNQVkgaW5mZXIgdGhhdCBhbGwgc2Vzc2lvbnMgd2VyZSBjbGVhcmVkLg0K PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WXV2YWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+UHJpeWF0b3NoIE1hbmRhbDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3Vz dCAxNCwgMjAxNyA3OjE3IEFNPGJyPg0KPGI+VG86PC9iPiBSRkMgRXJyYXRhIFN5c3RlbTsgdmYw MjEzQGdtYWlsLmNvbTsgamFyaS5hcmtrb0Blcmljc3Nvbi5jb207IGpvaG4ubG91Z2huZXlAbm9r aWEuY29tOyBnbGVuem9ybkBnbWFpbC5jb207IGJjbGFpc2VAY2lzY28uY29tOyB3YXJyZW5Aa3Vt YXJpLm5ldDsgam91bmkubm9zcGFtQGdtYWlsLmNvbTsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t PGJyPg0KPGI+Q2M6PC9iPiBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb RGltZV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY3MzMgKDUwODQpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBBbGwsIDxicj4NCktp bmRseSB2ZXJpZnkgdGhpcy4gPGJyPg0KPGJyPg0KUmVnYXJkcywgPGJyPg0KUHJpeWF0b3NoIE1h bmRhbCA8YnI+DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gVGh1 LCAxMCBBdWcgMjAxNyAyMTowNDo1NiAtMDcwMCAoUERUKSwgUkZDIEVycmF0YSBTeXN0ZW0gd3Jv dGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjxicj4NClRoZSBm b2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzY3MzMsIDxi cj4NCiZxdW90O0RpYW1ldGVyIEJhc2UgUHJvdG9jb2wmcXVvdDsuIDxicj4NCjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NCllvdSBtYXkgcmV2aWV3IHRo ZSByZXBvcnQgYmVsb3cgYW5kIGF0OiA8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2VycmF0YS9laWQ1MDg0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5yZmMtZWRp dG9yLm9yZy9lcnJhdGEvZWlkNTA4NDwvYT4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClR5cGU6IFRlY2huaWNhbCA8YnI+DQpSZXBvcnRl ZCBieTogUHJpeWF0b3NoIE1hbmRhbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByaXlhdG9zQGNkb3Qu aW4iPnByaXlhdG9zQGNkb3QuaW48L2E+Jmd0Ow0KPGJyPg0KPGJyPg0KU2VjdGlvbjogOC4xNiA8 YnI+DQo8YnI+DQpPcmlnaW5hbCBUZXh0IDxicj4NCi0tLS0tLS0tLS0tLS0gPGJyPg0KQnkgaW5j bHVkaW5nIE9yaWdpbi1TdGF0ZS1JZCBpbiBhIG1lc3NhZ2UsIGl0IGFsbG93cyBvdGhlciBEaWFt ZXRlciA8YnI+DQplbnRpdGllcyB0byBpbmZlciB0aGF0IHNlc3Npb25zIGFzc29jaWF0ZWQgd2l0 aCBhIGxvd2VyIE9yaWdpbi1TdGF0ZS1JZCA8YnI+DQphcmUgbm8gbG9uZ2VyIGFjdGl2ZS4gPGJy Pg0KSWYgYW4gYWNjZXNzIGRldmljZSBkb2VzIG5vdCBpbnRlbmQgZm9yIHN1Y2ggaW5mZXJlbmNl cyB0byBiZSBtYWRlLCBpdCA8YnI+DQpNVVNUIGVpdGhlciBub3QgaW5jbHVkZSBPcmlnaW4tU3Rh dGUtSWQgaW4gYW55IG1lc3NhZ2Ugb3Igc2V0IGl0cyB2YWx1ZSA8YnI+DQp0byAwLiA8YnI+DQo8 YnI+DQpDb3JyZWN0ZWQgVGV4dCA8YnI+DQotLS0tLS0tLS0tLS0tLSA8YnI+DQpCeSBpbmNsdWRp bmcgT3JpZ2luLVN0YXRlLUlkIGluIGEgbWVzc2FnZSwgaXQgYWxsb3dzIG90aGVyIERpYW1ldGVy IDxicj4NCmVudGl0aWVzIHRvIGluZmVyIHRoYXQgc2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIGEg bG93ZXIgT3JpZ2luLVN0YXRlLUlkIDxicj4NCmFyZSBubyBsb25nZXIgYWN0aXZlLiA8YnI+DQpJ ZiBhbiBhY2Nlc3MgZGV2aWNlIGRvZXMgbm90IGludGVuZCBmb3Igc3VjaCBpbmZlcmVuY2VzIHRv IGJlIG1hZGUsIGl0IDxicj4NCk1VU1QgZWl0aGVyIG5vdCBpbmNsdWRlIE9yaWdpbi1TdGF0ZS1J ZCBpbiBhbnkgbWVzc2FnZSBvciBzZXQgaXRzIHZhbHVlIDxicj4NCnRvIDAuIDxicj4NCkFzIGEg c3BlY2lhbCBjYXNlIHdoZW4gdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZCBjaGFuZ2VzIGZy b20gPGJyPg0KNDI5NDk2NzI5NSB0byAwLCB0aGVuIGFsc28gdGhlIGFjY2VzcyBkZXZpY2UgJm5i c3A7Y2xlYXIgYWxsIHRoZSBzZXNzaW9ucy4gPGJyPg0KPGJyPg0KTm90ZXMgPGJyPg0KLS0tLS0g PGJyPg0KT3JpZ2luLVN0YXRlLUlkIGlzIGRlZmluZWQgYXMgVW5zaWduZWQzMiBpbiBSRkMgNjcz MywgU2VjdGlvbiA4LjE2LiBTbyB0aGUgbWF4aW11bQ0KPGJyPg0KdmFsdWUgaXQgY2FuIGhhdmUg aXMgNDI5NDk2NzI5NS4gSWYgdGhlIHN5c3RlbSByZXN0YXJ0cyBtYW55IHRpbWVzIGFuZCB0aGUg dmFsdWUgb2YNCjxicj4NCk9yaWdpbi1TdGF0ZS1JZCByZWFjaGVzIHRoZSB2YWx1ZSB3aGljaCBp cyBzYW1lIGFzIGl0cyBtYXhpbXVtIHZhbHVlIDQyOTQ5NjcyOTUuIDxicj4NClRoZW4gd2hhdCB3 aWxsIGhhcHBlbiBmb3IgdGhlIG5leHQgcmVzdGFydC4gQXQgdGhlIG5leHQgcmVzdGFydCB0aGUg dmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkDQo8YnI+DQp3aWxsIGJlIDAgaWYgd2UgdHJ5IHRvIGlu Y3JlYXNlIHRoZSB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQuIDxicj4NCkl0IGlzIG5vdCBkZWZp bmVkIGluIHRoZSBSRkMgNjczMywgdGhhdCBob3cgdGhlIHN5c3RlbSBzaG91bGQgYmVoYXZlIGFm dGVyIDQyOTQ5NjcyOTUtdGgNCjxicj4NCnJlc3RhcnQgd2l0aCByZXNwZWN0IHRvIE9yaWdpbi1T dGF0ZS1JZC4gPGJyPg0KPGJyPg0KR2VuZXJhbGx5IHdoZW4gdGhlIHBlZXIgcmVjZWl2ZXMgYW4g aW5jcmVhc2VkIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZCwgdGhlbiBpdCBjbGVhciBhbGwgc2Vz c2lvbnMuDQo8YnI+DQpJZiB0aGUgdmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkIHJlYWNoZXMgaXRz IG1heGltdW0gaS5lLiwgNDI5NDk2NzI5NSwgdGhlbiBhZnRlciBhbm90aGVyIHJlc3RhcnQNCjxi cj4NCml0cyB2YWx1ZSB3aWxsIGJlIDAuIEZvciBhIHNwZWNpYWwgY2FzZSBmb3IgdHJhbnNpdGlv biBvZiB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQgZnJvbQ0KPGJyPg0KNDI5NDk2NzI5NSB0byAw LCB0aGUgcGVlciBzaG91bGQgY2xlYXIgaXRzIHNlc3Npb24uIDxicj4NCjxicj4NCkluc3RydWN0 aW9uczogPGJyPg0KLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5 IHBvc3RlZCBhcyAmcXVvdDtSZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UgPGJy Pg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxk IGJlIHZlcmlmaWVkIG9yIDxicj4NCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hl ZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAmbmJzcDsgPGJyPg0KY2FuIGxvZyBpbiB0byBjaGFuZ2Ug dGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuIDxicj4NCjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClJGQzY3MzMgKGRy YWZ0LWlldGYtZGltZS1yZmMzNTg4YmlzLTMzKSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBEaWFtZXRlciBCYXNlIFByb3RvY29sIDxicj4NClB1Ymxp Y2F0aW9uIERhdGUgJm5ic3A7ICZuYnNwOzogT2N0b2JlciAyMDEyIDxicj4NCkF1dGhvcihzKSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogVi4gRmFqYXJkbywgRWQuLCBKLiBB cmtrbywgSi4gTG91Z2huZXksIEcuIFpvcm4sIEVkLiA8YnI+DQpDYXRlZ29yeSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogUFJPUE9TRUQgU1RBTkRBUkQgPGJyPg0K U291cmNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzog RGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgPGJyPg0KQXJlYSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBPcGVyYXRpb25z IGFuZCBNYW5hZ2VtZW50IDxicj4NClN0cmVhbSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IElFVEYgPGJyPg0KVmVyaWZ5aW5nIFBhcnR5ICZuYnNwOyAm bmJzcDsgOiBJRVNHIDxicj4NCjxicj4NCjxicj4NClByaXlhdG9zaCA8YnI+DQpFeHQ6IDg1MTcg PGJyPg0KTW9iOiA5ODEwNDgwMjY2IDxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4N Cjo6RGlzY2xhaW1lcjo6IDxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudChzKSBhcmUgY29uZmlkZW50 aWFsIGFuZCBpbnRlbmRlZCA8YnI+DQpmb3IgdGhlIG5hbWVkIHJlY2lwaWVudChzKSBvbmx5LiBJ dCBzaGFsbCBub3QgYXR0YWNoIGFueSBsaWFiaWxpdHkgb24gQy1ET1QuIDxicj4NCkFueSB2aWV3 cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBlbWFpbCBhcmUgc29sZWx5IHRob3NlIG9m IHRoZSBhdXRob3IgPGJyPg0KYW5kICZuYnNwO21heSAmbmJzcDtub3QgJm5ic3A7bmVjZXNzYXJp bHkgJm5ic3A7cmVmbGVjdCAmbmJzcDt0aGUgJm5ic3A7IG9waW5pb25zIDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C43C255C7106314F8D13D03FA20CFE49A8AC9B54wtlexchp2sandvi_-- From nobody Mon Aug 14 05:54:47 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DA2132196 for ; Mon, 14 Aug 2017 03:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B1fl0AsxNFf9 for ; Mon, 14 Aug 2017 03:51:29 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CD7132192 for ; Mon, 14 Aug 2017 03:51:29 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Mon, 14 Aug 2017 06:51:26 -0400 From: Dave Dolson To: Priyatosh Mandal , RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "warren@kumari.net" , "jouni.nospam@gmail.com" , "lionel.morand@orange.com" CC: "dime@ietf.org" Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTE68YeM6TpIqW/EGeAHwz10SRjKKDg/CAgAArP98= Date: Mon, 14 Aug 2017 10:51:25 +0000 Message-ID: <20170814105124.5115986.90299.28199@sandvine.com> References: <20170811040456.E8570B81789@rfc-editor.org>, <20170814041602.M44812@cdot.in> In-Reply-To: <20170814041602.M44812@cdot.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_2017081410512451159869029928199sandvinecom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 14 Aug 2017 05:54:38 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 10:51:32 -0000 --_000_2017081410512451159869029928199sandvinecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my opinion, the change should not be accepted. In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.com; john.loug= hney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; j= ouni.nospam@gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times and the = value of Origin-State-Id reaches the value which is same as its maximum value 429496= 7295. Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transition of value of Origin-S= tate-Id from 4294967295 to 0, the peer should clear its session. 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 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 Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C-DOT= . Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions --_000_2017081410512451159869029928199sandvinecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David Dolson
Sandvine
From: Priyatosh Mandal
Sent: Monday, August 14, 2017 12:57 AM
To: RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.co= m; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@k= umari.net; jouni.nospam@gmail.com; lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)<= /div>

Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata Sy= stem wrote
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/eid5084

--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal <priyatos@cdot.in>

Section: 8.16

Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.

Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.
As a special case when the value of Origin-State-Id changes from
4294967295 to 0, then also the access device  clear all the sessions. =

Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum
value it can have is 4294967295. If the system restarts many times and the = value of
Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.
Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th
restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart
its value will be 0. For a special case for transition of value of Origin-S= tate-Id from
4294967295 to 0, the peer should clear its session.

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

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


Priyatosh
Ext: 8517
Mob: 9810480266
---------------------------------------------------------------------------= -----
::Disclaimer::
---------------------------------------------------------------------------= -----
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and  may  not  necessarily  reflect  the   op= inions
--_000_2017081410512451159869029928199sandvinecom_-- From nobody Mon Aug 14 05:54:56 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031813219E for ; Mon, 14 Aug 2017 04:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_SPF_HELO_TEMPERROR=0.01] autolearn=no autolearn_force=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 bHlaIUwF2vHb for ; Mon, 14 Aug 2017 04:19:36 -0700 (PDT) Received: from sandesh.cdotd.ernet.in (unknown [196.1.105.47]) by ietfa.amsl.com (Postfix) with SMTP id 9872C1320D8 for ; Mon, 14 Aug 2017 04:19:32 -0700 (PDT) Received: from mail.cdot.in (webmail.cdotd.ernet.in [196.1.105.198]) by sandesh.cdotd.ernet.in (Postfix) with ESMTP id 8EEB11DDE4A8; Mon, 14 Aug 2017 16:48:36 +0530 (IST) Received: from cdot.in (localhost [127.0.0.1]) by mail.cdot.in (8.14.7/8.13.8) with ESMTP id v7EBIY0m022914; Mon, 14 Aug 2017 16:48:34 +0530 From: "Priyatosh Mandal" To: Dave Dolson , RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "warren@kumari.net" , "jouni.nospam@gmail.com" , "lionel.morand@orange.com" Cc: "dime@ietf.org" Date: Mon, 14 Aug 2017 16:48:34 +0530 Message-Id: <20170814110558.M60858@cdot.in> In-Reply-To: <20170814105124.5115986.90299.28199@sandvine.com> References: <20170811040456.E8570B81789@rfc-editor.org>, <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> X-Mailer: OpenWebMail 2.54 X-OriginatingIP: 196.1.110.232 (priyatos) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.0881798638469888" Archived-At: X-Mailman-Approved-At: Mon, 14 Aug 2017 05:54:38 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 11:19:41 -0000 This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.0881798638469888 Content-Type: text/plain; charset=utf-8 Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-State-Id. If after this, the value of Origin-State-Id is increased, it will automatically become 0. So the peer node which receives the value 0 after 4294967295, can assume the node which sent this 0, faced a restart. Here the peer-node  is already aware that the previous value of origin-state-id was 4294967295. So it can easily conclude node restart. I understand  the meaning of 0 as explained in RFC 6733 :"If an access device does not intend for such inferences to be made, it MUSTeither not include Origin-State-Id in any message or set its value to 0". But this is a special case, where the value of Origin-State-Id changes from 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the change should not be accepted.  In your roll-over special case, the device should skip over the value 0, using 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device  clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum value it can have is 4294967295. If the system restarts many times and the value of Origin-State-Id reaches the value which is same as its maximum value 4294967295. Then what will happen for the next restart. At the next restart the value of Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart its value will be 0. For a special case for transition of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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   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 Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the   opinions Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the  opinions ------=OPENWEBMAIL_ATT_0.0881798638469888 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Sir,
The situation is a transition from the maximum value 4294967295 of Or= igin-State-Id. If after this, the value of Origin-State-Id is increased, it= will automatically become 0. So the peer node which receives the value 0 a= fter 4294967295, can assume the node which sent this 0,
faced a restart. Here the peer-node=C2=A0 is already aware that the p= revious value of origin-state-id was 4294967295. So it can easily conclude = node restart.

I understand=C2=A0 the meaning of 0 as explained in RFC 6733 :"I= f an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0&quo= t;. 
But this is a special case, where the value of Origi=
n-State-Id changes from  4294967295 to 0.



So kindly reconsider this.

Thanking you,
Priyatosh=20




On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson=20 wrote
In my opinion, the change should not be accepted.=C2=A0
=20 In your roll-over special case, the device should skip over the value 0, us= ing 1=20 or some other value instead of=20 zero.
=20
=20 David=C2=A0Dolson
=20 Sandvine

=20
From: Priyatosh=20 Mandal
Sent: Monday, August 14, 2017 12:57=20 AM
To: RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.= com;=20 john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com;=20 warren@kumari.net; jouni.nospam@gmail.com;=20 lionel.morand@orange.com
Cc:=20 dime@ietf.org
Subject: Re: [Dime] [Technical Errata Reported] RFC6733=20 (5084)

=20
Dear All,=20
=20 Kindly verify this.=20
=20
=20 Regards,=20
=20 Priyatosh Mandal=20
=20
=20 On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata Sy= stem=20 wrote
=20 The following errata report has been submitted for RFC6733,=20
=20 "Diameter Base Protocol".=20
=20
=20 --------------------------------------=20
=20 You may review the report below and at:=20
=20 http= ://www.rfc-editor.org/errata/eid5084
=20
=20 --------------------------------------=20
=20 Type: Technical=20
=20 Reported by: Priyatosh Mandal <priyatos@cdot.in>=20
=20
=20 Section: 8.16=20
=20
=20 Original Text=20
=20 -------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20
=20 MUST either not include Origin-State-Id in any message or set its value=20
=20 to 0.=20
=20
=20 Corrected Text=20
=20 --------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20
=20 MUST either not include Origin-State-Id in any message or set its value=20
=20 to 0.=20
=20 As a special case when the value of Origin-State-Id changes from=20
=20 4294967295 to 0, then also the access device =C2=A0clear all the sessions.= =20
=20
=20 Notes=20
=20 -----=20
=20 Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the= =20 maximum
=20 value it can have is 4294967295. If the system restarts many times and the = value=20 of
=20 Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.=20
=20 Then what will happen for the next restart. At the next restart the value o= f=20 Origin-State-Id
=20 will be 0 if we try to increase the value of Origin-State-Id.=20
=20 It is not defined in the RFC 6733, that how the system should behave after= =20 4294967295-th
=20 restart with respect to Origin-State-Id.=20
=20
=20 Generally when the peer receives an increased value of Origin-State-Id, the= n it=20 clear all=20 sessions.
=20 If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after=20 another=20 restart
=20 its value will be 0. For a special case for transition of value of=20 Origin-State-Id=20 from
=20 4294967295 to 0, the peer should clear its session.=20
=20
=20 Instructions:=20
=20 -------------=20
=20 This erratum is currently posted as "Reported". If necessary, ple= ase=20
=20 use "Reply All" to discuss whether it should be verified or=20
=20 rejected. When a decision is reached, the verifying party =C2=A0=20
=20 can log in to change the status and edit the report, if necessary.=20
=20
=20 --------------------------------------=20
=20 RFC6733 (draft-ietf-dime-rfc3588bis-33)=20
=20 --------------------------------------=20
=20 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Diameter Base Prot= ocol=20
=20 Publication Date =C2=A0 =C2=A0: October 2012=20
=20 Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : V. Fajardo, Ed., J. Arkko, J= .=20 Loughney, G. Zorn, Ed.=20
=20 Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: PROPOSED STANDARD=20
=20 Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Maintenan= ce=20 and Extensions=20
=20 Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Operations an= d=20 Management=20
=20 Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF=20
=20 Verifying Party =C2=A0 =C2=A0 : IESG=20
=20
=20 Priyatosh=20
=20 Ext: 8517=20
=20 Mob: 9810480266=20
=20 ---------------------------------------------------------------------------= -----=20
=20 ::Disclaimer::=20
=20 ---------------------------------------------------------------------------= -----=20
=20 The contents of this email and any attachment(s) are confidential and inten= ded=20
=20 for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20
=20 Any views or opinions presented in this email are solely those of the autho= r=20
=20 and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0=20 opinions=20
=20


Priyatosh=20
Ext: 8517=20
Mob: 9810480266=20
---------------------------------------------------------------------------= -----=20
::Disclaimer::=20=20
---------------------------------------------------------------------------= -----=20 =20
The contents of this email and any attachment(s) are confidential and inten= ded=20
for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20=20
Any views or opinions presented in this email are solely those of the autho= r=20=20
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 opinions
------=OPENWEBMAIL_ATT_0.0881798638469888-- From nobody Mon Aug 14 09:20:40 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2111321D0 for ; Mon, 14 Aug 2017 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 o29VbJjEZ4Yi for ; Mon, 14 Aug 2017 06:01:58 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0111.outbound.protection.outlook.com [104.47.37.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A231321CB for ; Mon, 14 Aug 2017 06:01:57 -0700 (PDT) Received: from DM5PR05CA0060.namprd05.prod.outlook.com (10.174.188.177) by BLUPR05MB1955.namprd05.prod.outlook.com (10.162.224.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 13:01:55 +0000 Received: from BN3NAM01FT017.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::204) by DM5PR05CA0060.outlook.office365.com (2603:10b6:4:39::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10 via Frontend Transport; Mon, 14 Aug 2017 13:01:55 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; cdot.in; dkim=none (message not signed) header.d=none;cdot.in; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN3NAM01FT017.mail.protection.outlook.com (10.152.67.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1304.16 via Frontend Transport; Mon, 14 Aug 2017 13:01:54 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v7ECqeLE025828; Mon, 14 Aug 2017 08:01:53 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by plsapdm3.corp.sprint.com with ESMTP id 2c9xx9gd6c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Aug 2017 08:01:53 -0500 Received: from plsapdm3.corp.sprint.com (plsapdm3.corp.sprint.com [127.0.0.1]) by pps.reinject (8.16.0.16/8.16.0.16) with SMTP id v7ED1rXl032865; Mon, 14 Aug 2017 08:01:53 -0500 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by plsapdm3.corp.sprint.com with ESMTP id 2c9xx9gd65-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Aug 2017 08:01:53 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 14 Aug 2017 08:01:51 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Mon, 14 Aug 2017 08:01:51 -0500 From: "Bertz, Lyle T [CTO]" To: Priyatosh Mandal , Dave Dolson , RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "warren@kumari.net" , "jouni.nospam@gmail.com" , "lionel.morand@orange.com" CC: "dime@ietf.org" Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTE68Yz05SCldUd0iJEvC11dVdbKKDg/CAgAArP9+AAFtmAP//x/Jw Date: Mon, 14 Aug 2017 13:01:51 +0000 Message-ID: <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com> References: <20170811040456.E8570B81789@rfc-editor.org>, <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> <20170814110558.M60858@cdot.in> In-Reply-To: <20170814110558.M60858@cdot.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.47] Content-Type: multipart/alternative; boundary="_000_1efe047abe674df0acf2c82406abbbc7plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(2980300002)(438002)(377454003)(199003)(189002)(2906002)(108616004)(7696004)(5250100002)(8936002)(2501003)(575784001)(14454004)(229853002)(33646002)(2900100001)(4326008)(24736003)(53546010)(626005)(84326002)(81166006)(606006)(93886004)(356003)(7416002)(68736007)(86362001)(5660300001)(5890100001)(2201001)(8676002)(966005)(7736002)(81156014)(6116002)(102836003)(3846002)(790700001)(236005)(97736004)(6306002)(54896002)(50986999)(54356999)(512874002)(76176999)(39060400002)(189998001)(4546004)(45080400002)(30436002)(478600001)(2950100002)(106466001)(6246003)(53936002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1955; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT017; 1:D9y9G4kbQgv2DX5qITMHKLTWoyqy6MUFhLSKf8sMilZKbfntmWUhovqyMQ4Q40qfGVIljoce0dSugv0BOiQlzARF/GQw73EI7I6bpFa4fDVFIX+C0Whd1WNpkoBzMBPvRbWoy6fMffBuA2hyMVznorcPCRWvDtkQQWQ9waHlUlcfISPj2y2oR0S9HyTF+gW7nyFlBrCy4vh5MLSAvRkihcs3Y3S1Rjirvo5gGh5fhcBGXS+PqsBAAbl7KXy8qw4hqwaofD/hgt5yWINEYZi/fEEOQFFX2t2kjOdBg3uP9IB1B2sho9Dp9Vo47vq2RV5dVWmDW+IoeeC521rhsKgC+TtxQnAbwB0RNo2zLPEMiIsTFUVsrWM7akrUtDBJSc8ResWYwpAvO/YfqWFVYT/Ip/hBHxTfOVKXdYTbWDnWjfGxopY/jeq4TuSgQDDAafbKtyvvs3lacRDdZ4QxjVjPCEDTajm7MKLjliSNyU+h5izYXq3c6WIjZnNpX0aJfcFlOPShVjojM6Gp/aUk7U+Drg0KGdqeRportZ27tTUEwIbFvyxJ2dUtO137MwAaA4eSQ7kgxfOWY5j4zatygWNYurDJrzeF07WcXJ3+Jm3zQR9b+69otbUgClW04q3eSbKA9es/xJFQPlOW1EUUntiqRikFUrsx+FMX1JTA9EIgER6PcYXDTf+d7KWEzZkdrlj5cmdfu+fAum+nyGYKD9wUC6LORdCJ0irp36cuocn0o6AmxFrv+T0HGhqecie55jjOOQkFd0CaZhov7jckoAup7euHi9Xj+ZeOmtMl9zVweKSyuYbnmRks24ordVp3hNv7Y8vFxK5VMpBni/H+Tu6rx7GDjCsOQ9qRrYdAf5pHSac= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c05cbdc-45bb-4149-b560-08d4e314a377 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB1955; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 3:b9OWXD5vhoM033uOwsEluYPtS4F4CtB93VFFPSXtxhDxzu4FAfmaLLI9lcHvI+mRBaoFs+Kf7DHBKoinDGPRv56PgvVzexlB8IDZ9AoPTNgCNJvHFrXmZWiEM3sjpQSeu8SPXpN31AxBV3hnu0IBqrxJBIp+3kWTFqBrrEzLKRhd85rqcCQi4EJarXQo05fsfQce/IRQcGLbGS5Q8OhzyOlB5WGhy4mQDIsoNziBdX6GgmyPQ0Zjw9Ld0X/gWyoIfkgKHFyWoFRHukhG27bGaGSL9b+YKeBGKrT/RvJR32jx/Kxmy6r307SgoZwQ7bmKcovY1jblmdXELeXAjtkitWKPif1fOoa87xhWeBOP0jk=; 25:N5OY0aG1Fltckhvf3pyBO/hO2xrNfyBU+w855WnyWOeHPX/6onmDQVyP7Yhxg1n1w0GGWa704/YUX54XAdQQV+97v14YN6GCPqnnkdw7n7OyviOH8rqzLTEI+5lEFoGRhdEIh8GVmwYe3nWr41FLINBMKdOLLGpOvu+scekasqIV5bNP9qaACYRIBWaJchcCZBKe/IMw7KFRasyJRZKO9TcSbgkQsMVOSVvPNE+cnUKbA2zq/lF7MQ9SXJZexZmmkQhi6QywD/4wZsmFafCGEvvMIPyWE6Gh/BTuGS93tRLsKrGT/UpMRIPoRZyqajV6NkLnYN3niHPWzkKydT0VGw== X-MS-TrafficTypeDiagnostic: BLUPR05MB1955: X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 31:fL8HujjBktdkzZ7Zv23n2iGDhSbyhAQ/OR5DuSgCUIS9WF8A5EMdiaZRtUZEBszgoUm45UgDWITHPa9SAmE3ErpBAxySdlIznE8wizByNjxdBW7qgH9DDSqLdPlgCmLc+TAkelwmhRP0oOsGMZmF5CyyJhUJP7yGBD+ZrRMxjUpwX+0hwxCVgQiw+shfOdka2kNSkbZmnv7gXpNMEhqFd21Y59ZZTYsYSb45iEAApZw=; 20:6aYIBrGuZ4UIDQZxert5dGFQHqtMAFFz1dOUPciKhVXXnZmDCtP1tqEC5v3eC3Q+tG8D9FFiv5ouiLtPPVcPkIWfUz0eZgjd5TefkdEjiTj+LCGWKQ0gxgq2DiGuKkZwJYkrzzl8GJ+YxAYZQ2oukCcghMPsW+zNByMR1Wsa/prwuH7bKTR+27aXQ6Liqp/GM+cgbaRJ+ZT0/VduZ2AgCrBer6QswfbvwBJuYm5LKildaBBzrr2PfRuV6Ui4VMCzOWPO0PBvZ8gUAKIWGqlMskP2or2QXTMiBNLTsGlAuUejvPcqnaKi+MQBxPL0vqTUhZUkV87OWwL0WJX0wtdihVfkzRoGYfudjoQPvfH+HgsMldwc46BUT5iDu+6nF5utG8UWh26uYmbkohysQwyUMbnEWzlnteaXkr87j0W6pAD1Q6gkuB4Pzcz2uYoNM5ZEw24G1ZwNmRNe/JVFfhgHds//VIqkxr5+/vuHwwCkCvqzg/tvgMlmig1lxffoC1PI X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(189930954265078)(82608151540597)(95692535739014)(18271650672692)(219752817060721)(21748063052155); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(13016025)(13018025)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93004095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB1955; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB1955; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 4:d/1heueouwSwq0n/OuRmq8JSsUgg44Z4a3eVLOFlMQQEyF6k32q9GYZJZ7gQ3JxjW7ktdxt0JKmRByY8iUGYo4cT0VYBqMrrkEU+Muw6o8bhghqwK7UCDFFbadCl5TNdP4ZcVfq/98G0A2A7fb5/gsxwab5Srfuix+w7QKrd0/tCHe/6r0Hb0xYfrdv8oMf3GtQiP/WuDt8KKpyAQiHjBig0O+BbDtE4B951iUIpEKYLEpsaQYA+tgDC0MwYowW9Xr3ovIP/909Sd/XST4u6DVa6zTpOybpmMBMFCcp5mK5xFMbJyon8VVFGFSz+baHYzE1Z4jLnxrJYm/TXvQRs2x7s0Bv6+MDqwolojGryRXY/n1m6d9jTe9LCjucKOyM2WueFkTvN70+UVySFYfTWfN258gQa+Kjv8QMJHcUUDxQLh+zbWW6kWjNh6kJ3tl/FOStwMSujrKiUzb8Lhu1B4zd9VGdrI556l1ATDkJrGt1AbUNoCEScxmEyz982T4iu X-Forefront-PRVS: 039975700A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB1955; 23:5d9FZ2OHXvUwD5uWa3X2aYLxnNUal/qV4fikBUqaw?= =?us-ascii?Q?Gjmf2Pk9AXL5YhMH2YKhkYPAw4N+rVqs485mw5VT7Bu6ldmRgZaFresrq8GQ?= =?us-ascii?Q?FjSx0pidkrYfs6v3rrmlCzPklu5/IFpD1me6wSRHZebEwk3XlVzkSkZsG4qR?= =?us-ascii?Q?INvYmDVt5RMRtGukxwyGB3B+lVclXOZlsaHbjKvInDUp9WWxtbAO/Rxs0hUF?= =?us-ascii?Q?W98Bj+UJXVn2P9yXJpCM1uoclhvS+/Jx6EFduu/828yegpODEC/o2fr2n8HO?= =?us-ascii?Q?5v6qTT/HBbKvoyejtyGiAo8sc39HDFoZOfSxKVni1qbF0D3FgGQaP3KJLiAD?= =?us-ascii?Q?Of8d0dLy0M8AtMI3KmhxEjNHbtiR2JxKUm8y8yGQxdCC4LadmKZBgXLtV03t?= =?us-ascii?Q?6RI4Vqwyq/Bwow+vHn0IAN6Zy0istzz1l8FWYY/iPsanzVK9WDAkdKyWpssR?= =?us-ascii?Q?qteymyOtuHksl4VkwCi0NhXnxG9pipONN3cQ8IQXKV/Tb0ekRN1cHEbv+ctO?= =?us-ascii?Q?wUz8wqviw4ybT/oSE3vH2untP6jFgDG9PUj4gF52AabJKfXShis2abJ7txYN?= =?us-ascii?Q?BeK3GBxRyHoAdpbwGF15rQI40xmSQbe+mckesw6t0Ji+2EVuo7atyOZjvhGx?= =?us-ascii?Q?N9J80MjOaIybLPPArNw/Zsr4dJANQwyYjjAcEMGk1dmXE0GZ6ddcB6N3rfYw?= =?us-ascii?Q?GT1nyHVV/itO4mBF9ER/W9lBp+/xhB40MxiD82/wae5dGOWmjc1S8H4KUgSR?= =?us-ascii?Q?uCkMTF0Ly6QgH52sjJSaSJWwUEpDcmjciWJ5AHOpDcuiwdzIviNGkbxJ9hOz?= =?us-ascii?Q?kj3bQyEIIzaFza6i/OSEAPMNdMeElZSZSzIlexp0Obl1sQEoIKR8VLVAdz9p?= =?us-ascii?Q?2eokiNHbEziBpvQJ4LKKifIpPiiFWkWQdDY8oNT140ExUOF/fDUjbjt81fDU?= =?us-ascii?Q?0Z+O60U8fTqPAmmVd0bqdcuRKy4VlPu1C4dqB/TLM4jelElxqDIuMA/qSMTL?= =?us-ascii?Q?/Z5UTMlUCHxP4WYerH0r5/GOvXFKlHZLoN36Rm20IYrX9Fx9h9bh6mCpN4Ye?= =?us-ascii?Q?DLiBY254RtEfWo7qAxcjWQtK6BwU13bQoWCLUvVC6+kY05PeX6KVqIKMjene?= =?us-ascii?Q?3CxkkJI7qB6ABZrjubMFsmBR+KcqqfUDZ1ohtiEgIXnPS9jJRm/NkErrWKZh?= =?us-ascii?Q?cLzJAkdZ/IAgMUDnJ4fMEE/eHyLIcCfynIzgv968uajGzWySHqWUnU0NkqM2?= =?us-ascii?Q?QbmzHzHgo5v1ffL7rir3DugQSW2NTVTYA7O/5ROVEocmcck+xnrqRl7TKn+7?= =?us-ascii?Q?er727BuFcnXrgPqFlslI2siUMR6/3UUw528xmWrteQGD2xFNayAiUEcaqlRC?= =?us-ascii?Q?ZcuDRMDf1eWIqNWEwZuBxlITejl1X002EjjPufR7lZLjt/u?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1955; 6:3N2HYHumQcjttiAljqAPso6zM/t9qLzGWwx8wRNkSxFcHwj7qwbVJzKDbWoWdmKtxWVSkEXKvSc6cKdoMTIE7sfFoDZZ4i0cxUlEkPbNW8lvs7kI6WDVOsNNUPiQeK8TjxxaHlhbCQ6tyPYicbm5XceMAs8ALTdPxNRk314pmESjz0b11HRpioTzLwpwFEZ241h3yMeoCR9lvt2x6TxoQiNGfzB6u7DIs3R9ivWX87LxNrn2HB+qEh7WyqE5plu4s/gG4Wk3phnbUDxNI6ZByisYzqVA95RtG++TGmcoOtvt6flNeScOraOIH+hifS8bwXJpwFU5uLCaYPF8d0qlQw==; 5:HfuSIkdvF9Cm21EI8h16/8p5R9RMkXCPPVnvXsqyHIsFpiIqhn/9WLW2nHH0MAs5tV6tgJKpWry1mJ7dOq1ySggzyBItipoZGlzkLUPHUQ1SDb+iY5VwQdBrSh0ZOUqYrtHAiM5xjcZiMnKlCjwG4w==; 24:gNPV7E8Q9dHcmct9vtiWVgECweQzWjVXBMh7UZ4ygSd2AZQwUOvbVE951OBgjYIUh3U03i5/rVckcwlCNhloLZ/PlZrsifnAdxcHNQBDNss=; 7:SsTd9AH5ZUZNg87s59gGzeLcx5pZNNduYpG3TWryn2zZhztwhfwssuJ6J2jgjBEk2KFNRy/qZv7W4PMYDL05zlmQKNQGUEvoXNKhN1mp+E/Beq64oMWJ+WeXll8b+g86rr9wx8wqzXaM7O+HBVyTYrs4JOssM02mcQOPppTRBfTejWAfRx3jRLjawus3zFd1SpLbSOzcuVN7kSCy4L287+0GoYBFffQ9HNDPez2QCmc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2017 13:01:54.2933 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1955 Archived-At: X-Mailman-Approved-At: Mon, 14 Aug 2017 09:20:38 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 13:02:02 -0000 --_000_1efe047abe674df0acf2c82406abbbc7plswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHdoYXQgRGF2ZSBpcyBhbGx1ZGluZyB0byBpcyB0aGF0IGlmIG9uZSAqZG9lcyBp bnRlbmQgZm9yIHRoZSBpbmZlcmVuY2VzIHRvIGJlIG1hZGUqIHRoZW4gcm9sbGluZyBvdmVyIHRo ZSB2YWx1ZSB0byAwIGlzIG5vdCBhcHByb3ByaWF0ZSBhbmQgYSB2YWx1ZSA+IDAsIGUuZy4gMSwg TVVTVCBiZSB1c2VkLg0KDQpJbiBhIHNlbnNlIGl0IGlzIG5vdCBhbiBlcnJvciBhcyBtdWNoIGFz IGEgbm90ZSAvIHdhcm5pbmcgZm9yIHRob3NlIHdobyBhcmUgYWxsb2NhdGluZyB0aGF0IEFWUCBp biBhIHNwZWNpZmljIG1hbm5lci4NCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByaXlhdG9zaCBNYW5kYWwNClNlbnQ6IE1vbmRheSwgQXVn dXN0IDE0LCAyMDE3IDY6MTkgQU0NClRvOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5j b20+OyBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz47IHZmMDIx M0BnbWFpbC5jb207IGphcmkuYXJra29AZXJpY3Nzb24uY29tOyBqb2huLmxvdWdobmV5QG5va2lh LmNvbTsgZ2xlbnpvcm5AZ21haWwuY29tOyBiY2xhaXNlQGNpc2NvLmNvbTsgd2FycmVuQGt1bWFy aS5uZXQ7IGpvdW5pLm5vc3BhbUBnbWFpbC5jb207IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0K Q2M6IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGltZV0gW1RlY2huaWNhbCBFcnJhdGEg UmVwb3J0ZWRdIFJGQzY3MzMgKDUwODQpDQoNCkhlbGxvIFNpciwNClRoZSBzaXR1YXRpb24gaXMg YSB0cmFuc2l0aW9uIGZyb20gdGhlIG1heGltdW0gdmFsdWUgNDI5NDk2NzI5NSBvZiBPcmlnaW4t U3RhdGUtSWQuIElmIGFmdGVyIHRoaXMsIHRoZSB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQgaXMg aW5jcmVhc2VkLCBpdCB3aWxsIGF1dG9tYXRpY2FsbHkgYmVjb21lIDAuIFNvIHRoZSBwZWVyIG5v ZGUgd2hpY2ggcmVjZWl2ZXMgdGhlIHZhbHVlIDAgYWZ0ZXIgNDI5NDk2NzI5NSwgY2FuIGFzc3Vt ZSB0aGUgbm9kZSB3aGljaCBzZW50IHRoaXMgMCwNCmZhY2VkIGEgcmVzdGFydC4gSGVyZSB0aGUg cGVlci1ub2RlICBpcyBhbHJlYWR5IGF3YXJlIHRoYXQgdGhlIHByZXZpb3VzIHZhbHVlIG9mIG9y aWdpbi1zdGF0ZS1pZCB3YXMgNDI5NDk2NzI5NS4gU28gaXQgY2FuIGVhc2lseSBjb25jbHVkZSBu b2RlIHJlc3RhcnQuDQoNCkkgdW5kZXJzdGFuZCAgdGhlIG1lYW5pbmcgb2YgMCBhcyBleHBsYWlu ZWQgaW4gUkZDIDY3MzMgOiJJZiBhbiBhY2Nlc3MgZGV2aWNlIGRvZXMgbm90IGludGVuZCBmb3Ig c3VjaCBpbmZlcmVuY2VzIHRvIGJlIG1hZGUsIGl0IE1VU1QgZWl0aGVyIG5vdCBpbmNsdWRlIE9y aWdpbi1TdGF0ZS1JZCBpbiBhbnkgbWVzc2FnZSBvciBzZXQgaXRzIHZhbHVlIHRvIDAiLg0KDQpC dXQgdGhpcyBpcyBhIHNwZWNpYWwgY2FzZSwgd2hlcmUgdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0 ZS1JZCBjaGFuZ2VzIGZyb20gIDQyOTQ5NjcyOTUgdG8gMC4NCg0KDQoNClNvIGtpbmRseSByZWNv bnNpZGVyIHRoaXMuDQoNCg0KDQpUaGFua2luZyB5b3UsDQpQcml5YXRvc2gNCg0KDQoNCg0KT24g TW9uLCAxNCBBdWcgMjAxNyAxMDo1MToyNSArMDAwMCwgRGF2ZSBEb2xzb24gd3JvdGUNCkluIG15 IG9waW5pb24sIHRoZSBjaGFuZ2Ugc2hvdWxkIG5vdCBiZSBhY2NlcHRlZC4NCkluIHlvdXIgcm9s bC1vdmVyIHNwZWNpYWwgY2FzZSwgdGhlIGRldmljZSBzaG91bGQgc2tpcCBvdmVyIHRoZSB2YWx1 ZSAwLCB1c2luZyAxIG9yIHNvbWUgb3RoZXIgdmFsdWUgaW5zdGVhZCBvZiB6ZXJvLg0KDQpEYXZp ZCBEb2xzb24NClNhbmR2aW5lDQoNCg0KRnJvbTogUHJpeWF0b3NoIE1hbmRhbA0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMTQsIDIwMTcgMTI6NTcgQU0NClRvOiBSRkMgRXJyYXRhIFN5c3RlbTsgdmYw MjEzQGdtYWlsLmNvbTxtYWlsdG86dmYwMjEzQGdtYWlsLmNvbT47IGphcmkuYXJra29AZXJpY3Nz b24uY29tPG1haWx0bzpqYXJpLmFya2tvQGVyaWNzc29uLmNvbT47IGpvaG4ubG91Z2huZXlAbm9r aWEuY29tPG1haWx0bzpqb2huLmxvdWdobmV5QG5va2lhLmNvbT47IGdsZW56b3JuQGdtYWlsLmNv bTxtYWlsdG86Z2xlbnpvcm5AZ21haWwuY29tPjsgYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJj bGFpc2VAY2lzY28uY29tPjsgd2FycmVuQGt1bWFyaS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmku bmV0Pjsgam91bmkubm9zcGFtQGdtYWlsLmNvbTxtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNv bT47IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu Y29tPg0KQ2M6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW0RpbWVdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2NzMzICg1MDg0KQ0KDQoN Cg0KRGVhciBBbGwsDQpLaW5kbHkgdmVyaWZ5IHRoaXMuDQoNClJlZ2FyZHMsDQpQcml5YXRvc2gg TWFuZGFsDQoNCk9uIFRodSwgMTAgQXVnIDIwMTcgMjE6MDQ6NTYgLTA3MDAgKFBEVCksIFJGQyBF cnJhdGEgU3lzdGVtIHdyb3RlDQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4g c3VibWl0dGVkIGZvciBSRkM2NzMzLA0KIkRpYW1ldGVyIEJhc2UgUHJvdG9jb2wiLg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWW91IG1heSByZXZpZXcgdGhlIHJl cG9ydCBiZWxvdyBhbmQgYXQ6DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1 MDg0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGElMkZlaWQ1MDg0JmRhdGE9MDIl N0MwMSU3Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M2MjdlNWY5OTliNmU0NzUwZmFlNDA4 ZDRlMzEzYTU2MiU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2 MzYzODMxMjA5MDE2MDY3MzMmc2RhdGE9cnpUQ0ZrZmM3S0N6R3hOaGRDc25DalZTRk9WdWk5bEp5 QW1zV0t4ZFRoQSUzRCZyZXNlcnZlZD0wPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KVHlwZTogVGVjaG5pY2FsDQpSZXBvcnRlZCBieTogUHJpeWF0b3NoIE1hbmRh bCA8cHJpeWF0b3NAY2RvdC5pbjxtYWlsdG86cHJpeWF0b3NAY2RvdC5pbj4+DQoNClNlY3Rpb246 IDguMTYNCg0KT3JpZ2luYWwgVGV4dA0KLS0tLS0tLS0tLS0tLQ0KQnkgaW5jbHVkaW5nIE9yaWdp bi1TdGF0ZS1JZCBpbiBhIG1lc3NhZ2UsIGl0IGFsbG93cyBvdGhlciBEaWFtZXRlcg0KZW50aXRp ZXMgdG8gaW5mZXIgdGhhdCBzZXNzaW9ucyBhc3NvY2lhdGVkIHdpdGggYSBsb3dlciBPcmlnaW4t U3RhdGUtSWQNCmFyZSBubyBsb25nZXIgYWN0aXZlLg0KSWYgYW4gYWNjZXNzIGRldmljZSBkb2Vz IG5vdCBpbnRlbmQgZm9yIHN1Y2ggaW5mZXJlbmNlcyB0byBiZSBtYWRlLCBpdA0KTVVTVCBlaXRo ZXIgbm90IGluY2x1ZGUgT3JpZ2luLVN0YXRlLUlkIGluIGFueSBtZXNzYWdlIG9yIHNldCBpdHMg dmFsdWUNCnRvIDAuDQoNCkNvcnJlY3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KQnkgaW5jbHVk aW5nIE9yaWdpbi1TdGF0ZS1JZCBpbiBhIG1lc3NhZ2UsIGl0IGFsbG93cyBvdGhlciBEaWFtZXRl cg0KZW50aXRpZXMgdG8gaW5mZXIgdGhhdCBzZXNzaW9ucyBhc3NvY2lhdGVkIHdpdGggYSBsb3dl ciBPcmlnaW4tU3RhdGUtSWQNCmFyZSBubyBsb25nZXIgYWN0aXZlLg0KSWYgYW4gYWNjZXNzIGRl dmljZSBkb2VzIG5vdCBpbnRlbmQgZm9yIHN1Y2ggaW5mZXJlbmNlcyB0byBiZSBtYWRlLCBpdA0K TVVTVCBlaXRoZXIgbm90IGluY2x1ZGUgT3JpZ2luLVN0YXRlLUlkIGluIGFueSBtZXNzYWdlIG9y IHNldCBpdHMgdmFsdWUNCnRvIDAuDQpBcyBhIHNwZWNpYWwgY2FzZSB3aGVuIHRoZSB2YWx1ZSBv ZiBPcmlnaW4tU3RhdGUtSWQgY2hhbmdlcyBmcm9tDQo0Mjk0OTY3Mjk1IHRvIDAsIHRoZW4gYWxz byB0aGUgYWNjZXNzIGRldmljZSAgY2xlYXIgYWxsIHRoZSBzZXNzaW9ucy4NCg0KTm90ZXMNCi0t LS0tDQpPcmlnaW4tU3RhdGUtSWQgaXMgZGVmaW5lZCBhcyBVbnNpZ25lZDMyIGluIFJGQyA2NzMz LCBTZWN0aW9uIDguMTYuIFNvIHRoZSBtYXhpbXVtDQp2YWx1ZSBpdCBjYW4gaGF2ZSBpcyA0Mjk0 OTY3Mjk1LiBJZiB0aGUgc3lzdGVtIHJlc3RhcnRzIG1hbnkgdGltZXMgYW5kIHRoZSB2YWx1ZSBv Zg0KT3JpZ2luLVN0YXRlLUlkIHJlYWNoZXMgdGhlIHZhbHVlIHdoaWNoIGlzIHNhbWUgYXMgaXRz IG1heGltdW0gdmFsdWUgNDI5NDk2NzI5NS4NClRoZW4gd2hhdCB3aWxsIGhhcHBlbiBmb3IgdGhl IG5leHQgcmVzdGFydC4gQXQgdGhlIG5leHQgcmVzdGFydCB0aGUgdmFsdWUgb2YgT3JpZ2luLVN0 YXRlLUlkDQp3aWxsIGJlIDAgaWYgd2UgdHJ5IHRvIGluY3JlYXNlIHRoZSB2YWx1ZSBvZiBPcmln aW4tU3RhdGUtSWQuDQpJdCBpcyBub3QgZGVmaW5lZCBpbiB0aGUgUkZDIDY3MzMsIHRoYXQgaG93 IHRoZSBzeXN0ZW0gc2hvdWxkIGJlaGF2ZSBhZnRlciA0Mjk0OTY3Mjk1LXRoDQpyZXN0YXJ0IHdp dGggcmVzcGVjdCB0byBPcmlnaW4tU3RhdGUtSWQuDQoNCkdlbmVyYWxseSB3aGVuIHRoZSBwZWVy IHJlY2VpdmVzIGFuIGluY3JlYXNlZCB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQsIHRoZW4gaXQg Y2xlYXIgYWxsIHNlc3Npb25zLg0KSWYgdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZCByZWFj aGVzIGl0cyBtYXhpbXVtIGkuZS4sIDQyOTQ5NjcyOTUsIHRoZW4gYWZ0ZXIgYW5vdGhlciByZXN0 YXJ0DQppdHMgdmFsdWUgd2lsbCBiZSAwLiBGb3IgYSBzcGVjaWFsIGNhc2UgZm9yIHRyYW5zaXRp b24gb2YgdmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkIGZyb20NCjQyOTQ5NjcyOTUgdG8gMCwgdGhl IHBlZXIgc2hvdWxkIGNsZWFyIGl0cyBzZXNzaW9uLg0KDQpJbnN0cnVjdGlvbnM6DQotLS0tLS0t LS0tLS0tDQpUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQiLiBJ ZiBuZWNlc3NhcnksIHBsZWFzZQ0KdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBp dCBzaG91bGQgYmUgdmVyaWZpZWQgb3INCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVh Y2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eQ0KY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1 cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpSRkM2NzMzIChkcmFmdC1pZXRmLWRpbWUtcmZjMzU4OGJp cy0zMykNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaXRsZSAgICAg ICAgICAgICAgIDogRGlhbWV0ZXIgQmFzZSBQcm90b2NvbA0KUHVibGljYXRpb24gRGF0ZSAgICA6 IE9jdG9iZXIgMjAxMg0KQXV0aG9yKHMpICAgICAgICAgICA6IFYuIEZhamFyZG8sIEVkLiwgSi4g QXJra28sIEouIExvdWdobmV5LCBHLiBab3JuLCBFZC4NCkNhdGVnb3J5ICAgICAgICAgICAgOiBQ Uk9QT1NFRCBTVEFOREFSRA0KU291cmNlICAgICAgICAgICAgICA6IERpYW1ldGVyIE1haW50ZW5h bmNlIGFuZCBFeHRlbnNpb25zDQpBcmVhICAgICAgICAgICAgICAgIDogT3BlcmF0aW9ucyBhbmQg TWFuYWdlbWVudA0KU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNClZlcmlmeWluZyBQYXJ0eSAg ICAgOiBJRVNHDQoNClByaXlhdG9zaA0KRXh0OiA4NTE3DQpNb2I6IDk4MTA0ODAyNjYNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo6OkRpc2NsYWltZXI6Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudChzKSBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0KZm9yIHRoZSBuYW1lZCByZWNpcGllbnQocykgb25s eS4gSXQgc2hhbGwgbm90IGF0dGFjaCBhbnkgbGlhYmlsaXR5IG9uIEMtRE9ULg0KQW55IHZpZXdz IG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIGVtYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2Yg dGhlIGF1dGhvcg0KYW5kICBtYXkgIG5vdCAgbmVjZXNzYXJpbHkgIHJlZmxlY3QgIHRoZSAgIG9w aW5pb25zDQoNCg0KDQpQcml5YXRvc2gNCkV4dDogODUxNw0KTW9iOiA5ODEwNDgwMjY2DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KOjpEaXNjbGFpbWVyOjoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnQocykgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQNCmZvciB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9u bHkuIEl0IHNoYWxsIG5vdCBhdHRhY2ggYW55IGxpYWJpbGl0eSBvbiBDLURPVC4NCkFueSB2aWV3 cyBvciBvcGluaW9ucyBwcmVzZW50ZWQgaW4gdGhpcyBlbWFpbCBhcmUgc29sZWx5IHRob3NlIG9m IHRoZSBhdXRob3INCmFuZCAgbWF5ICBub3QgIG5lY2Vzc2FyaWx5ICByZWZsZWN0ICB0aGUgICBv cGluaW9ucw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIGUtbWFp bCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9y IHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug Y29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4N Cg== --_000_1efe047abe674df0acf2c82406abbbc7plswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHdoYXQgRGF2ZSBpcyBh bGx1ZGluZyB0byBpcyB0aGF0IGlmIG9uZSAqPGI+ZG9lcyBpbnRlbmQgZm9yIHRoZSBpbmZlcmVu Y2VzIHRvIGJlIG1hZGU8L2I+KiB0aGVuIHJvbGxpbmcgb3ZlciB0aGUgdmFsdWUgdG8gMCBpcyBu b3QgYXBwcm9wcmlhdGUgYW5kIGENCiB2YWx1ZSAmZ3Q7IDAsIGUuZy4gMSwgTVVTVCBiZSB1c2Vk LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIGEgc2Vuc2Ug aXQgaXMgbm90IGFuIGVycm9yIGFzIG11Y2ggYXMgYSBub3RlIC8gd2FybmluZyBmb3IgdGhvc2Ug d2hvIGFyZSBhbGxvY2F0aW5nIHRoYXQgQVZQIGluIGEgc3BlY2lmaWMgbWFubmVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRGlNRSBbbWFpbHRvOmRpbWUtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJpeWF0b3NoIE1hbmRhbDxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAxNCwgMjAxNyA2OjE5IEFNPGJyPg0KPGI+VG86 PC9iPiBEYXZlIERvbHNvbiAmbHQ7ZGRvbHNvbkBzYW5kdmluZS5jb20mZ3Q7OyBSRkMgRXJyYXRh IFN5c3RlbSAmbHQ7cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyZndDs7IHZmMDIxM0BnbWFpbC5j b207IGphcmkuYXJra29AZXJpY3Nzb24uY29tOyBqb2huLmxvdWdobmV5QG5va2lhLmNvbTsgZ2xl bnpvcm5AZ21haWwuY29tOyBiY2xhaXNlQGNpc2NvLmNvbTsgd2FycmVuQGt1bWFyaS5uZXQ7IGpv dW5pLm5vc3BhbUBnbWFpbC5jb207IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxicj4NCjxiPkNj OjwvYj4gZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdIFtUZWNo bmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2NzMzICg1MDg0KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIFNpciwgPGJyPg0KVGhlIHNpdHVhdGlv biBpcyBhIHRyYW5zaXRpb24gZnJvbSB0aGUgbWF4aW11bSB2YWx1ZSA0Mjk0OTY3Mjk1IG9mIE9y aWdpbi1TdGF0ZS1JZC4gSWYgYWZ0ZXIgdGhpcywgdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1J ZCBpcyBpbmNyZWFzZWQsIGl0IHdpbGwgYXV0b21hdGljYWxseSBiZWNvbWUgMC4gU28gdGhlIHBl ZXIgbm9kZSB3aGljaCByZWNlaXZlcyB0aGUgdmFsdWUgMCBhZnRlciA0Mjk0OTY3Mjk1LCBjYW4g YXNzdW1lIHRoZSBub2RlIHdoaWNoDQogc2VudCB0aGlzIDAsIDxicj4NCmZhY2VkIGEgcmVzdGFy dC4gSGVyZSB0aGUgcGVlci1ub2RlJm5ic3A7IGlzIGFscmVhZHkgYXdhcmUgdGhhdCB0aGUgcHJl dmlvdXMgdmFsdWUgb2Ygb3JpZ2luLXN0YXRlLWlkIHdhcyA0Mjk0OTY3Mjk1LiBTbyBpdCBjYW4g ZWFzaWx5IGNvbmNsdWRlIG5vZGUgcmVzdGFydC4NCjxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCZu YnNwOyB0aGUgbWVhbmluZyBvZiAwIGFzIGV4cGxhaW5lZCBpbiBSRkMgNjczMyA6JnF1b3Q7SWYg YW4gYWNjZXNzIGRldmljZSBkb2VzIG5vdCBpbnRlbmQgZm9yIHN1Y2ggaW5mZXJlbmNlcyB0byBi ZSBtYWRlLCBpdCBNVVNUIGVpdGhlciBub3QgaW5jbHVkZSBPcmlnaW4tU3RhdGUtSWQgaW4gYW55 IG1lc3NhZ2Ugb3Igc2V0IGl0cyB2YWx1ZSB0byAwJnF1b3Q7Lg0KPG86cD48L286cD48L3A+DQo8 cHJlPkJ1dCB0aGlzIGlzIGEgc3BlY2lhbCBjYXNlLCB3aGVyZSB0aGUgdmFsdWUgb2YgT3JpZ2lu LVN0YXRlLUlkIGNoYW5nZXMgZnJvbSZuYnNwOyA0Mjk0OTY3Mjk1IHRvIDAuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PGJyPjxicj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YnI+U28ga2luZGx5 IHJlY29uc2lkZXIgdGhpcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhbmtpbmcgeW91LCA8YnI+DQpQ cml5YXRvc2ggPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPk9uIE1vbiwgMTQgQXVnIDIwMTcgMTA6NTE6MjUgJiM0MzswMDAwLCBE YXZlIERvbHNvbiB3cm90ZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pg0KPGJyPg0KSW4gbXkgb3BpbmlvbiwgdGhlIGNoYW5nZSBzaG91bGQgbm90IGJlIGFjY2VwdGVk LiZuYnNwOyA8YnI+DQpJbiB5b3VyIHJvbGwtb3ZlciBzcGVjaWFsIGNhc2UsIHRoZSBkZXZpY2Ug c2hvdWxkIHNraXAgb3ZlciB0aGUgdmFsdWUgMCwgdXNpbmcgMSBvciBzb21lIG90aGVyIHZhbHVl IGluc3RlYWQgb2YgemVyby4NCjxicj4NCjxicj4NCkRhdmlkJm5ic3A7RG9sc29uIDxicj4NClNh bmR2aW5lIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6 MTAwLjAlO2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVyLXNwYWNpbmc6IDBweCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGI+RnJvbTogPC9iPlByaXlhdG9zaCBNYW5kYWwg PGJyPg0KPGI+U2VudDogPC9iPk1vbmRheSwgQXVndXN0IDE0LCAyMDE3IDEyOjU3IEFNIDxicj4N CjxiPlRvOiA8L2I+UkZDIEVycmF0YSBTeXN0ZW07IDxhIGhyZWY9Im1haWx0bzp2ZjAyMTNAZ21h aWwuY29tIj52ZjAyMTNAZ21haWwuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpqYXJpLmFya2tv QGVyaWNzc29uLmNvbSI+amFyaS5hcmtrb0Blcmljc3Nvbi5jb208L2E+OyA8YSBocmVmPSJtYWls dG86am9obi5sb3VnaG5leUBub2tpYS5jb20iPg0Kam9obi5sb3VnaG5leUBub2tpYS5jb208L2E+ OyA8YSBocmVmPSJtYWlsdG86Z2xlbnpvcm5AZ21haWwuY29tIj5nbGVuem9ybkBnbWFpbC5jb208 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNv bTwvYT47IDxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldCI+DQp3YXJyZW5Aa3VtYXJp Lm5ldDwvYT47IDxhIGhyZWY9Im1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tIj5qb3VuaS5u b3NwYW1AZ21haWwuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n ZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4gPGJyPg0KPGI+Q2M6IDwvYj48YSBo cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT4gPGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbRGltZV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY3MzMg KDUwODQpIDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+ DQo8YnI+DQpEZWFyIEFsbCwgPGJyPg0KS2luZGx5IHZlcmlmeSB0aGlzLiA8YnI+DQo8YnI+DQpS ZWdhcmRzLCA8YnI+DQpQcml5YXRvc2ggTWFuZGFsIDxicj4NCjxicj4NCjxiPk9uIFRodSwgMTAg QXVnIDIwMTcgMjE6MDQ6NTYgLTA3MDAgKFBEVCksIFJGQyBFcnJhdGEgU3lzdGVtIHdyb3RlPC9i PiA8YnI+DQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZv ciBSRkM2NzMzLCA8YnI+DQomcXVvdDtEaWFtZXRlciBCYXNlIFByb3RvY29sJnF1b3Q7LiA8YnI+ DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpZb3Ug bWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDogPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUy Rnd3dy5yZmMtZWRpdG9yLm9yZyUyRmVycmF0YSUyRmVpZDUwODQmYW1wO2RhdGE9MDIlN0MwMSU3 Q2x5bGUudC5iZXJ0eiU0MHNwcmludC5jb20lN0M2MjdlNWY5OTliNmU0NzUwZmFlNDA4ZDRlMzEz YTU2MiU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3QzAlN0M2MzYzODMx MjA5MDE2MDY3MzMmYW1wO3NkYXRhPXJ6VENGa2ZjN0tDekd4TmhkQ3NuQ2pWU0ZPVnVpOWxKeUFt c1dLeGRUaEElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2VycmF0YS9laWQ1MDg0PC9hPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVHlwZTogVGVjaG5pY2FsIDxicj4NClJl cG9ydGVkIGJ5OiBQcml5YXRvc2ggTWFuZGFsICZsdDs8YSBocmVmPSJtYWlsdG86cHJpeWF0b3NA Y2RvdC5pbiI+cHJpeWF0b3NAY2RvdC5pbjwvYT4mZ3Q7DQo8YnI+DQo8YnI+DQpTZWN0aW9uOiA4 LjE2IDxicj4NCjxicj4NCk9yaWdpbmFsIFRleHQgPGJyPg0KLS0tLS0tLS0tLS0tLSA8YnI+DQpC eSBpbmNsdWRpbmcgT3JpZ2luLVN0YXRlLUlkIGluIGEgbWVzc2FnZSwgaXQgYWxsb3dzIG90aGVy IERpYW1ldGVyIDxicj4NCmVudGl0aWVzIHRvIGluZmVyIHRoYXQgc2Vzc2lvbnMgYXNzb2NpYXRl ZCB3aXRoIGEgbG93ZXIgT3JpZ2luLVN0YXRlLUlkIDxicj4NCmFyZSBubyBsb25nZXIgYWN0aXZl LiA8YnI+DQpJZiBhbiBhY2Nlc3MgZGV2aWNlIGRvZXMgbm90IGludGVuZCBmb3Igc3VjaCBpbmZl cmVuY2VzIHRvIGJlIG1hZGUsIGl0IDxicj4NCk1VU1QgZWl0aGVyIG5vdCBpbmNsdWRlIE9yaWdp bi1TdGF0ZS1JZCBpbiBhbnkgbWVzc2FnZSBvciBzZXQgaXRzIHZhbHVlIDxicj4NCnRvIDAuIDxi cj4NCjxicj4NCkNvcnJlY3RlZCBUZXh0IDxicj4NCi0tLS0tLS0tLS0tLS0tIDxicj4NCkJ5IGlu Y2x1ZGluZyBPcmlnaW4tU3RhdGUtSWQgaW4gYSBtZXNzYWdlLCBpdCBhbGxvd3Mgb3RoZXIgRGlh bWV0ZXIgPGJyPg0KZW50aXRpZXMgdG8gaW5mZXIgdGhhdCBzZXNzaW9ucyBhc3NvY2lhdGVkIHdp dGggYSBsb3dlciBPcmlnaW4tU3RhdGUtSWQgPGJyPg0KYXJlIG5vIGxvbmdlciBhY3RpdmUuIDxi cj4NCklmIGFuIGFjY2VzcyBkZXZpY2UgZG9lcyBub3QgaW50ZW5kIGZvciBzdWNoIGluZmVyZW5j ZXMgdG8gYmUgbWFkZSwgaXQgPGJyPg0KTVVTVCBlaXRoZXIgbm90IGluY2x1ZGUgT3JpZ2luLVN0 YXRlLUlkIGluIGFueSBtZXNzYWdlIG9yIHNldCBpdHMgdmFsdWUgPGJyPg0KdG8gMC4gPGJyPg0K QXMgYSBzcGVjaWFsIGNhc2Ugd2hlbiB0aGUgdmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkIGNoYW5n ZXMgZnJvbSA8YnI+DQo0Mjk0OTY3Mjk1IHRvIDAsIHRoZW4gYWxzbyB0aGUgYWNjZXNzIGRldmlj ZSAmbmJzcDtjbGVhciBhbGwgdGhlIHNlc3Npb25zLiA8YnI+DQo8YnI+DQpOb3RlcyA8YnI+DQot LS0tLSA8YnI+DQpPcmlnaW4tU3RhdGUtSWQgaXMgZGVmaW5lZCBhcyBVbnNpZ25lZDMyIGluIFJG QyA2NzMzLCBTZWN0aW9uIDguMTYuIFNvIHRoZSBtYXhpbXVtDQo8YnI+DQp2YWx1ZSBpdCBjYW4g aGF2ZSBpcyA0Mjk0OTY3Mjk1LiBJZiB0aGUgc3lzdGVtIHJlc3RhcnRzIG1hbnkgdGltZXMgYW5k IHRoZSB2YWx1ZSBvZg0KPGJyPg0KT3JpZ2luLVN0YXRlLUlkIHJlYWNoZXMgdGhlIHZhbHVlIHdo aWNoIGlzIHNhbWUgYXMgaXRzIG1heGltdW0gdmFsdWUgNDI5NDk2NzI5NS4gPGJyPg0KVGhlbiB3 aGF0IHdpbGwgaGFwcGVuIGZvciB0aGUgbmV4dCByZXN0YXJ0LiBBdCB0aGUgbmV4dCByZXN0YXJ0 IHRoZSB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQNCjxicj4NCndpbGwgYmUgMCBpZiB3ZSB0cnkg dG8gaW5jcmVhc2UgdGhlIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZC4gPGJyPg0KSXQgaXMgbm90 IGRlZmluZWQgaW4gdGhlIFJGQyA2NzMzLCB0aGF0IGhvdyB0aGUgc3lzdGVtIHNob3VsZCBiZWhh dmUgYWZ0ZXIgNDI5NDk2NzI5NS10aA0KPGJyPg0KcmVzdGFydCB3aXRoIHJlc3BlY3QgdG8gT3Jp Z2luLVN0YXRlLUlkLiA8YnI+DQo8YnI+DQpHZW5lcmFsbHkgd2hlbiB0aGUgcGVlciByZWNlaXZl cyBhbiBpbmNyZWFzZWQgdmFsdWUgb2YgT3JpZ2luLVN0YXRlLUlkLCB0aGVuIGl0IGNsZWFyIGFs bCBzZXNzaW9ucy4NCjxicj4NCklmIHRoZSB2YWx1ZSBvZiBPcmlnaW4tU3RhdGUtSWQgcmVhY2hl cyBpdHMgbWF4aW11bSBpLmUuLCA0Mjk0OTY3Mjk1LCB0aGVuIGFmdGVyIGFub3RoZXIgcmVzdGFy dA0KPGJyPg0KaXRzIHZhbHVlIHdpbGwgYmUgMC4gRm9yIGEgc3BlY2lhbCBjYXNlIGZvciB0cmFu c2l0aW9uIG9mIHZhbHVlIG9mIE9yaWdpbi1TdGF0ZS1JZCBmcm9tDQo8YnI+DQo0Mjk0OTY3Mjk1 IHRvIDAsIHRoZSBwZWVyIHNob3VsZCBjbGVhciBpdHMgc2Vzc2lvbi4gPGJyPg0KPGJyPg0KSW5z dHJ1Y3Rpb25zOiA8YnI+DQotLS0tLS0tLS0tLS0tIDxicj4NClRoaXMgZXJyYXR1bSBpcyBjdXJy ZW50bHkgcG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFz ZSA8YnI+DQp1c2UgJnF1b3Q7UmVwbHkgQWxsJnF1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBpdCBz aG91bGQgYmUgdmVyaWZpZWQgb3IgPGJyPg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyBy ZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5ICZuYnNwOyA8YnI+DQpjYW4gbG9nIGluIHRvIGNo YW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4gPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KUkZDNjcz MyAoZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMzMpIDxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IERpYW1ldGVyIEJhc2UgUHJvdG9jb2wgPGJyPg0K UHVibGljYXRpb24gRGF0ZSAmbmJzcDsgJm5ic3A7OiBPY3RvYmVyIDIwMTIgPGJyPg0KQXV0aG9y KHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBWLiBGYWphcmRvLCBFZC4s IEouIEFya2tvLCBKLiBMb3VnaG5leSwgRy4gWm9ybiwgRWQuIDxicj4NCkNhdGVnb3J5ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBQUk9QT1NFRCBTVEFOREFSRCA8 YnI+DQpTb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiBEaWFtZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyA8YnI+DQpBcmVhICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IE9wZXJh dGlvbnMgYW5kIE1hbmFnZW1lbnQgPGJyPg0KU3RyZWFtICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogSUVURiA8YnI+DQpWZXJpZnlpbmcgUGFydHkgJm5i c3A7ICZuYnNwOyA6IElFU0cgPGJyPg0KPGJyPg0KUHJpeWF0b3NoIDxicj4NCkV4dDogODUxNyA8 YnI+DQpNb2I6IDk4MTA0ODAyNjYgPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0K OjpEaXNjbGFpbWVyOjogPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50KHMpIGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIDxicj4NCmZvciB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9ubHkuIEl0 IHNoYWxsIG5vdCBhdHRhY2ggYW55IGxpYWJpbGl0eSBvbiBDLURPVC4gPGJyPg0KQW55IHZpZXdz IG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIGVtYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2Yg dGhlIGF1dGhvciA8YnI+DQphbmQgJm5ic3A7bWF5ICZuYnNwO25vdCAmbmJzcDtuZWNlc3Nhcmls eSAmbmJzcDtyZWZsZWN0ICZuYnNwO3RoZSAmbmJzcDsgb3BpbmlvbnMgPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KUHJpeWF0b3NoIDxicj4NCkV4dDogODUxNyA8YnI+DQpNb2I6IDk4MTA0ODAyNjYg PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KOjpEaXNjbGFpbWVyOjogPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50KHMpIGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIDxicj4N CmZvciB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9ubHkuIEl0IHNoYWxsIG5vdCBhdHRhY2ggYW55 IGxpYWJpbGl0eSBvbiBDLURPVC4gPGJyPg0KQW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRl ZCBpbiB0aGlzIGVtYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciA8YnI+DQphbmQg Jm5ic3A7bWF5ICZuYnNwO25vdCAmbmJzcDtuZWNlc3NhcmlseSAmbmJzcDtyZWZsZWN0ICZuYnNw O3RoZSAmbmJzcDsgb3BpbmlvbnMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YnI+ DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NClRo aXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1c2UgYnkgb3Ro ZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoZSBt ZXNzYWdlLjxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1efe047abe674df0acf2c82406abbbc7plswe13m04adsprintcom_-- From nobody Mon Aug 14 09:20:45 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F741321ED for ; Mon, 14 Aug 2017 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NxxtNN_T8oRy for ; Mon, 14 Aug 2017 07:17:30 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 5903C132055 for ; Mon, 14 Aug 2017 07:17:30 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x191so50807778qka.5 for ; Mon, 14 Aug 2017 07:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DBtdbg51qzk3Y+9IFgWJAv4SZGTYFoHbve86GtSHqd8=; b=ajUo/03CMDJiDSjcylHE64TW56qgOicDROOGNoQ1djfGYRfJHtjUi18rnWnanoe6MP AxAiy54wGmRCW59VGm6Xabc0V1temfjcumbbFmPfGdTC2YGc/13ieABRWqXz4Sfgve26 9QecSdyi3qgmXe304BG9MGWn6sI/4ekn+ETbUcpz7seS9HAy1z1JiZK9NgFT11UuGIBE 4tlQ0pYpOXow2EMIZPvjsOas5BLnXRaBdtfW5H6gIM5Htr1Tk97NWfAC95b01zo2XuFj JZumGl72YlUlZH4qzbxIe/SJUu6g1hUZD8clMxCnYBYjo8px41vvEzJebAfApAOGo7l6 DCLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DBtdbg51qzk3Y+9IFgWJAv4SZGTYFoHbve86GtSHqd8=; b=Ag5Jh3O0y0VFEUAah4pYxl7ILkxu6cSsfT+aup8NOWGInNHq9TCZg0YFO3+MTeADoF WhRSgLnVvTEcX6/4e0XX/az7jf3bEcH2Nnl5y0u7I0NTB40cSU2rkyR92URwp6f9At2r LXqZWkgCyCUs+7dJxYDo+eulkEiNzldb/a4JJm7TLSjdqGjhxLhiOTXqS6Po5Kqs+6II bTmMJTbtdpxkJwwRDrKv+HplR36IHc8Gi2v88NL+cfvdznZucP0bW+eR0yi5QgWelMmM 4zXjfs2ZK5xfgDK5enVSiivSwDxbsOoA61LeSH6MfBeDBNwAvwl8E5DzlTJbvzoLBJQe yZbg== X-Gm-Message-State: AHYfb5hxqD5Cnia6U0UCJi9r5Ud/KyWPawyOuJi2v4BsLsB+ow7OPl7v GutsWj8SrHnMA6TwbZPMET+E4ozdhA== X-Received: by 10.55.106.67 with SMTP id f64mr30810613qkc.15.1502720249461; Mon, 14 Aug 2017 07:17:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.248 with HTTP; Mon, 14 Aug 2017 07:17:28 -0700 (PDT) Received: by 10.200.39.248 with HTTP; Mon, 14 Aug 2017 07:17:28 -0700 (PDT) In-Reply-To: <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com> References: <20170811040456.E8570B81789@rfc-editor.org> <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> <20170814110558.M60858@cdot.in> <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com> From: Priyatosh Mandal Date: Mon, 14 Aug 2017 19:47:28 +0530 Message-ID: To: "Bertz, Lyle T [CTO]" Cc: Dave Dolson , "john.loughney@nokia.com" , RFC Errata System , "glenzorn@gmail.com" , "dime@ietf.org" , "bclaise@cisco.com" , "lionel.morand@orange.com" , "jari.arkko@ericsson.com" , "warren@kumari.net" , "vf0213@gmail.com" , "jouni.nospam@gmail.com" , Priyatosh Mandal Content-Type: multipart/alternative; boundary="001a11487bc6aa83080556b7521f" Archived-At: X-Mailman-Approved-At: Mon, 14 Aug 2017 09:20:38 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 14:17:34 -0000 --001a11487bc6aa83080556b7521f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kindly note that, with the incremental change of this origin-state-id the peer node clear sessions. So when the change is from the maximum value to the minimum value of origin-state-id then it is not an incremental change. This is an exceptional situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wrote: > I believe what Dave is alluding to is that if one **does intend for the > inferences to be made** then rolling over the value to 0 is not > appropriate and a value > 0, e.g. 1, MUST be used. > > > > In a sense it is not an error as much as a note / warning for those who > are allocating that AVP in a specific manner. > > > > *From:* DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Priyatosh > Mandal > *Sent:* Monday, August 14, 2017 6:19 AM > *To:* Dave Dolson ; RFC Errata System < > rfc-editor@rfc-editor.org>; vf0213@gmail.com; jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > > > Hello Sir, > The situation is a transition from the maximum value 4294967295 of > Origin-State-Id. If after this, the value of Origin-State-Id is increased= , > it will automatically become 0. So the peer node which receives the value= 0 > after 4294967295, can assume the node which sent this 0, > faced a restart. Here the peer-node is already aware that the previous > value of origin-state-id was 4294967295. So it can easily conclude node > restart. > > I understand the meaning of 0 as explained in RFC 6733 :"If an access > device does not intend for such inferences to be made, it MUST either not > include Origin-State-Id in any message or set its value to 0". > > But this is a special case, where the value of Origin-State-Id changes fr= om 4294967295 to 0. > > > > > So kindly reconsider this. > > > > > Thanking you, > Priyatosh > > > > > *On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote* > In my opinion, the change should not be accepted. > In your roll-over special case, the device should skip over the value 0, > using 1 or some other value instead of zero. > > David Dolson > Sandvine > > > > *From: *Priyatosh Mandal > *Sent: *Monday, August 14, 2017 12:57 AM > *To: *RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com > *Cc: *dime@ietf.org > *Subject: *Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > > > Dear All, > Kindly verify this. > > Regards, > Priyatosh Mandal > > *On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote* > 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/eid5084 > > > -------------------------------------- > Type: Technical > Reported by: Priyatosh Mandal > > Section: 8.16 > > Original Text > ------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id > are no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value > to 0. > > Corrected Text > -------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id > are no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value > to 0. > As a special case when the value of Origin-State-Id changes from > 4294967295 to 0, then also the access device clear all the sessions. > > Notes > ----- > Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So th= e > maximum > value it can have is 4294967295. If the system restarts many times and th= e > value of > Origin-State-Id reaches the value which is same as its maximum value > 4294967295. > Then what will happen for the next restart. At the next restart the value > of Origin-State-Id > will be 0 if we try to increase the value of Origin-State-Id. > It is not defined in the RFC 6733, that how the system should behave afte= r > 4294967295-th > restart with respect to Origin-State-Id. > > Generally when the peer receives an increased value of Origin-State-Id, > then it clear all sessions. > If the value of Origin-State-Id reaches its maximum i.e., 4294967295, the= n > after another restart > its value will be 0. For a special case for transition of value of > Origin-State-Id from > 4294967295 to 0, the peer should clear its session. > > 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 > 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 > > Priyatosh > Ext: 8517 > Mob: 9810480266 > -------------------------------------------------------------------------= ------- > > ::Disclaimer:: > -------------------------------------------------------------------------= ------- > > The contents of this email and any attachment(s) are confidential and > intended > for the named recipient(s) only. It shall not attach any liability on > C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > > > Priyatosh > Ext: 8517 > Mob: 9810480266 > -------------------------------------------------------------------------= ------- > > ::Disclaimer:: > -------------------------------------------------------------------------= ------- > > The contents of this email and any attachment(s) are confidential and > intended > for the named recipient(s) only. It shall not attach any liability on > C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > ------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copi= es > of the message. > --001a11487bc6aa83080556b7521f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kindly note that, with the incremental change of this ori= gin-state-id the peer node clear sessions. So when the change is from the m= aximum value to the minimum value of origin-state-id then it is not an incr= emental change. This is an exceptional situation, which I feel to be part o= f rfc.=C2=A0

Regards,=C2=A0
Dr. Priyatosh Mandal, Ph. D.

=

On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com> wrote:

I believe what Dave is alluding to is= that if one *does intend for the inferences to be made* then rollin= g over the value to 0 is not appropriate and a value > 0, e.g. 1, MUST be used.

=C2=A0

In a sense it is not an error as much= as a note / warning for those who are allocating that AVP in a specific ma= nner.

=C2=A0

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal
Sent: Monday, August 14, 2017 6:19 AM
To: Dave Dolson <ddolson@sandvine.com>; RFC Errata System <rfc-editor@rfc-editor.o= rg>; vf0213@gm= ail.com; j= ari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange= .com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

=C2=A0

Hello Sir,
The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node which sent this 0,
faced a restart. Here the peer-node=C2=A0 is already aware that the previou= s value of origin-state-id was 4294967295. So it can easily conclude node r= estart.

I understand=C2=A0 the meaning of 0 as explained in RFC 6733 :"If an a= ccess device does not intend for such inferences to be made, it MUST either= not include Origin-State-Id in any message or set its value to 0". 

But this is a special case, where the value of Origin-State-Id changes=
 from=C2=A0 4294967295 to 0.



So kindly reconsider this.
=C2=A0


Thanking you,
Priyatosh




On Mon, 14 Aug 2017 10:51:25 +0000, Dav= e Dolson wrote
In my opinion, the change should not be accepted.=C2=A0
In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero.

David=C2=A0Dolson
Sandvine



From: Priyatosh Mandal
Sent: Monday, August 14, 2017 12:57 AM
To: RFC Errata System; vf0213@gmail.com; jari.arkko@eri= csson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand= @orange.com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)



Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-edit= or.org/errata/eid5084

--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal <priyatos@cdot.in>

Section: 8.16

Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.

Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.
As a special case when the value of Origin-State-Id changes from
4294967295 to 0, then also the access device =C2=A0clear all the sessions. =

Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum
value it can have is 4294967295. If the system restarts many times and the = value of
Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.
Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th
restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart
its value will be 0. For a special case for transition of value of Origin-S= tate-Id from
4294967295 to 0, the peer should clear its session.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =C2=A0
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 : Diameter Base Prot= ocol
Publication Date =C2=A0 =C2=A0: October 2012
Author(s) =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: PROPOSED STANDARD
Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Maintenan= ce and Extensions
Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Operations an= d Management
Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF
Verifying Party =C2=A0 =C2=A0 : IESG

Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions



Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
--001a11487bc6aa83080556b7521f-- From nobody Tue Aug 15 20:51:51 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859D132190 for ; Tue, 15 Aug 2017 20:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WW5SR1p8xlyJ for ; Tue, 15 Aug 2017 20:51:46 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 9487E1320CF for ; Tue, 15 Aug 2017 20:51:46 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id s6so14674053qtc.1 for ; Tue, 15 Aug 2017 20:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=V8pxDFcH21UmmkzEyiP48cbhbUcjKhGqFjrM6rPAfcA=; b=jRw8iiE0gD++xTC3hOw29wklARztgr6D+Dc9N3wwF5TetUFPEYo7uXbl3Hur9OHAPh B7UU5wSOZrHCx4RAYAhOaenYkb0cZUkAuxgY0RKn5mPH2A2ZuIBkWQr+fr39mAjYLTGd eNBRnkunuP62Hns9YYcZChFdaiyhdHmB/nF++n66YMVBHzXqPyDFRDfn+l60hfmHAtiU P0MA0yv0SNgpqEEhqQfYgEm8pmiPzekM1pxdGByRERTMjRbEWkgBnc4ezQPbd8yGvu97 C+hjowzclRGCSjayeCDv/FIpMPY4YNogB+gsL2cDvVEogKazlIa5IlklKrPZELLXjK9k /OcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=V8pxDFcH21UmmkzEyiP48cbhbUcjKhGqFjrM6rPAfcA=; b=Cta6TjF9gceg0Kpca5xfwQ/W9Swh1nX+HjyhtCvb3Y3GgrV+M8acFnQ1GbzNZisr/F x2iRR45FkTUM2Er8yT1+33iI1wK9kivrAIUm4PzgO4Mc5fSZpT5rFNtcOcg2pP8XU5iL bw6QHlVvMLVo4IUjI6SWnsZM3+v0S8/+HwtfUy3wZ0bJLTrtL+zfiCz8/c7+W/kcRBQM J/8fzchOeboj6Iv7WpHz92uvg+Qf7rEjC2G4+sBqF4bW4PgiIMb5byeHFUoK1/eIMehg ltNHVETuZD1wdmqpzGpA80CI5/IsdUv/B+t/d+h/br7FupZPLLt5TaS7cSA1GeAERQOY DIFw== X-Gm-Message-State: AHYfb5i0zF/v6BmTY4ToFFz3cM9+ZZefTPzOAX0W/zQqZb7nXoR1Flzf xBGyDzM1DC5EKyLkGCMa6zUILRbojg== X-Received: by 10.200.43.193 with SMTP id n1mr445839qtn.272.1502855505461; Tue, 15 Aug 2017 20:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.248 with HTTP; Tue, 15 Aug 2017 20:51:44 -0700 (PDT) From: Priyatosh Mandal Date: Wed, 16 Aug 2017 09:21:44 +0530 Message-ID: To: "dime@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 03:51:50 -0000 Hello , Should I consider the Reported Errata ID: 5084, as rejected. Kindly confirm. Regards, Dr. Priyatosh Mandal, Ph.D. On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that, with the incremental change of this origin-state-id the peer node clear sessions. So when the change is from the maximum value to the minimum value of origin-state-id then it is not an incremental change. This is an exceptional situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wrote: I believe what Dave is alluding to is that if one *does intend for the inferences to be made* then rolling over the value to 0 is not appropriate and avalue > 0, e.g. 1, MUST be used. In a sense it is not an error as much as a note / warning for those who are allocating that AVP in a specific manner. From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson ; RFC Errata System ; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-State-Id. If after this, the value of Origin-State-Id is increased, it will automatically become 0. So the peer node which receives the value 0 after 4294967295, can assume the node whichsent this 0, faced a restart. Here the peer-node is already aware that the previous value of origin-state-id was 4294967295. So it can easily conclude node restart. I understand the meaning of 0 as explained in RFC 6733 :"If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0".But this is a special case, where the value of Origin-State-Id changes from 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the change should not be accepted. In your roll-over special case, the device should skip over the value 0, using 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum value it can have is 4294967295. If the system restarts many times and the value of Origin-State-Id reaches the value which is same as its maximum value 4294967295. Then what will happen for the next restart. At the next restart the value of Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart its value will be 0. For a special case for transition of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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 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 Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions ----------------------------------------------------------------------- This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From nobody Tue Aug 15 22:18:09 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110C1321A5 for ; Tue, 15 Aug 2017 22:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GJjdlw9vuH3m for ; Tue, 15 Aug 2017 22:18:06 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 B06E41200C5 for ; Tue, 15 Aug 2017 22:18:05 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id y15so11618184lfd.5 for ; Tue, 15 Aug 2017 22:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=bQePpQTFZ+PQfY6k9Caw50hrY4mMVa2g2FmW0odliW0=; b=InMFKiGwRfTfm/1+S15I3NGYtlz7v9FQdZyV9jgxZ54M9r8ig5orBZDjsr4rcia0ed RRhD/YQawBIk0YjOmdWAVlTYCbB8qo5slIUwS/8EONXxR5qxdA1ACvs7GfKb5SDwF5dj TbCCXLdZvZXFcCTXYvBK78Xt2Pgj6FjAW+EH23XPFgW/IKQADOMalo/rvJiW0ymoNzW8 sUBKPjgCUJe02VIDAImUkoJCIteYkpaov0ELOPii3t4BbuU45LigxZgMBgyQD+0fIOTk wTV+XoaAXshI4EPvsfIG8kUrc5FE/w7RpEShcwPfq8w0M1AjOzjt+Gm38laLUgiIxqvd Esfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=bQePpQTFZ+PQfY6k9Caw50hrY4mMVa2g2FmW0odliW0=; b=R6LpHVGPiKaZXVa3+khWZX+OICb+/FjeX+P8OWtTQXmFZLhZ5pPkmhx4NJqaA7tWvR lOjkGG8MpiIth1tqHfMjSgVMUIngOWPQhLRpaY9KlCRjjGNQjVjHTzH3plM+/23beuVe IOjN8BVrXasiqYKn+8LrOeHvwFWz+DD56JWzTMR6R9v9Sm2iogDzYWIkgu38jOWvSnqS lxCIpkCuxICoBSXBq3Cvj1/diY3Z00SbQkIYzJ6MGmTgxu9pUjVoVxSlFr+lhmcoX4sp 46gCE8cVBPXd/WlyPCXnvRW9nlNricvfkUtlSSZKdehvx2RFaaf+7F/VDHhoe5zMDOkZ Dhyg== X-Gm-Message-State: AHYfb5hU/BDWQvySy0CUz1BYs7GFSvhSpsTRVEQVlp1ctRZ+oanPTgs5 RHC3TY4cqqvFmjNOOrE= X-Received: by 10.46.20.74 with SMTP id 10mr163179lju.11.1502860683762; Tue, 15 Aug 2017 22:18:03 -0700 (PDT) Received: from JOKO (mobile-access-5d6aed-174.dhcp.inet.fi. [93.106.237.174]) by smtp.gmail.com with ESMTPSA id f89sm4468lfb.68.2017.08.15.22.18.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 22:18:02 -0700 (PDT) From: "Jouni" To: "'Priyatosh Mandal'" , References: In-Reply-To: Date: Wed, 16 Aug 2017 08:18:01 +0300 Message-ID: <330801d3164f$08a93250$19fb96f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ0oGzN8D7T13kr+TMaG3CCsQS+CKFDXPMw Content-Language: en-us Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 05:18:09 -0000 Not until it has been officially announced by the chairs/AD etc. - Jouni > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal > Sent: Wednesday, August 16, 2017 06:52 AM > To: dime@ietf.org > Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Hello , > Should I consider the Reported Errata ID: 5084, as rejected. > > Kindly confirm. > > Regards, > Dr. Priyatosh Mandal, Ph.D. > > On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note > that, with the incremental change of this origin-state-id the peer node > clear sessions. So when the change is from the maximum value to the > minimum value of origin-state-id then it is not an incremental change. > This is an exceptional situation, which I feel to be part of rfc. > > Regards, > Dr. Priyatosh Mandal, Ph. D. > > On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" > wrote: > > I believe what Dave is alluding to is that if one *does intend for the > inferences to be made* then rolling over the value to 0 is not appropriate > and avalue > 0, e.g. 1, MUST be used. > > In a sense it is not an error as much as a note / warning for those who > are allocating that AVP in a specific manner. > > > From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal > Sent: Monday, August 14, 2017 6:19 AM > To: Dave Dolson ; RFC Errata System editor.org>; vf0213@gmail.com; jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Hello Sir, > The situation is a transition from the maximum value 4294967295 of Origin- > State-Id. If after this, the value of Origin-State-Id is increased, it > will automatically become 0. So the peer node which receives the value 0 > after 4294967295, can assume the node whichsent this 0, faced a restart. > Here the peer-node is already aware that the previous value of origin- > state-id was 4294967295. So it can easily conclude node restart. > > I understand the meaning of 0 as explained in RFC 6733 :"If an access > device does not intend for such inferences to be made, it MUST either not > include Origin-State-Id in any message or set its value to 0".But this is > a special case, where the value of Origin-State-Id changes from > 4294967295 to 0. > > So kindly reconsider > this. > > Thanking you, > Priyatosh > > On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the > change should not be accepted. > In your roll-over special case, the device should skip over the value 0, > using 1 or some other value instead of zero. > > David Dolson > Sandvine > > From: Priyatosh Mandal > Sent: Monday, August 14, 2017 12:57 AM > To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Dear All, > Kindly verify this. > > Regards, > Priyatosh Mandal > > On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 > > -------------------------------------- > Type: Technical > Reported by: Priyatosh Mandal > > Section: 8.16 > > Original Text > ------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id > are no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value to > 0. > > Corrected Text > -------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id > are no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value to > 0. > As a special case when the value of Origin-State-Id changes from > 4294967295 to 0, then also the access device clear all the sessions. > > Notes > ----- > Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the > maximum value it can have is 4294967295. If the system restarts many times > and the value of Origin-State-Id reaches the value which is same as its > maximum value 4294967295. > Then what will happen for the next restart. At the next restart the value > of Origin-State-Id will be 0 if we try to increase the value of Origin- > State-Id. > It is not defined in the RFC 6733, that how the system should behave after > 4294967295-th restart with respect to Origin-State-Id. > > Generally when the peer receives an increased value of Origin-State-Id, > then it clear all sessions. > If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then > after another restart its value will be 0. For a special case for > transition of value of Origin-State-Id from > 4294967295 to 0, the peer should clear its session. > > 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 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 > > Priyatosh > Ext: 8517 > Mob: 9810480266 > -------------------------------------------------------------------------- > ------ > ::Disclaimer:: > -------------------------------------------------------------------------- > ------ > The contents of this email and any attachment(s) are confidential and > intended for the named recipient(s) only. It shall not attach any > liability on C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > Priyatosh > Ext: 8517 > Mob: 9810480266 > -------------------------------------------------------------------------- > ------ > ::Disclaimer:: > -------------------------------------------------------------------------- > ------ > The contents of this email and any attachment(s) are confidential and > intended for the named recipient(s) only. It shall not attach any > liability on C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > ----------------------------------------------------------------------- > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all > copies of the message. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Aug 15 22:19:48 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428C41321A5 for ; Tue, 15 Aug 2017 22:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Mq-Gi6DsL0Fo for ; Tue, 15 Aug 2017 22:19:44 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7104E1200C5 for ; Tue, 15 Aug 2017 22:19:44 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 01:19:42 -0400 From: Yuval Lifshitz To: Priyatosh Mandal , "dime@ietf.org" Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTFkMB1LNI3UJIyUO+j8zPQ+evOaKGcRKQ Date: Wed, 16 Aug 2017 05:19:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 05:19:47 -0000 Don't think it should be rejected. Even if the implementation rollover 4M t= o 1 (and not to zero) there is still an issue of the fact that the origin-s= tate-id is not incremented. IMO, it should be addressed in the spec. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal Sent: Wednesday, August 16, 2017 6:52 AM To: dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello , Should I consider the Reported Errata ID: 5084, as rejected. Kindly confirm. Regards, Dr. Priyatosh Mandal, Ph.D. On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that= , with the incremental change of this origin-state-id the peer node clear s= essions. So when the change is from the maximum value to the minimum value = of origin-state-id then it is not an incremental change. This is an excepti= onal situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wr= ote: I believe what Dave is alluding to is that if one *does intend for the infe= rences to be made* then rolling over the value to 0 is not appropriate and = avalue > 0, e.g. 1, MUST be used. In a sense it is not an error as much as a note / warning for those who are= allocating that AVP in a specific manner. From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson ; RFC Errata System ; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.= com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam= @gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node whichsent this 0, faced a restart. Here the = peer-node is already aware that the previous value of origin-state-id was = 4294967295. So it can easily conclude node restart. I understand the meaning of 0 as explained in RFC 6733 :"If an access devi= ce does not intend for such inferences to be made, it MUST either not inclu= de Origin-State-Id in any message or set its value to 0".But this is a spec= ial case, where the value of Origin-State-Id changes from 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the ch= ange should not be accepted. In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The follo= wing errata report has been submitted for RFC6733, "Diameter Base Protocol"= . -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times = and the value of Origin-State-Id reaches the value which is same as its max= imum value 4294967295. Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State= -Id. It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transitio= n of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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 can log in to change the status and ed= it 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 Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions ----------------------------------------------------------------------- This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Aug 16 05:39:58 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7A913201E for ; Wed, 16 Aug 2017 05:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lS4FimOkt-5J for ; Wed, 16 Aug 2017 05:39:53 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454F112700F for ; Wed, 16 Aug 2017 05:39:53 -0700 (PDT) Received: from SN1PR05CA0003.namprd05.prod.outlook.com (10.163.68.141) by BLUPR0501MB2148.namprd05.prod.outlook.com (10.164.23.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.12; Wed, 16 Aug 2017 12:39:51 +0000 Received: from SN1NAM01FT012.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::209) by SN1PR05CA0003.outlook.office365.com (2a01:111:e400:5197::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.12 via Frontend Transport; Wed, 16 Aug 2017 12:39:51 +0000 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by SN1NAM01FT012.mail.protection.outlook.com (10.152.64.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1304.16 via Frontend Transport; Wed, 16 Aug 2017 12:39:51 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v7GC2P3p015463; Wed, 16 Aug 2017 07:39:50 -0500 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by plsapdm3.corp.sprint.com with ESMTP id 2c9xx9vhhn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Aug 2017 07:39:50 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 16 Aug 2017 07:39:49 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1293.002; Wed, 16 Aug 2017 07:39:49 -0500 From: "Bertz, Lyle T [CTO]" To: Yuval Lifshitz , Priyatosh Mandal , "dime@ietf.org" Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTFk9KP+Egj7Sx3Eqd5N6HAiQLp6KG7KTQ Date: Wed, 16 Aug 2017 12:39:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.39; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(438002)(377454003)(24454002)(13464003)(199003)(189002)(108616004)(189998001)(2900100001)(46406003)(2950100002)(23726003)(229853002)(2501003)(47776003)(86362001)(575784001)(6116002)(102836003)(478600001)(24736003)(97736004)(3846002)(2906002)(45080400002)(97756001)(106466001)(6246003)(966005)(53546010)(7696004)(53936002)(5660300001)(33646002)(305945005)(626005)(54356999)(81156014)(81166006)(68736007)(50466002)(8936002)(5890100001)(50986999)(76176999)(5250100002)(356003)(39060400002)(6306002)(8676002)(7736002)(8746002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2148; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT012; 1:oxXo4N5xtdLwRcCHGgoQY2gyzyxdthw4RScNdEN+sRVD753CKdsqdjzw518YYSDgG6miSeXYi9SyYRrkpJCcNsgNFTBARL6bUZ064v6xuf0cnYxxApX/TXnBGxFzaaEiBgqcNDRDIVDdM91iuxzFM1ZbdOY9JVvGMq/cMrR0Vize/3VFKEqE5C1YrBnaGr76FNc5DXwHfJVwaF73DFJgvIguNQw4RhUP4Besq4b5waSOrUvIip0JFeDAHr++Va+BGnRfrsq2AKoD3bETO0D/R0ERoZJXlA9wzpVYe7bx5NYB8LnNp557IlmJXjkTlgf5UNPhDJyehT1aFRg6W3CJjvSozEAD6fy5yew6S+jS/o1NvBlF7IUcaiVrUoaPjq365jY93jrZ8ynGz1JLU06WFBAxGvbezu7SxuatMwRqmAPjCEFwO4f7vqBFwsJpF9vaYw5/ubT5Adoz9YdLSDQn3vMT3HlrYFmX8K7oZoyNSbrEN7EKwMGjrAYqZR1kCdS2msd27S0SG/KLZpc+CTD6ozFnP8J1zoUjVZUCTM1HLrMX9okl+FERfnGOwao8HoFuUK5Amcl5qqOb/BqVZBxPgMcZaGd9lfNznJ1yIEQagIqj2DYcoxiTBVcObgw+tYbtgLOIoydM3po8QdgXFOXdj9NzcaRnW2h6zix9sjGEWQZz1e6U+246vwfUCCDdw7ReBZvDXHTGUdLH0Uidj5U2Cb0jteRelmiv2TGhIK+jlmigeez2/Wbz0lAYPrt4AVcQ6PPTfm/SGYGbc2caVqWsZ67WbBIPp7xhjDzDavbmrJsVQMiCwm97fd6NRQOhGuQRnRk7MZbjppv/GTL9m5jWig== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 22226e90-e05b-4985-ce30-08d4e4a3e389 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(8251501002)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB2148; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2148; 3:X/OYsdO1KuLbIdEh5/Zyik/NL9fK2560FBGWA2Hwt391eiEINvN9zTckRsSN/8tmWBaavDamUjBKk5jSmfWX/m/ECymQfA8tI2+G7zTUxtVyOtdi5JIN/PcFLlm6DkW5hac8gjIaEffbEglt76XUq3kceuOZgqxER0jMWfDZ/s4NXRCjL1hzDuDOZ1q8ve1DHsmBFhXtWOeb+ldsaMnFZVf7LozmjoyEEaTgVY6hjv1BRj1CGCOn/6bh9AMk8rj5UbM4Gp+BDV2hjItw227+M3zljAnMKsfXbLxsKRObltIbw4wUR8UJlMTHVKN0Q/dCio30bbeR2gObwC4nfYrC/qZy7BbtxFpzHcLa4WuWI/k=; 25:Vf46UmAWK/fxr6UXrP4z/Uad78+j7QQtr5WdAiX/OjaXmnXwZhsa5Yj6wrSc/mkj7ZeNgWG+asEbQFF70JEQnL2tfMmGp7tji3V2h2h89FLeS6prF6gn142j19/OMLFuBrzJXpD+DHJWGHIWLjeNiwx13YKge9DfceO4Z+O2QnBSyroxcOc+n8YXqSRoY5N+ueBY2j+eKiBmwunHjMh5ssEdZqQmIRphTswQsjizrSZt08Q0g3DIGpPMnhrzkLTl5ApO1kLpSvU7Dl4LKYZnRkCY/d7OKTZLWgjsASlHWEUF0VlCOwe4aDdvQhQvcA2kb8rTrtHTz0P+VmZrULusYw== X-MS-TrafficTypeDiagnostic: BLUPR0501MB2148: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2148; 31:hHTfOSzv8AqO70Tf3uMrF/dsFkxqdeXNm9KVRoxGwz8AaSLBz/o59quGNkLEw+d6bMUNeoxGMPc9GYjHgHSmQQmA6K0XAqjc+CNXmjo6PMFqgRrV0MYCoviLFdRKnNoKMDtoXRF8LztUKSAN8GJvxAgb5t2joW2yr0DFBDixtHwX7Cum6xXlcRDvfFNNuqObo09MijJbk4TfGZqE5OBBn49NiJfrapubRMp4GLtwu0A=; 20:c/zd5Z6ocrMmgQIrYpnZYVxjVzQr7LTDdoTP3daTGW6LTPCXGLCtNKAfYu26zxBBUeyzXTImOHkh/zdK7i41MPqH6QzpLkXbhzyrpXKNgOp7BJhq9Yppj3ERyzRilWMQtoV5zTs1IzQn3mrBWUqXVKU16OhhUxj7dCxTu03y3pzKGDZiL/Q84CF+3y+/MXsP+8yo+ADjv1Zwl9SOa5hwItuGvGc4Xg/Yceq5Xjpw2T06KOJZPChlKDfxzaTTP0/cxT87/1Z3HYgddhV3KW68sHrsdnXp6Cif/BORo7w7cwFr9kcjDCu7UualowhB5j1FJci4Vbqi+SnyPOQwp07tyIvXJ74NOgm3TTLaq+LMXdiVgp1izViClhXEmI5JDYuys2HxlVOD0CsHUuenqh4C3nvhfR9yOD2+9nBIoyDTl0vFFKqUxHBhXQ9ZNhw9LH4v7JCge8PoNHkvb+GqjakQTJpWNIN/XOz4QoUM65ewPTZORgm/R+jTVkvKfhtMqMrR X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(18430343700868)(189930954265078)(82608151540597)(95692535739014)(18271650672692)(219752817060721); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13018025)(13016025)(8121501046)(93006095)(93004095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB2148; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB2148; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2148; 4:dtbepiwEbXkE87J3q9dXcu/xwJ0KbgAhogZ/FDbQE28vleAyyxWeBVqwaxBDw6mX1mdWHiiyprHfqMeiXzEkGPh2dJ3CcKJn4QWJUi/NrFtbyJRfTRSHxSHg8ojNzH0xIO2Juh4sPGySWn8Irn7gzQidAbTplh0xuEFfOsbiyNwmhX+O6xRuFVGiA7zCJe91oEU+agEpDHjUNpoESBp8oDuR3Z1iRsKApANXzoVHsJil4Htrh34j6VB0jWFCmwDBgKV2/avrMT7TNlQYbIrMZzQcQgtmVNMPP05v4XGN7TwUvEOWIaP3Hgvui4+m2t8B28QAvT8MGNRa89mxXuAPOSz0x9G1zwxvqRg57QbNwl2K9MCgK1vKqJA7DTGVS/T9eYtJmRb2ADw4IE0yfwWoVecwmlckG7t9+/9xASnomLd5v6+7xOw6WnzNJ83sne3Zf80HWDTY3YJalYqByHw4pKzgteF2NvEV0ofqUGKcLkXEWpb4X3DKTNPMSYR3gqGt X-Forefront-PRVS: 0401647B7F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB2148; 23:3NLOGSQimY7cI4kKT8LuXlLEir920NrYMWcJcoD?= =?us-ascii?Q?5rSz2gOHAxtNcNTYgKQYdlFGijRXJIsvyvjVsgNclRvQprQrGA9pSqswkGhc?= =?us-ascii?Q?zBE5lLA25ob+RIitucF5ZD+YjpFWwGH1RwzRbcEB6OKY1//Af3Fn213j6eCd?= =?us-ascii?Q?2/9mP2g0Lj0yWX9KTDKUpVHCdUkLdy0W1SOFeH3ag4JVjHbI8Hx7Z4fEbomJ?= =?us-ascii?Q?aIti4e+F49POzjQPdD2/rCjE6GW6JMD4yE72XooacTs0SxMCysEr46Ped+EM?= =?us-ascii?Q?Fvnb8HNXwzka0S5gnmIpIJvygYl2CEO8WYQO/TsD9+RBETo8nhm3yWILYdxf?= =?us-ascii?Q?CmC/Pudc+SKV5Wzh1jTJwv6sYlz9go80uxdHp3YeXJRWE+BP43DtEnvzLEVx?= =?us-ascii?Q?EvYbdBK+/O5JyU93Bw0evGhpwaBsOpQ3FlqRtuMQi1vwnQTHj7XEbqO1DBZr?= =?us-ascii?Q?ZnenFYuOqlfxRycPWKLrniqhS9MmHgnCaIrVG2ktrNDwMzYmtpwfD1s9wmzb?= =?us-ascii?Q?AeweFOqhR3+tM/9IUXJKR3dLjgAuJu6JIX7uCHxx8bL6WoittUjd6gwyESQ0?= =?us-ascii?Q?Ru4nMlZhPVHwb3isp5cSRyvkKR0RrLjAiMO3K+oQNL5aUt8GJFmHn3CMUCzi?= =?us-ascii?Q?iT+MgXwoDxSSSrc22p5BJAcC6p4wSVKpNNLAMT0XQo4abWdr3hRZU6bRilat?= =?us-ascii?Q?d7EmfC9/cInkuX6+eS37fQtbFKMfYRPbo6+LOjsmzxbS08mrS7WdblCkGJne?= =?us-ascii?Q?vwohglwfweFbvFygVem4qlT3ZXtsuhwpePwh25hoZ7CsCSJWvfKgNLESIC08?= =?us-ascii?Q?oyPMknDHldLaSAJ/xkQlJmLvl9+AicyAcuUilW1TOed1TYLiK269Mq4sJeUv?= =?us-ascii?Q?Ud8yv5944xkNDSINb815Kb+OLQRn6cByX6fwsb+wJYizHiPps7oHKrHppaKp?= =?us-ascii?Q?dVM5k3kRcEhkFJ3H5WjAQui57CX1HtRB7el8CvgYVFF1IN9TevJDUxmKZLa4?= =?us-ascii?Q?JQ0rRAyjlvYu/JEqEVsp+dYmIUe+gKf3Ic2Al00yYK+7OdOFjz6XuiVo2QTs?= =?us-ascii?Q?PdUYPbN9zB89K/dYZ9/a505ubBT3mO8ysY7TcUJpXSolIDSX3dr5WSHbnJDE?= =?us-ascii?Q?JocI5T3u7d589PwfFAWJu4mx0psOFLOzcP7vRL+i+3rXsLXl5k0fzbl6wjuc?= =?us-ascii?Q?D2MmqGLwOFe0WKZlpxN7GVtfM1RyKY31/dTBuWaR1yLZJ3RGNYDyUdIh9aUU?= =?us-ascii?Q?yg7WEFLrfxcXPH1pk7KqjaDDVSeQGAxMk0xV0/veh8FeqU4Qw0RftZiUgdNe?= =?us-ascii?Q?t+RFiv1bfEeVuPS40RGJlOSQyN2/KeJaMvMDxOGTvIda7?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2148; 6:dcEX4AVhxGNaAkr6oVt1hhI4/7tFhonc5KHhl8yLtkf8FwzZElAykpx1e3d9itE2Tum8ZZQnLEVmFiiq2Zgu/gf+HiL/VTLFcsYRiJqYHpFgfz3yBpM/vZS9knsgCNAbJ/THGfpP8FybZq+3xwJ4l9UUEtNjlc75DQtpVSLlDUoJcqMzLOWhoUCAi1ZtSwykj9/twvPOjbOhWJkc92/smEbO5409aO1ktJ+OhXkRB9eZ1R7fj3M7f6w21XLKYOasKcSX1IDBhvFOTd5/Gz0jd/7gm2xhd7YnHfEKm5WqwQt+u0nD5RoLVrT5TOomoEdX5DvkFBbm8P7evkbiou5Nbg==; 5:ziRnIuhoswUyXOUX1OMBzY/nXLmHl5hbPmeodfe8x/HZmHddvo3hrEniyGApbM0mQjmxACrPd/PNocHmfdjSGRw9/ERjWYbTVJT8e7kwyWXIajKEZSV6JFVyMqxbQKU4XqwFlT/16O7GsfbVykVU1w==; 24:RaYYPzLABzIVLYz97Jpw5piTLykNN5f5VdcA6KZ1q4ctFauWTk60oEQyfO+DWSQgXyHlfXzWDXSFmClihgLAig3TqdjGtVjkbI2o54Q9wNA=; 7:Of5DwjwPV7Lg2Dt2g18bqYmguvH4uBhv4bNi60WydlHoMo877dZ12hzaJx9HIGQya3kYhlx7h5F6VSe+A/a+JH75m30l0G8xmny3I/9IxMxni9ejYinIwpxKHjIsuUgOPlETk5NIZHaxpXca6YwpZGYw/6oFYlPJGgRuLllMFzYk4JsY8UdHcXn6uTvTp62ODqUM/6S8yDg+E3VM19s9/zWas3F6TIzphB0dSYSihro= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2017 12:39:51.2468 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2148 Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 12:39:57 -0000 However, the spec is not wrong as much as there is no warning to ensure the= reader is aware of the situation. =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, August 16, 2017 12:20 AM To: Priyatosh Mandal ; dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Don't think it should be rejected. Even if the implementation rollover 4M t= o 1 (and not to zero) there is still an issue of the fact that the origin-s= tate-id is not incremented. IMO, it should be addressed in the spec. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal Sent: Wednesday, August 16, 2017 6:52 AM To: dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello , Should I consider the Reported Errata ID: 5084, as rejected. Kindly confirm. Regards, Dr. Priyatosh Mandal, Ph.D. On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that= , with the incremental change of this origin-state-id the peer node clear s= essions. So when the change is from the maximum value to the minimum value = of origin-state-id then it is not an incremental change. This is an excepti= onal situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wr= ote: I believe what Dave is alluding to is that if one *does intend for the infe= rences to be made* then rolling over the value to 0 is not appropriate and = avalue > 0, e.g. 1, MUST be used. In a sense it is not an error as much as a note / warning for those who are= allocating that AVP in a specific manner. From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson ; RFC Errata System ; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.= com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam= @gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node whichsent this 0, faced a restart. Here the = peer-node is already aware that the previous value of origin-state-id was = 4294967295. So it can easily conclude node restart. I understand the meaning of 0 as explained in RFC 6733 :"If an access devi= ce does not intend for such inferences to be made, it MUST either not inclu= de Origin-State-Id in any message or set its value to 0".But this is a spec= ial case, where the value of Origin-State-Id changes from 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the ch= ange should not be accepted. In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The follo= wing errata report has been submitted for RFC6733, "Diameter Base Protocol"= . -------------------------------------- You may review the report below and at: https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.rfc-e= ditor.org%2Ferrata%2Feid5084&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2= 2cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%= 7C636384575908897376&sdata=3DEITh8Z6bWAwU9pur6Zrospr9D%2Fd2UgKe%2BTBrmkh%2B= DzA%3D&reserved=3D0 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times = and the value of Origin-State-Id reaches the value which is same as its max= imum value 4294967295. Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State= -Id. It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transitio= n of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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 can log in to change the status and ed= it 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 Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions ----------------------------------------------------------------------- This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ DiME mailing list DiME@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.com= %7C22cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%= 7C0%7C636384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGwWDQUFCQ= u%2BqKTNJxg%3D&reserved=3D0 _______________________________________________ DiME mailing list DiME@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.com= %7C22cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%= 7C0%7C636384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGwWDQUFCQ= u%2BqKTNJxg%3D&reserved=3D0 From nobody Wed Aug 16 07:25:42 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806CC132195 for ; Wed, 16 Aug 2017 07:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LAYBccRPN6Ok for ; Wed, 16 Aug 2017 07:25:37 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F6A1321AE for ; Wed, 16 Aug 2017 07:25:37 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 10:25:35 -0400 From: Yuval Lifshitz To: "Bertz, Lyle T [CTO]" , Priyatosh Mandal , "dime@ietf.org" Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTFozFFiwznYlzkkG/tEqEsW/3D6KHCU4w Date: Wed, 16 Aug 2017 14:25:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 14:25:40 -0000 Not sure if errata is meant to capture "clarifications", but should probabl= y be captured somewhere so it could be added to a future version. -----Original Message----- From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]=20 Sent: Wednesday, August 16, 2017 3:40 PM To: Yuval Lifshitz; Priyatosh Mandal; dime@ietf.org Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084) However, the spec is not wrong as much as there is no warning to ensure the= reader is aware of the situation. =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, August 16, 2017 12:20 AM To: Priyatosh Mandal ; dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Don't think it should be rejected. Even if the implementation rollover 4M t= o 1 (and not to zero) there is still an issue of the fact that the origin-s= tate-id is not incremented. IMO, it should be addressed in the spec. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal Sent: Wednesday, August 16, 2017 6:52 AM To: dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello , Should I consider the Reported Errata ID: 5084, as rejected. Kindly confirm. Regards, Dr. Priyatosh Mandal, Ph.D. On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that= , with the incremental change of this origin-state-id the peer node clear s= essions. So when the change is from the maximum value to the minimum value = of origin-state-id then it is not an incremental change. This is an excepti= onal situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wr= ote: I believe what Dave is alluding to is that if one *does intend for the infe= rences to be made* then rolling over the value to 0 is not appropriate and = avalue > 0, e.g. 1, MUST be used. In a sense it is not an error as much as a note / warning for those who are= allocating that AVP in a specific manner. From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson ; RFC Errata System ; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.= com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam= @gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node whichsent this 0, faced a restart. Here the = peer-node is already aware that the previous value of origin-state-id was = 4294967295. So it can easily conclude node restart. I understand the meaning of 0 as explained in RFC 6733 :"If an access devi= ce does not intend for such inferences to be made, it MUST either not inclu= de Origin-State-Id in any message or set its value to 0".But this is a spec= ial case, where the value of Origin-State-Id changes from 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the ch= ange should not be accepted. In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The follo= wing errata report has been submitted for RFC6733, "Diameter Base Protocol"= . -------------------------------------- You may review the report below and at: https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fwww.rfc-e= ditor.org%2Ferrata%2Feid5084&data=3D02%7C01%7Clyle.t.bertz%40sprint.com%7C2= 2cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%= 7C636384575908897376&sdata=3DEITh8Z6bWAwU9pur6Zrospr9D%2Fd2UgKe%2BTBrmkh%2B= DzA%3D&reserved=3D0 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active. If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times = and the value of Origin-State-Id reaches the value which is same as its max= imum value 4294967295. Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State= -Id. It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transitio= n of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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 can log in to change the status and ed= it 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 Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT. Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions ----------------------------------------------------------------------- This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ DiME mailing list DiME@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.com= %7C22cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%= 7C0%7C636384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGwWDQUFCQ= u%2BqKTNJxg%3D&reserved=3D0 _______________________________________________ DiME mailing list DiME@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdime&data=3D02%7C01%7Clyle.t.bertz%40sprint.com= %7C22cd07b0b7174d6fdc7608d4e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%= 7C0%7C636384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGwWDQUFCQ= u%2BqKTNJxg%3D&reserved=3D0 From nobody Wed Aug 16 08:23:45 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23AB132491 for ; Tue, 15 Aug 2017 20:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_SPF_HELO_TEMPERROR=0.01] autolearn=no autolearn_force=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 ITISDnQPCfFt for ; Tue, 15 Aug 2017 20:39:57 -0700 (PDT) Received: from sandesh.cdotd.ernet.in (unknown [196.1.105.47]) by ietfa.amsl.com (Postfix) with SMTP id 86A6E13248F for ; Tue, 15 Aug 2017 20:39:53 -0700 (PDT) Received: from mail.cdot.in (webmail.cdotd.ernet.in [196.1.105.198]) by sandesh.cdotd.ernet.in (Postfix) with ESMTP id A5A201DDE0BC; Wed, 16 Aug 2017 09:08:56 +0530 (IST) Received: from cdot.in (localhost [127.0.0.1]) by mail.cdot.in (8.14.7/8.13.8) with ESMTP id v7G3cuaX134931; Wed, 16 Aug 2017 09:08:56 +0530 From: "Priyatosh Mandal" To: "dime@ietf.org" Date: Wed, 16 Aug 2017 09:08:56 +0530 Message-Id: <20170816033715.M45010@cdot.in> In-Reply-To: References: <20170811040456.E8570B81789@rfc-editor.org> <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> <20170814110558.M60858@cdot.in> <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com> X-Mailer: OpenWebMail 2.54 X-OriginatingIP: 196.1.110.232 (priyatos) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.326737289640249" Archived-At: X-Mailman-Approved-At: Wed, 16 Aug 2017 08:23:44 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 03:40:04 -0000 This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.326737289640249 Content-Type: text/plain; charset=utf-8 Hello , Should I consider the Reported Errata ID: 5084, as rejected. Kindly confirm. Regards, Dr. Priyatosh Mandal, Ph.D. On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that, with the incremental change of this origin-state-id the peer node clear sessions. So when the change is from the maximum value to the minimum value of origin-state-id then it is not an incremental change. This is an exceptional situation, which I feel to be part of rfc.  Regards,  Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" wrote: I believe what Dave is alluding to is that if one *does intend for the inferences to be made* then rolling over the value to 0 is not appropriate and avalue > 0, e.g. 1, MUST be used.   In a sense it is not an error as much as a note / warning for those who are allocating that AVP in a specific manner.   From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson ; RFC Errata System ; vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)   Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-State-Id. If after this, the value of Origin-State-Id is increased, it will automatically become 0. So the peer node which receives the value 0 after 4294967295, can assume the node whichsent this 0, faced a restart. Here the peer-node  is already aware that the previous value of origin-state-id was 4294967295. So it can easily conclude node restart. I understand  the meaning of 0 as explained in RFC 6733 :"If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0".But this is a special case, where the value of Origin-State-Id changes from  4294967295 to 0. So kindly reconsider this.  Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the change should not be accepted.  In your roll-over special case, the device should skip over the value 0, using 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device  clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the maximum value it can have is 4294967295. If the system restarts many times and the value of Origin-State-Id reaches the value which is same as its maximum value 4294967295. Then what will happen for the next restart. At the next restart the value of Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, then it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then after another restart its value will be 0. For a special case for transition of value of Origin-State-Id from 4294967295 to 0, the peer should clear its session. 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   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 Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the   opinions Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the   opinions ----------------------------------------------------------------------- This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. Priyatosh Ext: 8517 Mob: 9810480266 -------------------------------------------------------------------------------- ::Disclaimer:: -------------------------------------------------------------------------------- The contents of this email and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on C-DOT. Any views or opinions presented in this email are solely those of the author and  may  not  necessarily  reflect  the  opinions ------=OPENWEBMAIL_ATT_0.326737289640249 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ,
Should I consider the Reported Errata ID: 5084, as rejected.

Kindly confirm.

Regards,
Dr. Priyatosh Mandal, Ph.D. =



On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote
Kindly note=20 that, with the incremental change of this origin-state-id the peer node cle= ar=20 sessions. So when the change is from the maximum value to the minimum value= of=20 origin-state-id then it is not an incremental change. This is an exceptiona= l=20 situation, which I feel to be part of rfc.=C2=A0
=20
Regards,=C2=A0
Dr.=20 Priyatosh Mandal, Ph. D.
=20
On Aug 14, 2017 6:32 PM, "Bertz, Lyle T=20 [CTO]" <Lyle.T.Bertz@spr= int.com> wrote:

=20
I=20 believe what Dave is alluding to is that if one *does intend for the=20 inferences to be made* then rolling over the value to 0 is not appropri= ate=20 and=20 a value > 0, e.g. 1, MUST be used.=20
=C2=A0
In=20 a sense it is not an error as much as a note / warning for those who are=20 allocating that AVP in a specific=20 manner.
=C2=A0
=20
From: DiME=20 [mailto:dime-bou= nces@ietf.org] On Behalf Of Priyatosh Mandal
=20 Sent: Monday, August 14, 2017 6:19 AM
=20 To: Dave Dolson <ddolson@sandvine.com>; RFC Errata System <rfc-editor@rfc-editor.org= >; vf0213@gmai= l.com; jar= i.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.c= om
=20 Cc: dime@ietf.org=
=20 Subject: Re: [Dime] [Technical Errata Reported] RFC6733=20 (5084)
=20 =C2=A0
Hello Sir,=20
=20 The situation is a transition from the maximum value 4294967295 of=20 Origin-State-Id. If after this, the value of Origin-State-Id is increased, = it=20 will automatically become 0. So the peer node which receives the value 0 af= ter=20 4294967295, can assume the node=20 which sent this 0,=20
=20 faced a restart. Here the peer-node=C2=A0 is already aware that the previou= s value=20 of origin-state-id was 4294967295. So it can easily conclude node=20 restart.
=20
=20 I understand=C2=A0 the meaning of 0 as explained in RFC 6733 :"If an a= ccess=20 device does not intend for such inferences to be made, it MUST either not=20 include Origin-State-Id in any message or set its value to=20 0". 
But this is a special case, where the value of Origin-State-Id changes=
=20
from=C2=A0 4294967295 to=20
0.

=20

=20


 So kindly reconsider=20
this.
=C2=A0

=20
=20 Thanking you,=20
=20 Priyatosh=20
=20
=20 On Mon, 14 Aug 2017 10:51:25 +0000, Dav= e=20 Dolson wrote
=20 In my opinion, the change should not be accepted.=C2=A0=20
=20 In your roll-over special case, the device should skip over the value 0, us= ing 1=20 or some other value instead of=20 zero.
=20
=20 David=C2=A0Dolson=20
=20 Sandvine=20

=20
=20 From: Priyatosh Mandal=20
=20 Sent: Monday, August 14, 2017 12:57 AM=20
=20 To: RFC Errata System; vf0213@gmail.com; jari.arkko@eri= csson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand= @orange.com=20
=20 Cc: dime@ietf.org= =20
=20 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)=20


=20
=20 Dear All,=20
=20 Kindly verify this.=20
=20
=20 Regards,=20
=20 Priyatosh Mandal=20
=20
=20 On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote=20
=20 The following errata report has been submitted for RFC6733,=20
=20 "Diameter Base Protocol".=20
=20
=20 --------------------------------------=20
=20 You may review the report below and at:=20
=20 http://www.rfc-editor.org/errata/eid5084
=20
=20 --------------------------------------=20
=20 Type: Technical=20
=20 Reported by: Priyatosh Mandal <priyatos@cdot.in>
=20
=20 Section: 8.16=20
=20
=20 Original Text=20
=20 -------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20
=20 MUST either not include Origin-State-Id in any message or set its value=20
=20 to 0.=20
=20
=20 Corrected Text=20
=20 --------------=20
=20 By including Origin-State-Id in a message, it allows other Diameter=20
=20 entities to infer that sessions associated with a lower Origin-State-Id=20
=20 are no longer active.=20
=20 If an access device does not intend for such inferences to be made, it=20
=20 MUST either not include Origin-State-Id in any message or set its value=20
=20 to 0.=20
=20 As a special case when the value of Origin-State-Id changes from=20
=20 4294967295 to 0, then also the access device =C2=A0clear all the sessions.= =20
=20
=20 Notes=20
=20 -----=20
=20 Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the= =20 maximum
=20 value it can have is 4294967295. If the system restarts many times and the = value=20 of
=20 Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.=20
=20 Then what will happen for the next restart. At the next restart the value o= f=20 Origin-State-Id
=20 will be 0 if we try to increase the value of Origin-State-Id.=20
=20 It is not defined in the RFC 6733, that how the system should behave after= =20 4294967295-th
=20 restart with respect to Origin-State-Id.=20
=20
=20 Generally when the peer receives an increased value of Origin-State-Id, the= n it=20 clear all=20 sessions.
=20 If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after=20 another=20 restart
=20 its value will be 0. For a special case for transition of value of=20 Origin-State-Id=20 from
=20 4294967295 to 0, the peer should clear its session.=20
=20
=20 Instructions:=20
=20 -------------=20
=20 This erratum is currently posted as "Reported". If necessary, ple= ase=20
=20 use "Reply All" to discuss whether it should be verified or=20
=20 rejected. When a decision is reached, the verifying party =C2=A0=20
=20 can log in to change the status and edit the report, if necessary.=20
=20
=20 --------------------------------------=20
=20 RFC6733 (draft-ietf-dime-rfc3588bis-33)=20
=20 --------------------------------------=20
=20 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Diameter Base Prot= ocol=20
=20 Publication Date =C2=A0 =C2=A0: October 2012=20
=20 Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : V. Fajardo, Ed., J. Arkko, J= . Loughney, G. Zorn, Ed.=20
=20 Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: PROPOSED STANDARD=20
=20 Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Maintenan= ce and Extensions=20
=20 Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Operations an= d Management=20
=20 Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF=20
=20 Verifying Party =C2=A0 =C2=A0 : IESG=20
=20
=20 Priyatosh=20
=20 Ext: 8517=20
=20 Mob: 9810480266=20
=20 -------------------------------------------------------------= -------------------=20
=20 ::Disclaimer::=20
=20 -------------------------------------------------------------= -------------------=20
=20 The contents of this email and any attachment(s) are confidential and inten= ded=20
=20 for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20
=20 Any views or opinions presented in this email are solely those of the autho= r=20
=20 and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions=20
=20
=20 Priyatosh=20
=20 Ext: 8517=20
=20 Mob: 9810480266=20
=20 -------------------------------------------------------------= -------------------=20
=20 ::Disclaimer::=20
=20 -------------------------------------------------------------= -------------------=20
=20 The contents of this email and any attachment(s) are confidential and inten= ded=20
=20 for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20
=20 Any views or opinions presented in this email are solely those of the autho= r=20
=20 and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions=20
=20

=20 This e-mail may contain Sprint proprietary information intended for the sol= e use=20 of the recipient(s). Any use by others is prohibited. If you are not the=20 intended recipient, please contact the sender and delete all copies of the= =20 message.
=20



Priyatosh=20
Ext: 8517=20
Mob: 9810480266=20
---------------------------------------------------------------------------= -----=20
::Disclaimer::=20=20
---------------------------------------------------------------------------= -----=20 =20
The contents of this email and any attachment(s) are confidential and inten= ded=20
for the named recipient(s) only. It shall not attach any liability on C-DOT= .=20=20
Any views or opinions presented in this email are solely those of the autho= r=20=20
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 opinions
------=OPENWEBMAIL_ATT_0.326737289640249-- From nobody Wed Aug 16 09:30:55 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CEA1320BE for ; Wed, 16 Aug 2017 09:30:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0iXg5ozUZfMd for ; Wed, 16 Aug 2017 09:30:49 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 512DF132630 for ; Wed, 16 Aug 2017 09:30:49 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id v29so23806081qtv.3 for ; Wed, 16 Aug 2017 09:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UYuBxkocmn73C9+iZ0ngDu6x1Li0nrOOvnYZNpwZ+jI=; b=D9dFnkrlHKLVw/35Y8/a9fxsJaSiBOfQr5Bsy1P9mCE4mdQsc2pOMx/rr51WO/uwJH ceD/oMjnQ3/B2GXM1vcQV657sfpfvIKXxbLxurDnR8SP84wNOUnhFzJRo42dUTn/Id0v WMooHwT6Y8T2I+dskQ2Nwf7NkUrm/P63F0Lnwb9ozPgcq9J8THcH2Mdt825/B+Fw2r6c 74gehkY/pwIfqpmsS+jfwb7M7YuZvkrAWrXTlwqjS/5VYNxVALsS2y65OsijcELdJLJl NLvQUUo8v/Q1PXhI6YYSn5Z8rxDllOb6RNmCDWL5Kf9awqZ5FX8pYMGeL9T/d1HoYJuQ TdNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UYuBxkocmn73C9+iZ0ngDu6x1Li0nrOOvnYZNpwZ+jI=; b=JjV+8Uu5NsuIwYOLQTdRQTjJPE+2DVohRy1zt/izVi3ZYijk1PotMcBM2BPEAtBnXb zKKYxtjJ4z6sa/qvE7izd96qBB7AQxAdEvrQw7HHucXkgFDakkK+31jd40FCLZFPoYwT KtOHrouipp66oE3WFFoB/0rxD3MKrGycdXur/dJcDRkv982Ral8p70FYLRHubwgVt88X I1DcLUQeO54DKFEEtAh7MoDA040f2B/NNzFNDhgIAbq+ZtcyLnwLuHu8tP0BiGHCiUOy X2J6fjxZ6CArGXZU2jHjZyFvJvu0spmWAwryeHN2bfK2thRbO8WlsJPlEwAvVrDhYkPY qj5w== X-Gm-Message-State: AHYfb5haPwqqSg6lqSVGfZpcum6mMZc+MUQ/9uvIB52yAjxcqWGhfUp0 YXBsmu2f2GNOSHkM2ai6kszZiek3bA== X-Received: by 10.200.55.204 with SMTP id e12mr3427730qtc.180.1502901048406; Wed, 16 Aug 2017 09:30:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:30:47 -0700 (PDT) Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:30:47 -0700 (PDT) In-Reply-To: References: From: Priyatosh Mandal Date: Wed, 16 Aug 2017 22:00:47 +0530 Message-ID: To: Yuval Lifshitz Cc: "dime@ietf.org" , "Bertz, Lyle T [CTO]" Content-Type: multipart/alternative; boundary="001a1141e4ca1f773a0556e16b99" Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 16:30:53 -0000 --001a1141e4ca1f773a0556e16b99 Content-Type: text/plain; charset="UTF-8" The respective section can be enhanced to say for transition from maximum to the minimum value of origin-state-id, the peer access node should assume the node restart. Otherwise the present description based implementation can cause hang situation of various nodes which actually wait to receive increased value of origin-state-id to clear session. I mean if a node receives 0 after processing of the maximum value of origin-state-id, how it will behave? Not defined in RFC. So to remove the hang situation the explanation of this transition of value can be included. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 16, 2017 7:55 PM, "Yuval Lifshitz" wrote: > Not sure if errata is meant to capture "clarifications", but should > probably be captured somewhere so it could be added to a future version. > > -----Original Message----- > From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] > Sent: Wednesday, August 16, 2017 3:40 PM > To: Yuval Lifshitz; Priyatosh Mandal; dime@ietf.org > Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084) > > However, the spec is not wrong as much as there is no warning to ensure > the reader is aware of the situation. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz > Sent: Wednesday, August 16, 2017 12:20 AM > To: Priyatosh Mandal ; dime@ietf.org > Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Don't think it should be rejected. Even if the implementation rollover 4M > to 1 (and not to zero) there is still an issue of the fact that the > origin-state-id is not incremented. > IMO, it should be addressed in the spec. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal > Sent: Wednesday, August 16, 2017 6:52 AM > To: dime@ietf.org > Subject: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Hello , > Should I consider the Reported Errata ID: 5084, as rejected. > > Kindly confirm. > > Regards, > Dr. Priyatosh Mandal, Ph.D. > > On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note > that, with the incremental change of this origin-state-id the peer node > clear sessions. So when the change is from the maximum value to the minimum > value of origin-state-id then it is not an incremental change. This is an > exceptional situation, which I feel to be part of rfc. > > Regards, > Dr. Priyatosh Mandal, Ph. D. > > On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" > wrote: > > I believe what Dave is alluding to is that if one *does intend for the > inferences to be made* then rolling over the value to 0 is not appropriate > and avalue > 0, e.g. 1, MUST be used. > > In a sense it is not an error as much as a note / warning for those who > are allocating that AVP in a specific manner. > > > From: DiME [mailto:dime-bounces@ietf.org]On Behalf Of Priyatosh Mandal > Sent: Monday, August 14, 2017 6:19 AM > To: Dave Dolson ; RFC Errata System < > rfc-editor@rfc-editor.org>; vf0213@gmail.com; jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Hello Sir, > The situation is a transition from the maximum value 4294967295 of > Origin-State-Id. If after this, the value of Origin-State-Id is increased, > it will automatically become 0. So the peer node which receives the value 0 > after 4294967295, can assume the node whichsent this 0, faced a restart. > Here the peer-node is already aware that the previous value of > origin-state-id was 4294967295. So it can easily conclude node restart. > > I understand the meaning of 0 as explained in RFC 6733 :"If an access > device does not intend for such inferences to be made, it MUST either not > include Origin-State-Id in any message or set its value to 0".But this is a > special case, where the value of Origin-State-Id changes from 4294967295 > to 0. > > So kindly reconsider > this. > > Thanking you, > Priyatosh > > On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the > change should not be accepted. > In your roll-over special case, the device should skip over the value 0, > using 1 or some other value instead of zero. > > David Dolson > Sandvine > > From: Priyatosh Mandal > Sent: Monday, August 14, 2017 12:57 AM > To: RFC Errata System; vf0213@gmail.com;jari.arkko@ericsson.com; > john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com; > warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com > Cc: dime@ietf.org > Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Dear All, > Kindly verify this. > > Regards, > Priyatosh Mandal > > On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The > following errata report has been submitted for RFC6733, "Diameter Base > Protocol". > > -------------------------------------- > You may review the report below and at: > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5084&data= > 02%7C01%7Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4e4666ace% > 7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636384575908897376&sdata= > EITh8Z6bWAwU9pur6Zrospr9D%2Fd2UgKe%2BTBrmkh%2BDzA%3D&reserved=0 > > -------------------------------------- > Type: Technical > Reported by: Priyatosh Mandal > > Section: 8.16 > > Original Text > ------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id are > no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value to > 0. > > Corrected Text > -------------- > By including Origin-State-Id in a message, it allows other Diameter > entities to infer that sessions associated with a lower Origin-State-Id are > no longer active. > If an access device does not intend for such inferences to be made, it > MUST either not include Origin-State-Id in any message or set its value to > 0. > As a special case when the value of Origin-State-Id changes from > 4294967295 to 0, then also the access device clear all the sessions. > > Notes > ----- > Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the > maximum value it can have is 4294967295. If the system restarts many times > and the value of Origin-State-Id reaches the value which is same as its > maximum value 4294967295. > Then what will happen for the next restart. At the next restart the value > of Origin-State-Id will be 0 if we try to increase the value of > Origin-State-Id. > It is not defined in the RFC 6733, that how the system should behave after > 4294967295-th restart with respect to Origin-State-Id. > > Generally when the peer receives an increased value of Origin-State-Id, > then it clear all sessions. > If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then > after another restart its value will be 0. For a special case for > transition of value of Origin-State-Id from > 4294967295 to 0, the peer should clear its session. > > 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 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 > > Priyatosh > Ext: 8517 > Mob: 9810480266 > ------------------------------------------------------------ > -------------------- > ::Disclaimer:: > ------------------------------------------------------------ > -------------------- > The contents of this email and any attachment(s) are confidential and > intended for the named recipient(s) only. It shall not attach any liability > on C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > Priyatosh > Ext: 8517 > Mob: 9810480266 > ------------------------------------------------------------ > -------------------- > ::Disclaimer:: > ------------------------------------------------------------ > -------------------- > The contents of this email and any attachment(s) are confidential and > intended for the named recipient(s) only. It shall not attach any liability > on C-DOT. > Any views or opinions presented in this email are solely those of the > author > and may not necessarily reflect the opinions > > ----------------------------------------------------------------------- > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copies > of the message. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdime& > data=02%7C01%7Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4e466 > 6ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0% > 7C636384575908897376&sdata=OuKsSusa3%2FM8fjvTaKJ%2F% > 2FEgL%2FGwWDQUFCQu%2BqKTNJxg%3D&reserved=0 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdime& > data=02%7C01%7Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4e466 > 6ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0% > 7C636384575908897376&sdata=OuKsSusa3%2FM8fjvTaKJ%2F% > 2FEgL%2FGwWDQUFCQu%2BqKTNJxg%3D&reserved=0 > --001a1141e4ca1f773a0556e16b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The respective section can be enhanced to say for transit= ion from maximum to the minimum value of origin-state-id, the peer access n= ode should assume the node restart. Otherwise the present description based= implementation can cause hang situation of various nodes which actually wa= it to receive increased value of origin-state-id to clear session. I mean i= f a node receives 0 =C2=A0after processing of the maximum value of origin-s= tate-id, how it will behave? Not defined in RFC.=C2=A0 So to remove the han= g situation the explanation of this transition of value can be included.=C2= =A0

Regards,=C2=A0
Dr. Priyatosh Mandal, Ph. D.=C2=A0

On Aug 16, 2017 7:55 PM, "Yuv= al Lifshitz" <ylifshitz@s= andvine.com> wrote:
Not sure if errata is meant to capture "clarifications", b= ut should probably be captured somewhere so it could be added to a future v= ersion.

-----Original Message-----
From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: Wednesday, August 16, 2017 3:40 PM
To: Yuval Lifshitz; Priyatosh Mandal; dime= @ietf.org
Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084)

However, the spec is not wrong as much as there is no warning to ensure the= reader is aware of the situation.

-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of Yuval Lifshitz
Sent: Wednesday, August 16, 2017 12:20 AM
To: Priyatosh Mandal <priyotos= htsp@gmail.com>; dime@ietf.org<= br> Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

Don't think it should be rejected. Even if the implementation rollover = 4M to 1 (and not to zero) there is still an issue of the fact that the orig= in-state-id is not incremented.
IMO, it should be addressed in the spec.

-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of Priyatosh Mandal
Sent: Wednesday, August 16, 2017 6:52 AM
To: dime@ietf.org
Subject: [Dime] [Technical Errata Reported] RFC6733 (5084)

Hello ,
Should I consider the Reported Errata ID: 5084, as rejected.

Kindly confirm.

Regards,
Dr. Priyatosh Mandal, Ph.D.

On Mon, 14 Aug 2017 19:47:28 +0530, Priyatosh Mandal wrote Kindly note that= , with the incremental change of this origin-state-id the peer node clear s= essions. So when the change is from the maximum value to the minimum value = of origin-state-id then it is not an incremental change. This is an excepti= onal situation, which I feel to be part of rfc.

Regards,
Dr. Priyatosh Mandal, Ph. D.

On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com> wrote:

I believe what Dave is alluding to is that if one *does intend for the infe= rences to be made* then rolling over the value to 0 is not appropriate and = avalue > 0, e.g. 1, MUST be used.

In a sense it is not an error as much as a note / warning for those who are= allocating that AVP in a specific manner.


From: DiME [mailto:dime-bounces@ie= tf.org]On Behalf Of Priyatosh Mandal
Sent: Monday, August 14, 2017 6:19 AM
To: Dave Dolson <ddolson@sandvin= e.com>; RFC Errata System <rfc-editor@rfc-editor.org>; vf0213@gmail.com; jari.ar= kko@ericsson.com; john.lough= ney@nokia.com; glenzorn@gmail.com= ; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

Hello Sir,
The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node whichsent this 0, faced a restart. Here the = peer-node=C2=A0 is already aware that the previous value of origin-state-id= was 4294967295. So it can easily conclude node restart.

I understand=C2=A0 the meaning of 0 as explained in RFC 6733 :"If an a= ccess device does not intend for such inferences to be made, it MUST either= not include Origin-State-Id in any message or set its value to 0".But= this is a special case, where the value of Origin-State-Id changes from=C2= =A0 4294967295 to 0.

So kindly reconsider
this.

Thanking you,
Priyatosh

On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the ch= ange should not be accepted.
In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero.

David Dolson
Sandvine

From: Priyatosh Mandal
Sent: Monday, August 14, 2017 12:57 AM
To: RFC Errata System; vf0213@gmail.com= ;jari.arkko@ericsson.co= m;
john.loughney@nokia.com; glenzorn@gmail.com;bclaise@cisco.com;
warren@kumari.net; jouni.nospam@gmail.com;lionel.morand@orange.com
Cc: dime@ietf.org
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The follo= wing errata report has been submitted for RFC6733, "Diameter Base Prot= ocol".

--------------------------------------
You may review the report below and at:
https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3= A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5084&data=3D02%7C01%7= Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4e4666ac= e%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C6363845759088= 97376&sdata=3DEITh8Z6bWAwU9pur6Zrospr9D%2Fd2UgKe%2BTBrmkh%2BD= zA%3D&reserved=3D0

--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal <priya= tos@cdot.in>

Section: 8.16

Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active.
If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0.
Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter entitie= s to infer that sessions associated with a lower Origin-State-Id are no lon= ger active.
If an access device does not intend for such inferences to be made, it MUST= either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from
4294967295 to 0, then also the access device=C2=A0 clear all the sessions.<= br>
Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times = and the value of Origin-State-Id reaches the value which is same as its max= imum value 4294967295.
Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State= -Id.
It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transitio= n of value of Origin-State-Id from
4294967295 to 0, the peer should clear its session.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase use "Reply All" to discuss whether it should be verified or r= ejected. When a decision is reached, the verifying party can log in to chan= ge 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: Diameter Base= Protocol
Publication Date=C2=A0 =C2=A0 : October 2012
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: V. Fajardo, Ed., J. Ark= ko, J. Loughney, G. Zorn, Ed.
Category=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 : Diameter Maintenan= ce and Extensions
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT.
Any views or opinions presented in this email are solely those of the autho= r
and=C2=A0 may=C2=A0 not=C2=A0 necessarily=C2=A0 reflect=C2=A0 the=C2=A0 =C2= =A0opinions

Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C= -DOT.
Any views or opinions presented in this email are solely those of the autho= r
and=C2=A0 may=C2=A0 not=C2=A0 necessarily=C2=A0 reflect=C2=A0 the=C2=A0 =C2= =A0opinions

-----------------------------------------------------------------= ------

This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdime&data= =3D02%7C01%7Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4= e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C6= 36384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGw= WDQUFCQu%2BqKTNJxg%3D&reserved=3D0

_______________________________________________
DiME mailing list
DiME@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdime&data= =3D02%7C01%7Clyle.t.bertz%40sprint.com%7C22cd07b0b7174d6fdc7608d4= e4666ace%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C6= 36384575908897376&sdata=3DOuKsSusa3%2FM8fjvTaKJ%2F%2FEgL%2FGw= WDQUFCQu%2BqKTNJxg%3D&reserved=3D0
--001a1141e4ca1f773a0556e16b99-- From nobody Thu Aug 17 20:12:42 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBC71320BE for ; Wed, 16 Aug 2017 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fzOrLXpAHhm3 for ; Wed, 16 Aug 2017 09:30:49 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA9813264A for ; Wed, 16 Aug 2017 09:30:48 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 16 Aug 2017 12:30:46 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 12:30:46 -0400 From: Dave Dolson To: Priyatosh Mandal , "Bertz, Lyle T [CTO]" CC: "john.loughney@nokia.com" , RFC Errata System , "glenzorn@gmail.com" , "dime@ietf.org" , "bclaise@cisco.com" , "lionel.morand@orange.com" , "jari.arkko@ericsson.com" , "warren@kumari.net" , "vf0213@gmail.com" , "jouni.nospam@gmail.com" , Priyatosh Mandal Thread-Topic: [Dime] [Technical Errata Reported] RFC6733 (5084) Thread-Index: AQHTE68YeM6TpIqW/EGeAHwz10SRjKKDg/CAgAArP9+AAEqjAIAAHNuAgAAVIQCAAwbZTA== Date: Wed, 16 Aug 2017 16:30:45 +0000 Message-ID: <20170816163045.5115986.81818.28569@sandvine.com> References: <20170811040456.E8570B81789@rfc-editor.org> <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> <20170814110558.M60858@cdot.in> <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_2017081616304551159868181828569sandvinecom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 17 Aug 2017 20:12:41 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 16:30:52 -0000 --_000_2017081616304551159868181828569sandvinecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Priyatosh, You are asking for a change in interpretation that is not backwards compati= ble. I'm suggesting a backwards compatible clarification would be that for the r= ollover case, the agent should skip the value of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 10:17 AM To: Bertz, Lyle T [CTO] Cc: Dave Dolson; john.loughney@nokia.com; RFC Errata System; glenzorn@gmail= .com; dime@ietf.org; bclaise@cisco.com; lionel.morand@orange.com; jari.arkk= o@ericsson.com; warren@kumari.net; vf0213@gmail.com; jouni.nospam@gmail.com= ; Priyatosh Mandal Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084) Kindly note that, with the incremental change of this origin-state-id the p= eer node clear sessions. So when the change is from the maximum value to th= e minimum value of origin-state-id then it is not an incremental change. Th= is is an exceptional situation, which I feel to be part of rfc. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" > wrote: I believe what Dave is alluding to is that if one *does intend for the infe= rences to be made* then rolling over the value to 0 is not appropriate and = a value > 0, e.g. 1, MUST be used. In a sense it is not an error as much as a note / warning for those who are= allocating that AVP in a specific manner. From: DiME [mailto:dime-bounces@ietf.org] On = Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson >; RFC Er= rata System >; = vf0213@gmail.com; jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.= nospam@gmail.com; lionel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Hello Sir, The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node which sent this 0, faced a restart. Here the peer-node is already aware that the previous val= ue of origin-state-id was 4294967295. So it can easily conclude node restar= t. I understand the meaning of 0 as explained in RFC 6733 :"If an access devi= ce does not intend for such inferences to be made, it MUST either not inclu= de Origin-State-Id in any message or set its value to 0". But this is a special case, where the value of Origin-State-Id changes from= 4294967295 to 0. So kindly reconsider this. Thanking you, Priyatosh On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote In my opinion, the change should not be accepted. In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero. David Dolson Sandvine From: Priyatosh Mandal Sent: Monday, August 14, 2017 12:57 AM To: RFC Errata System; vf0213@gmail.com; jari.arkk= o@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com= ; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lio= nel.morand@orange.com Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) Dear All, Kindly verify this. Regards, Priyatosh Mandal On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote 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/eid5084 -------------------------------------- Type: Technical Reported by: Priyatosh Mandal > Section: 8.16 Original Text ------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. Corrected Text -------------- By including Origin-State-Id in a message, it allows other Diameter entities to infer that sessions associated with a lower Origin-State-Id are no longer active. If an access device does not intend for such inferences to be made, it MUST either not include Origin-State-Id in any message or set its value to 0. As a special case when the value of Origin-State-Id changes from 4294967295 to 0, then also the access device clear all the sessions. Notes ----- Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum value it can have is 4294967295. If the system restarts many times and the = value of Origin-State-Id reaches the value which is same as its maximum value 429496= 7295. Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id will be 0 if we try to increase the value of Origin-State-Id. It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th restart with respect to Origin-State-Id. Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions. If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart its value will be 0. For a special case for transition of value of Origin-S= tate-Id from 4294967295 to 0, the peer should clear its session. 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 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 Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C-DOT= . Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions Priyatosh Ext: 8517 Mob: 9810480266 ---------------------------------------------------------------------------= ----- ::Disclaimer:: ---------------------------------------------------------------------------= ----- The contents of this email and any attachment(s) are confidential and inten= ded for the named recipient(s) only. It shall not attach any liability on C-DOT= . Any views or opinions presented in this email are solely those of the autho= r and may not necessarily reflect the opinions ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_2017081616304551159868181828569sandvinecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David Dolson
Sandvine
From: Priyatosh Mandal
Sent: Monday, August 14, 2017 10:17 AM
To: Bertz, Lyle T [CTO]
Cc: Dave Dolson; john.loughney@nokia.com; RFC Errata System; gl= enzorn@gmail.com; dime@ietf.org; bclaise@cisco.com; lionel.morand@orange.co= m; jari.arkko@ericsson.com; warren@kumari.net; vf0213@gmail.com; jouni.nosp= am@gmail.com; Priyatosh Mandal
Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084)<= /div>

Kindly note that, with the incremental change of this ori= gin-state-id the peer node clear sessions. So when the change is from the m= aximum value to the minimum value of origin-state-id then it is not an incr= emental change. This is an exceptional situation, which I feel to be part of rfc. 

Regards, 
Dr. Priyatosh Mandal, Ph. D.


On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CT= O]" <Lyle.T.Bertz@sprint= .com> wrote:

I believe what Dave is alluding to = is that if one *does intend for the inferences to be made* then roll= ing over the value to 0 is not appropriate and a value > 0, e.g. 1, MUST be used.

 

In a sense it is not an error as mu= ch as a note / warning for those who are allocating that AVP in a specific = manner.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal
Sent: Monday, August 14, 2017 6:19 AM
To: Dave Dolson <ddolson@sandvine.com>; RFC Errata System <rfc-editor@rfc-editor.o= rg>; vf0213@gmail.com;= jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

 

Hello Sir,
The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node which sent this 0,
faced a restart. Here the peer-node  is already aware that the previou= s value of origin-state-id was 4294967295. So it can easily conclude node r= estart.

I understand  the meaning of 0 as explained in RFC 6733 :"If an a= ccess device does not intend for such inferences to be made, it MUST either= not include Origin-State-Id in any message or set its value to 0". 

But this is a special case, where the value of Origin-State-Id changes=
 from  4294967295 to 0.



So kindly reconsider this.
 


Thanking you,
Priyatosh




On Mon, 14 Aug 2017 10:51:25 +0000,= Dave Dolson wrote
In my opinion, the change should not be accepted. 
In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero.

David Dolson
Sandvine



From: Priyatosh Mandal
Sent: Monday, August 14, 2017 12:57 AM
To: RFC Errata System; vf0213@gmail.com; jari.arkko@eri= csson.com; john.loughney@= nokia.com; glenzorn@gmail.com<= /a>; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gm= ail.com; lionel.morand= @orange.com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)



Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-edit= or.org/errata/eid5084

--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal <priyatos@cdot.in>

Section: 8.16

Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.

Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.
As a special case when the value of Origin-State-Id changes from
4294967295 to 0, then also the access device  clear all the sessions. =

Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum
value it can have is 4294967295. If the system restarts many times and the = value of
Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.
Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th
restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart
its value will be 0. For a special case for transition of value of Origin-S= tate-Id from
4294967295 to 0, the peer should clear its session.

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

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

Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and  may  not  necessarily  reflect  the   op= inions



Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and  may  not  necessarily  reflect  the   op= inions



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
--_000_2017081616304551159868181828569sandvinecom_-- From nobody Thu Aug 17 20:12:48 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524D3132351 for ; Wed, 16 Aug 2017 09:41:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DBcus9xAZ-k1 for ; Wed, 16 Aug 2017 09:41:42 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 9668C120727 for ; Wed, 16 Aug 2017 09:41:42 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id a18so24072927qta.0 for ; Wed, 16 Aug 2017 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OnG5+FXRnw0s4HxpbP93PxcnnHQ8lvci/J2tF1xprMc=; b=uf639aPYiE8U7q8eHB/4hAZ3iBgjYXq/M7KO4ITi1xBHziR4z2ZKU6EOUX2dnqGd/O Y6oG09AGOyLFIP7Bsw254FPP4ElxAGqHtGEgNomTDcgKyOU/1QbheOdgFGg8kEV+2zxb DX5uRJj2HeKM6XP5FKPoQZmJmXfzB0i44vwGjmnS3w9O2NwqdOb4G/Mq445TIRAhksP9 pPwu5frHDtmxGYgsRU0qw0nJbi53wcxTPc+MMXxhfZDTMuoVUIuTgqpT3pph75hWE92X 8eWoKnPhJTy+40Y+0IWd0R54qYgjbQzyA3sw6sm2iKbd5SIJUx84CB1d5Pa64f0/zaTO WvRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OnG5+FXRnw0s4HxpbP93PxcnnHQ8lvci/J2tF1xprMc=; b=W/HFi6R99T3aOlzUwXYWwhGzHCul64NYyJUynE0cMc9kXd6cDx53UUqUMk6n5v3Y54 eS3EuUqKEwQSkq9zer7KmHjWE0BYqR9aAsXag7x4gdY0za4CplAHzwjRJDaaS1cy1hj8 ZGyolxyUlu5EHEypL80JwAcyBliYi1Sy4bKc58ExtSguFpAW0bcawc/WaShibcrbyhvl hh6G3QgDiJBDP+QH1N7GBe0a1jwh04jQ6620CbEu4ZZGlwsF0Vl53RvxD++WhdLFYoGv 7s6pzlWcLD9mGidg4wDgKQSBfrzbFf7FFrc0waRVTeH6mV3yU3gNtlSFjSOKoQzb2yY8 NQEA== X-Gm-Message-State: AHYfb5gjQkObz8k1JcYbDZwPBnGBdJqHqxEO8iFlQkae8XMJzxNjUa9p UX601/sEl5E3OsKto/MfyUGrfojh5g== X-Received: by 10.237.35.203 with SMTP id k11mr3566731qtc.182.1502901701581; Wed, 16 Aug 2017 09:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:41:40 -0700 (PDT) Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:41:40 -0700 (PDT) In-Reply-To: <20170816163045.5115986.81818.28569@sandvine.com> References: <20170811040456.E8570B81789@rfc-editor.org> <20170814041602.M44812@cdot.in> <20170814105124.5115986.90299.28199@sandvine.com> <20170814110558.M60858@cdot.in> <1efe047abe674df0acf2c82406abbbc7@plswe13m04.ad.sprint.com> <20170816163045.5115986.81818.28569@sandvine.com> From: Priyatosh Mandal Date: Wed, 16 Aug 2017 22:11:40 +0530 Message-ID: To: Dave Dolson Cc: "john.loughney@nokia.com" , RFC Errata System , "glenzorn@gmail.com" , "bclaise@cisco.com" , "dime@ietf.org" , "jari.arkko@ericsson.com" , "lionel.morand@orange.com" , "vf0213@gmail.com" , "warren@kumari.net" , Priyatosh Mandal , "jouni.nospam@gmail.com" , "Bertz, Lyle T [CTO]" Content-Type: multipart/alternative; boundary="001a114227de0e22a90556e19216" Archived-At: X-Mailman-Approved-At: Thu, 17 Aug 2017 20:12:41 -0700 Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 16:41:46 -0000 --001a114227de0e22a90556e19216 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sir, Consider the situation of increment of origin-state-id from maximum to the next will be 0 only. The node which will be sending 0, has to modify the value internally to 1, before sending to peer. Here also the peer receiving the information will be confused what to do with that? Because it is not an incremented value. So this has to be explained somewhere. Also this is not probably backward compatible. Regards, Dr. Priyatosh Mandal, Ph. D. On Aug 16, 2017 10:00 PM, "Dave Dolson" wrote: > Priyatosh, > You are asking for a change in interpretation that is not backwards > compatible. > I'm suggesting a backwards compatible clarification would be that for the > rollover case, the agent should skip the value of zero. > > > David Dolson > Sandvine > *From: *Priyatosh Mandal > *Sent: *Monday, August 14, 2017 10:17 AM > *To: *Bertz, Lyle T [CTO] > *Cc: *Dave Dolson; john.loughney@nokia.com; RFC Errata System; > glenzorn@gmail.com; dime@ietf.org; bclaise@cisco.com; > lionel.morand@orange.com; jari.arkko@ericsson.com; warren@kumari.net; > vf0213@gmail.com; jouni.nospam@gmail.com; Priyatosh Mandal > *Subject: *RE: [Dime] [Technical Errata Reported] RFC6733 (5084) > > Kindly note that, with the incremental change of this origin-state-id the > peer node clear sessions. So when the change is from the maximum value to > the minimum value of origin-state-id then it is not an incremental change= . > This is an exceptional situation, which I feel to be part of rfc. > > Regards, > Dr. Priyatosh Mandal, Ph. D. > > > On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CTO]" > wrote: > >> I believe what Dave is alluding to is that if one **does intend for the >> inferences to be made** then rolling over the value to 0 is not >> appropriate and a value > 0, e.g. 1, MUST be used. >> >> >> >> In a sense it is not an error as much as a note / warning for those who >> are allocating that AVP in a specific manner. >> >> >> >> *From:* DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Priyatosh >> Mandal >> *Sent:* Monday, August 14, 2017 6:19 AM >> *To:* Dave Dolson ; RFC Errata System < >> rfc-editor@rfc-editor.org>; vf0213@gmail.com; jari.arkko@ericsson.com; >> john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; >> warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com >> *Cc:* dime@ietf.org >> *Subject:* Re: [Dime] [Technical Errata Reported] RFC6733 (5084) >> >> >> >> Hello Sir, >> The situation is a transition from the maximum value 4294967295 of >> Origin-State-Id. If after this, the value of Origin-State-Id is increase= d, >> it will automatically become 0. So the peer node which receives the valu= e 0 >> after 4294967295, can assume the node which sent this 0, >> faced a restart. Here the peer-node is already aware that the previous >> value of origin-state-id was 4294967295. So it can easily conclude node >> restart. >> >> I understand the meaning of 0 as explained in RFC 6733 :"If an access >> device does not intend for such inferences to be made, it MUST either no= t >> include Origin-State-Id in any message or set its value to 0". >> >> But this is a special case, where the value of Origin-State-Id changes f= rom 4294967295 to 0. >> >> >> >> >> So kindly reconsider this. >> >> >> >> >> Thanking you, >> Priyatosh >> >> >> >> >> *On Mon, 14 Aug 2017 10:51:25 +0000, Dave Dolson wrote* >> In my opinion, the change should not be accepted. >> In your roll-over special case, the device should skip over the value 0, >> using 1 or some other value instead of zero. >> >> David Dolson >> Sandvine >> >> >> >> *From: *Priyatosh Mandal >> *Sent: *Monday, August 14, 2017 12:57 AM >> *To: *RFC Errata System; vf0213@gmail.com; jari.arkko@ericsson.com; >> john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; >> warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com >> *Cc: *dime@ietf.org >> *Subject: *Re: [Dime] [Technical Errata Reported] RFC6733 (5084) >> >> >> >> Dear All, >> Kindly verify this. >> >> Regards, >> Priyatosh Mandal >> >> *On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote* >> 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/eid5084 >> >> >> -------------------------------------- >> Type: Technical >> Reported by: Priyatosh Mandal >> >> Section: 8.16 >> >> Original Text >> ------------- >> By including Origin-State-Id in a message, it allows other Diameter >> entities to infer that sessions associated with a lower Origin-State-Id >> are no longer active. >> If an access device does not intend for such inferences to be made, it >> MUST either not include Origin-State-Id in any message or set its value >> to 0. >> >> Corrected Text >> -------------- >> By including Origin-State-Id in a message, it allows other Diameter >> entities to infer that sessions associated with a lower Origin-State-Id >> are no longer active. >> If an access device does not intend for such inferences to be made, it >> MUST either not include Origin-State-Id in any message or set its value >> to 0. >> As a special case when the value of Origin-State-Id changes from >> 4294967295 to 0, then also the access device clear all the sessions. >> >> Notes >> ----- >> Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So >> the maximum >> value it can have is 4294967295. If the system restarts many times and >> the value of >> Origin-State-Id reaches the value which is same as its maximum value >> 4294967295. >> Then what will happen for the next restart. At the next restart the valu= e >> of Origin-State-Id >> will be 0 if we try to increase the value of Origin-State-Id. >> It is not defined in the RFC 6733, that how the system should behave >> after 4294967295-th >> restart with respect to Origin-State-Id. >> >> Generally when the peer receives an increased value of Origin-State-Id, >> then it clear all sessions. >> If the value of Origin-State-Id reaches its maximum i.e., 4294967295, >> then after another restart >> its value will be 0. For a special case for transition of value of >> Origin-State-Id from >> 4294967295 to 0, the peer should clear its session. >> >> 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 >> 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 >> >> Priyatosh >> Ext: 8517 >> Mob: 9810480266 >> ------------------------------------------------------------------------= -------- >> >> ::Disclaimer:: >> ------------------------------------------------------------------------= -------- >> >> The contents of this email and any attachment(s) are confidential and >> intended >> for the named recipient(s) only. It shall not attach any liability on >> C-DOT. >> Any views or opinions presented in this email are solely those of the >> author >> and may not necessarily reflect the opinions >> >> >> >> Priyatosh >> Ext: 8517 >> Mob: 9810480266 >> ------------------------------------------------------------------------= -------- >> >> ::Disclaimer:: >> ------------------------------------------------------------------------= -------- >> >> The contents of this email and any attachment(s) are confidential and >> intended >> for the named recipient(s) only. It shall not attach any liability on >> C-DOT. >> Any views or opinions presented in this email are solely those of the >> author >> and may not necessarily reflect the opinions >> >> ------------------------------ >> >> This e-mail may contain Sprint proprietary information intended for the >> sole use of the recipient(s). Any use by others is prohibited. If you ar= e >> not the intended recipient, please contact the sender and delete all cop= ies >> of the message. >> > --001a114227de0e22a90556e19216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sir,=C2=A0
Consider the situation of inc= rement of origin-state-id from maximum to the next will be 0 only. The =C2= =A0node which will be sending 0, has to modify the value internally to 1, b= efore sending to peer. Here also the peer receiving the information will be= confused what to do with that? Because it is not an incremented value. So = this has to be explained somewhere. Also this is not probably backward comp= atible.=C2=A0
Regards,=C2=A0
= Dr. Priyatosh Mandal, Ph. D.=C2=A0
On Aug 16, 2017 10:00 PM, "Dave Dolson&qu= ot; <ddolson@sandvine.com>= ; wrote:
Priyatosh,=C2=A0
You are asking for a change in interpretation that is not backwards compati= ble.
I'm suggesting a backwards compatible clarification would be that for t= he rollover case, the agent should skip the value of zero.


David=C2=A0Dolson
Sandvine
From: Priyatosh Mandal
Sent: Monday, August 14, 2017 10:17 AM
To: Bertz, Lyle T [CTO]
Subject: RE: [Dime] [Technical Errata Reported] RFC6733 (5084)<= /div>

Kindly note that, with the incremental change of this ori= gin-state-id the peer node clear sessions. So when the change is from the m= aximum value to the minimum value of origin-state-id then it is not an incr= emental change. This is an exceptional situation, which I feel to be part of rfc.=C2=A0

Regards,=C2=A0
Dr. Priyatosh Mandal, Ph. D.


On Aug 14, 2017 6:32 PM, "Bertz, Lyle T [CT= O]" <L= yle.T.Bertz@sprint.com> wrote:

I believe what Dave is alluding to is= that if one *does intend for the inferences to be made* then rollin= g over the value to 0 is not appropriate and a value > 0, e.g. 1, MUST be used.

=C2=A0

In a sense it is not an error as much= as a note / warning for those who are allocating that AVP in a specific ma= nner.

=C2=A0

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal
Sent: Monday, August 14, 2017 6:19 AM
To: Dave Dolson <ddolson@sandvine.com>; RFC Errata System <rfc-editor@rfc-editor.o= rg>; vf0213@gmail.com;= jari.arkko@ericsson.com; john.loughney@nokia.com; glenzorn@gmail.com; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gmail.com; lionel.morand@orange.com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

=C2=A0

Hello Sir,
The situation is a transition from the maximum value 4294967295 of Origin-S= tate-Id. If after this, the value of Origin-State-Id is increased, it will = automatically become 0. So the peer node which receives the value 0 after 4= 294967295, can assume the node which sent this 0,
faced a restart. Here the peer-node=C2=A0 is already aware that the previou= s value of origin-state-id was 4294967295. So it can easily conclude node r= estart.

I understand=C2=A0 the meaning of 0 as explained in RFC 6733 :"If an a= ccess device does not intend for such inferences to be made, it MUST either= not include Origin-State-Id in any message or set its value to 0". 

But this is a special case, where the value of Origin-State-Id changes=
 from=C2=A0 4294967295 to 0.



So kindly reconsider this.
=C2=A0


Thanking you,
Priyatosh




On Mon, 14 Aug 2017 10:51:25 +0000, Dav= e Dolson wrote
In my opinion, the change should not be accepted.=C2=A0
In your roll-over special case, the device should skip over the value 0, us= ing 1 or some other value instead of zero.

David=C2=A0Dolson
Sandvine



From: Priyatosh Mandal
Sent: Monday, August 14, 2017 12:57 AM
To: RFC Errata System; vf0213@gmail.com; jari.arkko@eri= csson.com; john.loughney@= nokia.com; glenzorn@gmail.com<= /a>; bclaise@cisco.com; warren@kumari.net; jouni.nospam@gm= ail.com; lionel.morand= @orange.com
Cc: dime@ietf.org=
Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (5084)



Dear All,
Kindly verify this.

Regards,
Priyatosh Mandal

On Thu, 10 Aug 2017 21:04:56 -0700 (PDT), RFC Errata System wrote The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-edit= or.org/errata/eid5084

--------------------------------------
Type: Technical
Reported by: Priyatosh Mandal <priyatos@cdot.in>

Section: 8.16

Original Text
-------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.

Corrected Text
--------------
By including Origin-State-Id in a message, it allows other Diameter
entities to infer that sessions associated with a lower Origin-State-Id are no longer active.
If an access device does not intend for such inferences to be made, it
MUST either not include Origin-State-Id in any message or set its value to 0.
As a special case when the value of Origin-State-Id changes from
4294967295 to 0, then also the access device =C2=A0clear all the sessions. =

Notes
-----
Origin-State-Id is defined as Unsigned32 in RFC 6733, Section 8.16. So the = maximum
value it can have is 4294967295. If the system restarts many times and the = value of
Origin-State-Id reaches the value which is same as its maximum value 429496= 7295.
Then what will happen for the next restart. At the next restart the value o= f Origin-State-Id
will be 0 if we try to increase the value of Origin-State-Id.
It is not defined in the RFC 6733, that how the system should behave after = 4294967295-th
restart with respect to Origin-State-Id.

Generally when the peer receives an increased value of Origin-State-Id, the= n it clear all sessions.
If the value of Origin-State-Id reaches its maximum i.e., 4294967295, then = after another restart
its value will be 0. For a special case for transition of value of Origin-S= tate-Id from
4294967295 to 0, the peer should clear its session.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =C2=A0
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 : Diameter Base Prot= ocol
Publication Date =C2=A0 =C2=A0: October 2012
Author(s) =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: PROPOSED STANDARD
Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Maintenan= ce and Extensions
Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Operations an= d Management
Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF
Verifying Party =C2=A0 =C2=A0 : IESG

Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions



Priyatosh
Ext: 8517
Mob: 9810480266
-----------------------------------------------------------------= ---------------
::Disclaimer::
-----------------------------------------------------------------= ---------------
The contents of this email and any attachment(s) are confidential and inten= ded
for the named recipient(s) only. It shall not attach any liability on C-DOT= .
Any views or opinions presented in this email are solely those of the autho= r
and =C2=A0may =C2=A0not =C2=A0necessarily =C2=A0reflect =C2=A0the =C2=A0 op= inions



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
--001a114227de0e22a90556e19216--