On Thu, Sep 3, 2015 at 1:40 PM, Robert Wilton <[email protected]> wrote:
> Hi, > > I've posted a new experimental draft, that proposes a potential different > solution for handling applied configuration, for possible discussion at > next week's interim meeting on opstate. > > Comments before hand are welcome. > > This is better than the "config" and "state" containers at least. Multiple schema nodes to represent the same object in different states doubles the complexity of the module. Considering 97% + of devices don't need this stuff, that's just not worth 2X the cost. However, it is important that the schema be stable. The way an <rpc-reply> is parsed cannot really depend on an <rpc> that was sent earlier. But a leaf like <mtu> will either be represented as a leaf or as a container in the <rpc-reply>, depending on the <with-config-state> parameter that was sent in the <rpc>. I appreciate sec. 7. It is good to relate the solution back to the requirements (even if that list seems to be growing every week). I have not personally seen the problems in the requirements list. The delay between intended and applied is usually milliseconds, sometimes seconds. I don't agree that we need to diagnose line cards that are not plugged in. The operator should figure this out some other way (e.g. entity-mib). It is not clear how long this data will indicate 'in progress'. Most of the time, <cfg-intended> and <cfg-actual> will be the same. (This basically triples the size of a <get-config> response) I don't see why any enum other than 'diff-cfg-only' would be used. This is how I would also expect the <get-state> operation to work in Kent's draft. It would really help if you included the YANG module you want to standardize. There are a couple examples but no formal definition. Thanks, > Rob > Andy > > > -------- Forwarded Message -------- Subject: New Version Notification for > draft-wilton-netmod-opstate-yang-00.txt Date: Thu, 3 Sep 2015 13:31:00 > -0700 From: [email protected] To: Robert Wilton <[email protected]> > <[email protected]>, Robert Wilton <[email protected]> <[email protected]> > > A new version of I-D, draft-wilton-netmod-opstate-yang-00.txt > has been successfully submitted by Robert Wilton and posted to the > IETF repository. > > Name: draft-wilton-netmod-opstate-yang > Revision: 00 > Title: "With-config-state" Capability for NETCONF/RESTCONF > Document date: 2015-09-03 > Group: Individual Submission > Pages: 22 > URL: > https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/ > Htmlized: > https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-00 > > > Abstract: > This document proposes a possible alternative solution for handling > applied configuration state in YANG as described in draft-openconfig- > netmod-opstate-01. The proposed solution, roughly modelled on the > with-defaults NETCONF/RESTCONF capability, aims to meet the key > requirements set out in draft-openconfig-netmod-opstate-01 without > the need for YANG module authors to explicitly duplicate > configuration nodes in both configuration and operational containers. > This draft does not address the issue of co-location of configuration > and operational state for interfaces, nor does it provide a NETCONF > mechanism to retrieve operational data separately from configuration > data. > > > > > 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. > > The IETF Secretariat > > > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
