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

[Kent Watsen <[e-mail]>]

=== Re: dynamic subscription case ===

> I was also unsure (the draft needs to be more clear with regards to expected behavior).  That said, I have a fews concerns:
>  
> [Tianran]: I am not sure if I am doing the right thing on the examples. Maybe you can give some more suggestions.
> This draft intent to provide a transport independent solution. Actual transport design, say RESTCONF, NETCONF, HTTPS, may have several options and need some more considerations. I am not sure if we should consider them all in this draft. So the question is what kind of example is helpful? I did not see a similar example in the draft-ietf-netconf-subscribed-notifications.

Do not take draft-ietf-netconf-subscribed-notifications as an example to follow when it comes to examples.  The lack of examples in that draft continues to cause confusion.  As RFC 8407 says: "Each specification that defines one or more modules SHOULD contain usage examples, either throughout the document or in an appendix.".

It is understood that, in addition to variations in encoding (e.g., XML, JSON), this document (and SN) have variations in transports (RC, HTTP, etc.).  This additional dimension is easily addressed, just preface your examples with something like "For instance, assuming the use of the transport defined by [draft-foo-bar] and using the XML (or JSON) encoding, the following example illustrates yada yada..."


>  The following questions are respect to one potential RESTCONF transport solution I am considering. I give only my considerations.
> 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?
> [Tianran]: I do not think it’s necessary to establish a full RESTCONF connection to each line-card. May be the http connection with server push capability is OK.

Fine, but my point is that your draft needs to explicitly say it and, more importantly, state exactly what is or is not allowed over such less than full connections.


>  2) are we sure the client connections will always be routable to the line cards?
> [Tianran]: I assume the address is routable.

Again, the draft needs to state this.


> 3) are there any security issues with line-cards having open ports?
> [Tianran]: The master returns the URIs containing the line-card port to the receiver within an security channel.

True, but the line-card has an open port that could be detected via a port sweep and thereafter attacked (DoS?).  The Security Considerations section needs to mention this.


>  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?   
> [Tianran]: Good question. It’s impossible to include all the transports in this draft. This example seek to be compatible with draft-ietf-netconf-restconf-notif.
> On the other hand, maybe we can consider only to use the https client as in draft-mahesh-netconf-https-notif as the only tcp transport for all the scenario.

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. 





=== Re: configured subscription case ===
 
> 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?
>  
> [Tianran]Again, I want to be compatible with existing transport proposals as in draft-mahesh-netconf-https-notif.  So I suggested to include a list of channels in the receiver configuration. On one hand, it can support the multiple message originators scenario. On the other hand, one channel configuration can be compatible with the one message originator scenario.
>  
> Only this modification J
>        <receiver>
>          <name>foo</name>
>          <channel>
>            <tcp-params>
>  
>  
> I can add a sequence diagram to show how it works for this transport/example.

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`).



 
Kent // contributor