YANG Groupings for
HTTP Clients and HTTP ServersWatsen Networkskent+ietf@watsen.net
Operations
NETCONF Working GroupThis document defines two YANG modules: the first defines a minimal
grouping for configuring an HTTP client, and the second defines
a minimal grouping for configuring an HTTP server. It is
intended that these groupings will be used to help define the
configuration for simple HTTP-based protocols (not for complete
webservers or browsers).This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: 2020-03-08 --> the publication
date of this draftThe following Appendix section is to be removed prior to publication:
Appendix A. Change LogThis document defines two YANG 1.1 modules: the first defines a minimal
grouping for configuring an HTTP client, and the second defines
a minimal grouping for configuring an HTTP server. It is
intended that these groupings will be used to help define the
configuration for simple HTTP-based protocols (not for complete
webservers or browsers).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.This section provides a tree diagram for
the "ietf-http-client" module.This section presents an example showing the http-client-grouping
populated with some data.This YANG module has normative references to .This section provides a tree diagram for
the "ietf-http-server" module.This section presents an example showing the http-server-grouping
populated with some data.This YANG module has normative references to .The YANG modules defined in this document are designed to be accessed
via YANG based management protocols, such as NETCONF and RESTCONF . Both of these
protocols have mandatory-to-implement secure transport layers (e.g.,
SSH, HTTP) with mutual authentication.The NETCONF access control model (NACM)
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.Since the modules defined in this document only define groupings,
these considerations are primarily for the designers of other modules
that use these groupings.There are a number of data nodes defined in the YANG modules that are
writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability: 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. These are the subtrees and data nodes
and their sensitivity/vulnerability: Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity/vulnerability: This document registers two URIs in the "ns" subregistry of the
IETF XML Registry . Following the format in
, the following registrations are
requested:This document registers two YANG modules in the YANG Module Names
registry . Following the format in , the following registrations are requested:Modified Abstract and Intro to be more accurate wrt intended applicability.In ietf-http-client, removed "protocol-version" and all auth schemes except "basic".In ietf-http-client, factored out "client-identity-grouping" for proxy connections.In ietf-http-server, removed "choice required-or-optional" and "choice local-or-external".In ietf-http-server, moved the basic auth under a "choice auth-type" limited by new "feature basic-auth".Removed the unused "external-client-auth-supported" feature from ietf-http-server.The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name):
TBD