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

Martin Bjorklund <mbj@tail-f.com> Mon, 16 September 2019 19:25 UTC

Return-Path: <mbj@tail-f.com>
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 5E7001200CC for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 12:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQXD9B-N-edW for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 12:25:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE3120129 for <netconf@ietf.org>; Mon, 16 Sep 2019 12:25:28 -0700 (PDT)
Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id AF7D21AE0187; Mon, 16 Sep 2019 21:25:26 +0200 (CEST)
Date: Mon, 16 Sep 2019 21:25:26 +0200 (CEST)
Message-Id: <20190916.212526.427039138127777720.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com>
References: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> <20190910.090803.448863675820254782.mbj@tail-f.com> <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com>
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: <https://mailarchive.ietf.org/arch/msg/netconf/n5Mn4Qvc7Bk1Mae0et9P6C7zcl4>
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
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: Mon, 16 Sep 2019 19:25:44 -0000

Kent Watsen <kent+ietf@watsen.net> 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.,
> NACM?

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...

Ok.


/martin