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

[Mahesh Jethanandani <[e-mail]>]

Hi Martin,

> On Feb 23, 2021, at 12:59 AM, Martin Björklund <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh & Kent (as co-authors)