> From: i2rs on Behalf Of Juergen Schoenwaelder, February 03, 2015 3:03 AM > > On Mon, Feb 02, 2015 at 06:53:16PM -0500, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can > > access the draft at: > > > > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt > > > > I like to point out that some statements in the draft are either unclear or > wrong.
As a "00" draft, I do expect that there will be changes needed. Your feedback is certainly appreciated. > o limited support for pushed notification of changes. (Currently > notifications are for configuration data only. And even then, > subscription mechanisms for such notifications are undefined.) The sub-bullet was intended to refine the "existing YANG technology ecosystem" paragraph above it. That said, the word "undefined" will be changed in the next draft. More below. > RFC 5277 defines a <create-subscription> mechanism. RFC 6470 defines > notifications that allow to track changes in a configuration datastore. So > why is > the subscription mechanisms undefined? Netconf Event Notifications RFC5277 is useful, and everything possible from it should be incorporated in the ultimate technology solution. But RFC5277 does not follow the Pub/Sub paradigm. It predates YANG. In addition, a goal of this document is to frame requirements so as not to preclude support for additional transports beyond Netconf. Netconf Base Notifications RFC6470 is applicable for configuration info only. The I2RS requirements mean we need to track many other things such as routing changes. > But in more general terms, I am wondering what the scope of this work is. Is > the > goal to provide a mechanism similar to what we have already for 'config true' > datastores for 'config false' datastores or is the goal to replace the > existing > mechanism with a new mechanism that will cover both 'config true' and 'config > false' datastores? The goal of this document is to aggregate and refine the I2RS requirements which highlight the needs of YANG Pub/Sub. I believe there are several interesting requirements areas to explore here, including, - Dampening: confining the visibility of volatility into something digestible by the subscriber - Liveliness: what to do if subsets of YANG subtrees can no longer be monitored or are stale - Presentation: how do we bundle a set of discrete object notifications into a single publishable update for a Subscription Mechanisms will follow requirements. Eric > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
