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

[Martin Björklund <[e-mail]>]

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