Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-https-notif-14: (with COMMENT)

[Mahesh Jethanandani <[e-mail]>]

Hi Murray,

> On Jan 30, 2024, at 10:02 PM, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-netconf-https-notif-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Lars' DISCUSS position.

The update from -13 to -14 version of the draft states that while the payload between HTTP 1.1, HTTP 2.0 and HTTP 3.0 would not change, the transport does. And because NETCONF is not supported over QUIC, this document cannot claim support for HTTP 3.0 today.

In the future when NETCONF  is supported over QUIC, and we have definitions for configuration for UDP client/server (a draft for which is currently undergoing WG adoption), support for HTTP 3.0 can be added.

>  I also support John Scudder's DISCUSS
> position, and withdraw my own, which I realize now was incorrect and
> "Specification Required" was a reasonable choice.  Apologies for this oversight.

Will update the document to revert the changes.

> 
> Comments preserved from the previous ballot version:
> 
> The SHOULD in Section 2 has me wondering why one might choose not to do what it
> says.  Or should this be a MUST?

I think I explained this as part of the update to the draft. The reason for keeping it a SHOULD is because the method described in this document is deliberately kept lightweight, and require the minimum of setup before being able to send a notification. Otherwise, this would be no different from YANG Push or other methods that expect a session to be setup and capabilities discovered before sending notifications. 

Granted, this method has the downside that it might encounter an error if the receiver does not support the capability. Therefore, we call out the fact that the sender has to be prepared to deal with such an error.

> 
> I suspect you need normative references to RFC 7303 ("application/xml") and RFC
> 8259 ("application/json").

We did add the normative references in -14.

Thanks.

> 
> 
>