Telechat Review of draft-ietf-netconf-https-notif-15
review-ietf-netconf-https-notif-15-httpdir-telechat-nottingham-2024-02-02-00

## 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.