Re: [netconf] RFC 6241 Ambiguity

[Andy Bierman <[e-mail]>]

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