jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-netconf-https-notif

Commentary: See comment .
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.
This document defines a protocol for sending asynchronous event
notifications similar to notifications defined in RFC 5277, but over
HTTPS.  YANG modules for configuring publishers are also defined.
Examples are provided illustrating how to configure various
publishers.
This document defines a protocol for sending notifications over
HTTPS.  Using HTTPS maximizes transport-level interoperability, while
allowing for a variety of encoding options.  This document defines
support for JSON and XML; future efforts may define support for other
encodings (e.g., binary).
This document defines a protocol for sending asynchronous event
notifications similar to notifications defined in RFC5277, but over
HTTPS.  Using HTTPS, which is a secure form of RFC9110, maximizes
transport-level interoperability, while allowing for a variety of
encoding options.  This document defines support for JSON and XML;
future efforts may define support for other encodings (e.g., binary).
Configured subscriptions enable a server, acting as a publisher of
notifications, to proactively push notifications to external
receivers without the receivers needing to first connect to the
server, as is the case with dynamic subscriptions.
Configured subscriptions enable a server (e.g., a NETCONF or RESTCONF
server), acting as a publisher of notifications, to proactively push
notifications to external receivers without the receivers needing to
first connect to the server, as is the case with dynamic
subscriptions.
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.
The following term is defined in RFC8040.
The protocol consists of two HTTP-based target resources presented by
the receiver.  These two resources share a common prefix that the
publisher learns from a request it issues, as defined in section 3.2.
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.
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.
Draft: draft-ietf-netconf-https-notif

Commentary: Better .
The response should be "204 (No Content)".
The response on success should be "204 (No Content)".  In case of
corrupted or malformed event, the response should be an appropriate
HTTP error response.
Some of the readable data nodes in the YANG modules may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes.  The model does not define any
readable subtrees and data nodes.
The container "receiver-identity" contains nodes like "cert-maps"
that are used by the HTTP server to map to the HTTPS client's
certificate to a 'local' username.  An unintended modification of
these nodes will result in new connection requests be denied.
Some of the readable data nodes in the YANG modules may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes.  The model does not define any
readable subtrees and data nodes that are particularly sensitive or
vulnerable.
Draft: draft-ietf-netconf-https-notif

Commentary: Looks good to me .
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 notfications.
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.
The YANG modules specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as RFC6241 or RFC8040.  The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is
RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is RFC8446.  The RFC8341 provides the
means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such
as RFC6241 or RFC8040.  The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is
RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is RFC8446.  The RFC8341 provides the
means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
The YANG modules in this document makes use of grouping that are
defined in I-D.ietf-netconf-http-client-server, and RFC7407.  Please
see the Security Considerations section of those documents for
considerations related to sensitivity and vulnerability of the data
nodes defined in them.
The YANG modules in this document make use of grouping that are
defined in I-D.ietf-netconf-http-client-server, and RFC7407.  Please
see the Security Considerations section of those documents for
considerations related to sensitivity and vulnerability of the data
nodes defined in them.
Draft: draft-ietf-netconf-https-notif

Commentary: Draft does n't compile : The directory does n't exist ...
The interaction between the receiver and the publisher can be a
single notification with a response or of type "pipelining" where
multiple notifications as sent part of a single message.
With a single notification, the interfaction between the receiver and
the publisher would look something like this.
To learn the capabilities of the receiver, the publisher can issue a
HTTPS GET request with Accept-Type set to application/ietf-https-
notif-cap+xml or application/ietf-https-notif-cap+json, with latter
as the mandatory to implement, and the default in case the type is
not specified.  If the receiver supports capabilities such as binary
encoding of data, it can return that as a capability in a response.
Please note that, when used in conjunction with RFC8639, dynamic
discovery of the receiver&#146;s supported encoding is considered
only when the "/subscriptions/subscription/encoding&#148; leaf is not
configured, per the &#147;encoding&#148; leaf&#146;s description
statement.
To learn the capabilities of the receiver, the publisher can issue a
HTTPS GET request with Accept-Type set to application/ietf-https-
notif-cap+xml or application/ietf-https-notif-cap+json, with latter
as the mandatory to implement, and the default in case the type is
not specified.  If the receiver supports capabilities such as I-
D.ietf-netconf-notification-messages of data, it can return that as a
capability in a response.
Please note that, when used in conjunction with RFC8639, dynamic
discovery of the receiver&#146;s supported encoding is considered
only when the "/subscriptions/subscription/encoding&#148; leaf is not
configured, per the &#147;encoding&#148; leaf&#146;s description
statement.
This YANG module is definition of the list of capabilities of the
receiver.  A publisher can request these capabilities from the
receiver, e.g. by issuing a GET request towards it.  It consists of a
<rpc> statement that takes an 'input' argument describing the path to
the reciever capabilities, and an output statement which is a list of
'receiver-capability".
An abridged tree diagram representing the module is show below.
The YANG module imports RFC6991.
Draft: draft-ietf-netconf-https-notif

Commentary: This adds an XML example . The only question is whether we need a prefix for ietf - https - notif in the example .
Encoding notifications for the HTTPS notifications is the same as the
encoding notifications as defined in RFC8040 Section 6.4, with the
following changes.  Instead of saying that for JSON-encoding
purposes, the module name for "notification" element will be "ietf-
restconf, it will say that for JSON-encoding purposes, the module
name for "notification" element will be "ietf-https-notif".
Notifications are encoded as defined in RFC8040 Section 6.4.  The
examples in that section apply for sending notifications over the
"https-notif" based transport.