Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

Martin Bjorklund <> Tue, 27 August 2019 07:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6F6312002E for <>; Tue, 27 Aug 2019 00:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T_Ll9oHMuglg for <>; Tue, 27 Aug 2019 00:15:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 677441200FB for <>; Tue, 27 Aug 2019 00:15:57 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id A581B1AE0451; Tue, 27 Aug 2019 09:15:54 +0200 (CEST)
Date: Tue, 27 Aug 2019 09:15:31 +0200
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
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, 27 Aug 2019 07:16:00 -0000


I think that defining a "simple" protocol for notification delivery
only is an interesting problem to work on.  However, this document
doesn't define this protocol.  It just says "https".  But how is the
client supposed to deliver the notifs?  PUT?  POST?  To which uri?
Further, it doesn't discuss authorization at all (which "user" will be
used for NACM checks of the notifications?)

The document relies on the client-server suite of drafts, including
the individual draft draft-kwatsen-netconf-http-client-server (these
need to be added as references BTW).  I would really like the WG to
finish these documents before starting to work on something new.
(BUT, I also think that having a module that is the user of these
generic client-server drafts is very useful to validate the design of
them.  (*))

I have a bunch of more detailed comments as well, but these can wait.

(*) An observation: This module introduces a level of indirection for
receivers; something we should have done in the
subscribed-notifications model directly.  Perhaps we should revisit
that model and add the indirection there instead.


Kent Watsen <> wrote:
> This email begins a 2-week adoption poll for:
>     <>
> In-room support for this draft was noted but, as always, it is
> necessary to confirm WG consensus on the list.  If interested in the
> WG defining an HTTPS-based solution for *configured subscriptions*
> (for which there are none to date), please voice your support for this
> draft's adoption.  If objecting, please state your reasons.
> PS: Authors, please additionally respond to as if there is any IPR to
> disclose.
> Kent and Mahesh // as chairs