Re: [netconf] RFC 6241 Ambiguity

["Jonathan Hansford" <[e-mail]>]

Kent,

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.

With the diff, should that be against the original text or the original 
erratum?

Thanks,

Jonathan


On 14/05/2019 19:45:12, "Kent Watsen" <[e-mail]> wrote:

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

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus