Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt

Kent Watsen <> Tue, 28 July 2020 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFFD93A0C34 for <>; Tue, 28 Jul 2020 13:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_H2=-0.001, 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 3CniX8JA3LQH for <>; Tue, 28 Jul 2020 13:52:30 -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 5A3C13A0C2E for <>; Tue, 28 Jul 2020 13:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1595969549; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RHhcTEIhSxXbeqITC6uIpe7nV3Mvp6cS+TSAaqoRd8s=; b=R+NatMALw+viL9CXY4zpyL1phDzkRatJhFdiK3i7bAVN803C697Qv+xTdki8JO6R sV6LyFcI4xSNi2eWkDdVE0kIBSyv9LaVd8wGUScyH8RLzgc9Uw7HJWHjGxRRSgO9Q35 uktI5ldyQJlmq4FczoOP6SZis5RA5Hji3hqDZQQA=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A78963C-04AD-4732-A0AF-CA32F7C9094C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 28 Jul 2020 20:52:28 +0000
In-Reply-To: <>
Cc: Mahesh Jethanandani <>, "" <>
To: "Eric Voit (evoit)" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-SES-Outgoing: 2020.07.28-
Archived-At: <>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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: Tue, 28 Jul 2020 20:52:32 -0000

Hi Eric,

> There are many downsides to *not* including the Subscription State Change Notifications, including the DOS attacks listed below.   As several people mentioned during the session, the draft isn't clear on which elements of https-notif require SN, and which do not. 

Disagree, as it’s obvious that *implementing* the modules requires SN, while not implementing them doesn’t.  But, per your comment below, it would be good to float this point towards the beginning.

> Additionally, the intro section of https-notif isn't clear here: 
>      This document defines two YANG 1.1 [RFC7950] data
>     modules, one for augmenting the Subscription to YANG Notifications
>      [RFC8639] to add a transport type, and another for configuring and
>     managing HTTPS based receivers for the notifications.
> The first time I understand all of SN isn't mandatory is Section 8.2.

Ack, see above.

> If there are mandatory SN elements which are sometimes optional, could you explicitly list these in the draft?

This draft does not “update” RFC 8639.  No change to RFC8639 normative text exists in the draft.

> Also could you list what the potential downsides of excluding mandatory might be, and when these potential downsides can be safely discounted?

An enumerated list would be overkill.  A passing comment is sufficient.  The following seems about right:  

  “Using the 'https-notif’ transport outside of RFC 8639 MAY be desirable in cases where a simple notification-delivery mechanism is sufficient for the intended use.  When advanced delivery features are needed (e.g., replay, QoS), RFC 8639 is SHOULD be used.”