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

Martin Bjorklund <mbj@tail-f.com> Tue, 10 September 2019 07:08 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 D170E120089 for <netconf@ietfa.amsl.com>; Tue, 10 Sep 2019 00:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwE4g6FOZ-OV for <netconf@ietfa.amsl.com>; Tue, 10 Sep 2019 00:08:30 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1673712004F for <netconf@ietf.org>; Tue, 10 Sep 2019 00:08:30 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id E0D121AE0187; Tue, 10 Sep 2019 09:08:27 +0200 (CEST)
Date: Tue, 10 Sep 2019 09:08:03 +0200 (CEST)
Message-Id: <20190910.090803.448863675820254782.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com>
References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <20190827.091531.2170309439792906317.mbj@tail-f.com> <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-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/CehsofRUMKl-vInmX-YDJN8OgC0>
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: Tue, 10 Sep 2019 07:08:33 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> Hi Martin,
> 
> Mahesh reminded me that this message still needs a response...

Hmm, I have apparently missed this.  I was wondering why noone replied
to my comments ;-)


> > 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?)
> 
> Many good points here.
> 
> 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.


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

> (to your point about it being
> good to have a user of the client-server drafts to validate the
> design).  Thusly that part of the example in the I-D should be:
> 
>   <receivers
>       xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">
>       <receiver>
>         <name>foo</name>
>         <tcp-params>
>           <remote-address>my-receiver.my-domain.com</remote-address>
>           <remote-port>443</remote-port>
>         </tcp-params>
>         <tls-params>
>           <server-authentication>
>             <ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
>             <server-certs>explicitly-trusted-server-certs</server-certs>
>           </server-authentication>
>         </tls-params>
>         <http-params>
>           <client-identity>
>             <basic>
>               <user-id>my-name</user-id>
>               <password>my-passsord</password>
>             </basic>
>          </client-identity>
>          <path>/some/path</path>
>         <http-params>
>       </receiver>
>   </receivers>
> 
> 
> For high-availability, note that ietf-tcp-client defines the
> "remote-address" field as follows:
> 
>     leaf remote-address {
>       type inet:host;
>       mandatory true;
>       description
>         "The IP address or hostname of the remote peer to
>          establish a connection with.  If a domain name is
>          configured, then the DNS resolution should happen on
>          each connection attempt.  If the DNS resolution
>          results in multiple IP addresses, the IP addresses
>          are tried according to local preference order until
>          a connection has been established or until all IP
>          addresses have failed.";
>     }
> 
> 
> 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.

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


/martin




> Assuming `notification` statements ("foo", "bar", and "baz") are
> defined in a module called "my-foobar-module" (with xmlns
> "https://example.com/my-foobar-module"), an example HTTP/1.1
> notification-delivery message might be (blank lines added for
> readability):
> 
> 
>     POST /some/path HTTP/1.1
>     Host: my-receiver.my-domain.com
>     Content-Type: application/yang-data+xml
> 
>     <notification
>       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>       <eventTime>2019-03-22T12:35:00Z</eventTime>
>       <foo xmlns="https://example.com/my-foobar-module">
>         ...
>       </foo>
>     </notification>
> 
>     <notification
>       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>       <eventTime>2019-03-22T12:35:00Z</eventTime>
>       <bar xmlns="https://example.com/my-foobar-module">
>         ...
>       </bar>
>     </notification>
> 
>     <notification
>       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>       <eventTime>2019-03-22T12:35:00Z</eventTime>
>       <baz xmlns="https://example.com/my-foobar-module">
>         ...
>       </baz>
>     </notification>
> 
> 
> With response:
> 
>       HTTP/1.1 204 No Content
>       Date: Thu, 26 Jan 2017 20:56:30 GMT
>       Server: my-receiver.my-domain.com
> 
> 
> Thoughts?
> 
> Kent
> 
> 
>