Re: [netconf] RFC 6241 Ambiguity

[Kent Watsen <[e-mail]>]

> So I need to contact the RFC Editor to correct Erratum 5397, with the relevant text in sections 7.8 and 7.9 being changed to something like:
> 
> 7.8: "If a NETCONF server receives a <close-session> request while processing a confirmed commit (Section 8.4) for that session, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."
> 
> 7.9: "If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4) for the session to be killed, unless the confirmed commit is a persistent confirmed commit, it MUST restore the configuration to its state before the confirmed commit was issued. A persistent confirmed commit MUST survive session termination."

Ideally, Errata 5397 is deleted (because I think that it's clear that Section 8.4 overrides the 7.8 behavior) but, if we have to patch the errata, I might suggests:

For Section 7.8
  OLD (in RFC 6241)

    The server will release any locks
    and resources associated with the session and gracefully close any
    associated connections.

  NEW:

    The server will release any locks
    and resources, associated with the session and gracefully close any
    associated connections.  As an exception to the previous sentence, if
    the session is processing a persistent confirmed commit (Section 8.4),
    the resources necessary for supporting confirmed commit are not released.

For Section 7.9:
  OLD (in RFC 6241)

      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.

  NEW:
      What you have above seems fine, though I'd leave off the last sentence.


> I also need to contact the RFC Editor to correct Erratum 3821 to change:
> 
> If the session issuing a sequence of one or more confirmed commits is
> terminated for any reason before the confirm timeout expires, the server
> MUST restore the configuration to its state before the sequence of
> confirmed commits was issued, unless the last confirmed commit also
> included a <persist> element.
> 
> If the device reboots for any reason before the confirm timeout
> expires, the server MUST restore the configuration to its state
> before the sequence of confirmed commits was issued.
> 
> to something like:
> 
> If the session issuing a sequence of one or more confirmed commits is
> terminated for any reason before the confirm timeout expires, the server
> MUST restore the configuration to its state before the sequence of
> confirmed commits was issued, unless the confirmed commit is a
> persistent confirmed commit.
> 
> If the device reboots for any reason before the confirm timeout
> expires, unless a persistent confirmed commit is in progress, the 
> server MUST restore the configuration to its state before the
> sequence of confirmed commits was issued.
> 
>  A persistent confirmed commit MUST survive session termination.
> 

This seems okay but, again, I'd leave out the last sentence.


Side note: huge errata are hard to read without a diff.  If a lot of text, then the NEW (or the NOTES) should include a diff highlighting exactly what changed.

Kent // contributor



> Are those errata OK? 
>