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

[Priyatosh Mandal <[e-mail]>]

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]" <[e-mail]>
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:[e-mail]] *On Behalf Of *Priyatosh
> Mandal
> *Sent:* Monday, August 14, 2017 6:19 AM
> *To:* Dave Dolson <[e-mail]>; RFC Errata System <
> [e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *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; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Cc: *[e-mail]
> *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 <[e-mail]>
>
> 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: [phone]
> --------------------------------------------------------------------------------
>
> ::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: [phone]
> --------------------------------------------------------------------------------
>
> ::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.
>