Re: [Dime] [Technical Errata Reported] RFC6733 (5084)
Priyatosh Mandal <priyotoshtsp@gmail.com> Mon, 14 August 2017 14:17 UTC
Return-Path: <priyotoshtsp@gmail.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 08F741321ED for <dime@ietfa.amsl.com>; 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 <dime@ietfa.amsl.com>; 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 <dime@ietf.org>; Mon, 14 Aug 2017 07:17:30 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id x191so50807778qka.5 for <dime@ietf.org>; 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 <priyotoshtsp@gmail.com>
Date: Mon, 14 Aug 2017 19:47:28 +0530
Message-ID: <CADTSkb1574M34oBKk7vUisrOCfcA8LD59SCRqwq-DftuJGbi1Q@mail.gmail.com>
To: "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Cc: Dave Dolson <ddolson@sandvine.com>, "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>
Content-Type: multipart/alternative; boundary="001a11487bc6aa83080556b7521f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/UWwZxKdOCanEddoevEdn6mWaxws>
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 <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: Mon, 14 Aug 2017 14:17:34 -0000
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> 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 <ddolson@sandvine.com>; 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 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 > <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> > > 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