Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

[Kent Watsen <[e-mail]>]

Search for <Kent> below.

// contributor


<kent-orig> Okay, glad to see that you embrace using ietf-netconf-server, rather than ietf-netconf-client.  And I'll grant you that it's infinitely more likely that the ietf-netconf-server module would be implemented (i.e., the top-level /ncs:netconf-server container exists), more so than the ietf-netconf-client module would be implemented.  The WG created the top-level /ncc:netconf-client container more for the sake of symmetry than for having a use-case for when it would be implemented.  I think the question to ask is, is it possible that a device wants to use SN but doesn't *implement* ietf-netconf-server?
 
<Eric>  Yes, this will be possible.   Reasons would include: alternative transports (COMI, UDP), HTTP2 configured subscriptions (which might use ietf-restconf-server), or no need for a publisher to include the configured subscriptions feature.   

<Kent> I should've be more specific: is it possible that a device would use netconf-notif (where your leafref is defined) but not implement ietf-netconf-server?   Similarly, restconf-notif would presumably have a leafref to ietf-restconf-server, etc.
 


<kent-orig> Even though it seems like ietf-netconf-server might always be implemented, I do not yet think it is okay for this data model to have a leafref to one of the globally-configured /ncs:netconf-server/ncs:call-home/ncs:netconf-client instances, since that instance would be expected to use normal NETCONF interactions (i.e. client-driven); it could be a problem if the server started sending <subscription-started> messages right away.  For this reason, maybe the SN data model needs to have its own instance of the netconf-server-grouping (perhaps with the top-level /listen tree pruned out), so then it's clear that these netconf-server instances are specifically for subscriptions?
 
<Eric> The original thread was trying to enforce a single transport across the receivers of a configured subscription, and where objects specific to that transport could be augmented to those receivers.

<Kent> Sorry, can you go over this again.  What is the stated goal?  I recall Martin wanting the same encoding across receivers, but the same transport too?  I assume you don't mean "same transport" but "same kind of transport"?  So, if one receiver of a subscription uses netconf-notif, they all must use netconf-notif?

<Eric> The design pattern in the example augmentation below seems to do that.  This design pattern should hold whether a leafref is augmented in, or a group is augmented in.   This design pattern also works with the existing SN model.  I don’t know of an alternate proposal which meets these requirements.

<Kent> unsure.
 
<Eric> If this makes sense, the question becomes when to apply this design pattern on top of SN.   I agree there are interesting questions you raise above.  These questions appear to be bound to NETCONF call-home, and therefore the answers should be more closely aligned with draft-ietf-netconf-netconf-event-notifications rather than SN itself.

<Kent> agreed, most of this regards what's in the transport-binding drafts (netconf-notif, etc.), but I'm wanting to do this to prove out that the SN model.
 
<Eric> That is the driver behind my “ietf-netconf-subscribed-notifications-plus.yang” below.  Whether it augments in a  leafref or a group, this snippet of YANG provides a template for transport specific augmentations.  And using this template, how to embody NETCONF call home for subscriptions  could be delivered in a timeframe concurrent with “ietf-netconf-server.yang”.    

<Kent> I understand you're trying to say "let's not worry about how ietf-netconf-server works with this now".  I appreciate the desire to defer what we can.  I will again say, as co-chair, that I'm okay with us moving without having a draft that depends on ietf-netconf-server or the ietf-restconf-server modules.  That said, I don't understand what value the *conf-notif drafts have if they don't.  It seems that these drafts should depend on the ietf-*conf-server modules, but in order to get something to market faster, we want them to depend on something more like the ietf-*conf-no-crypto-server (right?), which the SN has further reduced to a single "address" leaf, which might be fine, but I don't think it should be in the SN model, since the ietf-*conf-server modules already define an address field, which would be redundant.

 
<Eric> Noe: If you wanted, a possible alternative to concurrent module delivery might be a single model.  To do this you would include a “subscription support” feature within “ietf-netconf-server.yang”.    The needed augmentation to "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"  could then be made there.  (Note: that augmentation of course would be refined to meet the call-home questions/considerations from this thread, such as being aimed to its own instance of the netconf-server-grouping.)  

<Kent> If I understand correctly, this would be a way to flag the call-home connection as being for SN, which addresses the I raised about how that would be known.  This is possible, and it might work well, but rather than put it into the ietf-*conf-server models directly, I think it would be better for the *conf-notif drafts to augment in the flag.


<kent-orig> I also have an issue with the proposed leafref because it leaves open the possibility that two subscriptions could point to the same /ncs:netconf-server/ncs:call-home/ncs:netconf-client instance, which would likely cause protocol and state machine problems.  
 
<Eric> Looking closer, perhaps a better place for the receiver leafref would be a choice of: 
/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name/ncs:ssh/ncs:endpoints/ncs:endpoint/ncs:name
or
/ncs:netconf-server/ncs:call-home/ncs:netconf-client/ncs:name/ncs:tls/ncs:endpoints/ncs:endpoint/ncs:name
 
But again, I am fine with anything which doesn’t insert redundant data as part of the receiver call home configuration.
 
<Kent> No, just pointing to /ncs:netconf-server/ncs:call-home/ncs:netconf-client should work, since the instance can have only one transport (ssh or tls) defined at a time.  That said, if your requirement is that they must all be ssh or must all be tls, we have a bigger issue.   FYI, the list of "endpoints" is there for HA reasons - they're a pool of failover endpoints the server can try - is that concept consistent with the SN draft?


/kw