Subject: Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

From: Gert Grammel <[email-masked]>
Date: Fri, 5 Feb 2016 12:20:07 +0000

Hi Kent,

On P.7 the current draft says: "Any rollback that may occur will restore
both the intended and the applied configurations to their previous states."

It is not clear to me to which phase of the configuration this statement
refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous operation is
defined as 
Asynchronous Configuration Operation:  A configuration request to
  update the running configuration of a server that is applied
  asynchronously with respect to the client request.  The server
  MUST update its intended configuration before replying to the
  client indicating whether the request will be processed.  This
  reply to the client only indicates whether there are any errors
  in the original request.  The server's applied configuration
  state is updated after the configuration change has been fully
  effected to all impacted components in the server.

The statement "The server MUST update its intended configuration before
replying to the client indicating whether the request will be processed²,
doesn¹t define what to do after responding. I suggest to add the following
clarification:
1) in case of a negative response from the Server, the server shall roll
back the intended config and the applied config shall not be affected.
2) in case of a positive response from the server, the intended config
shall remain. Upon failure in applying intended config, only applied
config is affected according to the error-option (rollback-on-error,
stop-on-error and continue-on-error)

Rationale for 1: since the server didn¹t accept a new intended config
(e.g. due to a syntax error), the original intended config should remain
untouched.
Rationale for 2: The intended state is logically owned by the client and a
server is supposed to align with it. Once a server accepted the intended
config with a positive response, a failure in the server execution doesn¹t
affect the intention. It would be the client to modify the intended state
if the intention changes. The difference between intended and applied
state is an important source of information for a client. Removing the
intended state after rollback would nullify the intention rather than
documenting which applied state differs from its intended state. This is
also in line with Œcontinue-on-error¹ and Œstop-on-error¹. In both cases
the difference between intended and applied state is important as changes
have only partially be applied. Hence the error-option should apply to
applied-config.

- Gert

On 2016-02-02 18:54, "netmod on behalf of Kent Watsen"
<[email-masked] on behalf of [email-masked]> wrote:

>
>Hi All,
>
>I didn¹t receive the usual announcement CC-ed to the netmod list, so I¹m
>replying to this one sent to the id-announce list instead.
>
>Anyway, this morning I posted -01 of this draft and then shortly after
>-02 to fix some cleanup items I only noticed after -01 was posted  :ooops:
>
>Either way, this update is an overhaul to the original draft posted last
>September.
>
>Kent
>
>
>
>
>
>On 2/2/16, 10:30 AM, "[email-masked]"
><[email-masked]> wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>
>>
>>        Title           : Operational State Enhancements for YANG,
>>NETCONF, and RESTCONF
>>        Authors         : Kent Watsen
>>                          Andy Bierman
>>                          Martin Bjorklund
>>                          Juergen Schoenwaelder
>>	Filename        : draft-kwatsen-netmod-opstate-02.txt
>>	Pages           : 27
>>	Date            : 2016-02-02
>>
>>Abstract:
>>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>>   satisfying the requirements set forth in Terminology and Requirements
>>   for Enhanced Handling of Operational State.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>I-D-Announce mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/i-d-announce
>>Internet-Draft directories: http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Fri, 5 Feb 2016 18:14:54 +0000

>replying to the client indicating whether the request will be processed²,

I think that this statement is/was a mistake.  It should’ve been left open to the server to return immediately, as even updating intended can take 3o+ seconds on some systems...

>stop-on-error and continue-on-error)

This does not match my understanding of the desired behavior, nor would I know how to implement it without introducing additional API and metadata to support/control that approach.

Kent