## In 1. Introduction:

> Using HTTPS, which is a secure form of HTTP Semantics [RFC9110], maximizes transport-level interoperability, while allowing for a variety of encoding options.

The wording around "HTTP Semantics is odd. I'd suggest just:

> Using HTTPS [RFC9110], which maximizes transport-level interoperability, while allowing for a variety of encoding options.

## In 1. Introduction:

> The protocol supports HTTP/1.1: Message Syntax and Routing [RFC9112] and, HTTP/2 [RFC9113].  While the payload does not change between these versions of HTTP and HTTP/3 [RFC9114], the underlying transport does.  Since NETCONF does not support QUIC: A UDP-Based Multiplexed and Secure Transport [RFC9000], support for HTTP/3 [RFC9114], is considered out of scope of this document.

This doesn't make any sense; whether or not NETCONF supports QUIC is immaterial if you're using HTTP as a substrate. See also BCP56 Section 4.1. All of this text should be removed.

## In 1. Introduction:

> This document defines support for JSON and XML

should be

> This document defines support for JSON and XML content

## In 1. Introduction:

> This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a NETCONF or RESTCONF server.  It does expect the receiver to be an HTTPS server to receive the notifications.

Please introduce the term 'receiver' more clearly (perhaps with a reference?)

## In 3.3:

> The receiver responds with a "200 (OK)" message

... and in 4.2:

> The response on success SHOULD be "204 (No Content)". 

This style of specification often leads to interoperability problems, because some clients will interpret this as a requirement for the status code to be 200, when what is received on the wire may be something else (e.g., a 304 from a cache). See BCP56 Section 4.6.