Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)
"Eric Voit (evoit)" <evoit@cisco.com> Fri, 31 January 2020 18:04 UTC
Return-Path: <evoit@cisco.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 267601208CC for <netconf@ietfa.amsl.com>; Fri, 31 Jan 2020 10:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eE9iMDrC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=x7kBUzJP
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 q-depItvrOTj for <netconf@ietfa.amsl.com>; Fri, 31 Jan 2020 10:04:04 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1911201E0 for <netconf@ietf.org>; Fri, 31 Jan 2020 10:04:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30858; q=dns/txt; s=iport; t=1580493844; x=1581703444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lfd2qArvGSJ36KzkSe/Dux12URN4+KUH5M6cu8k0IW8=; b=eE9iMDrC/uwUeASwr0lkDP35Q1MZrMDu0SiRpjJa0vDpXCq62PXklygP AEMjlW8aD8KOTrQdfoBRd29ATqSfkqhE3O/J9cljT5KLRac0A6pemkHe2 sVbLUTMXBLt0DJvknoOgm7HecVG5es2lbaH+i93Ukfuqn/RvKX7yKHqbW k=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:elI09x1vKNQd1KB+smDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQBFP8LeLCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzCAAUazRe/5tdJa1lHAEBAQEBBwEBEQEEBAEBgXuBJS9QBWwrLSAECyoKhAqDRgOKdYJfhz2CJI4uglIDVAIHAQEBCQMBARgBDAgCAQGDe0UCgjEkOBMCAw0BAQQBAQECAQUEbYU3DIVmAQEBAQMBARARChMBASwJAgEPAgEIFRATAwQDAgICHwYLFBECBAENBQgGDQeDBYF9TQMfDwECDKMGAoE5iGJ1gTKCfwEBBYEzAg5BgxENC4IFBwMGgTiBU4pNGoFBP4ERR4JMPoIbSQEBAgEBGIExGCsJgloygiyNXYleiHOOckQKgjuDa4I4gSKKUIRFgkiYPY5ggUuHHIIokAkCBAIEBQIOAQEFgWkigVhwFTuCbFAYDY4dOIM7hRSFP3SBKYwQAYEPAQE
X-IronPort-AV: E=Sophos;i="5.70,386,1574121600"; d="p7s'?scan'208,217";a="624844227"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 18:04:02 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VI42pO002647 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 18:04:02 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 12:04:02 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 12:04:01 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 12:04:01 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bklz6KBknbv9s6iNSdpkNBPPu9CuI+zKshlcc1xIHT9OmM1nxdXbbH+LsMfK9bSo+EAAv5/F1FcLP/fiy/u06WL3cSLEKGZJlsKPgAWx3ZWuhsbgyuNV61k0Gr9XT2DMcViT6vpIzb70QmU/04eGdEDx/rZcdkKp9r4KLj/huceqP8mlXbqrNWUytk8JY5v4TbI0W8zj+62QbShHMyYG0OZ/GiGFg0emyYrIEpo9yVDqhnVZ5aOxN8It/tZr99vTgRtneijedadawme0RxXnpTNFhNEGMJtDkqWF9l0+Muk6Kja6gzyXxtS/Bb57n6p5Aqm6GlsXRuFnlnU3AXV+wQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W3nYC848cnH1mEVsnBbMa23uOO7skMRAg5JNCTu7Ys8=; b=Ozhd0p1kBGKT1aGlpj89i79meb7iJdHTURQ3JA5hfpUp7gGdFL3iJ92RT5yQMgar8nkeIKijp/As79D37994A4dA+PDKxy74i48My/jULkOXEKcRBvTuXg7mzXP9Ic2SLHQtwKKI3ORntH+gMugvVQLQPNcPZrYLOckHDBoKCdvYfxZCeQNP/RnfBt270rWxTEqdzUhrIh7JMlmnMRes3iQ7i3wfZpor+MPvgMA/XEIf/vH6A4YH0M0aJ7nPL6i8KbMcIfMGgHAjofnGfQn3RxcHFBCVDkzMi42dUNVxJR2GiY50I5AfvN42irR0489a9hoGIMwfpYrNFKaJ3a5gJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W3nYC848cnH1mEVsnBbMa23uOO7skMRAg5JNCTu7Ys8=; b=x7kBUzJPOCQEM9nymf2SfuN49dGBc0ugqoVRFG6r2JSvOscagP+4uVbaDS00hei6MGvyluXjqDWSyV9tJMft2WUYAAxL05LarOqyfJXD+HlVI3A1MTU8ETwSLmdFA1MdGKgHovMUgfxNC0Umi0/J3cjK1v+hve+MI4im144+Z4o=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3221.namprd11.prod.outlook.com (20.177.186.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Fri, 31 Jan 2020 18:04:00 +0000
Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 18:04:00 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Mahesh Jethanandani <mjethanandani@gmail.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: AQHV1XCe/lJrt7B/vkCp8Nt9IDtyWKgAYk+AgASxC2A=
Date: Fri, 31 Jan 2020 18:04:00 +0000
Message-ID: <BYAPR11MB253666D0F66E0334D2C3361CA1070@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB25368EF3AFE9E2CBF396B8D0A1370@BYAPR11MB2536.namprd11.prod.outlook.com> <123C86B4-CE8C-4BBD-84CF-630310CEA50E@gmail.com> <CABCOCHShV-yQznA7OncPeTtiknxmNVMQARHU=Jhh=Dki+vsEAg@mail.gmail.com>
In-Reply-To: <CABCOCHShV-yQznA7OncPeTtiknxmNVMQARHU=Jhh=Dki+vsEAg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d243d11a-58c7-4491-4221-08d7a677f30b
x-ms-traffictypediagnostic: BYAPR11MB3221:
x-microsoft-antispam-prvs: <BYAPR11MB32213FC291FEA1A97128DC3CA1070@BYAPR11MB3221.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 029976C540
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(199004)(189003)(186003)(15650500001)(110136005)(66946007)(55016002)(9686003)(26005)(52536014)(66616009)(66476007)(64756008)(33656002)(5660300002)(76116006)(66556008)(66446008)(71200400001)(86362001)(53546011)(6506007)(81166006)(8676002)(4326008)(316002)(478600001)(81156014)(7696005)(966005)(9326002)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3221; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HBBV6LQZk4txk+A3ktRz67on0GAvX7LS/YzlTJ3korzsgW4xpYCS06xf8QnIiMsHrZGpvIfUJURsmGIRpvaxmHwDTZDMm8YD7vEdiFy5bt+L6xpEtRdI3efTS5KVHaagiK9e5yN47qmrrM/VC5Y0ib8VM0p1cBgj+gwSIpuwy4cO3Avq85rkz6F+9I9Cns8966hTaef7hB+/p3z/xhtmrwtIjgZVGd0QIx9KWZuM0zWbjDzTzRwcGVYgJDu+07X6Xxxad56jbIpqy++QJY8y4anVuk3+S5q2fCjYXWwU/DOnAd/NhlzW1FbbpeoeGW1wbPJGxAAMFp0Oq8Q+CI+fKjUHq0qJCO/1D5a5eSKi2uk/rHqmz7J+ZB35bCbdP0qcur3zZSiAQY9mnjItqoF6ZrSEtmTO0UKhAZ/dMOvC79BGQvApkKtzgm3ywuKcFwawZbmKoriIjpmqX161xJcvRVZnOx/ziranOasDqRGI/Zi5XWrDUNd0aFHUgzxHKcrF5Xa/tWWxZgLMFBQGIxlUew==
x-ms-exchange-antispam-messagedata: 5WR9JUSE73YbibdMQD4nrcOlaBobrTb6xZ/LUfzvVM1bP9BFL8sjoh39b08j6eduNbyJ7NBifAumBNpDCSmosCXKeOpcRfReVJup5aBW4VUZuTUWdB7spDlYJFHv9rNs+qMia2C0orivtv5ar2u1gA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0AC0_01D5D836.E3C7BF90"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d243d11a-58c7-4491-4221-08d7a677f30b
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 18:04:00.3915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: linpw89dHt8TXMxugbASHdR8VwZugNRI8agz9qZYz+NWNHmHMUaPmlrcep32A6GO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3221
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/iNrEIsyM1s7cZbqbF1D5bBQgyz8>
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: Fri, 31 Jan 2020 18:04:07 -0000
Hi Andy, From: Andy Bierman, January 28, 2020 1:13 PM On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> > wrote: 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. I would like to see clear and consistent text wrt to RFC 5277. There is this confusing text: YANG one-way exchanges currently use a non-extensible header and encoding defined in section <https://tools.ietf.org/html/rfc5277#section-4> 4 of RFC-5277. These RFCs MUST be updated to enable this draft. These RFCs SHOULD be updated to provide examples This seems inconsistent with this text: Backwards Compatibility With this specification, there is no change to YANG's 'notification' statement Legacy clients are unaffected, and existing users of [RFC5277 <https://tools.ietf.org/html/rfc5277> ], [RFC7950 <https://tools.ietf.org/html/rfc7950> ], and [RFC8040 <https://tools.ietf.org/html/rfc8040> ] are free to use current behaviors until all involved device support this specification. <eric> I don't see these as inconsistent. The YANG notification statement is defined in RFC-7950 Section 7.16. And legacy clients do not need to change. It is rather odd to see RFC 2119 language used for a directive to a WG to take on some sort of work item. (RFCs MUST be updated) <eric> I agree that RFC 2119 language is not proper here. Perhaps the specific changes should be framed as notes to RFC editor. I think this draft needs some sort of Applicability Statement. Why are servers supposed to use this header and stop using the RFC 5277 header? <eric> Makes sense, I will put together some text on this. The mandatory info like subscription-id is redundant since the payload already has this info. <eric> The subscription-id is only in the notifications defined in RFC-8641. I.e. "push-update" and " push-change-update". This is the biggest gap which needs to be remedied. This new header can make it much more difficult for a client to write code to process a notification, since the header itself would be modeled with YANG and subject to change. The processing may also be slower because the added complexity. It does not seem that every server needs this added complexity. <eric> This is one reason that this specification isn't ready to obsolete RFC-5277 notifications. Eric Cheers. Mahesh and Kent (as co-chairs). Andy 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 <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> draft-ietf-netconf-notification-messages. 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 <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> draft-ietf-netconf-notification-messages *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 <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> draft-ietf-netconf-https-notif 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> _______________________________________________ netconf mailing list netconf@ietf.org <mailto:netconf@ietf.org> https://www.ietf.org/mailman/listinfo/netconf
- [netconf] Configured receiver capability exchange Eric Voit (evoit)
- Re: [netconf] Configured receiver capability exch… Balázs Lengyel
- Re: [netconf] Configured receiver capability exch… Eric Voit (evoit)
- Re: [netconf] Configured receiver capability exch… Eric Voit (evoit)
- Re: [netconf] Configured receiver capability exch… Martin Bjorklund
- Re: [netconf] Configured receiver capability exch… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Andy Bierman
- Re: [netconf] Configured receiver capability exch… Mahesh Jethanandani
- Re: [netconf] Configured receiver capability exch… Eric Voit (evoit)
- Re: [netconf] Configured receiver capability exch… Mahesh Jethanandani
- [netconf] WGLC on draft-ietf-netconf-notification… Mahesh Jethanandani
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Andy Bierman
- [netconf] 答复: WGLC on draft-ietf-netconf-notifica… Tianran Zhou
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… wangzitao
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Qin Wu
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Qin Wu
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Qin Wu
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Eric Voit (evoit)
- Re: [netconf] WGLC on draft-ietf-netconf-notifica… Qin Wu