From 471970e4e6142981da5fe905836d921d4160587f Mon Sep 17 00:00:00 2001 From: Mahesh Jethanandani Date: Sat, 9 May 2026 20:17:48 -0700 Subject: [PATCH] Add support for yang-data+xml and yang-data+json --- draft/draft-ietf-netconf-https-notif.xml | 101 ++++++++++++----------- src/yang/ietf-https-notif-transport.yang | 32 ++++++- 2 files changed, 84 insertions(+), 49 deletions(-) diff --git a/draft/draft-ietf-netconf-https-notif.xml b/draft/draft-ietf-netconf-https-notif.xml index 56b409a..4d6d711 100755 --- a/draft/draft-ietf-netconf-https-notif.xml +++ b/draft/draft-ietf-netconf-https-notif.xml @@ -61,9 +61,10 @@ target="RFC9114"> HTTP/3, support for it is considered out of scope of this document at this time. - This document defines support for JSON and XML content; + This document defines support for JSON and XML content, using + the media types defined in RESTCONF; future efforts may define support for other encodings (e.g., - binary). This document requires that the publisher is a "server" + CBOR). 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 @@ -232,30 +233,29 @@ To learn the capabilities of a receiver, a publisher can issue an HTTPS GET request to the "capabilities" resource - (see ) on the receiver with - "Accept" header set using the "application/xml" as defined - in XML Media Types, and/or - "application/json" as defined in JSON media-types. + (see ) on the receiver with the + "Accept" header set to "application/yang-data+xml" and/or + "application/yang-data+json", as defined in + RESTCONF.
The receiver responds with a "200 (OK)" message, having the - "Content-Type" header set to either "application/xml" or - "application/json" (which ever was selected), and containing + "Content-Type" header set to either "application/yang-data+xml" or + "application/yang-data+json" (whichever was selected), and containing in the response body a list of the receiver's capabilities encoded in the selected format. - Even though a YANG module is not defined for this interaction, - the response body MUST conform to the following YANG-modeled - format: + The response body MUST conform to the "receiver-capabilities" + structure defined in the "ietf-https-notif-transport" YANG module + (see YANG Data Structure Extensions):
- container receiver-capabilities { + structure receiver-capabilities { description - "A container for a list of capabilities supported by - the receiver."; + "A structure defining the response body for the capabilities + GET request."; leaf-list receiver-capability { - type "inet:uri"; + type inet:uri; description "A capability supported by the receiver. A partial list of capabilities is defined in the 'Capabilities for HTTPS @@ -280,11 +280,11 @@
+Accept: application/yang-data+xml, application/yang-data+json;q=0.5]]>
- If the receiver is able to reply using "application/xml", and - assuming it is able to receive JSON and XML encoded notifications, + If the receiver is able to reply using "application/yang-data+xml", + and assuming it is able to receive JSON and XML encoded notifications, and it is able to process the RFC 8639 state machine, the response might look like this: @@ -293,40 +293,41 @@ Accept: application/xml, application/json;q=0.5]]> Date: Wed, 26 Feb 2020 20:33:30 GMT Server: example-server Cache-Control: no-cache -Content-Type: application/xml +Content-Type: application/yang-data+xml - - \ - urn:ietf:capability:https-notif-receiver:encoding:json\ + + + urn:ietf:params:yang-notif:https-capability:encoding:json - \ - urn:ietf:capability:https-notif-receiver:encoding:xml\ + + urn:ietf:params:yang-notif:https-capability:encoding:xml - \ - urn:ietf:capability:https-notif-receiver:sub-notif\ + + urn:ietf:params:yang-notif:https-capability:sub-notif ]]>
- If the receiver is unable to reply using "application/xml", the - response might look like this: + If the receiver is unable to reply using "application/yang-data+xml", + the response might look like this:
@@ -339,9 +340,9 @@ Content-Length: nnn The publisher sends an HTTP POST request to the "relay-notification" resource (see ) 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. + set to either "application/yang-data+json" or + "application/yang-data+xml" and a body containing the + notification encoded using the specified format. XML-encoded notifications are encoded using the format defined by NETCONF Event Notifications @@ -374,7 +375,7 @@ Content-Length: nnn
2019-03-22T12:35:00Z @@ -392,7 +393,7 @@ Content-Type: application/xml
- The YANG module imports + The YANG module imports + Common YANG Data Types, A YANG Data Model for SNMP Configuration, Subscription to YANG Notifications, + YANG Data Structure Extensions, - and YANG Groupings for HTTP Clients and HTTP Servers. + and YANG Groupings for HTTP Clients and HTTP Servers. + It also defines the "receiver-capabilities" structure used as + the response body of the capabilities GET request. The YANG module is shown below. @@ -513,7 +518,7 @@ INSERT_TEXT_FROM_FILE(../bin/ietf-https-notif-transport@YYYY-MM-DD.yang,69) are defined in YANG Groupings for HTTP Clients and HTTP Servers, YANG Groupings for + target="RFC9645">YANG Groupings for TLS Clients and TLS Servers, and A YANG Data Model for SNMP Configuration. Please see the Security Considerations section of those documents for @@ -710,23 +715,23 @@ Record: - - + + + - diff --git a/src/yang/ietf-https-notif-transport.yang b/src/yang/ietf-https-notif-transport.yang index 233d8d3..32f6269 100644 --- a/src/yang/ietf-https-notif-transport.yang +++ b/src/yang/ietf-https-notif-transport.yang @@ -3,6 +3,12 @@ module ietf-https-notif-transport { namespace "urn:ietf:params:xml:ns:yang:ietf-https-notif-transport"; prefix "hnt"; + import ietf-inet-types { + prefix inet; + reference + "RFC 9911: Common YANG Data Types."; + } + import ietf-x509-cert-to-name { prefix x509c2n; reference @@ -20,7 +26,13 @@ module ietf-https-notif-transport { reference "RFC XXXX: An HTTPS-based Transport for YANG Notifications."; } - + + import ietf-yang-structure-ext { + prefix sx; + reference + "RFC 8791: YANG Data Structure Extensions."; + } + import ietf-http-client { prefix httpc; reference @@ -137,4 +149,22 @@ module ietf-https-notif-transport { "Augment the transport-type choice to include the 'https' transport."; } + + sx:structure receiver-capabilities { + description + "A structure defining the response body for the GET request + to the 'capabilities' resource. When encoded as + 'application/yang-data+xml', the root element is + 'receiver-capabilities' in the namespace of this module. + When encoded as 'application/yang-data+json', the top-level + key is 'ietf-https-notif-transport:receiver-capabilities'."; + leaf-list receiver-capability { + type inet:uri; + description + "A capability supported by the receiver. A partial list + of capabilities is defined in the 'Capabilities for HTTPS + Notification Receivers' registry (RFC XXXX). Additional + custom capabilities MAY be defined."; + } + } }