Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

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

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


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 <[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]> wrote:
>
> Hi Andy,
>
>
>
> On May 16, 2019, at 10:02 AM, Andy Bierman <[e-mail]> wrote:
>
>
>
>
>
>
>
> On Wed, May 15, 2019 at 2:48 PM Kent Watsen <[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]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> Mahesh Jethanandani
>
> [e-mail]
>
>
>
>
>
>
>
>
>
> 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>
> <#m_-270464312496652421_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>