Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)

[Martin Bjorklund <[e-mail]>]

Hi,

Per Hedeland <[e-mail]> wrote:
> On 2019-02-20 01:44, Megan Ferguson wrote:
> > Jonathan and Benoit,
> > We have edited the "corrected text in this errata report as
> > suggested by Jonathan.
> 
> I don't know if this change - i.e. the addition of the text "or
> <persist-id>" in two places - should affect the status of the
> document, but it seems to me that it can then no longer be considered
> a "clarification", since it proposes a change to the semantics
> specified in RFC 6241. As far as I can see, it is clear from 6241 that
> the presence of the <persist-id> parameter does not affect the
> persistence, only the presence of the <persist> parameter does that.

Hmm, I missed this detail.

It is clearly not correct to say that the <persist-id> affects
persistence.   So s/or <persist-id>// in the 4th and 5th paragraphs.

Do you see any other issues with the proposed text?

(An editorial change - the 4th para should be split into two, just as
in the original text)



/martin






> 
> Furthermore, I'm afraid I fail to find any motivation for this change
> in the quoted message from Jonathan (as far as I can see, this message
> was not sent to the mailing list).
> 
> --Per Hedeland
> 
> > We have left the status of this report as Held for Document
> > Update.
> > Please let us know if any further action is necessary on our part.
> > The report itself is viewable at
> > https://www.rfc-editor.org/errata/eid3821.
> > Old (as in Jonathans original report):
> > If the session issuing a sequence of one or more
> > confirmed commits is terminated for any reason before the confirm
> > timeout expires, the server MUST restore the configuration to its
> > state before the sequence of confirmed commits was issued, unless
> > the last confirmed commit also included a <persist>
> > element.
> > If the device reboots for any reason before the confirm timeout
> > expires, the server MUST restore the configuration to its state
> > before the sequence of confirmed commits was issued.
> > New (as updated by Jonathans email - see the last line of both
> > paragraphs):
> > If the session issuing a sequence of one or more
> > confirmed commits is terminated for any reason before the confirm
> > timeout expires, the server MUST restore the configuration to its
> > state before the sequence of confirmed commits was issued, unless
> > the last confirmed commit also included a <persist> or <persist-id>
> > element.
> > If the device reboots for any reason before the confirm timeout
> > expires, the server MUST restore the configuration to its state
> > before the sequence of confirmed commits was issued, unless the last
> > confirmed commit also included a <persist> or <persist-id> element.
> > Thank you.
> > RFC Editor/mf
> > 
> >> Hi,
> >>   I raised erratum 3821 to clarify the meaning of the term "confirmed
> >>   commit" for those not familiar with the use of the term within
> >>   JUNOS. Both the original text and the erratum include text that states
> >>   If the device reboots for any reason before the confirm timeout
> >>   expires, the server MUST restore the configuration to its state before
> >>   the sequence of confirmed commits was issued.. I have since
> >>   discovered the description of the persist leaf on page 102 that
> >>   includes the statement, A persistent confirmed commit is not aborted
> >>   if the NETCONF session terminates.  The only way to abort a persistent
> >>   confirmed commit is to let the timer expire, or to use the
> >>   <cancel-commit> operation. Consequently, the replacement text should
> >>   read:
> >>   8.4.1.  Description
> >>   The :confirmed-commit:1.1 capability indicates that the server will
> >> support the <cancel-commit> operation, the <confirmed>, <confirm-
> >> timeout>, <persist>, and <persist-id> parameters for the <commit>
> >> operation, and differentiate between a to be confirmed <commit>
> >> operation (a confirmed commit) and a confirming <commit>
> >> operation. See Section 8.3 for further details on the <commit>
> >> operation.
> >>   A confirmed <commit> operation MUST be reverted if a confirming
> >> commit is not issued within the timeout period (by default 600
> >> seconds = 10 minutes). The confirming commit is a <commit> operation
> >> without the <confirmed> parameter and, if successful, cannot be
> >> reverted. The timeout period can be adjusted with the <confirm-
> >> timeout> parameter. If a follow-up confirmed <commit> operation is
> >> issued before the timer expires, the timer is reset to the new value
> >> (600 seconds by default). Both the confirming commit and a follow-up
> >> confirmed <commit> operation MAY introduce additional changes to the
> >> configuration.
> >>   If the <persist> element is not given in the confirmed commit
> >> operation, any follow-up commit and the confirming commit MUST be
> >> issued on the same session that issued the confirmed commit. If the
> >> <persist> element is given in the confirmed <commit> operation, a
> >> follow-up commit and the confirming commit can be given on any
> >> session, and they MUST include a <persist-id> element with a value
> >> equal to the given value of the <persist> element.
> >>   If the server also advertises the :startup capability, a <copy-
> >> config> from running to startup is also necessary to save the
> >> changes to startup. If the session issuing a sequence of one or more
> >> confirmed commits is terminated for any reason before the confirm
> >> timeout expires, the server MUST restore the configuration to its
> >> state before the sequence of confirmed commits was issued, unless
> >> the last confirmed commit also included a <persist> or <persist-id>
> >> element.
> >>   If the device reboots for any reason before the confirm timeout
> >> expires, the server MUST restore the configuration to its state
> >> before the sequence of confirmed commits was issued, unless the last
> >> confirmed commit also included a <persist> or <persist-id> element.
> >>   If a confirming commit is not issued, the device will revert its
> >> configuration to the state prior to the issuance of the first in the
> >> current sequence of confirmed commits. To cancel the current
> >> sequence of confirmed commits and revert changes without waiting for
> >> the confirm timeout to expire, the client can explicitly restore the
> >> configuration to its state before the sequence of confirmed commits
> >> was issued, by using the <cancel-commit> operation.
> >>   Jonathan Hansford
> > On Jan 13, 2014, at 7:53 AM, RFC Errata System
> > <[e-mail]> wrote:
> > 
> >> The following errata report has been held for document update
> >> for RFC6241, "Network Configuration Protocol (NETCONF)".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821
> >>
> >> --------------------------------------
> >> Status: Held for Document Update
> >> Type: Editorial
> >>
> >> Reported by: Jonathan Hansford <[e-mail]>
> >> Date Reported: 2013-12-06
> >> Held by: Benoit Claise (IESG)
> >>
> >> Section: 8.4.1
> >>
> >> Original Text
> >> -------------
> >> 8.4.1.  Description
> >>
> >> The :confirmed-commit:1.1 capability indicates that the server will
> >> support the <cancel-commit> operation and the <confirmed>,
> >> <confirm-timeout>, <persist>, and <persist-id> parameters for the
> >> <commit> operation.  See Section 8.3 for further details on the
> >> <commit> operation.
> >>
> >> A confirmed <commit> operation MUST be reverted if a confirming
> >> commit is not issued within the timeout period (by default 600
> >> seconds = 10 minutes).  The confirming commit is a <commit> operation
> >> without the <confirmed> parameter.  The timeout period can be
> >> adjusted with the <confirm-timeout> parameter.  If a follow-up
> >> confirmed <commit> operation is issued before the timer expires, the
> >> timer is reset to the new value (600 seconds by default).  Both the
> >> confirming commit and a follow-up confirmed <commit> operation MAY
> >> introduce additional changes to the configuration.
> >>
> >> If the <persist> element is not given in the confirmed commit
> >> operation, any follow-up commit and the confirming commit MUST be
> >> issued on the same session that issued the confirmed commit.  If the
> >> <persist> element is given in the confirmed <commit> operation, a
> >> follow-up commit and the confirming commit can be given on any
> >> session, and they MUST include a <persist-id> element with a value
> >> equal to the given value of the <persist> element.
> >>
> >> If the server also advertises the :startup capability, a
> >> <copy-config> from running to startup is also necessary to save the
> >> changes to startup.
> >>
> >> If the session issuing the confirmed commit is terminated for any
> >> reason before the confirm timeout expires, the server MUST restore
> >> the configuration to its state before the confirmed commit was
> >> issued, unless the confirmed commit also included a <persist>
> >> element.
> >>
> >> If the device reboots for any reason before the confirm timeout
> >> expires, the server MUST restore the configuration to its state
> >> before the confirmed commit was issued.
> >>
> >> If a confirming commit is not issued, the device will revert its
> >> configuration to the state prior to the issuance of the confirmed
> >> commit.  To cancel a confirmed commit and revert changes without
> >> waiting for the confirm timeout to expire, the client can explicitly
> >> restore the configuration to its state before the confirmed commit
> >> was issued, by using the <cancel-commit> operation.
> >>
> >> Corrected Text
> >> --------------
> >> 8.4.1.  Description
> >>
> >> The :confirmed-commit:1.1 capability indicates that the server will
> >> support the <cancel-commit> operation, the <confirmed>, <confirm-
> >> timeout>, <persist>, and <persist-id> parameters for the <commit>
> >> operation, and differentiate between a to be confirmed <commit>
> >> operation (a confirmed commit) and a confirming <commit>
> >> operation. See Section 8.3 for further details on the <commit>
> >> operation.
> >>
> >> A confirmed <commit> operation MUST be reverted if a confirming
> >> commit is not issued within the timeout period (by default 600
> >> seconds = 10 minutes). The confirming commit is a <commit> operation
> >> without the <confirmed> parameter and, if successful, cannot be
> >> reverted. The timeout period can be adjusted with the <confirm-
> >> timeout> parameter. If a follow-up confirmed <commit> operation is
> >> issued before the timer expires, the timer is reset to the new value
> >> (600 seconds by default). Both the confirming commit and a follow-up
> >> confirmed <commit> operation MAY introduce additional changes to the
> >> configuration.
> >>
> >> If the <persist> element is not given in the confirmed commit
> >> operation, any follow-up commit and the confirming commit MUST be
> >> issued on the same session that issued the confirmed commit. If the
> >> <persist> element is given in the confirmed <commit> operation, a
> >> follow-up commit and the confirming commit can be given on any
> >> session, and they MUST include a <persist-id> element with a value
> >> equal to the given value of the <persist> element.
> >>
> >> If the server also advertises the :startup capability, a <copy-
> >> config> from running to startup is also necessary to save the
> >> changes to startup. If the session issuing a sequence of one or more
> >> confirmed commits is terminated for any reason before the confirm
> >> timeout expires, the server MUST restore the configuration to its
> >> state before the sequence of confirmed commits was issued, unless
> >> the last confirmed commit also included a <persist> element.
> >>
> >> If the device reboots for any reason before the confirm timeout
> >> expires, the server MUST restore the configuration to its state
> >> before the sequence of confirmed commits was issued.
> >>
> >> If a confirming commit is not issued, the device will revert its
> >> configuration to the state prior to the issuance of the first in the
> >> current sequence of confirmed commits. To cancel the current
> >> sequence of confirmed commits and revert changes without waiting for
> >> the confirm timeout to expire, the client can explicitly restore the
> >> configuration to its state before the sequence of confirmed commits
> >> was issued, by using the <cancel-commit> operation.
> >>
> >> Notes
> >> -----
> >> This erratum seeks to clarify the meaning of the term "confirmed
> >> commit" for those not familiar with the use of the term within
> >> JUNOS. In particular, that the use of "confirmed" is not in the sense
> >> of the adjective (meaning "firmly established") but rather that the
> >> commit needs to be confirmed. It also emphasises that a "confirming
> >> commit" cannot be reverted. Finally it identifies that it is possible
> >> to have a sequence of "confirmed commits" prior to a "confirming
> >> commit" and that, should no "confirming commit" be received, the
> >> configuration will revert to the state prior to the first "confirmed
> >> commit" in the sequence.
> >>
> >> --------------------------------------
> >> RFC6241 (draft-ietf-netconf-4741bis-10)
> >> --------------------------------------
> >> Title               : Network Configuration Protocol (NETCONF)
> >> Publication Date    : June 2011
> >> Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed.,
> >> A. Bierman, Ed.
> >> Category            : PROPOSED STANDARD
> >> Source              : Network Configuration
> >> Area                : Operations and Management
> >> Stream              : IETF
> >> Verifying Party     : IESG
> >>
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> > 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>