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

[Per Hedeland <[e-mail]>]

On 2019-02-21 14:22, Martin Bjorklund wrote:
> 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.

Hm, right, the remainder of the change to the 5th paragraph should be
kept (I originally misread it as *only* adding "or <persist-id>" there
too).

> Do you see any other issues with the proposed text?

No, it seems fine - a useful clarification.

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

+1

--Per

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