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

[Kent Watsen <[e-mail]>]

Hi Tianran,

>> 1. In dynamic subscription case, how does Publisher agent behind Publisher
>> master know where a particular receiver is when pushing subscribed data to
>> the receiver in a separate channel?
> I think Appendix A.1 gives one example to show how this works in RESTCONF case.
> Firstly, the reply to the dynamic subscription will return the resource access URIs.
> Then, the receiver can use the URIs to GET the data.
> This is similar to draft-ietf-netconf-restconf-notif-15.

I was also unsure (the draft needs to be more clear with regards to expected behavior).  That said, I have a fews concerns:

1) will the client (a.k.a. the receiver) establish a full RESTCONF protocol connection to each line-card?  What YANG-library response might the line-cards return?
2) are we sure the client connections will always be routable to the line cards?
3) are there any security issues with line-cards having open ports?

Given the above, and the potential symmetry to the configured case, did you consider letting the server establish the connection to the client?  From an operator's perspective, perhaps both options need to be supported?   


>> 2. How multi-stream originator works for configured subscription case? 
> In appendix A.2, I use the similar example as in draft-mahesh-netconf-https-notif-00 to illustrate.
> In brief, the originators run on client mode, and connect to the receiver actively.

This example appears to be an exact copy/paste from draft-mahesh-netconf-https-notif, at least.  I didn't notice any differences and, that being the case, am unsure (again) what the expected behavior was intended to be.  Could you add a sequence diagram illustrating internal interactions?

Kent // contributor