Re: [Netconf] Anyone want just Configured Subscriptions?

-----邮件原件-----
发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Kent Watsen
发送时间: 2018年7月9日 4:19
收件人: Martin Bjorklund; j.schoenwaelder@jacobs-university.de
抄送: netconf@ietf.org
主题: Re: [Netconf] Anyone want just Configured Subscriptions?

> > > > If you do this, why does the client, after receiving a call 
> > > > home, not simply create dynamic subscriptions? ;-)
> > > 
> > > Well, the configured subscription is needed anyway in order for 
> > > the device to call home, so having the client create all 
> > > configured subscriptions as dynamic subscriptions as well doesn't 
> > > seem quite right.
> > 
> > To call home, all you need is call home configuration, not 
> > configured subscriptions.
>
> Yes, but the configured subscription defines parameters (stream and
> filter) to trigger the call home action.

I think Juergen's idea is to just configure /netconf-server/call-home/ netconf-client instances, and for those instances that are for notifications, the client can do a dynamic subscription;  no need to configure anything under the /subscriptions/subscription/receivers...

[Qin]: Forget the history of removing address and port under the /subscriptions/subscription/receivers, what's the real concern for this?
To support call home, what additional parameters are besides address and port?

Another idea is to have a separate notifications-specific list of call-home clients, which might be defined as MUST needing to advertise a new capability indicating that the flow of <notifications> can occur immediately:

  module ietf-netconf-notifications {
    prefix nn;
    import ietf-netconf-server { prefix ncs; }
    import ietf-subscribed-notifications { prefix sn; }

    // define a *local* netconf-server instance
    container "netconf-server" {
      uses "ncs:netconf-server-grouping" {
        // prune out the "listen" subtree
        refine "listen" {
          when "false()";
        }
      }
    }

    // add leafref to above locally-configured call-home instances
    augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
      leaf netconf-endpoint {
        type leafref {
          path "/nn:netconf-server/nn:call-home/nn:netconf-client/nn:name";
        }
      }
    }
  }

[Qin]: Does this new proposal has impact on ietf-netconf-notifications defined in RFC6470?
It looks netcnf-endpoint is not defined as part of base event notification.

Kent // contributor

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf