Re: [netconf] RFC 6241 Ambiguity

[<[e-mail]>]

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 <[e-mail]> On Behalf Of Andy Bierman
Sent: 16 May 2019 20:11
To: Mahesh Jethanandani <[e-mail]>
Cc: Kent Watsen <[e-mail]>; [e-mail]
Subject: Re: [netconf] RFC 6241 Ambiguity

 

 

 

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

Hi Andy,





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

 

 

 

On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[e-mail] <mailto:[e-mail]> > 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,




      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.

 

 

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.

 

 

 

      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.

 

 

This makes no operational sense if the <persist> parameter was used.

 

 

 

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.

 

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





 

 

not really

 

 





 





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.

 

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

 

_______________________________________________
netconf mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netconf

 

Mahesh Jethanandani

[e-mail] <mailto:[e-mail]> 

 

 

 

 

Andy

 

 



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