On 2/5/16, 7:20 AM, "Gert Grammel" <ggram...@juniper.net> wrote:
>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²,
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...
>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)
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
>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"
><netmod-boun...@ietf.org on behalf of kwat...@juniper.net> 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, "internet-dra...@ietf.org"
>><internet-dra...@ietf.org> 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
>>>i-d-annou...@ietf.org
>>>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
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
