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

Priyatosh Mandal <priyotoshtsp@gmail.com> Wed, 16 August 2017 16:41 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 524D3132351 for <dime@ietfa.amsl.com>; Wed, 16 Aug 2017 09:41:46 -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 DBcus9xAZ-k1 for <dime@ietfa.amsl.com>; Wed, 16 Aug 2017 09:41:42 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 9668C120727 for <dime@ietf.org>; Wed, 16 Aug 2017 09:41:42 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id a18so24072927qta.0 for <dime@ietf.org>; Wed, 16 Aug 2017 09:41:42 -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=OnG5+FXRnw0s4HxpbP93PxcnnHQ8lvci/J2tF1xprMc=; b=uf639aPYiE8U7q8eHB/4hAZ3iBgjYXq/M7KO4ITi1xBHziR4z2ZKU6EOUX2dnqGd/O Y6oG09AGOyLFIP7Bsw254FPP4ElxAGqHtGEgNomTDcgKyOU/1QbheOdgFGg8kEV+2zxb DX5uRJj2HeKM6XP5FKPoQZmJmXfzB0i44vwGjmnS3w9O2NwqdOb4G/Mq445TIRAhksP9 pPwu5frHDtmxGYgsRU0qw0nJbi53wcxTPc+MMXxhfZDTMuoVUIuTgqpT3pph75hWE92X 8eWoKnPhJTy+40Y+0IWd0R54qYgjbQzyA3sw6sm2iKbd5SIJUx84CB1d5Pa64f0/zaTO WvRQ==
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=OnG5+FXRnw0s4HxpbP93PxcnnHQ8lvci/J2tF1xprMc=; b=W/HFi6R99T3aOlzUwXYWwhGzHCul64NYyJUynE0cMc9kXd6cDx53UUqUMk6n5v3Y54 eS3EuUqKEwQSkq9zer7KmHjWE0BYqR9aAsXag7x4gdY0za4CplAHzwjRJDaaS1cy1hj8 ZGyolxyUlu5EHEypL80JwAcyBliYi1Sy4bKc58ExtSguFpAW0bcawc/WaShibcrbyhvl hh6G3QgDiJBDP+QH1N7GBe0a1jwh04jQ6620CbEu4ZZGlwsF0Vl53RvxD++WhdLFYoGv 7s6pzlWcLD9mGidg4wDgKQSBfrzbFf7FFrc0waRVTeH6mV3yU3gNtlSFjSOKoQzb2yY8 NQEA==
X-Gm-Message-State: AHYfb5gjQkObz8k1JcYbDZwPBnGBdJqHqxEO8iFlQkae8XMJzxNjUa9p UX601/sEl5E3OsKto/MfyUGrfojh5g==
X-Received: by 10.237.35.203 with SMTP id k11mr3566731qtc.182.1502901701581; Wed, 16 Aug 2017 09:41:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:41:40 -0700 (PDT)
Received: by 10.200.39.248 with HTTP; Wed, 16 Aug 2017 09:41:40 -0700 (PDT)
In-Reply-To: <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> <20170816163045.5115986.81818.28569@sandvine.com>
From: Priyatosh Mandal <priyotoshtsp@gmail.com>
Date: Wed, 16 Aug 2017 22:11:40 +0530
Message-ID: <CADTSkb1ShYR6hDugUANPFx3sDHVgw0Y3ETVGZOmo=BrGKRRJ3A@mail.gmail.com>
To: Dave Dolson <ddolson@sandvine.com>
Cc: "john.loughney@nokia.com" <john.loughney@nokia.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "glenzorn@gmail.com" <glenzorn@gmail.com>, "bclaise@cisco.com" <bclaise@cisco.com>, "dime@ietf.org" <dime@ietf.org>, "jari.arkko@ericsson.com" <jari.arkko@ericsson.com>, "lionel.morand@orange.com" <lionel.morand@orange.com>, "vf0213@gmail.com" <vf0213@gmail.com>, "warren@kumari.net" <warren@kumari.net>, Priyatosh Mandal <priyatos@cdot.in>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "Bertz, Lyle T [CTO]" <Lyle.T.Bertz@sprint.com>
Content-Type: multipart/alternative; boundary="001a114227de0e22a90556e19216"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/L9xHoFT2nL-rk-Od7BxR6mclm5c>
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:41:46 -0000

Sir,
Consider the situation of increment of origin-state-id from maximum to the
next will be 0 only. The  node which will be sending 0, has to modify the
value internally to 1, before sending to peer. Here also the peer receiving
the information will be confused what to do with that? Because it is not an
incremented value. So this has to be explained somewhere. Also this is not
probably backward compatible.
Regards,
Dr. Priyatosh Mandal, Ph. D.

On Aug 16, 2017 10:00 PM, "Dave Dolson" <ddolson@sandvine.com> wrote:

> 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>
> 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.
>>
>