> Hi, > > This draft says it addresses 2 deficiencies w/ existing mechanisms: > > The existing YANG technology ecosystem > is proving insufficient for those applications due to: > > o a reliance on RPC-style interactions where data is configured or > fetched on-demand by applications. > > o change notifications which identify a node associated with the > config change, without the actual data updates > > > I don't understand why RFCs for configuration are a problem. > The nice thing about polling is that the server is fairly sure the client is > alive and > still wants the updated info.
Polling is unlikely to have the required reaction speed. The very first requirement of the i2rs-usecase WG draft is "monitor the available routes installed in the RIB of each forwarding device, including near real time notification of route installation and removal". > I certainly agree that things could be simpler on the client by moving > complexity > to all the servers instead. Not sure the extra work each device will do is > worth > the increase in required resources. > > Currently, NETCONF/NACM does not support the access control granularity that > would be required to prune unauthorized data from notifications (e.g., > netconf- > config-change for some unauthorized data requires the new value to be > removed from the payload, depending on the user-id of the recipient). Thanks. We certainly need to explore this. And solve this. > Keeping the config data out of the notification was a deliberate decision by > the > NETCONF WG, because of increased complexity on the server, increased > payload size, and lack of access-control support. Understood. And choices previously made can meet the needs of many applications. However supporting quick reaction to topology changes gets hard when multiple interactions are needed to figure out the specifics of the routing update. Eric > > > Andy > > > > > On Mon, Mar 9, 2015 at 3:03 PM, <[email protected]> wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Interface to the Routing System Working > Group of the IETF. > > > > Title : Requirements for Subscription to YANG Datastores > > Authors : Eric Voit > > Alex Clemm > > Alberto Gonzalez Prieto > > Filename : draft-ietf-i2rs-pub-sub-requirements-01.txt > > Pages : 16 > > Date : 2015-03-09 > > > > Abstract: > > This document provides requirements for a service that allows client > > applications to subscribe to updates of a YANG datastore. Based on > > criteria negotiated as part of a subscription, updates will be pushed > > to targeted recipients. Such a capability eliminates the need for > > periodic polling of YANG datastores by applications and fills a > > functional gap in existing YANG transports (i.e. Netconf and > > Restconf). Such a service can be summarized as a "pub/sub" service > > for YANG datastore updates. Beyond a set of basic requirements for > > the service, various refinements are addressed. These refinements > > include: periodicity of object updates, filtering out of objects > > underneath a requested a subtree, and delivery QoS guarantees. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements- > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > [email protected] > > 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 > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
