> From: Juergen Schoenwaelder: Monday, December 12, 2016 6:10 PM > > The proper action in this case may be to kill the NETCONF session. > > It can be debated whether simply deleting state created by some other system > (the subscription in this case) is a proper management approach since it may > lead to undefined or erratic behaviour of other systems or to loops where some > systems create state that others delete and so on.
Wouldn't this have implications to I2RS or OpState? How would an Operator be able to focus only on the subset of dynamic state which is currently impacted? An analogy might be someone with phone and faulty video service connected over their broadband connection. They get on the phone with an operator to troubleshoot their video, but the operator can't reset the video CPE session without taking out the phone service as well. Eric > /js > > On Mon, Dec 12, 2016 at 05:43:57PM +0000, Tim Jenkins (timjenki) wrote: > > Hi, > > > > As an example, say a number of subscribers connect in to a system using > NETCONF, then issue the <establish-subscription> RPCs as defined by > https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01. These appear as > entries in the ietf-event-notifications/subscriptions container, which is > "config > false". They don't appear in the ietf-event-notifications/subscription-config > container since they are not configured; they are dynamic. > > > > A network manager is examining the system and observes the subscriptions in > the ietf-event-notifications/subscriptions container and decides that some or > all > of them should be deleted. Since the network manager may be using a tool that > uses NETCONF (or perhaps some other tool) to remotely manage the system, > what underlying method would be used to delete these subscriptions? > > > > As mentioned below, as far as I can tell, a standard NETCONF management > RPC like <edit-config> cannot be directed at these subscriptions since config > is > false. So I'm trying to understand if there is some other general solution > for this > type of problem for other protocols, or perhaps even for NETCONF other than a > custom RPC such as those already defined for this application specific > purpose. > > > > Hope this helps... > > > > Tim > > > > -- > > Cisco Systems Canada Co. > > 2000 Innovation Drive > > Kanata, ON, Canada, K2K 3E8 > > Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326> > > Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327> > > Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html> > > > > > > > > > > On 2016-12-12, 11:54 AM, "Kent Watsen" <[email protected]> wrote: > > > > Hi Tim, > > > > I don’t understand your problem. Which parts in the referenced drafts > should we look at, or can you provide an example? > > > > Thanks, > > Kent > > > > > > > > Hi, > > > > I have a general question related to management operations on > operational data. The question is intended to be protocol agnostic, since as I > understand it, the NETCONF management operations do not apply to data > modelled in YANG where config is false. In other words, there is no generic > NETCONF RPC that will, for example, delete entries in a table of operational > data. > > > > My question arises because we are implementing a feature that is defined > using YANG, and has custom NETCONF RPCs whose operations can create, > modify and delete rows of a YANG list that has entries that are both config is > true and config is false. The rows that are config is false are the only rows > that > can be affected by the custom NETCONF RPCs; the other rows are affected only > by the standard NETCONF management RPCs. However, there is a need for > management operations to be able to remove the rows and the operations > associated with them for various reasons. > > > > So my question is this: what is the general approach to this problem? > > > > As mentioned above, for NETCONF, I believe the answer is that a custom > RPC has to be used. But is this intended to be the case for all protocols > that can > deal with YANG modelled data? > > > > In case it matters, the specific case I'm dealing with is subscriptions > > as per > https://tools.ietf.org/html/draft-ietf-netconf-rfc5277bis-01 and > https://tools.ietf.org/html/draft-ietf-netconf-yang-push-04. > > > > Thanks, > > > > Tim > > > > -- > > Cisco Systems Canada Co. > > 2000 Innovation Drive > > Kanata, ON, Canada, K2K 3E8 > > Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326> > > Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327> > > Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html> > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > 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/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
