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

["Jouni" <[e-mail]>]

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

- Jouni

> -----Original Message-----
> From: DiME [mailto:[e-mail]] On Behalf Of Priyatosh Mandal
> Sent: Wednesday, August 16, 2017 06:52 AM
> To: [e-mail]
> 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]" <[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 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:[e-mail]]On Behalf Of Priyatosh Mandal
> Sent: Monday, August 14, 2017 6:19 AM
> To: Dave Dolson <[e-mail]>; RFC Errata System <rfc-editor@rfc-
> editor.org>; [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 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; [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
> 
> -----------------------------------------------------------------------
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime