Re: [Dime] [Technical Errata Reported] RFC6733 (5084)

Priyatosh Mandal <priyotoshtsp@gmail.com> Wed, 16 August 2017 16:30 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 61CEA1320BE for <dime@ietfa.amsl.com>; 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 <dime@ietfa.amsl.com>; 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 <dime@ietf.org>; Wed, 16 Aug 2017 09:30:49 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id v29so23806081qtv.3 for <dime@ietf.org>; 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: <C43C255C7106314F8D13D03FA20CFE49A8ACB1CD@wtl-exchp-2.sandvine.com>
References: <CADTSkb3XRQQeeULWLcO3YNdKf7WpG=c=2LZmpD+CA0ncW=+8+g@mail.gmail.com> <C43C255C7106314F8D13D03FA20CFE49A8ACAD67@wtl-exchp-2.sandvine.com> <e37d9a0e462c453ca94f0e6afaf9154b@plswe13m04.ad.sprint.com> <C43C255C7106314F8D13D03FA20CFE49A8ACB1CD@wtl-exchp-2.sandvine.com>
From: Priyatosh Mandal <priyotoshtsp@gmail.com>
Date: Wed, 16 Aug 2017 22:00:47 +0530
Message-ID: <CADTSkb3YR0zSkYy_U-k9SFgkgmSP8cRADwgM=NGGTaij4yFrAw@mail.gmail.com>
To: Yuval Lifshitz <ylifshitz@sandvine.com>
Cc: "dime@ietf.org" <dime@ietf.org>, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Content-Type: multipart/alternative; boundary="001a1141e4ca1f773a0556e16b99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/9aZO5lrJgqWV2LzcwyfvtOxoSLU>
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:53 -0000

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" <ylifshitz@sandvine.com> 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 <priyotoshtsp@gmail.com>om>; 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]" <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 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 <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 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 <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 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
>