Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

From: [email-masked]
Date: Mon, 22 Feb 2021 15:33:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : An HTTPS-based Transport for YANG Notifications
        Authors         : Mahesh Jethanandani
                          Kent Watsen
	Filename        : draft-ietf-netconf-https-notif-08.txt
	Pages           : 27
	Date            : 2021-02-22

Abstract:
   This document defines a protocol for sending notifications over
   HTTPS.  YANG modules for configuring publishers are also defined.
   Examples are provided illustrating how to configure various
   publishers.

   This document requires that the publisher is a "server" (e.g., a
   NETCONF or RESTCONF server), but does not assume that the receiver is
   a server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-08
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 22 Feb 2021 15:38:59 -0800

Hi WG,

The authors believe that this version of the draft addresses comments received during LC.

Thanks.

> On Feb 22, 2021, at 3:33 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Feb 2021 00:23:04 +0000

Hi Mahesh,

I believe that my comments from Friday are still open.

Thanks,

Eric

From: netconf <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: Monday, February 22, 2021 6:39 PM
To: [email-masked]
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Hi WG,

The authors believe that this version of the draft addresses comments
received during LC.

Thanks.

On Feb 22, 2021, at 3:33 PM, [email-masked]
<mailto:[email-masked]>  wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Configuration WG of the IETF.

Abstract:

_______________________________________________
netconf mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani

[email-masked] <mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Feb 2021 01:55:00 +0000

Hi Eric,

> I believe that my comments from Friday are still open.

We did something different.  We added an “rfc8639-enabled” capability so that receivers can indicate when they support the RFC 8639 state machine, thus highlighting the goodness that is had when using it that, obviously, is not present when not used.

K.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Feb 2021 03:14:11 +0000

I can live with that.  Thanks.

Eric

From: Kent Watsen <[email-masked]> 
Sent: Monday, February 22, 2021 8:55 PM
To: Eric Voit (evoit) <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; [email-masked]
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Hi Eric,

K.

---

From: Martin Björklund <[email-masked]>
Date: Tue, 23 Feb 2021 09:59:03 +0100 (CET)

Hi,

I have read this version, and most of my comments for -07 are
addressed.  However, I still have some comments:

o  2.  Overview of Publisher to Receiver Interaction

   The protocol consists of two HTTP-based target resources presented by
   the receiver.  These two resources are sub-paths of a common resource
   that the publisher must know (e.g. specified in its configuration
   data model).

 When reading this text (and 3.2 and 4.1) it is still not clear how
 this path is made known to the publisher.

 I suggest these changes:

 NEW:

   The protocol consists of two HTTP-based target resources presented by
   the receiver.  These two resources are sub-paths of a common resource
   that the publisher must know.  If the data model in section 6.2 is
   used, this common resource is defined in the "path" leaf in
   "http-client-parameters".

   o "capabilities":  A target resource enabling the publisher
      to discover what optional capabilities a receiver supports.
      Publishers SHOULD query this target before sending any
      notifications or if ever an error occurs.

   o "relay-notifications":  A target resource enabling the publisher
      to send one or more notification to a receiver.  This document
      defines support for sending only one notification per message; a
      future effort MAY extend the protocol to send multiple
      notifications per message.

 (note that sections 3.2 and 4.1 already refer to these resources by
 the names "capabilities" and "relay-notifications").

 Additional note: are these really "sub-paths of a common resource"?
 The "path" is just a prefix, it is not a resource.  Perhaps rephrase
 to:

   The protocol consists of two HTTP-based target resources presented
   by the receiver.  If the data model in section 6.2 is used, these
   resources are defined by the "path" leaf in "http-client-parameters".

 In 3.2 and 4.1 I would also do:

  OLD:

   To learn the capabilities of a receiver, a publisher can issue an
   HTTPS GET request to the "capabilities" resource under a known path
   on the receiver

  NEW:

   To learn the capabilities of a receiver, a publisher can issue an
   HTTPS GET request to the "capabilities" resource (see Section 2)
   on the receiver

  and similar in 4.1.

o  3.3.

     leaf-list receiver-capability {
       type "inet:uri";
       description
         "A capability supported by the receiver.  A full list of
          capabilities is defined in the 'Capabilities for HTTPS
          Notification Receivers' registry (see RFC XXXX).";
     }
   }

   As it is possible that the receiver may return custom capability
   URIs, the publisher MUST ignore any capabilities that it does not
   recognize.

  This seems contradictory - how can the server return custom
  capabilities if there is a full list of capabilities available in an
  IANA registry?

o  3 and 8.3

  There's a new capability defined:

   Name:        urn:ietf:capability:https-notif-receiver:encoding:rfc8639-enabled
   Reference:   RFC XXXX
   Description: Identifies support for RFC 8639 state machine.

 This is the only description of this capability in this document.
 How is it supposed to work?  What should a publisher do with this
 information?  Which state machine is referred to?

 (And, the name of the capability should be more descriptive, and not
 contain the RFC number.  What if there's a bis version published with
 some errors fixed?)

/martin