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

Priyatosh Mandal <priyotoshtsp@gmail.com> Wed, 16 August 2017 03:51 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 9859D132190 for <dime@ietfa.amsl.com>; 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 <dime@ietfa.amsl.com>; 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 <dime@ietf.org>; Tue, 15 Aug 2017 20:51:46 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id s6so14674053qtc.1 for <dime@ietf.org>; 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 <priyotoshtsp@gmail.com>
Date: Wed, 16 Aug 2017 09:21:44 +0530
Message-ID: <CADTSkb3XRQQeeULWLcO3YNdKf7WpG=c=2LZmpD+CA0ncW=+8+g@mail.gmail.com>
To: "dime@ietf.org" <dime@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/qYSdH_Bgf5hHZqMaBq6SgQQRanM>
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 <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 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]" <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>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-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 <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.