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

Martin Bjorklund <> Mon, 16 September 2019 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E7001200CC for <>; Mon, 16 Sep 2019 12:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QQXD9B-N-edW for <>; Mon, 16 Sep 2019 12:25:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4AE3120129 for <>; Mon, 16 Sep 2019 12:25:28 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id AF7D21AE0187; Mon, 16 Sep 2019 21:25:26 +0200 (CEST)
Date: Mon, 16 Sep 2019 21:25:26 +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: Mon, 16 Sep 2019 19:25:44 -0000

Kent Watsen <> wrote:
> Hi Martin,
> >> Firstly, while ietf-http-client defines HTTP "basic" authentication
> >> parameters, the example in the I-D didn't show them, even though the
> >> YANG module uses the ietf-http-client module.
> > 
> > I am not sure what this reply means exactly.  My comment about
> > authorization above was for outgoing notifications (section 3.4.6 in
> > RFC 8341).  I.e., the device needs a local username for the configured
> > subscription.
> Do you mean to add to the draft a new section called something like
> "Authorization" that mimics what's in the SN draft regarding, e.g.,

No I mean that when the device generates a notification, NACM needs a
user name to find the access control rules.  What is the user name
with this new protocol?

> >> That said,
> >> ietf-http-client fails to define a "path" field, so that appears to be
> >> something that should be added to it
> > 
> > I don't think 'path' belongs in http-client; not all http client
> > configs require a 'path' (e.g. restconf uses it's own mechanism wih
> > ".well-known").
> True, path isn't needed for RESTCONF clients.
> This draft doesn't assume anything about the server (if this is a
> valid assumption is discussed below) and, presumably, this assumption
> may be a common.  So maybe ietf-http-client should also define a
> feature statement for the new "path" leaf, thus servers have an easy
> way to turn it on.  It would be mandatory false, with the description
> statement indicating that it is only needed for some protocols.
> Alternatively, this draft could augment in a "path" leaf into the
> "http-params" section, or define a new section for just the path.
> Thoughts?

I prefer the latter.  I think the 'path' leaf will not be very common
whe the http-client grouping is used.

> Regarding the validity of the assumption that this draft must also (in
> addition to http-client-server) assume nothing about the remote
> server.  It seems like the completion to that assumption is, why is it
> not a RESTCONF server.  The reason is that we don't want to burden the
> remote server with needing to implement a full RESTCONF server.  But,
> if the server were to implement only one module that implements only
> one RPC (e.g., receive-notifications) and otherwise has no protocol
> accessible nodes, then a fully-compliant server-implementation could
> be very small (e.g., returning either an HTTP error code or an empty
> response for datastore oriented HTTP/RESTCONF requests).  Just an
> idea, it may not be too much of a jump for this draft, and the
> benefits a questionable (ability to assume discovery and have
> well-defined URL construction (i.e.,
> {+restconf}/operations/receive-notifications).

I'm fine with this being a new "protocol", not RESTCONF.

> >> As for the HTTP operation and request body, POST-ing a stream of
> >> notifications seems right.
> > 
> > Yes POST seems right.  I'm not so sure about the streaming though.
> > Perhaps pipelining is the right mechanism.  For "bulk" sending, the
> > "bundled-message" defined in draft-ietf-netconf-notification-messages
> > seems right.
> These sound like good conversations to have.
> > My point is that the document needs quite a lot of work, and I think
> > that the WG should spend its energy on getting the "client-server"
> > documents ready.   NOTE again that I do think that this is good work,
> > and we should work on it, the sooner the better (but after the
> > existing documents).
> We can slow-walk this draft.  As you say, we need to prioritize other
> drafts...