Original text:
<del> An HTTPS-based Transport for Configured Subscriptions </del>  draft-ietf-netconf-https-notif-latest Abstract <del> This document defines both a protocol for sending notifications over HTTPS as well as extensions to the data model for configured subscriptions defined in RFC 8639.  It also presents an example module for configuration without using the data model defined in RFC 8639. </del>  This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is RFC8639, the notification method defined in this document MAY be used outside of RFC8639 by using some of the definitions from this module along with the grouping defined in I-D.ietf-netconf-http-client- <del> server.  For an example on how that can be done, see Section 8.2. </del>  1.2. 2. The protocol consists of two HTTP-based target resources presented by <del> the receiver: A target resource enabling the publisher to discover what optional capabilities a receiver supports.  Publishers SHOULD query this target when before sending any notifications or if ever an error occurs. A target resource enabling to publish to send one or more notification to a receiver.  This document defines support for sending only one notification per message; a future effort MAY extend the protocol to send multiple notifications per message. </del>  The protocol is illustrated in the diagram below: The POST messages MAY be "pipelined" (not illustrated in the diagram above), whereby multiple notifications are sent without waiting for <del> the HTTP response for a previous request. </del>  3. supported encoding is necessary only when the "/subscriptions/subscription/encoding" leaf is not configured, per the "encoding" leaf's description statement in the "ietf-subscribed- <del> notification" module.  FIXME: do they need to discover *any* capabilities? </del>  3.2. To learn the capabilities of a receiver, a publisher can issue an <del> HTTPS GET request to the "capabilities" resource under a known path on the receiver with "Accept" header set using the "application/xml" and/or "application/json" media-types, with latter as the mandatory </del>  to implement, and the default in case the type is not specified. 3.3. Even though a YANG module is not defined for this interaction, the response body MUST conform to the following YANG-modeled format:  3.4. The publisher can send the following request to learn the receiver capabilities.  In this example, the "Accept" states that the receiver <del> wants to receive notifications in XML but, if not supported, to use JSON encoding. </del>  If the receiver is able to reply using "application/xml", and assuming it is able to receive JSON and XML encoded notifications, <del> the response might look like this: </del>  If the receiver is unable to reply using "application/xml", the response might look like this: 4.1. <del> The publisher sends an HTTPS POST request to the "relay- notifications" resource under a known path on the receiver with the "Content-Type" header set to either "application/json" or "application/xml" and a request body containing the notification encoded using the specified format. </del>  XML-encoded notifications are encoded using the format defined by RFC5277 for XML. Instead of saying that, for JSON-encoding purposes, the module name for the "notification" element is "ietf-restconf, the module <del> name will instead by "ietf-https-notif". </del>  4.2. 8.3. <del> Following the guidelines defined in RFC5226, this document defines a </del>  new registry called "Capabilities for HTTPS Notification Receivers". This registry defines capabilities that can be supported by HTTPS- based notification receivers.

Reviewer comments:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.

Revised text:
 <ins> An HTTPS-based Transport for YANG Notifications </ins> draft-ietf-netconf-https-notif-latest Abstract  <ins> This document defines a protocol for sending notifications over HTTPS.  YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. </ins> This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is RFC8639, the notification method defined in this document MAY be used outside of RFC8639 by using some of the definitions from this module along with the grouping defined in I-D.ietf-netconf-http-client-  <ins> server.  For an example on how that can be done, see Section A.2. </ins> 1.2. 2. The protocol consists of two HTTP-based target resources presented by  <ins> the receiver.  These two resources share a common prefix that the publisher must know.  If the data model in section 6.2 is used, this common prefix is defined by the "path" leaf in the "http-client- parameters" container. "capabilities": A target resource enabling the publisher to discover what optional capabilities a receiver supports. Publishers SHOULD query this target before sending any notifications or if ever an error occurs. "relay-notifications": A target resource enabling the publisher to send one or more notification to a receiver.  This document defines support for sending only one notification per message; a future effort MAY extend the protocol to send multiple notifications per message. </ins> The protocol is illustrated in the diagram below: The POST messages MAY be "pipelined" (not illustrated in the diagram above), whereby multiple notifications are sent without waiting for  <ins> the HTTP response for a previous POST. </ins> 3. supported encoding is necessary only when the "/subscriptions/subscription/encoding" leaf is not configured, per the "encoding" leaf's description statement in the "ietf-subscribed-  <ins> notification" module. </ins> 3.2. To learn the capabilities of a receiver, a publisher can issue an  <ins> HTTPS GET request to the "capabilities" resource (see overview) on the receiver with "Accept" header set using the "application/xml" and/or "application/json" media-types, with the latter as mandatory </ins> to implement, and the default in case the type is not specified. 3.3. Even though a YANG module is not defined for this interaction, the response body MUST conform to the following YANG-modeled format: <ins> As it is possible that the receiver may return custom capability URIs, the publisher MUST ignore any capabilities that it does not recognize. </ins> 3.4. The publisher can send the following request to learn the receiver capabilities.  In this example, the "Accept" states that the receiver  <ins> wants to receive the capabilities response in XML but, if not supported, then in JSON. </ins> If the receiver is able to reply using "application/xml", and assuming it is able to receive JSON and XML encoded notifications,  <ins> and it is able to process the RFC 8639 state machine, the response might look like this: </ins> If the receiver is unable to reply using "application/xml", the response might look like this: 4.1.  <ins> The publisher sends an HTTPS POST request to the "relay-notification" resource (see overview) on the receiver with the "Content-Type" header set to either "application/json" or "application/xml" and a body containing the notification encoded using the specified format. </ins> XML-encoded notifications are encoded using the format defined by RFC5277 for XML. Instead of saying that, for JSON-encoding purposes, the module name for the "notification" element is "ietf-restconf, the module  <ins> name will instead be "ietf-https-notif". </ins> 4.2. 8.3.  <ins> Following the guidelines defined in RFC8126, this document defines a </ins> new registry called "Capabilities for HTTPS Notification Receivers". This registry defines capabilities that can be supported by HTTPS- based notification receivers.