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

["Priyatosh Mandal" <[e-mail]>]

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

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