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

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> 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
> 
> 
>