Reviewer: Mark Nottingham Review result: Ready with Issues ## 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
