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

Kent Watsen <kent@watsen.net> Fri, 19 February 2021 21:15 UTC

Return-Path: <01000177bc25655a-b590a758-26cf-4ef4-9bcc-aae75b40c7e2-000000@amazonses.watsen.net>
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 F15573A0E1A; Fri, 19 Feb 2021 13:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 SoczjsV41ULP; Fri, 19 Feb 2021 13:15:22 -0800 (PST)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC673A0BC5; Fri, 19 Feb 2021 13:15:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613769303; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=0uylRTyRza7mDJPDzpiecU7hBHQ0DNEwNWu7xWXJmS4=; b=YhZgCz93qm8XWT8E6f/avlPmIzPjNESODdQT9gr1FNxD6pWV3oOuvEOjzij8SHYt JNZ3Ns9L5IvTpLwd0ZYf7UCJ55a30KHH7NBo53zdXQS/SyJ6dXxrFOTdUViSA79rrlH EN5HUMGdrDtmHhyOBVTFB0ClXUZ3cZpfCCpbrZxs=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000177bc25655a-b590a758-26cf-4ef4-9bcc-aae75b40c7e2-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6C7D75B-91B3-4E15-9B6E-2E927DCC6936"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 19 Feb 2021 21:15:03 +0000
In-Reply-To: <BL0PR11MB312282FE91F08D0F6C2DB47DA1849@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <MN2PR11MB43669EEF05655F07E39FE4BEB5A80@MN2PR11MB4366.namprd11.prod.outlook.com> <BL0PR11MB3122129B92F8B02D99081112A1BD9@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122FAD872B1FF80FDC6E0ABA18C9@BL0PR11MB3122.namprd11.prod.outlook.com> <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-000000@email.amazonses.com> <BL0PR11MB312282FE91F08D0F6C2DB47DA1849@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2021.02.19-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-rPS6j2yoDuZdYjedkTe8_xWKNI>
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: Fri, 19 Feb 2021 21:15:29 -0000

Hi Eric,


> The intent of my comment was mainly to assist the understandability between drafts.   Subscription state change notifications are a part of RFC8639.  

Assisting understandability is good!  :)


> This draft's Section 1.1 Applicability statement *totally appropriately* notes that only a subset of RFC8639 constructs are applicable.

The -06 "applicability statement” was removed in -07.

-07 also has an “applicability” section (Section 3.1), but it regards an entirely different matter.  That said, this “applicability” section has also been removed (or will be, when -08 is posted), per comments from Martin.


> As a result subscription state change notifications are not required when leveraging this specification.
> If there is a minimum set of subscription state change notifications required or desired, it would be good to list them.  I suspect there are not (as per the Applicability Statement).  Based on this, I believe it be worth listing some implications of not having the subscription state change notifications in the Security Considerations section.  E.g., not sending a <subscription-modified> might mean a receiver can't be sure that a compliant publisher is sending the full set of events expected.   Such a statement would make it easily apparent to an implementer of the differences in functionality delivered as they choose which RFCs to support.


RFC 8639 needs to state what notifications are required by valid implementations.  The notif drafts MUST NOT limit any notifications from being sent.  If there are Security Considerations related to certain notifications not being sent, they should be stated in RFC 8639.

Stated differently, the “notif” drafts define effectively *dumb* transport-level protocols.  If higher-level logic is layered on top of raw notifications, considerations for if certain notifications are *not* sent needs to be defined in the higher-level documents.

Does this make sense, or do you mean something else?  Please provide specific text that you are hoping to see included.


K.