Re: [netconf] RFC 6241 Ambiguity

[Mahesh Jethanandani <[e-mail]>]

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

      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.

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

> 
> 
> 
> 
>>> 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 <https://www.ietf.org/mailman/listinfo/netconf>

Mahesh Jethanandani
[e-mail]