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

Kent Watsen <> Sun, 14 July 2019 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A8FF120292 for <>; Sun, 14 Jul 2019 12:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CIBMbPhZv6nx for <>; Sun, 14 Jul 2019 12:14:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F91C120291 for <>; Sun, 14 Jul 2019 12:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1563131680; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=jNGL1hGKzVNY3sVCC84lu2/U5JlC8YgvkXpGH9j+ZlY=; b=Q6fNLGGmqfNzYfJ4JEa+1/4mWqYvmFWY1wYNmcWA4ANgHyspT27AzOMwVjMbV7/S azdH2E0uHDWPnBXu76gjvnVEMvlEm/mdtIoT9unPomHQnW/V3e2Go033WUgaoryU6i4 4y9moJFUulTz4HNtrhFKbFAWssRewUPriAFxK3iE=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B4548FF1-4C24-49CB-8618-31367E7DC060"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 14 Jul 2019 19:14:40 +0000
In-Reply-To: <>
Cc: Qin Wu <>, "" <>
To: Tianran Zhou <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.07.14-
Archived-At: <>
Subject: Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Jul 2019 19:14:44 -0000

=== 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