Subject: [Netconf] [Technical Errata Reported] RFC6241 (3821)

From: RFC Errata System <[email-masked]>
Date: Fri, 6 Dec 2013 02:07:37 -0800 (PST)

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Jonathan Hansford <[email-masked]>

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

Instructions:
-------------
This errata 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 (IESG)
can log in to change the status and edit the report, if necessary. 

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 09 Dec 2013 21:34:58 +0100

We have a set of 3 new errata reported to RFC6241.
See: http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table

We would like to hear from the authors/editors what their
opinion is on the reported errata.

It is probably best to report your views to the netconf mailing list.
but if you rather disuss it here first, that is OK too. We probably
have to repeat the discussion on the mlist later if we do, so best to
do it on the mailing list. It will hopefully trigger views from others aswell.

Thanks,
Bert and Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Dec 2013 22:07:52 +0100

> do it on the mailing list. It will hopefully trigger views from others aswell.

I think it would help a lot if there would be a motivation or some
sort of an explanation in addition to the OLD NEW text. As it is, I
have to guess what the submitter wants to achieve with these errata.
Since these are technical errata, it should be possible to describe
the problem/bug that is being fixed. It seems that the submitter is
trying to address multiple issues in those changes. Anyway, an
explanation would have been nice to have.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 09 Dec 2013 21:27:56 +0000

Apologies,

This was my first submission of errata and they came out of my September 
email and the subsequent thread about confirmed commits 
(http://www.ietf.org/mail-archive/web/netconf/current/msg08314.html). 
Consequently there has already been some discussion around the issue. 
The points I was seeking to clarify related to the definition of the 
term "Confirmed commit" (something that makes sense to those who have 
had exposure to JUNOS but appeared counter-intuitive to me in that a 
confirmed commit is one that hasn't yet been confirmed) and the fact 
that it is possible to have a sequence of confirmed commits prior to the 
confirming commit. I'm happy to add that text to the errata.

Jonathan

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 10 Dec 2013 11:22:08 +0000

Is there any way of adding Notes to an existing erratum? I cannot
find one. For the record: 

Erratum 3821:
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.

Erratum 3822:
This erratum
seeks to clarify that <cancel-commit> will cancel all configuration
changes arising from a sequence of "confirmed commits".

Erratum
3823:
This erratum seeks to clarify that the use of the "persist"
parameter will persist all configuration changes arising from a sequence
of "confirmed commits". 

Jonathan
>> On
Mon, Dec 09, 2013 at 09:34:58PM +0100, Bert Wijnen (IETF) wrote: 

>>> We have a set of 3 new errata reported to RFC6241. See:
http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table
[1] We would like to hear from the authors/editors what their opinion
is on the reported errata. It is probably best to report your views to
the netconf mailing list. but if you rather disuss it here first, that
is OK too. We probably have to repeat the discussion on the mlist later
if we do, so best to do it on the mailing list. It will hopefully
trigger views from others aswell.
>> I think it would help a lot if
there would be a motivation or some sort of an explanation in addition
to the OLD NEW text. As it is, I have to guess what the submitter wants
to achieve with these errata. Since these are technical errata, it
should be possible to describe the problem/bug that is being fixed. It
seems that the submitter is trying to address multiple issues in those
changes. Anyway, an explanation would have been nice to have. /js
_______________________________________________
> Netconf mailing list
[email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Links:
------
[1]
http://www.rfc-editor.org/errata_search.php?rfc=6241&amp;rec_status=15&amp;presentation=table

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Dec 2013 13:28:19 +0100 (CET)

"Bert Wijnen (IETF)" <[email-masked]> wrote:
> See:

I think the proposed text is fine, however I do not know if it
qualifies as an errata.  IMO it clarifies the description of
confirmed-commit, but the current text is not wrong.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Dec 2013 13:45:14 +0100

> confirmed-commit, but the current text is not wrong.

So perhaps it might qualify as an editorial erratum, rather than technical?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 10 Dec 2013 13:54:13 +0100

I we all agree, then we can leave it, but we should then categorize it as an
editorial change and not as a technical change.

Not sure if we(or rfc-editor) can/must do that.
Will try to find out.

Bert

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 10 Dec 2013 12:50:25 +0000

But, short of an RFC6241-bis (which I can't see occurring any time
soon), how else can the clarification be made available to readers of
the RFC? They might find the information if they search the Netconf
Discussion Archive, but that isn't particularly easy nor guaranteed to
provide the information needed (even assuming they realise there is a
need for clarification). For people who have been involved in all the
discussions on NETCONF since RFC 3535 much of this is presumably
obvious, but for those of us seeking to understand NETCONF based
primarily on a reading of the RFCs (in the absence of any book written
on the subject), it would be really useful if any clarifications that
arise through the Netconf Discussion Archive could be made more easily
available, maybe as annotations rather than errata. 

On 2013-12-10

http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table
[1] We would like to hear from the authors/editors what their opinion
is on the reported errata.

Links:
------
[1]

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 10 Dec 2013 15:25:14 +0100

Martin, did you mean to make this statement for all 3 reported errata,
or just for 3821?

If anyone disagrees with Martin's assessment, pls speak up NOW.

Thanks,
Bert

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Dec 2013 15:36:51 +0100 (CET)

[fixing andy's address]

> Martin, did you mean to make this statement for all 3 reported errata,

All three.

Editorial errata is fine with me. 

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Dec 2013 16:54:22 +0100

> Editorial errata is fine with me. 

If we ever update RFC 6241, perhaps we can find a better solution to
avoid the "confirmed commit" means "to-be-confirmed commit" confusion
in the first place.  The other changes (being more precise that it is
a sequence of confirmed commits and the more detailed list what is
impacted by the :confirmed-commit:1.1 capability) are fine. I am OK
with this as an editorial errata.

/js

---

From: joel jaeggli <[email-masked]>
Date: Tue, 10 Dec 2013 07:55:29 -0800

> available, maybe as annotations rather than errata. 

Imho this is not an appropriate use of the errata system.

if there is something wrong (with 6241) e.g. the 3822 errata is
necessary for correct implementation that's one thing, if the are
clarifying we should not be handling them in this fashion.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Dec 2013 07:59:02 -0800

Hi,

I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of confirmed commits"
is correct.  There is just 1 netconf-confirmed-commit notification for
start & complete
sent out no matter how how many times the procedure is extended.

If the procedure ends with a cancel or timeout, there is only 1 original
commit
that is restored.  It is incorrect to think of this procedure as a series of
confirmed commits.  A commit that extends the procedure is not treated
the same as the commit that starts the procedure.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Dec 2013 08:15:12 -0800

On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford
<[email-masked]>wrote:

>
>
> On 2013-12-10 15:59, Andy Bierman wrote:
>
> Hi,
>  Are you saying that the initial commit of the sequence (the confirmed
> commit?) is restored should the procedure be cancelled or timeout? Surely
> the commit that is restored is the one that preceded the confirmed commit.
>

The confirmed commit is the first <commit> that includes a <confirmed>
parameter.
The 2nd - Nth <commit> are extending the first commit operation.  The
server is still
obligated to revert the running config for the first commit (if it is
canceled or timed out).
This obligation is not removed because the commit is extended.  It is only
removed
if a confirming commit is received.

 Jonathan

Andy

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 10 Dec 2013 16:26:43 +0000

On 2013-12-10 16:15, Andy Bierman wrote: 

> On Tue, Dec 10, 2013 at
2013-12-10 15:59, Andy Bierman wrote: 
>>> is correct. There is just 1
netconf-confirmed-commit notification for start & complete 
>>> sent out
no matter how how many times the procedure is extended. 
>>> If the
procedure ends with a cancel or timeout, there is only 1 original commit

>> Are you saying that the initial commit of the sequence (the
confirmed commit?) is restored should the procedure be cancelled or
timeout? Surely the commit that is restored is the one that preceded the
confirmed commit.
> 
> The confirmed commit is the first <commit> that
includes a <confirmed> parameter. 
> The 2nd - Nth <commit> are
extending the first commit operation. The server is still 
> obligated
to revert the running config for the first commit (if it is canceled or
timed out). 
> This obligation is not removed because the commit is
extended. It is only removed 
> if a confirming commit is
received.

Andy, 
I'm not sure whether we agreeing or not. Section 8.4.1
of RFC6241 (2nd paragraph) talks about 'a follow-up confirmed <commit>
operation'. Are you saying that that second 'confirmed <commit>' (i.e. a
<commit> with the <confirmed> parameter) is not a "confirmed commit"?
And when you say 'the server is obligated to revert the running config
for the first commit' do you mean revert to the state prior to that
first confirmed <commit>? 
Jonathan 

>>> 
>>> On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund
"Bert Wijnen (IETF)" <[email-masked] [2]> wrote:
>>>> > Martin,
did you mean to make this statement for all 3 reported errata,
>>>> > or
just for 3821?
Bert
"Bert Wijnen (IETF)" <[email-masked] [3]> wrote:
>>>> > >> We have
a set of 3 new errata reported to RFC6241.
[4]
>>>> > > /martin

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
mailto:[email-masked]
[4]
http://www.rfc-editor.org/errata_search.php?rfc=6241&amp;rec_status=15&amp;presentation=table
[5]
mailto:[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Dec 2013 08:55:54 -0800

Hi,

The fact that it is not clear how confirmed commit works is an indication
of just how broken the shared candidate config is in NETCONF.
This is an artifact of CLI-based management, where nothing is locked,
and the management application is just an SSH terminal.

For programmatic applications, a shared scratchpad on the server is
a terrible design choice.  The NETCONF-EX draft fixes 1 or 2 of the
many problems (e.g., decouple confirmed-commit from candidate),
but it does not attempt to allow concurrent or independent transactions.

The persist-id supplies a long-lived lock on the <commit> operation,
but not against other sessions writing to the candidate (w/
edit/copy-config).

I found another clarification for confirmed commit.
Sec. 8.4.1, para 3:

   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.

Sec. 8.4.5.1:

     persist-id:

            Used to issue a follow-up confirmed commit or a confirming
            commit from any session, with the token from the previous
            <commit> operation.

There is no mention in 8.4.5.1 which error-tag to return if the persist-id
parameter is
missing or wrong. (in-use?).

Notice that 8.4.1 says "any follow-up commit" and 8.4.5.1 says "a follow-up
confirmed commit"?  This might make it unclear that any followup <commit>
without
the proper <persist-id> will be rejected by the server.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Dec 2013 09:05:50 -0800

On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford
<[email-masked]>wrote:

> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <[email-masked]
> > wrote:
>
>>  If the procedure ends with a cancel or timeout, there is only 1
>> original commit
>  I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd
> paragraph) talks about 'a follow-up confirmed <commit> operation'. Are you
> saying that that second 'confirmed <commit>' (i.e. a <commit> with the
> <confirmed> parameter) is not a "confirmed commit"? And when you say 'the
> server is obligated to revert the running config for the first commit' do
> you mean revert to the state prior to that first confirmed <commit>?
>

sec. 8.4.1, para 2:

   The confirming commit is a <commit> operation
   without the <confirmed> parameter.

The 2nd commit with a <confirmed> parameter extends the confirmed-commit
procedure.
Any cancel or complete applies to this commit.  If canceled, then the
changes made for the
2nd commit are going to be undone.  An extension commit is not a confirming
commit.
A cancel/timeout causes the config to revert to its state before the first
confirmed commit
operation.

 Jonathan

Andy

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 10 Dec 2013 16:05:11 +0000

> the same as the commit that starts the procedure.

Are
you saying that the initial commit of the sequence (the confirmed
commit?) is restored should the procedure be cancelled or timeout?
Surely the commit that is restored is the one that preceded the
confirmed commit. 
Jonathan 

> Andy 
> 
> On Tue, Dec 10, 2013 at 6:36
AM, Martin Bjorklund <[email-masked] [4]> wrote:
>> [fixing andy's
address]
>> 
>> "Bert Wijnen (IETF)" <[email-masked] [1]>
>> > If anyone
disagrees with Martin's assessment, pls speak up NOW.
Thanks,
>> > > I think
the proposed text is fine, however I do not know if it
>> > > qualifies
as an errata. IMO it clarifies the description of

Links:
------
[1]

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 12 Dec 2013 12:26:35 +0000

8:05 AM, Jonathan Hansford <[email-masked] [1]> wrote:
>>>>> sent
out no matter how how many times the procedure is extended. 

original commit 
>>>> Are you saying that the initial commit
of the sequence (the confirmed commit?) is restored should the procedure
be cancelled or timeout? Surely the commit that is restored is the one
that preceded the confirmed commit.
>>> 
>>> The confirmed commit is the
first <commit> that includes a <confirmed> parameter. 
>>> The 2nd - Nth
<commit> are extending the first commit operation. The server is still

>>> obligated to revert the running config for the first commit (if it
is canceled or timed out). 
>>> This obligation is not removed because
the commit is extended. It is only removed 
>>> if a confirming commit
is received.
>> 
>> Andy, 
>> I'm not sure whether we agreeing or not.
Section 8.4.1 of RFC6241 (2nd paragraph) talks about 'a follow-up
confirmed <commit> operation'. Are you saying that that second
'confirmed <commit>' (i.e. a <commit> with the <confirmed> parameter) is
not a "confirmed commit"? And when you say 'the server is obligated to
revert the running config for the first commit' do you mean revert to
the state prior to that first confirmed <commit>?
> sec. 8.4.1, para
2: 
> The 2nd commit with a <confirmed> parameter
extends the confirmed-commit procedure. 
> Any cancel or complete
applies to this commit. If canceled, then the changes made for the 
2nd commit are going to be undone. An extension commit is not a
confirming commit. 
> A cancel/timeout causes the config to revert to
its state before the first confirmed commit 
Jonathan
> Andy

Andy, 
What I think you seem to be stating here is
that there are three types of commit (and possibly, by extension, four):

 	* "Confirmed commit" - the first successful commit with a
<confirmed> parameter after a successful commit without a <confirmed>
parameter
 	* "Extension commit" - any commit with a <confirmed>
parameter after a "confirmed commit" and before any successful
"confirming commit"
 	* "Confirming commit" - any commit without a
<confirmed> parameter after a "confirmed commit" and before any other
successful "confirming commit"
 	* "Standard commit" - any commit
without a <confirmed> parameter after a successful "confirming commit"
and before a subsequent "confirmed commit"

By those definitions a
"confirmed commit" cannot follow another "confirmed commit" without an
intervening "confirming commit". Yet 8.4.5.1 talks about follow-up
"confirmed commits" and "confirming commits". How can there be a
follow-up "confirmed commit", unless the definition of a "confirmed
commit" becomes something like: 

(the first commit with a <confirmed>
parameter after a successful commit without a <confirmed> parameter) OR
(the first successful commit with a <confirmed> parameter from another
session and the appropriate <persist-id>) 

Also, 8.4.5.1 states the
<persist> parameter makes the "confirmed commit" survive a session
termination. Does that mean the <persist-id> parameter can only be
successful if the original session has been terminated, or is it more
accurate to state that the <persist> parameter allows the "confirmed
commit" to be extended by other sessions, whether or not the original
session has been terminated? 

Thanks, 

Jonathan 

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 08:57:15 -0800

On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford
<[email-masked]>wrote:

> On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <[email-masked]
> > wrote:
>
>> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <
>> [email-masked]> wrote:
>>
>> This obligation is not removed because the commit is extended.  It is
>> only removed
> What I think you seem to be stating here is that there are three types of
> commit (and possibly, by extension, four):
>
>    1. "Confirmed commit" - the first successful commit with a <confirmed>
>    parameter after a successful commit without a <confirmed> parameter
>    2. "Extension commit" - any commit with a <confirmed> parameter after
>    a "confirmed commit" and before any successful "confirming commit"
>    3. "Confirming commit" - any commit without a <confirmed> parameter
>    after a "confirmed commit" and before any other successful "confirming
>    commit"
>    4. "Standard commit" - any commit without a <confirmed> parameter
>    after a successful "confirming commit" and before a subsequent "confirmed
>    commit"
>
> By those definitions a "confirmed commit" cannot follow another "confirmed
> commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about
> follow-up "confirmed commits" and "confirming commits". How can there be a
> follow-up "confirmed commit", unless the definition of a "confirmed commit"
> becomes something like:
>
> (the first commit with a <confirmed> parameter after a successful commit
> without a <confirmed> parameter) OR (the first successful commit with a
> <confirmed> parameter from another session and the appropriate <persist-id>)
>

The saved state that that gets reverted if the commit is not confirmed does
not change
because anther commit with a <confirmed> element is received.  This 2nd
commit that
is extending the confirmed commit procedure is clearly not a confirming
commit, so
the server cannot update the saved state that will be reverted if necessary.

The terminology does not distinguish very well between the confirmed commit
procedure
and a <rpc> request that is called a confirmed commit.  There is only 1
confirmed commit
procedure active at any given time.  The 2nd confirmed commit <rpc> request
does not end
the first procedure and start a new one.  Once the procedure is ended
somehow,
then it ends for all the confirmed commit requests that are pending.

Also, 8.4.5.1 states the <persist> parameter makes the "confirmed commit"
> survive a session termination. Does that mean the <persist-id> parameter
> can only be successful if the original session has been terminated, or is
> it more accurate to state that the <persist> parameter allows the
> "confirmed commit" to be extended by other sessions, whether or not the
> original session has been terminated?
>

No -- any session that knows the correct persist-id can complete the
procedure,
including any session that sent a confirmed commit <rpc> request.

Andy

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 12 Dec 2013 12:20:40 -0500

Hi,

This thread about an errata says to me that implementers could implement the
original text in different ways and be conformant to the standard. 

The clarification text seems to be modifying what a conformant
implementation must do, and obviously the WG members haven't reached
consensus on just what that must be. 

If the clarification becomes part of conformance requirements, then existing
implementations would likely become non-conformant. 

To me, that says a -bis is called for, including WGLC and IETF LCs, to
change the conformance requirements of the standard.

I am not implementing this standard, so maybe I misjudge whether this
affects existing implementations or not. Please let me know if I am looking
at this incorrectly.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, December 12, 2013 11:57 AM
To: Jonathan Hansford
Cc: Rob Enns; joel jaeggli; Netconf
Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)

On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford <[email-masked]>
wrote:

 

On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <[email-masked]>
wrote:

 

On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <[email-masked]>
wrote:

Hi, 

is correct.  There is just 1 netconf-confirmed-commit notification for start
& complete

The 2nd - Nth <commit> are extending the first commit operation.  The server
is still

Andy,

sec. 8.4.1, para 2:

operation.

Jonathan

Andy

Andy,

1.	"Confirmed commit" - the first successful commit with a <confirmed>
parameter after a successful commit without a <confirmed> parameter
2.	"Extension commit" - any commit with a <confirmed> parameter after a
"confirmed commit" and before any successful "confirming commit"
3.	"Confirming commit" - any commit without a <confirmed> parameter
after a "confirmed commit" and before any other successful "confirming
commit"
4.	"Standard commit" - any commit without a <confirmed> parameter after
a successful "confirming commit" and before a subsequent "confirmed commit"

 

 

Also, 8.4.5.1 states the <persist> parameter makes the "confirmed commit"
survive a session termination. Does that mean the <persist-id> parameter can
only be successful if the original session has been terminated, or is it
more accurate to state that the <persist> parameter allows the "confirmed
commit" to be extended by other sessions, whether or not the original
session has been terminated?

 

Thanks,

Jonathan

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 09:42:48 -0800

Hi,

On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh <[email-masked]> wrote:

> Hi,
>
>
>
> This thread about an errata says to me that implementers could implement
> the original text in different ways and be conformant to the standard.
>
>
>

What are the implementation differences that the spec allows?

> implementation must do, and obviously the WG members haven’t reached

I do not agree that there is WG consensus to accept the errata -- the
discussion seems to show
that the term "confirmed commit" is used to refer to the entire procedure
and to a specific
form of a <commit> request.   There is no text that is clearly in error.

I don't think consensus has been established that different implementations
of confirmed commit
are possible.  The draft is clear about the definition of a confirming
commit, and also clear
what ends a confirmed commit procedure.

If the clarification becomes part of conformance requirements, then
> existing implementations would likely become non-conformant.
>
> To me, that says a –bis is called for, including WGLC and IETF LCs, to

Can you describe this non-conformance that needs to be fixed with a new RFC?
It seems to me (and other implementors) that restoring the running config to
its state before the first confirmed commit <rpc> request is the correct
behavior.

I do not agree that the current RFC text allows an interpretation that
permits the
server to treat a <commit> with a <confirmed> element as a confirming
commit.
Only a timeout, <cancel-commit> or confirming commit can release the server
from its obligation to revert the saved state.

> [email-masked]

Andy

> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, December 12, 2013 11:57 AM
> *To:* Jonathan Hansford
> *Cc:* Rob Enns; joel jaeggli; Netconf
> *Subject:* Re: [Netconf] [Technical Errata Reported] RFC6241 (3821)
>
>
>
>
>
>
>
> The saved state that that gets reverted if the commit is not confirmed
> does not change
>
> The terminology does not distinguish very well between the confirmed
> commit procedure
>
> procedure active at any given time.  The 2nd confirmed commit <rpc>
> request does not end
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Dec 2013 19:29:02 +0100 (CET)

Hi,

I agree w/ Andy.  The current text is correct, but can be improved
(clearer).

/martin

Andy Bierman <[email-masked]> wrote:
> > implementation must do, and obviously the WG members haven$B!G(Bt reached
> > To me, that says a $(Q#|(Bbis is called for, including WGLC and IETF LCs, to

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Dec 2013 21:13:19 +0100

> consensus on just what that must be. 

I do not thing this is a fair assessment of the situation.

I believe people do agree on the intended behaviour; there is perhaps
less agreement on how to describe it better. Jonathan's proposal in
the errata helps somewhat but I believe to really describe this well,
we actually need to discuss the various situations in more detail.

> change the conformance requirements of the standard.

I do not think this is the case. In other parts of the IETF, there are
sometimes implementation guideline documents that clear up some of the
issues. I am not saying we need to produce one but this would be an
option to deal with this case. The reason I am not exiting about such
an implementation guideline document is that confirmed commit by
itself does not justify to write one. If more things like this pop up,
we might reach the point where such a document could be reasonable to
produce.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 13 Dec 2013 09:42:46 +0100

Inline

> we actually need to discuss the various situations in more detail.

If we indeed believe that we agree on the behaviour and IF we believe we can
make the text to describe that better, then I propose that the document authors
sit together to come uo with a proposed new text that we can then discuss
on this list.

Bert