Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

Qin Wu <bill.wu@huawei.com> Sat, 06 February 2021 12:51 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EC63A1234; Sat, 6 Feb 2021 04:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93SCjsKEWFUb; Sat, 6 Feb 2021 04:51:11 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C613A1233; Sat, 6 Feb 2021 04:51:11 -0800 (PST)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DXsV52Gknz67jHs; Sat, 6 Feb 2021 20:46:21 +0800 (CST)
Received: from fraeml701-chm.china.huawei.com (10.206.15.50) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Sat, 6 Feb 2021 13:51:07 +0100
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Sat, 6 Feb 2021 13:51:07 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.15]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0509.000; Sat, 6 Feb 2021 20:51:05 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
Thread-Topic: WGLC: draft-ietf-netconf-https-notif-06
Thread-Index: Adb8hrXL1/zYo+imSqywerXloeit7g==
Date: Sat, 06 Feb 2021 12:51:04 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADD5EFCF@dggeml531-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.101.103]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/dhPPyRkcEKU9WSYXCl4z8RYqM98>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2021 12:51:13 -0000

Hi, authors of draft-ietf-netconf-https-notif
I have read the v-07 that has just been posted and have the following comments:
1. Section 1 said:
"future efforts may define support for other encodings (e.g., binary)."
Why Cbor can not be supported as one of example binary encoding? Isn't COBR IETF published standard work?

2. Section 1 ,last paragraph said:
"
   Configured subscriptions enable a server, acting as a publisher of
   notifications, to proactively push notifications to external
   receivers without the receivers needing to first connect to the
   server, as is the case with dynamic subscriptions.
"
I want to make sure two things this paragraph want to convey:
1.	So call home is not needed in this case to establish service initiated RESTCONF connection
2.   The connection between the server and the reciver is short live connection rather than long live connection? Correct?

3. Section 2 said:
"
   The protocol consists of two HTTP-based target resources presented by
   the receiver:
"
Is target resource target URI? Can you provide a reference for target resource?

4. Section 2 second bullet said:
"
a future effort MAY extend the protocol to send multiple notifications per message.
"
What do you indicate for sending multiple notification per message? Should you add reference to message header and bundle draft,i.e., draft-ietf-netconf-notification-messages?

5. Section 4.1 said:
"
   The publisher sends an HTTPS POST request to the "relay-
   notifications"  resource under a known path on the receiver
"
Where relay- notifications" resource is defined? In which RFC? Can you provide a reference to it. It is a surprise to see “relay-notification” appeared without any context information 
to be laid out for this? E.g., why relay-notification is picked? Is there any other choice?

6. Section 4.1 said:
"
Instead of saying that, for JSON-encoding purposes, the module
name for the "notification" element is "ietf-restconf, the module
name will instead by "ietf-https-notif".
"
s/the module name will instead by/the module name will be instead by

-Qin
-----邮件原件-----
发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Rob Wilton (rwilton)
发送时间: 2021年1月14日 21:12
收件人: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org
主题: [netconf] WGLC: draft-ietf-netconf-https-notif-06

This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06 ending on Jan 28.  Here is a direct link to the HTML version of the draft:

	https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

Please note, the reason that I am making this request rather than the WG chairs is because both chairs are listed as authors on this document.

Thank you,
Rob Wilton, OPS AD

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf