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

[<[e-mail]>]

Hi,

Apologies for taking so long to reply. I have been out of the loop for some
time. And apologies for not involving the mailing list. The RFC Errata page
states, "Note: To report an error in an existing erratum, please contact the
RFC Editor", so that is what I did. Maybe the note could be a bit more
informative for those not au fait with all the correct procedures to follow
within the IETF.

Further, I concur only the <persist> parameter affects persistence, and not
the <persist-id> parameter. Apologies again.

I am trying to understand the correct behaviour of clients and servers with
persistent confirmed commits, and in particular the persistence of locks and
configuration changes following a session termination. The reason is that I
have dealt with some elements that always restart when their configuration
changes, and I want to understand what is and isn't possible in that
scenario with NETCONF (RFC 6241). It would be helpful if someone could
confirm (or otherwise) my thoughts below. We intend to support :candidate
but not :writable-running.

THE PERSISTENCE OF A CONFIRMED COMMIT FOLLOWING SESSION TERMINATION

Section 8.3.5.2 :candidate <lock> and <unlock> states:

    When a client fails with outstanding changes to the candidate
    configuration, recovery can be difficult.  To facilitate easy
    recovery, any outstanding changes are discarded when the lock is
    released, whether explicitly with the <unlock> operation or
    implicitly from session failure.

Section 8.4.1 :confirmed-commit states:

    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.

The first paragraph from Section 8.4.1 mentions a corner case not covered in
Section 8.3.5.2. Assuming the description of that corner case to be correct,
it would be useful if an Erratum was raised on Section 8.3.5.2 to also
mention the corner case (see below).

The second paragraph from Section 8.4.1 makes it clear a device reboot will
revert the server to the configuration before the start of the confirmed
commit. So, on reboot, the device needs to determine whether a confirmed
commit was ongoing and, if it was, ignore both <startup> (if supported) and
<running>, and revert <running>. So if there is any device that reboots when
its configuration changes, persistent confirmed commits WILL NOT survive the
reboot and, if :writable-running is not supported, a standard <commit>
should be used instead. For all other causes of session termination, a
persistent confirmed commit WILL persist.

THE PERSISTENCE OF LOCKS FOLLOWING SESSION TERMINATION

Section 7.5 <lock> states:
    A lock MUST NOT be granted if any of the following conditions is
    true:

    *  A lock is already held by any NETCONF session or another
       entity.

    *  The target configuration is <candidate>, it has already been
       modified, and these changes have not been committed or rolled
       back.

    *  The target configuration is <running>, and another NETCONF
       session has an ongoing confirmed commit (Section 8.4).

    The server MUST respond with either an <ok> element or an
    <rpc-error>.

    A lock will be released by the system if the session holding the
    lock is terminated for any reason.

In the netconf WG email thread "[Netconf] Is there a problem with confirmed
commits?", I summarised my understanding of the above as, "it seems the
persist-id can be considered a de facto lock on both <candidate> and
<running> that is released on a confirming <commit>, a timeout on the
confirmed <commit> or a <cancel-commit>. Unlike other locks, this "lock"
could be shared between clients by sharing the persist-id." However, on
further examination it appears the lock on <candidate> will not persist if
the session terminates after a confirmed commit but before the confirming
commit, as all the changes currently in <candidate> will have been
committed. So is the intention for <candidate> to be not lockable for the
same duration as <running> during a confirmed commit? If so, it would be
useful if an Erratum was raised on Section 7.5 to clarify (see below).
However, since <edit-config> and <copy-config> operations with <candidate>
as the target cannot include the persist-id, there is no way for any session
to update <candidate> during a persistent confirmed commit following session
termination.

SOME OTHER CLARIFICATIONS SOUGHT

Section 7.5 <lock> states:

    If the lock is already held, the <error-tag> element will be 
    "lock-denied" and the <error-info> element will include the 
    <session-id> of the lock owner.  If the lock is held by a non- 
    NETCONF entity, a <session-id> of 0 (zero) is included.  Note that
    any other entity performing a lock on even a partial piece of a 
    target will prevent a NETCONF lock (which is global) from being 
    obtained on that target.

How should the error be reported if the lock is an implicit lock due to a
persistent confirmed commit that has survived session termination? I have
proposed a couple of alternatives as Errata below.

Section 8.4.4.1 <cancel-commit> states:
    Cancels an ongoing confirmed commit.  If the <persist-id>
    parameter is not given, the <cancel-commit> operation MUST be
    issued on the same session that issued the confirmed commit.

With a persistent confirmed commit, does a <cancel-commit> issues on the
same session that issued the confirmed commit require the <persist-id>
parameter?

FINAL THOUGHTS

In Section 7.5 <lock> it states:
    When the lock is acquired, the server MUST prevent any changes to
    the locked resource other than those requested by this session.
    SNMP and CLI requests to modify the resource MUST fail with an
    appropriate error.

It seems to me this is the same behaviour the server should exhibit with an
ongoing confirmed commit (except, maybe, wrt <candidate>). If that is the
case, it would be useful if an Erratum was raised on Section 8.4.1 to
clarify (see below).

PROPOSED ERRATA

Sections 7.5, 8.3.5.2 and 8.4.1

In Section 7.5:

OLD:
    When the lock is acquired, the server MUST prevent any changes to
    the locked resource other than those requested by this session.
    SNMP and CLI requests to modify the resource MUST fail with an
    appropriate error.

    :

    A lock MUST NOT be granted if any of the following conditions is
    true:
    *  A lock is already held by any NETCONF session or another
       entity.

    *  The target configuration is <candidate>, it has already been 
       modified, and these changes have not been committed or rolled
       back. 

    :

    If the lock is already held, the <error-tag> element will be 
    "lock-denied" and the <error-info> element will include the 
    <session-id> of the lock owner.  If the lock is held by a non- 
    NETCONF entity, a <session-id> of 0 (zero) is included.  Note that
    any other entity performing a lock on even a partial piece of a 
    target will prevent a NETCONF lock (which is global) from being 
    obtained on that target.
 
In Section 8.3.5.2:

OLD:
    When a client fails with outstanding changes to the candidate
    configuration, recovery can be difficult.  To facilitate easy
    recovery, any outstanding changes are discarded when the lock is
    released, whether explicitly with the <unlock> operation or
    implicitly from session failure.

In Section 8.4.1:

OLD:
    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.

It should say:

In Section 7.5:

NEW:
    When the lock is acquired, the server MUST prevent any changes to
    the locked resource other than those requested by this session.
    SNMP and CLI requests to modify the resource MUST fail with an
    appropriate error.

    :
    A lock MUST NOT be granted if any of the following conditions is
    true:
    *  A lock is already held by any NETCONF session or another
       entity.

    *  The target configuration is <candidate>, it has already been
       modified, and these changes have not been committed or rolled
       back, or another NETCONF session has an ongoing confirmed
       commit (Section 8.4).

    :

EITHER

    If the lock is already held, or another NETCONF session has an 
    ongoing confirmed commit (Section 8.4), the <error-tag> element
    will be "lock-denied" and the <error-info> element will include
    the <session-id> of the lock owner.  If the lock is held by a non-
    NETCONF entity, a <session-id> of 0 (zero) is included.  Note that
    any other entity performing a lock on even a partial piece of a
    target will prevent a NETCONF lock (which is global) from being
    obtained on that target. 
                                                                 
OR
                                                                 
    If the lock is already held, the <error-tag> element will be
    "lock-denied" and the <error-info> element will include the
    <session-id> of the lock owner.  If the lock is held by a non-
    NETCONF entity, or another NETCONF session has an ongoing
    confirmed commit (Section 8.4), a <session-id> of 0 (zero) is
    included.  Note that any other entity performing a lock on even a
    partial piece of a target will prevent a NETCONF lock (which is
    global) from being obtained on that target.

In Section 8.3.5.2:

NEW:
    Except in the case of a persistent confirmed commit (Section 
    8.4.5.1), when a client fails with outstanding changes to the 
    candidate configuration, recovery can be difficult.  To facilitate
    easy recovery, any outstanding changes are discarded when the lock
    is released, whether explicitly with the <unlock> operation or
    implicitly from session failure.

In Section 8.4.1:

NEW: 
    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.

    With an ongoing persistent confirmed commit, the server MUST
    prevent any changes to the candidate configuration datastore
    following session termination, and MUST prevent any changes to
    the running configuration datastore other than by a session
    using the <persist-id> parameter. SNMP and CLI requests to
    modify either resource MUST fail with an appropriate error.

Jonathan

-----Original Message-----
From: Per Hedeland <[e-mail]> 
Sent: 21 February 2019 13:48
To: Martin Bjorklund <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: [netconf] [Errata Held for Document Update] RFC6241 (3821)

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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus