Draft: draft-ietf-netconf-https-notif

Commentary: 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 .
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.
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.
While the YANG modules have been defined as an augmentation of
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-
server.  For an example on how that can be done, see Section 8.2.
While the YANG modules have been defined as an augmentation of
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-
server.  For an example on how that can be done, see Section A.2.
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.
The protocol consists of two HTTP-based target resources presented by
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.
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 request.
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.
For publishers using RFC8639, dynamic discovery of a receiver's
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-
notification" module.  FIXME: do they need to discover *any*
capabilities?
To learn the capabilities of a receiver, a publisher can issue an
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
to implement, and the default in case the type is not specified.
For publishers using RFC8639, dynamic discovery of a receiver's
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-
notification" module.
To learn the capabilities of a receiver, a publisher can issue an
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
to implement, and the default in case the type is not specified.
The publisher can send the following request to learn the receiver
capabilities.  In this example, the "Accept" states that the receiver
wants to receive notifications in XML but, if not supported, to use
JSON encoding.
As it is possible that the receiver may return custom capability
URIs, the publisher MUST ignore any capabilities that it does not
recognize.
The publisher can send the following request to learn the receiver
capabilities.  In this example, the "Accept" states that the receiver
wants to receive the capabilities response in XML but, if not
supported, then in JSON.
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.
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.
Instead of saying that, for JSON-encoding purposes, the module
name for the "notification" element is "ietf-restconf, the module
name will instead by "ietf-https-notif".
Instead of saying that, for JSON-encoding purposes, the module
name for the "notification" element is "ietf-restconf, the module
name will instead be "ietf-https-notif".
Following the guidelines defined in RFC5226, this document defines a
new registry called "Capabilities for HTTPS Notification Receivers".
This registry defines capabilities that can be supported by HTTPS-
based notification receivers.
Following the guidelines defined in RFC8126, this document defines a
new registry called "Capabilities for HTTPS Notification Receivers".
This registry defines capabilities that can be supported by HTTPS-
based notification receivers.