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

"Jouni" <jouni.nospam@gmail.com> Wed, 16 August 2017 05:18 UTC

Return-Path: <jouni.nospam@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 B110C1321A5 for <dime@ietfa.amsl.com>; Tue, 15 Aug 2017 22:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 GJjdlw9vuH3m for <dime@ietfa.amsl.com>; Tue, 15 Aug 2017 22:18:06 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 B06E41200C5 for <dime@ietf.org>; Tue, 15 Aug 2017 22:18:05 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id y15so11618184lfd.5 for <dime@ietf.org>; Tue, 15 Aug 2017 22:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=bQePpQTFZ+PQfY6k9Caw50hrY4mMVa2g2FmW0odliW0=; b=InMFKiGwRfTfm/1+S15I3NGYtlz7v9FQdZyV9jgxZ54M9r8ig5orBZDjsr4rcia0ed RRhD/YQawBIk0YjOmdWAVlTYCbB8qo5slIUwS/8EONXxR5qxdA1ACvs7GfKb5SDwF5dj TbCCXLdZvZXFcCTXYvBK78Xt2Pgj6FjAW+EH23XPFgW/IKQADOMalo/rvJiW0ymoNzW8 sUBKPjgCUJe02VIDAImUkoJCIteYkpaov0ELOPii3t4BbuU45LigxZgMBgyQD+0fIOTk wTV+XoaAXshI4EPvsfIG8kUrc5FE/w7RpEShcwPfq8w0M1AjOzjt+Gm38laLUgiIxqvd Esfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=bQePpQTFZ+PQfY6k9Caw50hrY4mMVa2g2FmW0odliW0=; b=R6LpHVGPiKaZXVa3+khWZX+OICb+/FjeX+P8OWtTQXmFZLhZ5pPkmhx4NJqaA7tWvR lOjkGG8MpiIth1tqHfMjSgVMUIngOWPQhLRpaY9KlCRjjGNQjVjHTzH3plM+/23beuVe IOjN8BVrXasiqYKn+8LrOeHvwFWz+DD56JWzTMR6R9v9Sm2iogDzYWIkgu38jOWvSnqS lxCIpkCuxICoBSXBq3Cvj1/diY3Z00SbQkIYzJ6MGmTgxu9pUjVoVxSlFr+lhmcoX4sp 46gCE8cVBPXd/WlyPCXnvRW9nlNricvfkUtlSSZKdehvx2RFaaf+7F/VDHhoe5zMDOkZ Dhyg==
X-Gm-Message-State: AHYfb5hU/BDWQvySy0CUz1BYs7GFSvhSpsTRVEQVlp1ctRZ+oanPTgs5 RHC3TY4cqqvFmjNOOrE=
X-Received: by 10.46.20.74 with SMTP id 10mr163179lju.11.1502860683762; Tue, 15 Aug 2017 22:18:03 -0700 (PDT)
Received: from JOKO (mobile-access-5d6aed-174.dhcp.inet.fi. [93.106.237.174]) by smtp.gmail.com with ESMTPSA id f89sm4468lfb.68.2017.08.15.22.18.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 22:18:02 -0700 (PDT)
From: "Jouni" <jouni.nospam@gmail.com>
To: "'Priyatosh Mandal'" <priyotoshtsp@gmail.com>, <dime@ietf.org>
References: <CADTSkb3XRQQeeULWLcO3YNdKf7WpG=c=2LZmpD+CA0ncW=+8+g@mail.gmail.com>
In-Reply-To: <CADTSkb3XRQQeeULWLcO3YNdKf7WpG=c=2LZmpD+CA0ncW=+8+g@mail.gmail.com>
Date: Wed, 16 Aug 2017 08:18:01 +0300
Message-ID: <330801d3164f$08a93250$19fb96f0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ0oGzN8D7T13kr+TMaG3CCsQS+CKFDXPMw
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/p0PKJFAv_SFqDqBkhNqQIoW4zCc>
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 05:18:09 -0000

Not until it has been officially announced by the chairs/AD etc.

- Jouni

> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Priyatosh Mandal
> Sent: Wednesday, August 16, 2017 06: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>; 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.
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime