Re: [netconf] Last Call: <draft-ietf-netconf-https-notif-13.txt> (An HTTPS-based Transport for YANG Notifications) to Proposed Standard

[Mark Nottingham <[e-mail]>]

> The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'An HTTPS-based Transport for YANG Notifications' <draft-ietf-netconf-https-notif-13.txt> as Proposed Standard
[...]
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/

I'm reviewing this document with a focus on how it uses HTTP.

* The Abstract and Introduction both start with "This document defines a protocol for sending notifications over HTTPS." This is a very general statement and is likely to mislead many readers -- 'notifications' are a very broad capability. Could you please make it more specific to the intended use case?

* The document talks about HTTP a lot, but doesn't actually reference RFC9110. It probably should.

* "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." This is a confusing paragraph. What is a "receiver"? More generally, it would be good if terms like "server" were consistently qualified, since it is used in both HTTP and NETCONF (apparently).

* Throughout, you use "target resource." What is the significance of "target" here? As far as I can tell, they're just HTTP resources.

* "These two resources share a common prefix that the publisher must know." Do you mean that the resources' identifiers (i.e., URIs) share a common prefix?

* "The POST messages MAY be "pipelined" (not illustrated in the diagram above), whereby multiple notifications are sent without waiting for the HTTP response for a previous POST." Did you consider this text from s 9.3.2 of RFC9112?

> Idempotent methods (Section 9.2.2 of [HTTP]) are significant to pipelining because they can be automatically retried after a connection failure. A user agent SHOULD NOT pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.

Also, the word pipelined doesn't need to be quoted.

* In s 3.4: "In this example, the "Accept" states that the publisher wants to receive the capabilities response in XML but, if not supported, then in JSON." The Accept header field doesn't use ordering to indicate precedence; you need to use q values. See RFC9110 s 12.5.1.

Cheers,

--
Mark Nottingham   https://www.mnot.net/