[As a contributor]
This update reflects the four on-list email threads since -00 was published as follows: 1. Regarding Balazs, Gert, and Robert’s thread here: https://www.ietf.org/mail-archive/web/netmod/current/msg14243.html The term “non-derived” state in Req #4 has been removed and new term “Operational State” has been added. The new requirement #3 is a little different than what’s in draft-openconfig-netmod-opstate, but I believe that it is what’s intended (no pun intended, doh!). No change made clarifying long running operations like backup, as this requirements draft, when referring to “asynchronous", regards configuration operations. Also no change made to add a new requirement for a YANG annotation for config nodes that are known to have potentially different intented-config value. Git diffs: https://github.com/netmod-wg/opstate-reqs/commit/6bc82d24e35337cb2229fb6338f21af2bf106647 https://github.com/netmod-wg/opstate-reqs/commit/3dabc4fa905c4d3037f808dbc8f18584d3e613d5 2. Regarding Jason and Gert’s thread here: https://www.ietf.org/mail-archive/web/netmod/current/msg14342.html I have not done anything about this yet, but it seems that something might need to be done. Personally, I don’t see how Rollback on Error could be allowed to rollback the intended config set via an asynchronous commit (e.g., after <ok/> has been sent). My thinking is that the server should send <rpc-error> if the client requests that combination. FWIW, I’m not troubled by 'hybrid' or cheating-synchronous implementations, as in my view, they don’t advertise support for applied configurations or for synchronous commits. 3. Regarding Jason and Randy’s thread here: https://www.ietf.org/mail-archive/web/netmod/current/msg14344.html The old 2-A was removed since it’s a duplicate to 4-C, and then the old 2 was removed since it’s covered in the new Operational State term. The old #5 was also removed to eliminate cruft from the draft. Then I fixed Appendix B to point to new section numbers. Git diffs: https://github.com/netmod-wg/opstate-reqs/commit/02ef5fedd4293024dab70514884e9661b9c86285 https://github.com/netmod-wg/opstate-reqs/commit/4a06744157dada4707a457ec06a17b048719ae0b 4. Regarding Jason and Gert’s thread here: https://www.ietf.org/mail-archive/web/netmod/current/msg14343.html No changes made here because I don’t think this hybrid case needs to be defined. In my view, a device either advertises support for synch or asynch or both or none (default). For the first three cases, the behavior is explicitly defined. For the last case, the behavior remains same as today (undefined), which is needed for backwards compatibility. Thanks, Kent On 12/15/15, 4:47 PM, "netmod on behalf of internet-dra...@ietf.org" <netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group > of the IETF. > > Title : NETMOD Operational State Requirements > Authors : Kent Watsen > Thomas Nadeau > Filename : draft-ietf-netmod-opstate-reqs-01.txt > Pages : 8 > Date : 2015-12-15 > >Abstract: > This document defines requirements for servers enabling better > visibility and control over the server's operational state. To > achieve this end, this document also defines terminology describing a > conceptual model enabling the requirements to be expressed. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-01 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-01 > > >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/ > >_______________________________________________ >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
