Juergen Schoenwaelder <[email protected]> wrote:
> 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.

+1


/martin

> 
> /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

Reply via email to