Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

Qin Wu <bill.wu@huawei.com> Thu, 13 February 2020 10:08 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 1AF2E1200C7 for <netconf@ietfa.amsl.com>; Thu, 13 Feb 2020 02:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Ke1oRRxZYQ-T for <netconf@ietfa.amsl.com>; Thu, 13 Feb 2020 02:08:54 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B95E12007A for <netconf@ietf.org>; Thu, 13 Feb 2020 02:08:54 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9D7285CAF387840873E4; Thu, 13 Feb 2020 10:08:50 +0000 (GMT)
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Feb 2020 10:08:50 +0000
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 13 Feb 2020 10:08:49 +0000
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 13 Feb 2020 10:08:49 +0000
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.52]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Thu, 13 Feb 2020 18:08:46 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "Eric Voit (evoit)" <evoit@cisco.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)
Thread-Index: AdXiVDU7eC3gH6aESdCiWUYBGtpr6A==
Date: Thu, 13 Feb 2020 10:08:46 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA966BA0B@dggeml511-mbx.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.138.33.123]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA966BA0Bdggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OqPTb3SpH0D3CmdcvmewtNTJtMk>
Subject: Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)
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: Thu, 13 Feb 2020 10:08:57 -0000

Eric:
Why structure message should tie to a single YANG data module with “yang-module” parameter, is this too restrictive?

-Qin
发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Mahesh Jethanandani
发送时间: 2020年1月28日 8:19
收件人: Eric Voit (evoit) <evoit@cisco.com>
抄送: netconf@ietf.org
主题: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

Hi Eric,

This e-mail triggers two responses. Let us deal with draft-ietf-netconf-notification-messages here, and I will bring up comments/questions related to draft-ietf-netconf-https-notif in the other thread.

You have indicated a desire that receiver capabilities should be documented by the transport specific draft, e.g. draft-ietf-netconf-https-notif, and not this draft. As such you believe that the draft is ready.

To the WG, the authors have indicated a desire to wrap up this draft, and would like us, the chairs, to issue a WGLC on it. Before we do that, we wanted to ask if the WG believes that the document is ready, and that there are no more issues that need to discussed/addressed by draft-ietf-netconf-notification-messages document at this time.

Cheers.

Mahesh and Kent (as co-chairs).


On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:

Hi Mahesh,

During the IETF 106 session, there was discussion on how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>=1>.  Section 6 highlights several of the considerations.   Relevant are the following:

(a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4.

(b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers.

(c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available capabilities of the far end.

(d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1).


Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> *just* to discover this single element of client functionality seems overkill/heavyweight.

I was fine with letting this remote capabilities discovery question sit for a while.   However draft-ietf-netconf-https-notif<https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> shows that we now must address this question.  Specifically should the diagram section 1.4.1 show this capability exchange?

It turns out that independent of draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway.  These questions are:
  (1) Does the targeted HTTPS receiver support configured subscriptions?
  (2) Can the targeted HTTP@ receiver accept a new subscription as described in a <subscription-started>?
Only if these questions are "yes", should the <subscription-started> be responded to with an "OK".

Add to this a third question driven from (a)-(d):
  (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"?

A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include body elements listing supported receiver resources.  Maybe something YANG encoded via ietf-yang-structure-ext containing:

      <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <capabilities>
          <capability>
            urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
          </capability>
        </capabilities>
      </foo>

What do you think of this approach?

Eric

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>