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

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

Hi, Mahesh
I see that v-11 has already been posted. I’ve reviewed the diff, and thanks for addressing my comments!
But I found that the latest version still has a few nits:
·         Sec. 1. Introduction
·         s/ notfications/notifications/
·         Sec. 1.3 Abbreviations
·         s/Hyper Text Transport Protocol Secure/Hypertext Transfer Protocol Secure/
·         Sec. 5.2  YANG Module
·         s/augemnts/augments/
·         PYANG reminds me that The IETF Trust Copyright statement is still not correct:
      "Copyright (c) 2022 IETF Trust and the persons identified as
        the document authors.", which should be:
       "Copyright (c) 2022 IETF Trust and the persons identified as
        authors of the code."
   The same case for Sec. 6.2 YANG module
·         Sec. 6.2 YANG Module
·         s/MUST NOT not/MUST NOT/
·         Sec.7 Security Considerations
·         The first paragraph: s/defines/define/
·         The second paragraph: s/makes/make/; s/are/is/
·         Sec. 8.3 The "Capabilities for HTTPS Notification Receivers" Registry
·         s/ urn:ietf:capability:https-notif-receiver:encoding:sub-notif/urn:ietf:capability:https-notif-receiver:sub-notif/
              (remove "encoding")
·         Appendix A.2
·         s/nofif/notif/

Best Regards,
Qiufang
From: Mahesh Jethanandani [mailto:[e-mail]]
Sent: Tuesday, July 12, 2022 4:01 AM
To: maqiufang (A) <[e-mail]>
Cc: [e-mail]; [e-mail]; Robert Wilton <[e-mail]>
Subject: Re: [netconf] Shepherd Review on draft-ietf-netconf-https-notif-10

[Pruning the list down to open issues]


On Jun 28, 2022, at 8:30 PM, maqiufang (A) <[e-mail]<mailto:[e-mail]>> wrote:


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

[mj] We do not require the receiver to be a RESTCONF client, as you observed above. The only requirement is that the receiver be an HTTPS server. Being a HTTP based protocol, it cannot be a NETCONF server or client.
So my only question is, would it be good to state clearly that the receiver is required to be an HTTPS server in Sec.2? Just a suggestion, feel free to accept or reject it.

[mj] In the Abstract we state that this document is defining the protocol for HTTPS, and explicitly not NC or RC. We will elaborate on the Abstract in the Introduction.

Thanks.


Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>