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

[Mahesh Jethanandani <[e-mail]>]

Hi Quifang,

First of all, and just to be clear, there was no change in the model. The change you are seeing is because of an update in the tool chain, especially pyang, which was updated to revision 2.5.3 and is being used to generate the tree diagram.

As you have already observed, the model is trying to use the “http-client-stack-grouping” from draft-ietf-netconf-http-client-server draft, but wants to disable support for http transport. A https based transport is the minimum requirement for the draft to muster passage through any security scrutiny. That is why you see the logical impossibility of including http in the model. It would therefore make sense that the tree diagram for the model also reflect that logical impossibility. Otherwise, it would not be a true reflection of the model.

Thanks.

> On Aug 23, 2022, at 5:41 AM, maqiufang (A) <[e-mail]> wrote:
> 
> Hi, Mahesh
> Thanks for posting another version to address my comments ;-)
>  
> Besides the fixed nits, the diff(https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-12 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-12>) also shows that you have removed the whole “tcp” case inside the “transport” choice from the tree diagram(change at page 12). Is this intentional? I do understand that you are creating a logic impossibility here to disable a tcp transport configuration, but I am unsure if this should be removed from the tree diagram totally. if we use pyang to generate the tree, pyang will output it honestly with the list of features that can never be met at the same time.
>  
> Best Regards,
> Qiufang
>  
> From: Mahesh Jethanandani [mailto:[e-mail]] 
> Sent: Tuesday, August 23, 2022 7:33 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
>  
> 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] <mailto:[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] <mailto:[e-mail]>] 
> Sent: Tuesday, July 12, 2022 4:01 AM
> To: maqiufang (A) <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Robert Wilton <[e-mail] <mailto:[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] <mailto:[e-mail]>

Mahesh Jethanandani
[e-mail]