Subject: [netconf] RFC 6241 Ambiguity

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 08 May 2019 13:33:10 +0000

Hi,

In RFC 6241:

Section 8.4.1 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."

Section 8.4.5.1 states the persist parameter makes "the confirmed commit 
survive a session termination".

Appendix C states the persist parameter "is used to make a confirmed 
commit persistent. 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."

However:

Section 7.8, Erratum 5397 states "If a NETCONF server receives a 
<close-session> request while processing a confirmed commit (Section 
8.4) for that session, regardless of whether the confirmed commit 
included a <persist> element, it MUST restore the configuration to its  
state before the confirmed commit was issued."

Section 7.9, Erratum 5397 states "If a NETCONF server receives a 
<kill-session> request while processing a confirmed commit (Section 8.4) 
for that session, regardless of whether the confirmed commit included a 
<persist> element, it MUST restore the configuration to its  state 
before the confirmed commit was issued."

Section 8.4.1 states "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."

So:

Is the use of <close-session> or <kill-session>, or the device 
rebooting, not considered to be the session being "terminated for any 
reason"? Or is it the case that "the only way to abort a persistent 
confirmed commit is to let the timer expire, or to use the 
<cancel-commit> operation"?

Jonathan

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

---

From: Kent Watsen <[email-masked]>
Date: Sat, 11 May 2019 14:43:31 +0000

It seems that the "for any reason" clause should be qualified modulo the "persist" element (please file an errata report).  Note also the last paragraph in Section 8.4.1, which shows RFC 624 straddling capability versions, hence the wonky text. 

To answer your question. it is the latter: the only way to abort a persistent confirmed commit is to let the timer expire, or to use the <cancel-commit> operation.

Kent // contributor

> On May 8, 2019, at 9:33 AM, Jonathan Hansford <[email-masked]> wrote:
> 
> Hi,
> 
> In RFC 6241:
> 
> Section 8.4.1 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."
> 
> Section 8.4.5.1 states the persist parameter makes "the confirmed commit survive a session termination".
> 
> Appendix C states the persist parameter "is used to make a confirmed commit persistent. 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." 
> 
> However:
> 
> Section 7.8, Erratum 5397 states "If a NETCONF server receives a <close-session> request while processing a confirmed commit (Section 8.4) for that session, regardless of whether the confirmed commit included a <persist> element, it MUST restore the configuration to its  state before the confirmed commit was issued."
> 
> Section 7.9, Erratum 5397 states "If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4) for that session, regardless of whether the confirmed commit included a <persist> element, it MUST restore the configuration to its  state before the confirmed commit was issued."
> 
> Section 8.4.1 states "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."
> 
> So:
> 
> Is the use of <close-session> or <kill-session>, or the device rebooting, not considered to be the session being "terminated for any reason"? Or is it the case that "the only way to abort a persistent confirmed commit is to let the timer expire, or to use the <cancel-commit> operation"?
> 
> Jonathan
> 
>  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>	Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <x-msg://11/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>_______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 May 2019 08:15:21 -0700

On Sat, May 11, 2019 at 7:43 AM Kent Watsen <[email-masked]> wrote:

> It seems that the "for any reason" clause should be qualified modulo the
> "persist" element (please file an errata report).  Note also the last
> paragraph in Section 8.4.1, which shows RFC 624 straddling capability
> versions, hence the wonky text.
>
> To answer your question. it is the latter: the only way to abort a
> persistent confirmed commit is to let the timer expire, or to use the
> <cancel-commit> operation.
>
> Kent // contributor
>
>
> MUST restore the configuration to its state before the confirmed commit was
> issued, unless the confirmed commit also  included a <persist> element."
>

> <close-session> request while processing a confirmed commit (Section 8.4)
> <persist> element, it MUST restore the configuration to its  state before
> the confirmed commit was issued."
>
>

I do not agree with this Errata and will never implement it as part of RFC
6241 conformance.
The entire point of the "persist" mechanism is to tie the confirmed commit
to a client, not to a session.
Cancelling the CC because a client sends a <close-session> (instead of
dropping the transport session)
is obviously counter-productive.  Using <close-session> instead of dropping
the session is
considered the best current practice.

> <persist> element, it MUST restore the configuration to its  state before
> the confirmed commit was issued."
>
>

This solution (and also 7.8) directly contradict the text cited in 8.4.1

> confirm timeout expires, the server MUST restore the configuration to its
> Is the use of <close-session> or <kill-session>, or the device rebooting,
> not considered to be the session being "terminated for any reason"? Or is
> it the case that "the only way to abort a persistent confirmed commit is to
> let the timer expire, or to use the <cancel-commit> operation"?
>
> Jonathan
>
>

Andy

>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 13 May 2019 10:43:36 +0000

So I need to contact the RFC Editor to correct Erratum 5397, with the 
relevant text in sections 7.8 and 7.9 being changed to something like:

>7.8: "If a NETCONF server receives a <close-session> request while 
>processing a confirmed commit (Section 8.4) for that session, unless 
>the confirmed commit is a persistent confirmed commit, it MUST restore 
>the configuration to its state before the confirmed commit was issued. 
>A persistent confirmed commit MUST survive session termination."
>
>7.9: "If a NETCONF server receives a <kill-session> request while 
>processing a confirmed commit (Section 8.4) for the session to be 
>killed, unless the confirmed commit is a persistent confirmed commit, 
>it MUST restore the configuration to its state before the confirmed 
>commit was issued. A persistent confirmed commit MUST survive session 
>termination."

I also need to contact the RFC Editor to correct Erratum 3821 to change:

>If the session issuing a sequence of one or more confirmed commits is
>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.

to something like:

>If the session issuing a sequence of one or more confirmed commits is
>MUST restore the configuration to its state before the sequence of
>confirmed commits was issued, unless the confirmed commit is a
>persistent confirmed commit.
>
>If the device reboots for any reason before the confirm timeout
>expires, unless a persistent confirmed commit is in progress, the
>server MUST restore the configuration to its state before the
>sequence of confirmed commits was issued.
>
>  A persistent confirmed commit MUST survive session termination.
>
Are those errata OK?

On 11/05/2019 16:15:21, "Andy Bierman" <[email-masked]> wrote:

>>It seems that the "for any reason" clause should be qualified modulo 
>>the "persist" element (please file an errata report).  Note also the 
>>last paragraph in Section 8.4.1, which shows RFC 624 straddling 
>>capability versions, hence the wonky text.
>>
>>>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."
>>>
>>>commit persistent. A persistent confirmed commit is not aborted if 
>>>the NETCONF session terminates. The only way to abort a persistent 
>>><cancel-commit> operation."
>
>>>
>>>However:
>>>
>>>included a <persist> element, it MUST restore the configuration to 
>I do not agree with this Errata and will never implement it as part of 
>RFC 6241 conformance.
>The entire point of the "persist" mechanism is to tie the confirmed 
>commit to a client, not to a session.
>is obviously counter-productive.  Using <close-session> instead of 
>dropping the session is
>>><kill-session> request while processing a confirmed commit (Section 
>>>included a <persist> element, it MUST restore the configuration to 

---

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 May 2019 18:45:12 +0000

> So I need to contact the RFC Editor to correct Erratum 5397, with the relevant text in sections 7.8 and 7.9 being changed to something like:
> 
> 7.8: "If a NETCONF server receives a <close-session> request while processing a confirmed commit (Section 8.4) for that session, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."
> 
> 7.9: "If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4) for the session to be killed, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."

Ideally, Errata 5397 is deleted (because I think that it's clear that Section 8.4 overrides the 7.8 behavior) but, if we have to patch the errata, I might suggests:

For Section 7.8
  OLD (in RFC 6241)

    The server will release any locks
    and resources associated with the session and gracefully close any
    associated connections.

  NEW:

    The server will release any locks
    and resources, associated with the session and gracefully close any
    associated connections.  As an exception to the previous sentence, if
    the session is processing a persistent confirmed commit (Section 8.4),
    the resources necessary for supporting confirmed commit are not released.

For Section 7.9:
  OLD (in RFC 6241)

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

  NEW:
      What you have above seems fine, though I'd leave off the last sentence.

>  A persistent confirmed commit MUST survive session termination.

This seems okay but, again, I'd leave out the last sentence.

Side note: huge errata are hard to read without a diff.  If a lot of text, then the NEW (or the NOTES) should include a diff highlighting exactly what changed.

Kent // contributor

---

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 15 May 2019 10:24:46 +0000

Kent,

I don't think Erratum 5397 should be deleted. Though the original 
section 7.8 makes no mention of confirmed commits, section 7.9 does, but 
does not differentiate between a vanilla confirmed commit and a 
persistent confirmed commit. Since a persistent confirmed commit is 
still a type of confirmed commit, without clarification the second 
paragraph of the description would seem to apply.

With the diff, should that be against the original text or the original 
erratum?

Thanks,

Jonathan

---

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 15 May 2019 14:33:27 -0700

> On May 15, 2019, at 3:24 AM, Jonathan Hansford <[email-masked]> wrote:
> 
> Kent,
> 
> I don't think Erratum 5397 should be deleted. Though the original section 7.8 makes no mention of confirmed commits, section 7.9 does, but does not differentiate between a vanilla confirmed commit and a persistent confirmed commit. Since a persistent confirmed commit is still a type of confirmed commit, without clarification the second paragraph of the description would seem to apply. 

I would agree.

> 
> With the diff, should that be against the original text or the original erratum?

The diff is building on top of the original erratum. I would think a diff w.r.t. to the original erratum would make sense.

> 
> Thanks,
> 
> Jonathan
> 
> 
> On 14/05/2019 19:45:12, "Kent Watsen" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>  
>  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>	Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> <x-msg://76/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>_______________________________________________
> netconf mailing list

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 May 2019 21:48:22 +0000

>> I don't think Erratum 5397 should be deleted. Though the original section 7.8 makes no mention of confirmed commits, section 7.9 does, but does not differentiate between a vanilla confirmed commit…

It's a minor point, but I could argue, as I wrote before, that such clarifications in 7.x are unnecessary because 8.4 provides overrides.   I prefer less text because it's easier to get right (wit this is at least the 3rd time Jonathan is at this now).  However "unnecessary" doesn't mean "wrong" and since we've already stepped in it, getting the 7.x errata right might be easier than getting 8.4 right.

> The diff is building on top of the original erratum. I would think a diff w.r.t. to the original erratum would make sense.

It depends, are you correcting the earlier errata or filing a new one?   Regardless, I expressed a diff for what I think the text should be (which you didn't comment on); how that is translated is up to you.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 May 2019 10:02:43 -0700

On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[email-masked]> wrote:

>
>
> I don't think Erratum 5397 should be deleted. Though the original section
> 7.8 makes no mention of confirmed commits, section 7.9 does, but does not
> differentiate between a vanilla confirmed commit and a persistent confirmed
> commit. Since a persistent confirmed commit is still a type of confirmed
> commit, without clarification the second paragraph of the description would
> seem to apply.
>
>
> I would agree.
>
>
>
7.8 does not say anything about the <kill-session> is for the
session that started a confirmed commit or extended a confirmed commmit.
It could be interpreted to mean any kill-session for any session causes
a confirmed commit to be rolled back.  The text below is so ambiguous it
is not even clear the <kill-session> has to be for an existing session,

> It's a minor point, but I could argue, as I wrote before, that such
> clarifications in 7.x are unnecessary because 8.4 provides overrides.   I
> prefer less text because it's easier to get right (wit this is at least the
> 3rd time Jonathan is at this now).  However "unnecessary" doesn't mean
> "wrong" and since we've already stepped in it, getting the 7.x errata right
> might be easier than getting 8.4 right.
>
>

8.4 para 3 says the confirmed commit is not tied to a session if the
persist/persist0id mechanism is used.

   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.

The problematic text is actually in <cancel_commit>

8.4.4.1.  <cancel-commit>

   Description:

         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.

In order to cancel a confirmed commit (belonging to another client, i.e
the persist-id is not known), the client issues a <kill-session> for
any random or non-existent session.  It would make more sense to issue a
<cancel-commit>
(maybe require superuser) instead. The access control policy for
<kill-session>
is the wrong way to configure access to cancelling a confirmed commit.

IMO these procedures are not well designed or documented, and an Errata
cannot
be used to fix it -- a new version of the protocol should fix it, in which
WG and IETF consensus
is reached for the selected solution.

> The diff is building on top of the original erratum. I would think a diff
> w.r.t. to the original erratum would make sense.
>
>
> It depends, are you correcting the earlier errata or filing a new one?
> Regardless, I expressed a diff for what I think the text should be (which
> you didn't comment on); how that is translated is up to you.
>
>
> Kent // contributor
>
>
Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 16 May 2019 11:50:01 -0700

Hi Andy,

> On May 16, 2019, at 10:02 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 

While the original text in 7.8 was ambiguous, Erratum 5397 does seem to clarify that the <close-session> (not <kill-session), is for the session in question, and not any session.

      If a NETCONF server receives a <close-session> request while
      processing a confirmed commit (Section 8.4) for that session, it
      MUST restore the configuration to its state before the confirmed
      commit was issued unless the confirmed commit included a <persist>
      element.
That is why I agree that Erratum 5397 should not be deleted, but should be modified to the text suggested by Jonathan.

> 8.4 para 3 says the confirmed commit is not tied to a session if the persist/persist0id mechanism is used.
> 
> any random or non-existent session.  It would make more sense to issue a <cancel-commit>
> (maybe require superuser) instead. The access control policy for <kill-session>
> IMO these procedures are not well designed or documented, and an Errata cannot
> be used to fix it -- a new version of the protocol should fix it, in which WG and IETF consensus

Do you want to open this as a netconf-next issue?

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 May 2019 12:10:38 -0700

On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani <
[email-masked]> wrote:

> While the original text in 7.8 was ambiguous, Erratum 5397 does seem to
> clarify that the <close-session> (not <kill-session), is for the session in
> question, and not any session.
>
>
I do not agree that close-session overrides the text in sec 8.4 supports
this procedure.
It also makes no sense from an operational POV, since dropping the session
(without a close-session) does not have this affect :

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

IMO this text overrides the close-session and kill-session text.

> That is why I agree that Erratum 5397 should not be deleted, but should be
> modified to the text suggested by Jonathan.
>
>
This makes no operational sense if the <persist> parameter was used.

> Do you want to open this as a netconf-next issue?
not really

Andy

---

From: <[email-masked]>
Date: Fri, 24 May 2019 10:56:33 +0100

Hi,

Apologies for the delay in responding.

The reason for the errata I have raised on persistent confirmed commits is because RFC 6241 seems to me to be ambiguous. For example, section 8.4.1 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.” To my mind, the reasons for terminating the session include the client issuing a <close-session>, another client issuing a <kill-session> on the session in question, a network failure, the client rebooting, and the server rebooting. Yet in the next paragraph it states, “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.” So does the second paragraph overrule the first when the session terminates due to the device rebooting? If so, what is the reason why a persistent confirmed commit cannot persist beyond a device reboot but it can for all other cases of session termination? And why does the RFC state about the persist parameter on page 101, “This parameter is used to make a confirmed commit persistent.  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”? The RFC could really do with making it clearer under what circumstances a persistent confirmed commit is aborted, hence my errata. If I have got them wrong, I apologise.

Re Kent’s point about section 8.4 overriding section 7.8 behaviour. Is that a common approach to RFCs, that subsequent sections can overrule prior sections without needing to add clarity in those prior sections? If so, why are there so many forward references to capabilities in section 7?

With the diffs in the errata, I am unclear what happens when reporting an error in an existing erratum. If the resultant erratum replaces the previous one, it would make sense to provide the diff against the original text. If it becomes an additional erratum, it would make sense to provide the diff against the previous erratum.

Re Andy’s point about the text on <kill-session> in section 7.9 being ambiguous, that is why I proposed the change. However, if that change is not correct, then surely we still need an erratum to clarify what the intent truly is. Clearly Andy is of the opinion an erratum is not sufficient and this needs to be fixed in a new version of the protocol which is why I’m confused as to why he doesn’t want to open this as a netconf-next issue.

For the work we are currently undertaking, persistent confirmed commits could be very useful. But if the RFC is ambiguous, errata cannot fix it and it isn’t a netconf-next issue we will have to remove support for it. But if that is the case then presumably we should not support any of :confirmed-commit:1.1.

Jonathan

From: netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: 16 May 2019 20:11
To: Mahesh Jethanandani <[email-masked]>
Cc: Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [netconf] RFC 6241 Ambiguity

On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani <[email-masked] <mailto:[email-masked]> > wrote:

Hi Andy,

On May 16, 2019, at 10:02 AM, Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:

On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[email-masked] <mailto:[email-masked]> > wrote:

I would agree.

 

 

I do not agree that close-session overrides the text in sec 8.4 supports this procedure.

   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.

 

 

 

 

8.4.4.1.  <cancel-commit>
 
   Description:

 

not really

 

 

Kent // contributor

Andy

Mahesh Jethanandani

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

 

Andy

---

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 May 2019 09:13:58 -0700

On Fri, May 24, 2019 at 2:56 AM <[email-masked]> wrote:

> The reason for the errata I have raised on persistent confirmed commits is
> because RFC 6241 seems to me to be ambiguous. For example, section 8.4.1
> 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.” To my mind, the
> reasons for terminating the session include the client issuing a
> <close-session>, another client issuing a <kill-session> on the session in
> question, a network failure, the client rebooting, and the server
> rebooting. Yet in the next paragraph it states, “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.” So does
> the second paragraph overrule the first when the session terminates due to
> the device rebooting? If so, what is the reason why a persistent confirmed
> commit cannot persist beyond a device reboot but it can for all other cases
> of session termination? And why does the RFC state about the persist
> parameter on page 101, “This parameter is used to make a confirmed commit
> persistent.  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”? The RFC
> could really do with making it clearer under what circumstances a
> persistent confirmed commit is aborted, hence my errata. If I have got them
> wrong, I apologise.
>
>
>
> Re Kent’s point about section 8.4 overriding section 7.8 behaviour. Is
> that a common approach to RFCs, that subsequent sections can overrule prior
> sections without needing to add clarity in those prior sections? If so, why
> are there so many forward references to capabilities in section 7?
>
>
>
> With the diffs in the errata, I am unclear what happens when reporting an
> error in an existing erratum. If the resultant erratum replaces the
> previous one, it would make sense to provide the diff against the original
> text. If it becomes an additional erratum, it would make sense to provide
> the diff against the previous erratum.
>
>
>
> Re Andy’s point about the text on <kill-session> in section 7.9 being
> ambiguous, that is why I proposed the change. However, if that change is
> not correct, then surely we still need an erratum to clarify what the
> intent truly is. Clearly Andy is of the opinion an erratum is not
> sufficient and this needs to be fixed in a new version of the protocol
> which is why I’m confused as to why he doesn’t want to open this as a
> netconf-next issue.
>
>
>
> For the work we are currently undertaking, persistent confirmed commits
> could be very useful. But if the RFC is ambiguous, errata cannot fix it and
> it isn’t a netconf-next issue we will have to remove support for it. But if
> that is the case then presumably we should not support any of
> :confirmed-commit:1.1.
>
>
>

It seems that some text in RFC 4741 was not updated in RFC 6241 to
support the addition of the <persist> and <persist-id> parameters.

The intent of the authors (and WG) during development of RFC 6241 was
that the <persist> parameter would decouple the confirmed commit procedure
from the session that issued the confirmed commit operation.

An errata is appropriate if the WG agrees
   (a) what text is incorrect
   (b) what is the intent of the incorrect text
   (c) what is the correct replacement text

It does not seem that any of these conditions are met in this case so I
guess it
is a netconf-next issue.

Jonathan

Andy

>
>
> *From:* netconf <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* 16 May 2019 20:11
> *To:* Mahesh Jethanandani <[email-masked]>
> *Cc:* Kent Watsen <[email-masked]>; [email-masked]
> *Subject:* Re: [netconf] RFC 6241 Ambiguity
>
>
>
>
>
>
>
>    If the session issuing the confirmed commit is terminated *for any*
>
> *   reason* before the confirm timeout expires, the server MUST restore
>
>    issued,* unless the confirmed commit also included a <persist>*
>
> *   element.*
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
> www.avast.com
> <#m_-270464312496652421_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

---

From: tom petch <[email-masked]>
Date: Fri, 24 May 2019 16:22:10 +0000

inline

Tom Petch

----- Original Message -----
From: <[email-masked]>
Sent: Friday, May 24, 2019 10:56 AM

Hi,

The reason for the errata I have raised on persistent confirmed commits
is because RFC 6241 seems to me to be ambiguous. For example, section
8.4.1 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.”
To my mind, the reasons for terminating the session include the client
issuing a <close-session>, another client issuing a <kill-session> on
the session in question, a network failure, the client rebooting, and
the server rebooting. Yet in the next paragraph it states, “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.” So does the second paragraph overrule the first when
the session terminates due to the device rebooting? If so, what is the
reason why a persistent confirmed commit cannot persist beyond a device
reboot but it can for all other cases of session termination? And why
does the RFC state about the persist parameter on page 101, “This
parameter is used to make a confirmed commit persistent.  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”? The RFC could really
do with making it clearer under what circumstances a persistent
confirmed commit is aborted, hence my errata. If I have got them wrong,
I apologise.

Re Kent’s point about section 8.4 overriding section 7.8 behaviour. Is
that a common approach to RFCs, that subsequent sections can overrule
prior sections without needing to add clarity in those prior sections?
If so, why are there so many forward references to capabilities in
section 7?

With the diffs in the errata, I am unclear what happens when reporting
an error in an existing erratum. If the resultant erratum replaces the
previous one, it would make sense to provide the diff against the
original text. If it becomes an additional erratum, it would make sense
to provide the diff against the previous erratum.

<tp>

Jonathan

The RFC Editor website says

 [Note: To report an error in an existing erratum, please contact the
RFC Editor.]

which suggests that we have an ad-hoc process and no formal procedure.
As yet, I do not see consensus as to what the totality of the changes to
the RFC should be, which for me is the starting point, before contacting
the RFC Editor to instigate the process.

On the more general point, if I read a document from start to end and
find later sections contradicting earlier ones I would regard the
document as flawed.

Tom Petch

 For the work we are currently undertaking, persistent confirmed commits
could be very useful. But if the RFC is ambiguous, errata cannot fix it
and it isn’t a netconf-next issue we will have to remove support for it.
But if that is the case then presumably we should not support any of
:confirmed-commit:1.1.

Jonathan

On Thu, May 16, 2019 at 11:50 AM Mahesh Jethanandani
<[email-masked] <mailto:[email-masked]> > wrote:

Hi Andy,

On May 16, 2019, at 10:02 AM, Andy Bierman <[email-masked]
<mailto:[email-masked]> > wrote:

On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[email-masked]
<mailto:[email-masked]> > wrote:

I would agree.

While the original text in 7.8 was ambiguous, Erratum 5397 does seem to
clarify that the <close-session> (not <kill-session), is for the session
in question, and not any session.

It also makes no sense from an operational POV, since dropping the
session

That is why I agree that Erratum 5397 should not be deleted, but should
be modified to the text suggested by Jonathan.

It's a minor point, but I could argue, as I wrote before, that such
clarifications in 7.x are unnecessary because 8.4 provides overrides.
I prefer less text because it's easier to get right (wit this is at
least the 3rd time Jonathan is at this now).  However "unnecessary"
doesn't mean "wrong" and since we've already stepped in it, getting the
7.x errata right might be easier than getting 8.4 right.

8.4.4.1.  <cancel-commit>

   Description:

be used to fix it -- a new version of the protocol should fix it, in
which WG and IETF consensus
is reached for the selected solution.

not really

The diff is building on top of the original erratum. I would think a
diff w.r.t. to the original erratum would make sense.

It depends, are you correcting the earlier errata or filing a new one?
Regardless, I expressed a diff for what I think the text should be
(which you didn't comment on); how that is translated is up to you.

Kent // contributor

Andy

Mahesh Jethanandani

Andy

---

------------------------------------------------------------------------
--------

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 31 May 2019 15:19:40 -0700

Several attempts have been made to clarify the role of confirmed commit in RFC 6241 vis-a-vis Section 7.8 <close-session> and Section 7.9 <kill-session>, and the text in Section 8.4 Confirmed Commit Capability.

We, (the chairs) believe that the best way to resolve issues with the current set of erratum that already exist or are being proposed is to minimize re-explaining the role of confirmed commit in both Section 7.8 and 7.9 and defer the explanation to Section 8.4 of the RFC. With that in mind, we are proposing that Section 7.8 and 7.9 should ultimately look as follows. Note, the highlights in all the sections are to enable identifying the changes.

OLD (as in original RFC 6241)

7.8 <https://tools.ietf.org/html/rfc6241#section-7.8>.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close any
      associated connections.  Any NETCONF requests received after a
      <close-session> request will be ignored.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

NEW

7.8 <https://tools.ietf.org/html/rfc6241#section-7.8>.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close any
      associated connections.  Any NETCONF requests received after a
      <close-session> request will be ignored.

      For details on what happens if a NETCONF server receives a 
      <close-session> request while processing a confirmed commit,
      please refer to Section 8.4 <https://tools.ietf.org/html/rfc6241#section-8.4>.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

OLD (as in original RFC 6241).

7.9 <https://tools.ietf.org/html/rfc6241#section-7.9>.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4 <https://tools.ietf.org/html/rfc6241#section-8.4>), it MUST restore the
      configuration to its state before the confirmed commit was issued.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

NEW

7.9 <https://tools.ietf.org/html/rfc6241#section-7.9>.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      For details on what happens if a NETCONF server receives a 
      <kill-session> request while processing a confirmed commit,
      please refer to Section 8.4 <https://tools.ietf.org/html/rfc6241#section-8.4>.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

In addition, the following paragraph in Section 8.4.1 would be modified.

OLD:

   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.

NEW:

   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, unless the confirmed commit 
   also included a <persist> element.

Current Erratums for RFC 6241 will be adjusted to accommodate these changes.

Mahesh & Kent (co-chairs)