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

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 15 Mar 2021 14:23:08 -0700

Hi Martin,

> On Feb 23, 2021, at 12:59 AM, Martin Björklund <[email-masked]> wrote:
> 
> 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.

Thanks for the suggested changes. We have incorporated them.

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

Ack.

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

Good point. We removed "sub-path”, and any suggestions that it is a resource, from the document.

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

Applied the changes to the draft.

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

Here is the updated text for the description statement:

    description
      "A capability supported by the receiver.  A partial list of
       capabilities is defined in the 'Capabilities for HTTPS
       Notification Receivers' registry (see RFC XXXX). Additional
       custom capabilities MAY be defined.”;

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

How about this for an updated name and description?

Record:
   Name:        urn:ietf:capability:https-notif-receiver:encoding:sub-notif
   Reference:   RFC XXXX
   Description: Identifies support for state machine described in RFC 8639,
                enabling the publisher to send, e.g., the
                "subscription-started" notification.

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

Mahesh & Kent (as co-authors)

---

From: Martin Björklund <[email-masked]>
Date: Tue, 16 Mar 2021 08:43:59 +0100 (CET)

Hi,

Thanks for addressing my comments.  See inline:

> > addressed.  However, I still have some comments:

[...]

>        custom capabilities MAY be defined.”;

Ok, but is it correct to say that the IANA registry is a "partial
list"?  I would say just "list" or perhaps "standard list".

>                 "subscription-started" notification.

I'm sorry but I still don't understand.  What is the purpose of this
capability?  Does it mean that if the reciever advertises this
capability then the publisher MUST send e.g. "subscription-started"?
This seems a bit odd; if this protocol is used as a configured
subscription, then the publisher will send "subscription-started"
regardless of any receiver capabilities, right?

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 17 Mar 2021 16:44:54 -0700

[Trimming it down to open issues]

Hi Martin,

> list"?  I would say just "list" or perhaps "standard list".

How about this?

description
     "A capability supported by the receiver.  A list of standard
      capabilities is defined in the 'Capabilities for HTTPS
      Notification Receivers' registry (see RFC XXXX). Additional
      custom capabilities MAY be defined.”;

> regardless of any receiver capabilities, right?

That is correct. This capability advertised by the receiver says that it support RFC 8639 based state machine. Only if the receiver advertises this capability  a “subscription-started” has to be sent before sending a notification. See Section 2, Overview of Publisher to Receiver Interaction. You will notice that in the figure, there is no requirement (by default) that a “subscription-started” has to be sent. 

HTH.