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

[Mahesh Jethanandani <[e-mail]>]

Hi Qiufang,

Thanks for reviewing the document carefully. Since the last post was a manual post, there was some confusion about which version of the file need to be posted. The recent post of -12 version of the draft should address the remaining comments you had.

Thanks.

> On Jul 21, 2022, at 7:03 PM, maqiufang (A) <[e-mail]> wrote:
> 
> 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]>

Mahesh Jethanandani
[e-mail]