Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt

[Kent Watsen <[e-mail]>]

[CC-ing Eric due to urgent SN issue]


Hi Tianran,

> Hmmm, my guess is that pretty much all transports supporting configured subscriptions will have the server (i.e., line cards) proactively initiate the connections to the notifications-receivers (and not have the receivers connecting to the servers).   This is more a macro-observation than a draft-mahesh-netconf-https-notif specific thing, though that draft follows this pattern too.
>  
> [Tianran2]: I am sorry I not quite clear. Here we are talking about the dynamic subscription. I conclude there are four potential modes.
> 1. The linecard runs on server mode. The connections are dynamically set up, when the receiver know the subscription decomposition result at run time.
> 2. The linecard runs on server mode. All the potential connections are set up. The receiver only get data dynamically.
> 3. The linecard runs on client mode. The connections are dynamically set up, when the linecard know the subscription decomposition result at run time.
> 4. The linecard runs on client mode. All the potential connections are set up. The linecards send data dynamically.

Yes, this section regards dynamic subscriptions, but the macro-observation is that it would be good if dynamic-subscriptions behaved like configured-subscriptions and, since configured-subscriptions will most likely always have the server initiating the connection, it would be consistent if that were true for dynamic-subscriptions too (as opposed to having open ports).   Makes sense?





>  Ah, a "channel" container was added, I didn't see that before.  The draft should've defined YANG module to add a "channel" container.  That said, I don't think what you're hoping to achieve here is legal/valid YANG (please ensure that all examples are validated using e.g., `yanglint`).
>  
> [Tianran2]: I did not define a YANG module for this, because this may make the this draft depend on draft-mahesh-netconf-https-notif. But I sent the comment to the mailing list to suggest draft-mahesh-netconf-https-notif to apply this modification.
> https://mailarchive.ietf.org/arch/msg/netconf/YmIh2l1xGJUq5gYwvrzcwnRphPg <https://mailarchive.ietf.org/arch/msg/netconf/YmIh2l1xGJUq5gYwvrzcwnRphPg>
>  
> Or do you think this draft can define a configuration framework, not include the details? So that transport like draft-mahesh-netconf-https-notif can augment.

Ah, I recall seeing that message fly by before.  Seems like no one replied, too bad.   Really, this is not a something any transport draft (e.g., draft-mahesh-netconf-https-notif) should have to specify.  It would have to be the SN draft (currently in AUTH48) and likely published before Montreal.  This creates quite a problem.  I strongly advise raising this to the SN draft authors (specifically Eric Voit, CC-ed) ASAP! 



Kent // contributor