Subject: Re: [Netconf] HTTP2 configured subscriptions, is RESTCONF call home necessary? (was RE: Anyone want just Configured Subscriptions?)

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jul 2018 03:37:17 +0000

> My opening thought is that we should nix configured subscriptions entirely
> for the first round of these drafts.  Only support dynamic subscriptions.

My thinking here is only to end the need to have this conversation, but
having this conversation is probably best, so please ignore this comment.

> My second thought is that, when we get around to defining configured 
> subscriptions, we should consider supporting both "publisher is the 
> transport-server" (for the awesome alignment of security credentials)
> as well as "publisher is the <transport>-client (for when there's a
> need for that).  IMO, this comes down to the "notif" modules, one for
> each variation, I envision a dozen or so in time.

For example:
 - notif-netconf-client   // uses /ietf-netconf-client:initiate/...
 - notif-netconf-server   // uses /ietf-netconf-server:call-home/...
 - notif-restconf-client  // uses /ietf-restconf-client:initiate/...
 - notif-restconf-server  // uses /ietf-restconf-server:call-home/...
 - notif-coap-client      // uses /ietf-coap-client:initiate/...   (TBD)
 - notif-coap-server      // uses /ietf-coap-server:call-home/...  (TBD)
 - notif-http1.1-client   // ???
 - notif-http2.0-client   // ???
 - notif-syslog-client    // ???       
 - etc.

And, for interoperability, we'd have to pick a mandatory to implement
transport, which would it be?  

Kent // contributor

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=el8MvXNhqSBoUo3X-Zxrmpm9epSFW1DK-c9I-UIJ5Mg&s=ivkOOUzylZB3d4jE_POKo5ixANfXcV8KfZozdCpzNok&e=