Re: [netconf] RFC 6241 Ambiguity

[Mahesh Jethanandani <[e-mail]>]

> On May 15, 2019, at 3:24 AM, Jonathan Hansford <[e-mail]> wrote:
> 
> 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. 

I would agree.

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

> 
> Thanks,
> 
> Jonathan
> 
> 
> On 14/05/2019 19:45:12, "Kent Watsen" <[e-mail] <mailto:[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?
>>>  
>>  
> 
> 
>  <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> <x-msg://76/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>_______________________________________________
> 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]