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>om>; RFC Errata System <
> rfc-editor@rfc-editor.org>gt;; 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.
>