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

[Kent Watsen <[e-mail]>]

Hi Martin,

Mahesh reminded me that this message still needs a response...


> 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.  That said, ietf-http-client fails to define a "path" field, so that appears to be something that should be added to it (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.

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