[netconf] Shepherd Review on draft-ietf-netconf-https-notif-10

["maqiufang (A)" <[e-mail]>]

Hi, all

I'm the document shepherd for this document as it moves beyond the WG for requested publication as an RFC.

As part of shepherd write-up. I read the latest version of the draft and have got some comments.
[I reviewed the draft at -09 during WG last call, so my comments here for -10 are basically editorial with only a few small questions.]

If the authors could produce a new revision, I will start working on the shepherd write-up. Thanks;-)

Best Regards,
Qiufang

Comments:

  *   Idnits(https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-https-notif-10.txt)  reports some error and warnings; some are innocuous, while others need to be handled:
** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72.

     *   [Sec 8.2] longer than 72.  Excess characters: 's': 'namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-notif-receivers'
     *   [Sec 8.3] longer than 72.  Excess characters: 'tif': 'Name: urn:ietf:capability:https-notif-receiver:encoding:sub-notif'

*         Abstract

  *   The second paragraph
What's the reason for the authors to highlight it in the abstract? Isn't it already the case in YANG notification?
The receiver is never assumed as a NETCONF/RTESTCONF server.

*         Section 1.3 Abbreviations

*         The expansion of HTTP here should be aligned with RFC2616, which is "Hypertext Transfer Protocol" (rather than "Hyper Text Transport Protocol").

*         Section 1.4 Terminology

  *   Should some other terms defined in RFC 8639 such as publisher, receiver, configured subscription, event also be mentioned here?

*         Section 1.4.1 Subscribed Notifications

  *   Why do we need a single section for this term which is defined elsewhere?

*         Section 2 Overview of Publisher to Receiver Interaction

  *   Would it be beneficial to state clearly in this section that the receiver which is a NETCONF or RESTCONF client, though, works as an HTTPS server to present HTTP target resources?

*         Section 3.4 Example
*         What's the consideration to express the receiver capability "urn:ietf:capability:https-notif-receiver:encoding:sub-notif" with a "encoding"? This capability isn't really about encoding, right? This seems kind of weird to me since you only define the URN to begin with "urn:ietf:capability:https-notif-receiver" in IANA consideration.
*         The second sentence,
s/the "Accept" states that the *receiver* wants to/the "Accept" states that the *publisher* wants to
                     (The HTTP request is sent by the publisher to learn the capabilities of the receiver.)
*         The JSON response:
       {
          receiver-capabilities {
            "receiver-capability": [
              "urn:ietf:capability:https-notif-receiver:encoding:json",
              "urn:ietf:capability:https-notif-receiver:encoding:xml",
              "urn:ietf:capability:https-notif-receiver:encoding:sub-notif"
            ]
          }
       }
          This is an invalid JSON expression, which I think should be:
         {
            "receiver-capabilities": {
              "receiver-capability": [
                "urn:ietf:capability:https-notif-receiver:encoding:json",
                "urn:ietf:capability:https-notif-receiver:encoding:xml",
                "urn:ietf:capability:https-notif-receiver:encoding:sub-notif"
              ]
            }
          }

*         Section 4.1 Request

  *   The second bullet of the third paragraph: Instead of saying that, for JSON-encoding purposes, the module name for the "notification" element is "ietf-restconf, the module name will instead be "ietf-https-notif".
Unclosed quotation mark for "ietf-restconf".

*         Section 5.2 YANG Module
*         The copyright year in the IETF Trust and authors Copyright Line does not match the current year
*         RFC XXXX, YANG Data Module for HTTPS Notifications.
This is inconsistent with your title (which is "An HTTPS-based Transport for YANG Notifications"). The same case in section 6.2 and Appendix A.2.

*         Section 6.1 Data Model Overview
*         I noticed that the authors have removed the "keepalives-supported" feature (the "keepalives" node depends on) in the abridged tree diagram (https://www.ietf.org/rfcdiff?url1=draft-ietf-netconf-https-notif-09&url2=draft-ietf-netconf-https-notif-10&difftype=--html), what's the consideration for that ( I think this feature is needed from my own generated tree) ?

*         Section 6.2 YANG module
*         The copyright year in the IETF Trust and authors Copyright Line does not match the current year

*         Section 7 Security Considerations

  *   Since two YANG modules are defined in this document, when you say "the YANG module"/"this YANG module" in this section, it's not very clear which YANG module you are referring to.

*         Section 8.3 The "Capabilities for HTTPS Notification Receivers" Registry
*         The "description" field: An arbitrary description of the algorithm.
What's the algorithm? Copy/paste error? s/algorithm/capability?
*         "The update policy is either "RFC Required".  Updates do not otherwise require an expert review by a Designated Expert."
How about: The update policy is "RFC Required"(remove 'either'). Updates do not otherwise require an expert review by a designated expert (lowercase 'd' and 'e').
BTW. Is the authors' intention that the new registry also doesn't require a designated expert review, right?
*         The initial assignment for your new registry: s/Name/URN?
The field name is URN, as defined in your registry.

*         Appendix A. Using Subscribed Notifications (RFC 8639)
*         The second paragraph, s/the Publisher/the publisher;
*         "and configures the "path" leaf value to "/some/path/"...", the subject is missing here, the receiver configures the "path" value to "/some/path/", or s/and/which, right?

*         Appendix A.2 Not Using Subscribed Notifications
*         The first paragraph, s/would to need/would need to
*         The second paragraph, s/Note that the module is "uses"/Note that the module "uses"/ (remove "is")?