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

Mahesh Jethanandani <> Tue, 28 July 2020 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 941B23A09DB for <>; Tue, 28 Jul 2020 15:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VW60zrP3VGvi for <>; Tue, 28 Jul 2020 15:33:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0B1A3A09CF for <>; Tue, 28 Jul 2020 15:33:17 -0700 (PDT)
Received: by with SMTP id u185so11843041pfu.1 for <>; Tue, 28 Jul 2020 15:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GtnUF6NXvbg1ij+CVoes+3BR2p8Bxy8H9obVbV5l+04=; b=Lg2md1K6H/5QG/lbcCDcEuAVglswOM4bnP4abRKG4yqPZVQa1G2sSGGN63rK+gRaR0 4jN8229xgKyqYhZcXpon3JlpSyhvCyBZZkiQWPzCR5b1tjMIBEi+SGNVaznRSOGnlbVB tgD+tj8t4+uvnxgFxeoknor0r19hE2wqBq62IrBSX7TXEW6bHrGZd+GleAdURCTzUWkZ 5fFfBMD6d2P0j4RxjyXBRY9dLHpqVxj3Zcg9onKMTFusMNAoT03vzVLdCbVcjSiqn/6x fifvXPJRB2WhVaytdkBsetMgpY1xOZYiUzDtrh7OIZdIHBDTEU2q54gS0GLCys6l6zpK Iyvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GtnUF6NXvbg1ij+CVoes+3BR2p8Bxy8H9obVbV5l+04=; b=ZMRBC11219VEoItOQb+nqOndEOC+k/ESSNzKky36Uy5TfBJdarbuOyqwjmorz6N+ls Y/ZffBYuB5tBkQZp/kuy4B0ibjsTBNVgfC75EQftSxMKQDUg8DQ3pSyoa7pWZOfezMQw IJQQUyAGHKpnNC2QID1LakSrA5+AK1pUjJE8NQ1ihbU8NcbMQS72+8L9TWFPLrJA2Rhk CB3P8Sxz7UlpdRPrpoRQYsuVjGpAhjeSJEbqkS3EHCez75EQjzsqmMAz2Lg0c4z8Dmca 5/XNgYosQ7pmlRcHQlFYw4foXZh8mwrhgOmcxdl91yBBLy+bxqxhyDJxPg47kdyLunjC naZA==
X-Gm-Message-State: AOAM532E4pDHQBwPkeuSgBVNWSG5YpBEL4dofNNr+XOlztsAV54h5tBg aPjDxVTmT12+2CgDkzbEKnk=
X-Google-Smtp-Source: ABdhPJxCeScSANel7mMr9wAE4QZuADXlE23jXyfMnv27fGyiiXr8SOXIAM8cb+cuMXOrnGZslAU+zw==
X-Received: by 2002:a63:441c:: with SMTP id r28mr26611290pga.372.1595975597070; Tue, 28 Jul 2020 15:33:17 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9c44:e9ff:18d8:c86c? ([2601:647:5600:5020:9c44:e9ff:18d8:c86c]) by with ESMTPSA id w71sm92360pfd.6.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 15:33:16 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A65FE228-B5C0-4A04-B8C8-4427CB5E23E5"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
Date: Tue, 28 Jul 2020 15:33:14 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, "Eric Voit (evoit)" <>, "" <>
To: Alexander Clemm <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.6)
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 22:33:20 -0000

Hi Alex,

If the implementation calls for a method by which a receiver wants to subscribe to particular notifications, by all means you need to implement SN. However, if all you need to implement is a channel by which notifications can be send from the publisher to the receiver, however that channel is set up, why would you need to implement SN?

Subscription State Change Notification is central to the concept of being able to subscribe to events. It is not central to how notifications are sent.


> On Jul 28, 2020, at 3:19 PM, Alexander Clemm <> wrote:
> Hi Kent,
> I am getting a bit confused here.  Are you saying that you would only need to implement the augmentations, not the subscriptions model being augmented?  Subscription State Change Notifications are an integral part of the whole subscription concept.  
> Anyway, I agree this point needs clarification.
> --- Alex
> From: netconf < <>> On Behalf Of Kent Watsen
> Sent: Tuesday, July 28, 2020 1:52 PM
> To: Eric Voit (evoit) < <>>
> Cc: <>
> Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt
> 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.”
> K.
> _______________________________________________
> netconf mailing list
> <>
> <>