Re: [netconf] RFC 6241 Ambiguity

[tom petch <[e-mail]>]

inline

Tom Petch

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

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.

<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



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



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


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