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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 3 Sep 2019 15:00:39 +0000

I support the adoption.

Building upon that, there are a few elements which would be good to consider
in future iterations.

(1)  Understanding the capabilities of the configured receiver is important.
One or more publishers of configured subscriptions could be used to
overwhelm a receiver which doesn't even support subscriptions.    This
document should include ways to ensure a configured stream won't be
established with an endpoint unequipped to deal with the inbound
notifications.  As a starting point for these discussions, there are
mechanisms in draft-ietf-netconf-restconf-notif v5 to address this.   E.g.,
the  HTTP transport augmentation on the receiver must send an "HTTP OK" to a
"subscription-started" notification before the publisher starts streaming
any subscribed content.

(2)  Multiple versions of draft-ietf-netconf-restconf-notif include
topics/text which might be useful, even as an appendix.   For example
Section B.2 of v5 includes example config operations and interaction models.

Side comment:  there are advantages in subscriptions over HTTP2 transports,
which I don't believe it will be covered in this draft.  GRPC has the
ability to optimize based its leverage of HTTP2.    To examples from
draft-ietf-netconf-restconf-notif v5 which are good to think about are:

(a) optimizing multiple configured subscription streams to a single receiver
(such as a controller). 

(b) it can be easier overwhelm a receiver which is unable to control or
handle the volume of Event Notifications received  

It would be good to somehow capture the implications of using different
underlying HTTP capabilities as part of these discussions.

Thanks,

Eric

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: [email-masked]
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00

In-room support for this draft was noted but, as always, it is necessary to
confirm WG consensus on the list.  If interested in the WG defining an
HTTPS-based solution for *configured subscriptions* (for which there are
none to date), please voice your support for this draft's adoption.  If
objecting, please state your reasons.  

PS: Authors, please additionally respond to as if there is any IPR to
disclose.

Kent and Mahesh // as chairs

---

From: Xufeng Liu <[email-masked]>
Date: Sun, 8 Sep 2019 19:35:55 -0400

Support the adoption.
Thanks,
- Xufeng

On Mon, Aug 26, 2019 at 6:03 PM Kent Watsen <[email-masked]> wrote:

> In-room support for this draft was noted but, as always, it is necessary
> to confirm WG consensus on the list.  If interested in the WG defining an
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 9 Sep 2019 20:40:28 +0000

I support the adoption as well.
--- Alex

From: netconf <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Tuesday, September 03, 2019 8:01 AM
To: Kent Watsen <[email-masked]>; Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

I support the adoption.

Building upon that, there are a few elements which would be good to consider in future iterations.

(1)  Understanding the capabilities of the configured receiver is important.  One or more publishers of configured subscriptions could be used to overwhelm a receiver which doesn't even support subscriptions.    This document should include ways to ensure a configured stream won't be established with an endpoint unequipped to deal with the inbound notifications.  As a starting point for these discussions, there are mechanisms in draft-ietf-netconf-restconf-notif v5 to address this.   E.g., the  HTTP transport augmentation on the receiver must send an "HTTP OK" to a "subscription-started" notification before the publisher starts streaming any subscribed content.

(2)  Multiple versions of draft-ietf-netconf-restconf-notif include topics/text which might be useful, even as an appendix.   For example Section B.2 of v5 includes example config operations and interaction models.

Side comment:  there are advantages in subscriptions over HTTP2 transports, which I don't believe it will be covered in this draft.  GRPC has the ability to optimize based its leverage of HTTP2.    To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are:
(a) optimizing multiple configured subscription streams to a single receiver (such as a controller).
(b) it can be easier overwhelm a receiver which is unable to control or handle the volume of Event Notifications received
It would be good to somehow capture the implications of using different underlying HTTP capabilities as part of these discussions.

Thanks,
Eric

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

    https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mahesh-netconf-https-notif-00&data=02%7C01%7Calex%40futurewei.com%7C16a2dc1806b74e35ad0308d7307f8c74%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637031196689741853&sdata=zdRh4U2o57W%2F0jcTAaPt4rEia%2FFze4Dboq8MdTFvoyA%3D&reserved=0>
In-room support for this draft was noted but, as always, it is necessary to confirm WG consensus on the list.  If interested in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please voice your support for this draft's adoption.  If objecting, please state your reasons.

PS: Authors, please additionally respond to as if there is any IPR to disclose.

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 9 Sep 2019 22:15:13 +0000

I support the adoption.

Tianran

________________________________
Sent from WeLink

发件人： Alexander Clemm<[email-masked]<mailto:[email-masked]>>
收件人： Eric Voit (evoit)<[email-masked]<mailto:[email-masked]>>;Kent Watsen<[email-masked]<mailto:[email-masked]>>;Mahesh Jethanandani<[email-masked]<mailto:[email-masked]>>
抄送： netconf<[email-masked]<mailto:[email-masked]>>
主题： Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
时间： 2019-09-10 04:40:59

I support the adoption.

(2)  Multiple versions of draft-ietf-netconf-restconf-notif include topics/text which might be useful, even as an appendix..   For example Section B.2 of v5 includes example config operations and interaction models.

Thanks,
Eric

---

From: Kent Watsen <[email-masked]>
Date: Tue, 10 Sep 2019 01:05:38 +0000

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Sep 2019 09:08:03 +0200 (CEST)

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

> 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

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

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 11 Sep 2019 09:33:43 +0000

Hi Kent,

Considering the multiple stream originator case, I would suggest this https-notif to add a channel level configuration.
i.e.

+--receivers
   +--receiver
      +--channels
         +--channel
            +--here put the http client server configurations

This is compatible with the single originator case with only one channel configuration.

If you do not like this, I think existing https-notif model also works.
i.e. each receiver configuration stands for one channel.
But this is not clear IMO.

Best,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, August 27, 2019 6:02 AM
To: [email-masked]
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 15:56:28 +0000

Hi Martin,

> RFC 8341).  I.e., the device needs a local username for the configured

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?

> configs require a 'path' (e.g. restconf uses it's own mechanism wih

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?

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

> "bundled-message" defined in draft-ietf-netconf-notification-messages

These sound like good conversations to have.

> and we should work on it, the sooner the better (but after the

We can slow-walk this draft.   As you say, we need to prioritize other drafts...

Kent // as co-author

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Sep 2019 16:05:50 +0000

Hi Tianran,

> This is compatible with the single originator case with only one channel configuration.

We can look at this.  Maybe use a choice statement between the two options...

Kent // co-author

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Sep 2019 21:25:26 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 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?

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

> We can slow-walk this draft.  As you say, we need to prioritize other

Ok.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Sep 2019 21:27:18 +0200 (CEST)

> We can look at this.  Maybe use a choice statement between the two options...

I don't think this is a good idea.  But then I don't really understand
the 'channel' concept.  I don't understand why the client needs to be
aware of these channels, but this should probably be discussed in a
separate thread.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Sep 2019 14:00:29 +0000

> user name to find the access control rules.  What is the user name

Now I understand.   There isn't a set answer for this yet.   Two approaches:

1) We could claim that it is the "system" that is the publisher (effectively no NACM)
2) We could have an explicit field for the "send as" user.  (default to "system"?)

> whe the http-client grouping is used.

Sure, and by "latter", do you mean a) augment in a "path" leaf into the
"http-params" section, or b) define a new section for just the path?

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

Okay.

Kent

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 18 Sep 2019 07:33:46 +0000

Maybe we could use as userId which configured the receiver as the userId of
the publisher. After all he is the one that decides to send the
notifications, if he has the correct rights, he can share the information
with whoever he wants.

Regards Balazs

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 2019. szeptember 17., kedd 16:00
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

1) We could claim that it is the "system" that is the publisher (effectively
no NACM)

2) We could have an explicit field for the "send as" user.  (default to
"system"?)