Re: [Dime] [Technical Errata Reported] RFC6733 (5084)
Dave Dolson <ddolson@sandvine.com> Wed, 16 August 2017 16:30 UTC
Return-Path: <ddolson@sandvine.com>
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 <dime@ietfa.amsl.com>; 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 <dime@ietfa.amsl.com>; 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 <dime@ietf.org>; 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 <ddolson@sandvine.com>
To: Priyatosh Mandal <priyotoshtsp@gmail.com>, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
CC: "john.loughney@nokia.com" <john.loughney@nokia.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "glenzorn@gmail.com" <glenzorn@gmail.com>, "dime@ietf.org" <dime@ietf.org>, "bclaise@cisco.com" <bclaise@cisco.com>, "lionel.morand@orange.com" <lionel.morand@orange.com>, "jari.arkko@ericsson.com" <jari.arkko@ericsson.com>, "warren@kumari.net" <warren@kumari.net>, "vf0213@gmail.com" <vf0213@gmail.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, Priyatosh Mandal <priyatos@cdot.in>
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>, <CADTSkb1574M34oBKk7vUisrOCfcA8LD59SCRqwq-DftuJGbi1Q@mail.gmail.com>
In-Reply-To: <CADTSkb1574M34oBKk7vUisrOCfcA8LD59SCRqwq-DftuJGbi1Q@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/dime/_W42L1-TDvdTzzEVIfT0HXXftH8>
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 <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 16:30:52 -0000
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]" <Lyle.T.Bertz@sprint.com<mailto: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 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<mailto:dime-bounces@ietf.org>] On Behalf Of Priyatosh Mandal Sent: Monday, August 14, 2017 6:19 AM To: Dave Dolson <ddolson@sandvine.com<mailto:ddolson@sandvine.com>>; RFC Errata System <rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>>; vf0213@gmail.com<mailto:vf0213@gmail.com>; jari.arkko@ericsson.com<mailto:jari.arkko@ericsson.com>; john.loughney@nokia.com<mailto:john.loughney@nokia.com>; glenzorn@gmail.com<mailto:glenzorn@gmail.com>; bclaise@cisco.com<mailto:bclaise@cisco.com>; warren@kumari.net<mailto:warren@kumari.net>; jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>; lionel.morand@orange.com<mailto:lionel.morand@orange.com> Cc: dime@ietf.org<mailto: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 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<mailto:vf0213@gmail.com>; jari.arkko@ericsson.com<mailto:jari.arkko@ericsson.com>; john.loughney@nokia.com<mailto:john.loughney@nokia.com>; glenzorn@gmail.com<mailto:glenzorn@gmail.com>; bclaise@cisco.com<mailto:bclaise@cisco.com>; warren@kumari.net<mailto:warren@kumari.net>; jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>; lionel.morand@orange.com<mailto:lionel.morand@orange.com> Cc: dime@ietf.org<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5084&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C627e5f999b6e4750fae408d4e313a562%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636383120901606733&sdata=rzTCFkfc7KCzGxNhdCsnCjVSFOVui9lJyAmsWKxdThA%3D&reserved=0> -------------------------------------- Type: Technical Reported by: Priyatosh Mandal <priyatos@cdot.in<mailto: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 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] [Technical Errata Reported] RFC6733 (5084) RFC Errata System
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Priyatosh Mandal
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Yuval Lifshitz
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Dave Dolson
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Priyatosh Mandal
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Bertz, Lyle T [CTO]
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Priyatosh Mandal
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Priyatosh Mandal
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Dave Dolson
- Re: [Dime] [Technical Errata Reported] RFC6733 (5… Priyatosh Mandal