Mboned                                                        J. Holland
Internet-Draft                                 Akamai Technologies, Inc.
Intended status: Standards Track                          March 10,                        October 30, 2020
Expires: September 11, 2020 May 3, 2021

      Discovery Of Restconf Metadata for Source-specific multicast
                       draft-ietf-mboned-dorms-00
                       draft-ietf-mboned-dorms-01

Abstract

   This document defines DORMS (Discovery Of Restconf Metadata for
   Source-specific multicast), a method to discover and retrieve
   extensible metadata about source-specific multicast channels using
   RESTCONF.  The reverse IP DNS zone for a multicast sender's IP
   address is configured to use SRV resource records to advertise the
   hostname of a RESTCONF server that publishes metadata according to a
   new YANG module with support for extensions.  A new service name and
   the new YANG module are defined.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 11, 2020. May 3, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.1.  Use cases . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.2.  Channel Selection . . . . . . . . . . . . . . . . . .   5
     1.4.  Notes for Contributors and Reviewers  . . . . . . . . . .   5
       1.4.1.  Venues for Contribution and Discussion  . . . . . . .   5
       1.4.2.  Non-obvious doc choices . . . . . . . . . . . . . . .   6
   2.  Discovery and Metdata Retrieval . . . . . . . . . . . . . . .   4   6
     2.1.  DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . .   4   6
     2.2.  Ignore List . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  RESTCONF Bootstrap  . . . . . . . . . . . . . . . . . . .   5
       2.2.1.   8
       2.3.1.  Root Resource Discovery . . . . . . . . . . . . . . .   5
       2.2.2.   8
       2.3.2.  Yang Library Version  . . . . . . . . . . . . . . . .   6
       2.2.3.   8
       2.3.3.  Yang Library Contents . . . . . . . . . . . . . . . .   6
       2.2.4.   9
       2.3.4.  Metadata Retrieval  . . . . . . . . . . . . . . . . .   7
       2.2.5.  10
       2.3.5.  Cross Origin Resource Sharing (CORS)  . . . . . . . .   8  11
   3.  Scalability Considerations  . . . . . . . . . . . . . . . . .   9  11
     3.1.  Provisioning  . . . . . . . . . . . . . . . . . . . . . .   9  11
     3.2.  Data Scoping  . . . . . . . . . . . . . . . . . . . . . .   9  12
   4.  YANG Model  . . . . . . . . . . . . . . . . . . . . . . . . .   9  12
     4.1.  Yang Tree . . . . . . . . . . . . . . . . . . . . . . . .  10  12
     4.2.  Yang Module . . . . . . . . . . . . . . . . . . . . . . .  10  13
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12  15
     5.1.  Linking Content to Traffic Streams  . . . . . . . . . . .  12  15
     5.2.  Linking Multicast Subscribers to Unicast Connections  . .  12  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13  16
     6.1.  The YANG Module Names Registry  . . . . . . . . . . . . .  13  16
     6.2.  The XML Registry  . . . . . . . . . . . . . . . . . . . .  16
     6.3.  The Service Name and Transport Protocol Port Number
           Registry  . . . . . . . . . . . . . . . . . . . . . . . .  13  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13  17
     7.1.  Secure Communications . .  YANG Model Considerations . . . . . . . . . . . . . . . .  13  17
     7.2.  Exposure of Metadata  . . . . . . . . . . . . . . . . . .  14  17
     7.3.  DNS Bootstrapping  Secure Communications . . . . . . . . . . . . . . . . . .  18
     7.4.  Record-Spoofing . .  14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . .  18
     7.5.  CORS considerations . . .  15
   9.  References . . . . . . . . . . . . . . . .  19
   8.  Acknowledgements  . . . . . . . . .  15
     9.1.  Normative . . . . . . . . . . . . .  20
   9.  References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References . . . . . . .  20
     9.1.  Normative References  . . . . . . . . . .  16
   Author's Address . . . . . . . .  20
     9.2.  Informative References  . . . . . . . . . . . . . . . .  17 .  21

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   This document defines DORMS (Discovery Of Restconf Metadata for
   Source-specific multicast).

   A DORMS service is a RESTCONF [RFC8040] service that provides read
   access to data in the "ietf-dorms" YANG [RFC7950] model defined in
   Section 4.  This model, along with optional extensions defined in
   other documents, provide an extensible set of information about
   multicast data streams.  A review of some example use cases that can
   be enabled by this kind of metadata is given in Section 1.3.

   This document defines the "dorms" service name for use with the SRV
   DNS Resource Record (RR) type [RFC2782].  A sender offering using a DORMS
   service to publish metadata SHOULD configure at least one SRV RR for
   the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source
   IP of its used by some active multicast channel to advertise traffic.  The domain name in one of
   these SRV records provides a hostname for corresponding to a DORMS server
   that can provide metadata for the sender's source-specific multicast
   traffic.  Doing so  Publishing such a RR enables receivers and middleboxes DORMS clients to discover and
   query a DORMS server as described in Section 2.

   The goal is to provide an extensible framework for attaching
   information necessary for the correct processing of multicast data
   channels, both for middle boxes forwarding the traffic, and for
   receivers subscribing to traffic (hereafter called "clients").

1.1.  Background

   The reader is assumed to be familiar with the basic DNS concepts
   described in [RFC1034], [RFC1035], and the subsequent documents that
   update them, as well as the use of the SRV Resource Record type as
   described in [RFC2782].

   The reader is also assumed to be familiar with the concepts and
   terminology regarding source-specific multicast as described in
   [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for
   group management of source-specific multicast channels, as described
   in [RFC4604].

   The reader is also assumed to be familiar with the concepts and
   terminology for RESTCONF [RFC8040] and YANG [RFC7950].

1.2.  Terminology
   +--------+----------------------------------------------------------+
   |   Term | Definition                                               |
   +--------+----------------------------------------------------------+
   |  (S,G) | A source-specific multicast channel, as described in     |
   |        | [RFC4607]. A pair of IP addresses with a source host IP  |
   |        | and destination group IP.                                |
   |        |                                                          |
   |  DORMS | An application or system that can communicate with DORMS |
   | client | servers to fetch metadata about (S,G)s.                  |
   |        |                                                          |
   |  DORMS | A RESTCONF server that implements the ietf-dorms YANG    |
   | server | model defined in this document.                          |
   |        |                                                          |
   |     RR | A DNS Resource Record, as described in [RFC1034]         |
   |        |                                                          |
   | RRType | A DNS Resource Record Type, as described in [RFC1034]    |
   |        |                                                          |
   |    SSM | Source-specific multicast, as described in [RFC4607]     |
   +--------+----------------------------------------------------------+

   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
   [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Discovery and Metdata Retrieval

   A client

1.3.  Motivation

   DORMS provides a framework that needs metadata can be extended to publish
   supplemental information about multicas traffic in a (S,G) MAY attempt to discover
   metadata for globally
   discoverable manner.  This is useful so that entities engaged in
   delivery or processing of the (S,G) using traffic that are not affiliated with
   the mechanisms defined here, and MAY use sender of the metadata received traffic and who may not otherwise have any means to manage
   discover information about the traffic, such as forwarding ISPs or processing
   operators of firewalls providing security guarantees to their users,
   can discover the
   packets information they may need in order to process the channel.

2.1.  DNS Bootstrap

   The DNS Bootstrap step is how
   traffic according to their requirements.

1.3.1.  Use cases

   For example, a client discovers an appropriate
   RESTCONF server, given the source address network that is capable of an (S,G).  Use forwarding multicast
   traffic may need to take provisioning actions or make admission
   control decisions at ingress points based on the expected bitrate of
   the
   DNS Bootstrap is OPTIONAL for clients with an alternate method traffic in order to prevent oversubscription of
   obtaining a RESTCONF hostname for a DORMS server with the network.

   Other use cases may include metadata for an
   (S,G).

   This mechanism only works for source-specific that can be used to authenticate
   the multicast (SSM)
   channels.  The source address traffic, metadata that describes the contents of the (S,G) is reversed and
   traffic, metadata that makes assertions about the legal status of the
   traffic within specific contexts, or metadata that describes the
   protocols or applications that can be used as an
   index into one to consume the traffic.
   Extensions to DORMS to support these or other kinds of metadata can
   be defined by later specifications.

   Detailing the reverse mapping trees (in-addr.arpa for IPv4,
   as described in Section 3.5 specific of [RFC1035], or ip6.arpa the possible extensions is out of scope for IPv6, as
   described in Section 2.5
   this document except to note that a range of [RFC3596]).

   When possible use cases are
   expected and they may be supported by a receiver or middle box needs metadata for an (S,G), for
   example when handling variety of different future
   extensions.

1.3.2.  Channel Selection

   In general, a new join for that DORMS client might learn of an (S,G) and looking up
   authentication by any means.
   Therefore, describing the full set of possible methods available, a receiver or middlebox can issue DORMS client
   might use to discover a
   DNS query set of (S,G)s for which it wants metadata is
   out of scope for this document.

   But to give a SRV RR using the "dorms" service name with the domain few examples, a multicast receiver application that is
   a DORMS client might learn about an (S,G) by getting signals from
   inside the reverse mapping tree, combining them application logic, such as described a selection made by a user, or
   a scheduled API call that reacts to updates in
   [RFC2782].

   For a library provided by
   a service operator.

   As another example, while handling an on-path router that's a join for (203.0.113.15, 232.1.1.1), DORMS client might
   instead learn about an (S,G) by receiving a
   receiver would perform PIM message or an IGMP or
   MLD membership report indicating a DNS query for downstream client has tried to
   subscribe to an (S,G).  Such a router might use information learned
   from the SRV RRType for DORMS metadata to make an access control decision about
   whether to propagate the domain:

        _dorms._tcp.15.113.0.203.in-addr.arpa.

   The DNS response join futher upstream in the network.

   Other approaches for this domain might return learning an (S,G) could be driven by monitoring
   a record route reflector to discover channels that are being actively
   forwarded, for a purpose such as:

        SRV 0 1 443 dorms-restconf.example.com. as monitoring network health.

1.4.  Notes for Contributors and Reviewers

   Note to RFC Editor: Please remove this section and its subsections
   before publication.

   This response informs section is to provide references to make it easier to review the receiver that a DORMS server SHOULD be
   reachable at dorms-restconf.example.com
   development and discussion on port 443.  Multiple SRV
   records are handled as described by [RFC2782].

   A sender providing DORMS discovery SHOULD publish at least one SRV
   record in the reverse DNS zone draft so far.

1.4.1.  Venues for each source address of the
   multicast channels it Contribution and Discussion

   This document is sending, in order the Github repository at:

   https://github.com/GrumpyOldTroll/ietf-dorms-cluster
   Readers are welcome to advertise open issues and send pull requests for this
   document.

   Please note that contributions may be merged and substantially
   edited, and as a reminder, please carefully consider the hostname Note Well
   before contributing: https://datatracker.ietf.org/submit/note-well/

   Substantial discussion of this document should take place on the DORMS server
   MBONED working group mailing list (mboned@ietf.org).

   o  Join: https://www.ietf.org/mailman/listinfo/mboned

   o  Search: https://mailarchive.ietf.org/arch/browse/mboned/

1.4.2.  Non-obvious doc choices

   Log of odd things that need to receivers and middle boxes.  The DORMS servers
   advertised SHOULD be configured with metadata for all the groups sent
   from the same source IP address way they are because of some
   reason that have metadata published with
   DORMS.

2.2.  RESTCONF Bootstrap

   Once the author or reviewers may want to know later.

   o  building the draft without this line produces a DORMS host has been chosen (whether via an SRV RR from a DNS
   response warning about no
      reference to [RFC6991] or via some other method), RESTCONF provides all [RFC8294], but these are imported in the
   information necessary to determine
      yang model.  RFC 8407 requires the versions normative reference to 8294
      (there's an exception for 6991 but I'm not sure why and url paths it doesn't
      seem forbidden).

2.  Discovery and Metdata Retrieval

   A client that needs metadata about an (S,G) MAY attempt to discover
   metadata for the (S,G) using the mechanisms defined here, and MAY use
   the metadata from received to manage the server.  A walkthrough forwarding or processing of the
   packets in the channel.

2.1.  DNS Bootstrap

   The DNS Bootstrap step is provided here for how a
   sequence client discovers an appropriate
   RESTCONF server, given the source address of example requests and responses from an (S,G).  Use of the
   DNS Bootstrap is OPTIONAL for clients with an alternate method of
   obtaining a receiver connecting
   to hostname of a new trusted DORMS server.

2.2.1.  Root Resource Discovery

   As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF server provides the link to the RESTCONF api entry point via with information about
   the
   "/.well-known/host-meta" or "/.well-known/host-meta.json" resource.

   Example:

   The receiver might send:

        GET /.well-known/host-meta.json HTTP/1.1
        Host: dorms-restconf.example.com
        Accept: application/json target (S,G).

   This mechanism only works for source-specific multicast (SSM)
   channels.  The server might respond as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:00 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/json

         {
           "links":[
             {
               "rel":"restconf",
               "href":"/top/restconf"
             }
           ]
         }

2.2.2.  Yang Library Version

   As described in Section 3.3.3 source address of [RFC8040], the yang-library-version
   leaf (S,G) is required by RESTCONF, reversed and can be used to determine the schema as an
   index into one of the ietf-yang-library module:

   Example:

   The receiver might send:

         GET /top/restconf/yang-library-version HTTP/1.1
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The server might respond reverse mapping trees (in-addr.arpa for IPv4,
   as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:01 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/yang-data+json

         {
             "ietf-restconf:yang-library-version": "2016-06-21"
         }

   TBD: We might need described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
   described in Section 2.5 of [RFC3596]).

   When a method DORMS client needs metadata for learning an (S,G), for example when
   handling a specific restconf server
   or resource path new join for that supports a version (S,G) and looking up the client knows how to use,
   in authentication
   methods that are available, a receiver or middlebox can issue a DNS
   query for a SRV RR using the case "dorms" service name with the client is older than domain
   from the server after reverse mapping tree, combining them as described in
   [RFC2782].

   For example, while handling a new yang-
   library version is released...  Can join for (203.0.113.15, 232.1.1.1), a
   receiver would perform a DNS query for the SRV RRType for the domain:

        _dorms._tcp.15.113.0.203.in-addr.arpa.

   The DNS response for this be just retry with domain might return a hold-
   down on specific hostnames, so record such as:

        SRV 0 1 443 dorms-restconf.example.com.

   This response informs the receiver that you can find a lower priority
   older DORMS server should be
   reachable at dorms-restconf.example.com on port 443, and should
   contain metadata about multicast traffic from the given source IP.
   Multiple SRV records, or is signaling that can find or
   negotiate an explicit version records are handled as part described by [RFC2782].

   A sender providing DORMS discovery SHOULD publish at least one SRV
   record in the reverse DNS zone for each source address of the lookup going
   multicast channels it is sending in order to be
   necessary? -jake 2019-08-26

2.2.3.  Yang Library Contents

   After checking that advertise the version hostname
   of the yang-library module will be
   understood by DORMS server to DORMS clients.  The DORMS servers advertised
   SHOULD be configured with metadata for all the receiver, groups sent from the client can check
   same source IP address that the desired have metadata module is available on the published with DORMS.

2.2.  Ignore List

   If a DORMS client reaches a DORMS server by fetching the
   module-state resource but determines through
   examination of responses from the ietf-yang-library module.

   Example:

   The receiver might send:

         GET /top/restconf/data/ietf-yang-library:modules-state/\
             module=ietf-dorms,2016-08-15
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The that DORMS server might respond as follows:

       HTTP/1.1 200 OK
       Date: Tue, 27 Aug 2019 20:56:02 GMT
       Server: example-server
       Cache-Control: no-cache
       Content-Type: application/yang-data+json

       {
         "ietf-yang-library:module": [
           {
             "conformance-type": "implement",
             "name": "ietf-dorms",
             "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms",
             "revision": "2019-08-25",
             "schema":
                 "https://example.com/yang/ietf-dorms@2019-08-25.yang"
           }
         ]
       }

   Other modules required that it may not
   understand or desired by the client also can be checked
   in a similar way, or able to use the full set responses of available modules can be
   retrieved by not providing the server (for example
   due to an issue like a key version mismatch or modules that are missing
   but are required for the "module" list.

2.2.4.  Metadata Retrieval

   Once the expected DORMS version is confirmed, client's purposes), the client can retrieve
   the metadata specific MAY add
   this server to an ignore list and reject servers in its ignore list
   during future discovery attempts.

   A client using the desired (S,G).

   Example:

   The receiver DNS Bootstrap discovery method in Section 2.1
   would treat servers in its ignore list as unreachable for the
   purposes of processing the SRV RR as described in [RFC2782].  (For
   example, a client might send:

         GET /top/restconf/data/ietf-dorms:metadata/\
             sender=203.0.113.15/group=232.1.1.1
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The end up selecting a server might respond as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:02 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/yang-data+json

         {
           "ietf-dorms:group": [
             {
               "group-address":"232.1.1.1",
               "udp-stream":[
                 {
                   "port":"5001"
                 }
               ]
             }
           ]
         }

   Note that when other modules are installed on the DORMS server that
   extend the ietf-dorms module, other fields MAY appear inside the
   response.  This is the primary mechanism for providing extensible
   metadata for with a less-
   preferred priority than servers in its ignore list, even if an HTTPS
   connection could have been formed successfully with some of those
   servers.)

   If an (S,G), so clients SHOULD ignore fields they do not
   understand.

   As mentioned in Section 3.2, most clients list is maintained, entries SHOULD use data resource
   identifiers in time out and allow
   for re-checking after either the request URI as in cache expiration time from the above example, in order
   response that caused the server to be added to
   retrieve metadata for only the targeted (S,G)s.

2.2.5.  Cross Origin Resource Sharing (CORS)

   It is RECOMMENDED ignore list, or
   for a configurable hold-down time that has a default value no shorter
   than an hour and no longer than 3 days.

2.3.  RESTCONF Bootstrap

   Once a DORMS servers use host has been chosen (whether via an SRV RR from a DNS
   response or via some other method), RESTCONF provides all the Access-Control-Allow-
   Origin header field, as specified by [W3C.REC-cors-20140116], and
   that they respond appropriately
   information necessary to Preflight requests.

   Providing '*' for the allowed origins exposes determine the DORMS-based versions and url paths for
   metadata to all web pages.  When access to from the metadata server.  A walkthrough is used as provided here for a
   prerequisite to permitting the joining
   sequence of the multicast flows, this
   would permit scripts example requests and responses from arbitrary web pages to issue joins for the
   multicast flows, which could allow e.g. malicious advertisements a receiver connecting
   to
   participate a new DORMS server.

2.3.1.  Root Resource Discovery

   As described in overjoining attacks (see Appendix A Section 3.1 of
   [I-D.draft-jholland-cb-assisted-cc-01]) using multicast flows not
   controlled by [RFC8040] and [RFC6415], the ad's senders.  Therefore RESTCONF
   server provides the use of '*' for allowed
   origins is NOT RECOMMENDED.  (TBD: this probably deserves a security
   considerations section.)

3.  Scalability Considerations

3.1.  Provisioning

   In contrast link to many common the RESTCONF deployments that are intended to
   provide configuration management for a service to a narrow set of
   authenticated administrators, DORMS servers often provide read-only
   metadata for public access, api entry point via the
   "/.well-known/host-meta" or for a very large set of end receivers,
   since it provides metadata "/.well-known/host-meta.json" resource.

   Example:

   The receiver might send:

        GET /.well-known/host-meta.json HTTP/1.1
        Host: dorms-restconf.example.com
        Accept: application/json

   The server might respond as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:00 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/json

         {
           "links":[
             {
               "rel":"restconf",
               "href":"/top/restconf"
             }
           ]
         }

2.3.2.  Yang Library Version

   As described in support Section 3.3.3 of multicast data streams [RFC8040], the yang-library-version
   leaf is required by RESTCONF, and
   multicast can scale to very large audiences.

   Operators are advised be used to provision determine the DORMS service in schema
   of the ietf-yang-library module:

   Example:

   The receiver might send:

         GET /top/restconf/yang-library-version HTTP/1.1
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The server might respond as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:01 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/yang-data+json

         {
             "ietf-restconf:yang-library-version": "2016-06-21"
         }

   If a way DORMS client determines through examination of the yang-library-
   version that
   will scale appropriately to it may not understand the size responses of the expected audience.
   Specific advice on such scaling is out of scope server due to
   a version mismatch, the server qualifies as a candidate for this document,
   but some adding to
   an ignore list as described in Section 2.2.

2.3.3.  Yang Library Contents

   After checking that the version of the mechanisms outlined in [RFC3040] or other online
   resources might yang-library module will be useful, depending on
   understood by the expected number of
   receivers.

3.2.  Data Scoping

   In receiver, the client can check that the desired
   metadata modules are available on the absence of contextual information, clients SHOULD issue
   narrowed requests for DORMS resources server by following fetching the format from
   Section 3.5.3 of [RFC8040] to encode data
   module-state resource identifiers in the
   request URI.  This avoids downloading excessive data, since from the DORMS ietf-yang-library module.

   Example:

   The receiver might send:

         GET /top/restconf/data/ietf-yang-library:modules-state/\
             module=ietf-dorms,2016-08-15
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The server may provide metadata for many (S,G)s, possibly from many
   different senders.

   However, clients MAY use heuristics might respond as follows:

       HTTP/1.1 200 OK
       Date: Tue, 27 Aug 2019 20:56:02 GMT
       Server: example-server
       Cache-Control: no-cache
       Content-Type: application/yang-data+json

       {
         "ietf-yang-library:module": [
           {
             "conformance-type": "implement",
             "name": "ietf-dorms",
             "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms",
             "revision": "2019-08-25",
             "schema":
                 "https://example.com/yang/ietf-dorms@2019-08-25.yang"
           }
         ]
       }

   Other modules required or out of band information about
   the service to issue requests for (S,G) metadata narrowed only desired by the
   source-address, client also can be checked
   in a similar way, or not narrowed at all.  Depending on the request
   patterns and the contents full set of the data store, this may result in fewer
   round trips or less overhead, and available modules can therefore be helpful behavior
   retrieved by not providing a key for scaling purposes.  Servers MAY restrict or throttle client access
   based on the "module" list.  If a DORMS
   client certificate presented (if any), or based on
   heuristics that take note of client request patterns.

   A complete description requires the presence of certain modules to perform its
   function discovers the heuristics required modules are not present on a server,
   that server qualifies for clients inclusion in an ignore list according to
   Section 2.2.

2.3.4.  Metadata Retrieval

   Once the expected DORMS version is confirmed, the client can retrieve
   the metadata specific to the desired (S,G).

   Example:

   The receiver might send:

         GET /top/restconf/data/ietf-dorms:metadata/\
             sender=203.0.113.15/group=232.1.1.1
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The server might respond as follows:

         HTTP/1.1 200 OK
         Date: Tue, 27 Aug 2019 20:56:02 GMT
         Server: example-server
         Cache-Control: no-cache
         Content-Type: application/yang-data+json

         {
           "ietf-dorms:group": [
             {
               "group-address":"232.1.1.1",
               "udp-stream":[
                 {
                   "port":"5001"
                 }
               ]
             }
           ]
         }

   Note that when other modules are installed on the DORMS server that
   extend the ietf-dorms module, other fields MAY appear inside the
   response.  This is the primary mechanism for providing extensible
   metadata for an (S,G), so clients SHOULD ignore fields they do not
   understand.

   As mentioned in Section 3.2, most clients SHOULD use data resource
   identifiers in the request URI as in the above example, in order to
   retrieve metadata for only the targeted (S,G)s.

2.3.5.  Cross Origin Resource Sharing (CORS)

   It is RECOMMENDED that DORMS servers use the Access-Control-Allow-
   Origin header field, as specified by [whatwg-fetch], and that they
   respond appropriately to Preflight requests.

   The use of '*' for allowed origins is NOT RECOMMENDED for DORMS
   servers.  A review of some of the potential consequences of
   unrestricted CORS access is given in Section 7.5.

3.  Scalability Considerations

3.1.  Provisioning

   In contrast to many common RESTCONF deployments that are intended to
   provide configuration management for a service to a narrow set of
   authenticated administrators, DORMS servers often provide read-only
   metadata for public access or for a very large set of end receivers,
   since it provides metadata in support of multicast data streams and
   multicast can scale to very large audiences.

   Operators are advised to provision the DORMS service in a way that
   will scale appropriately to the size of the expected audience.
   Specific advice on such scaling is out of scope for this document,
   but some of the mechanisms outlined in [RFC3040] or other online
   resources might be useful, depending on the expected number of
   receivers.

3.2.  Data Scoping

   In the absence of contextual information, clients SHOULD issue
   narrowed requests for DORMS resources by following the format from
   Section 3.5.3 of [RFC8040] to encode data resource identifiers in the
   request URI.  This avoids downloading excessive data, since the DORMS
   server may provide metadata for many (S,G)s, possibly from many
   different senders.

   However, clients MAY use heuristics or out of band information about
   the service to issue requests for (S,G) metadata narrowed only by the
   source-address, or not narrowed at all.  Depending on the request
   patterns and the contents of the data store, this may result in fewer
   round trips or less overhead, and can therefore be helpful behavior
   for scaling purposes in some scenarios.  Servers MAY restrict or
   throttle client access based on the client certificate presented (if
   any), or based on heuristics that take note of client request
   patterns.

   A complete description of the heuristics for clients and servers to
   meet their scalability goals is out of scope for this document.

4.  YANG Model

   The primary purpose of the YANG model defined here is to serve as a
   scaffold for the more useful metadata that will extend it.  Currently
   known  Example
   specified use cases include providing authentication information
   [I-D.draft-ietf-mboned-ambi-00] and bit-
   rate bit-rate information
   [I-D.draft-ietf-mboned-cbacc-00] for use by receivers and middle
   boxes, but more use cases are anticipated.

4.1.  Yang Tree

   The tree diagram below follows the notation defined in [RFC8340].

   module: ietf-dorms
     +--rw metadata
        +--rw sender* [source-address]
           +--rw source-address    inet:ip-address
           +--rw group* [group-address]
              +--rw group-address    rt-types:ip-multicast-group-address
              +--rw udp-stream* [port]
                 +--rw port    inet:port-number

                            DORMS Tree Diagram

4.2.  Yang Module

   <CODE BEGINS> file ietf-dorms@2020-03-10.yang ietf-dorms@2020-10-31.yang
   module ietf-dorms {
       yang-version 1.1;

       namespace "urn:ietf:params:xml:ns:yang:ietf-dorms";
       prefix "dorms";

       import ietf-inet-types {
           prefix "inet";
           reference "RFC 6991 Section 4";
       }

       import ietf-routing-types {
           prefix "rt-types";
           reference "RFC 8294";
       }

       organization "IETF"; "IETF MBONED (Multicast Backbone
           Deployment) Working Group";

       contact
           "Author:   Jake Holland
                      <mailto:jholland@akamai.com>
           ";

       description
       "Copyright (c) 2019 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
        for full legal notices.

        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 (RFC 2119) (RFC 8174) when, and only when,
        they appear in all capitals, as shown here.

        This module contains the definition for the DORMS data type.
        It provides out of band metadata about SSM channels.";

       revision 2019-08-25 {
           description "Initial revision.";
           reference
             "";
             // "I-D.draft-jholland-mboned-dorms";
               "I-D.draft-ietf-mboned-dorms";
       }

       container metadata {
           description "Metadata scaffold for source-specific multicast
               channels.";
           list sender {
               key source-address;
               description "Sender for DORMS";

               leaf source-address {
                   type inet:ip-address;
                   mandatory true;
                   description
                       "The source IP address of a multicast sender.";
               }

               list group {
                   key group-address;
                   description "Metadata for a DORMS (S,G).";

                   leaf group-address {
                       type rt-types:ip-multicast-group-address;
                       mandatory true;
                       description "The group IP address for an (S,G).";
                   }

                   list udp-stream {
                     key "port";
                     description
                         "Metadata for UDP traffic on a specific port.";
                     leaf port {
                         type inet:port-number;
                         mandatory true;
                         description
                             "The UDP port of a data stream in an (S,G).";
                   }
                 }
             }
         }
     }
 }
 <CODE ENDS>

5.  Privacy data stream.";
                     }
                   }
               }
           }
       }
   }
   <CODE ENDS>

5.  Privacy Considerations

5.1.  Linking Content to Traffic Streams

   In the typical case, the mechanisms defined in this document provide
   a standardized way to discover information that is already available
   in other ways.

   However, depending on the metadata provided by the server, observers
   may be able to more easily associate traffic from an (S,G) with the
   content contained within the (S,G).  At the subscriber edge of a
   multicast-capable network, where the network operator has the
   capability to localize an IGMP [RFC3376] or MLD [RFC3810] channel
   subscription to a specific user or location, for example by MAC
   address or source IP address, the structured publishing of metadata
   may make it easier to automate collection of data about the content a
   receiver is consuming.

5.2.  Linking Multicast Subscribers to Unicast Connections

   Subscription to a multicast channel generally only exposes the IGMP
   or MLD membership report to others on the same LAN, and as the
   membership propagates through a multicast-capable network, it
   ordinarily gets aggregated with other end users.

   However, a RESTCONF connection is a unicast connection, and exposes a
   different set of information to the operator of the RESTCONF server,
   including IP address and timing about the requests made.  Where DORMS
   access becomes required to succeed a multicast join, as expected in a
   browser deployment, this can expose new information about end users
   relative to services based solely on multicast streams.

   In some deployments it may be possible to use a proxy that aggregates
   many end users when the aggregate privacy characteristics are needed
   by end users.

6.  IANA Considerations

5.1.  Linking Content

6.1.  The YANG Module Names Registry

   This document adds one YANG module to Traffic Streams

   In the typical case, "YANG Module Names"
   registry maintained at <https://www.iana.org/assignments/yang-
   parameters>.  The following registrations are made, per the mechanisms defined format in this
   Section 14 of [RFC6020]:

         name:      ietf-dorms
         namespace: urn:ietf:params:xml:ns:yang:ietf-dorms
         prefix:    dorms
         reference: I-D.draft-ietf-mboned-dorms

6.2.  The XML Registry

   This document provide
   a standardized way adds the following registration to discover information that is already available
   in other ways.

   However, depending on the metadata provided by "ns" subregistry
   of the server, observers
   may be able to more easily associate traffic from an (S,G) with "IETF XML Registry" defined in [RFC3688], referencing this
   document.

          URI: urn:ietf:params:xml:ns:yang:ietf-dorms
          Registrant Contact: The IESG.
          XML: N/A, the
   content contained within requested URI is an XML namespace.

6.3.  The Service Name and Transport Protocol Port Number Registry

   This document adds one service name to the (S,G).  At "Service Name and
   Transport Protocol Port Number Registry" maintained at
   <https://www.iana.org/assignments/service-names-port-numbers>.  The
   following registrations are made, per the subscriber edge format in Section 8.1.1 of
   [RFC6335]:

        Service Name:            dorms
        Transport Protocol(s):   TCP, UDP
        Assignee:                IESG <iesg@ietf.org>
        Contact:                 IETF Chair <chair@ietf.org>
        Description:             The DORMS service (RESTCONF that
                                 includes ietf-dorms YANG model)
        Reference:               I-D.draft-ietf-mboned-dorms
        Port Number:             N/A
        Service Code:            N/A
        Known Unauthorized Uses: N/A
        Assignment Notes:        N/A

7.  Security Considerations

7.1.  YANG Model Considerations

   The YANG module specified in this document defines a
   multicast-capable network, where schema for data
   that is designed to be accessed via RESTCONF [RFC8040].  The lowest
   RESTCONF layer is HTTPS, and the network operator has mandatory-to-implement secure
   transport is TLS [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the
   capability means to localize an IGMP [RFC3376] restrict access for particular NETCONF or MLD [RFC3810] channel
   subscription
   RESTCONF users to a specific user preconfigured subset of all available NETCONF or location by MAC address
   RESTCONF protocol operations and content.  DORMS servers MAY use NACM
   to control access to data nodes.

   No data nodes defined in this YANG module are writable, creatable, or source
   IP address, the structured publishing
   deletable.  This YANG module is intended for publication of metadata may make it easier read-only
   data according to automate collection a well-defined schema.

7.2.  Exposure of data about Metadata

   Although some DORMS servers MAY restrict access based on client
   identity, as described in Section 2.5 of [RFC8040], many DORMS
   servers will use the content a receiver is
   consuming.

5.2.  Linking Multicast Subscribers to Unicast Connections

   Subscription ietf-dorms YANG model to a multicast channel generally only exposes publish information
   without restriction, and even DORMS servers requiring client
   authentication will inherently, because of the IGMP
   or MLD membership report purpose of DORMS, be
   providing the DORMS metadata to others on potentially many receivers.

   Accordingly, future YANG modules that augment data paths under "ietf-
   dorms:metadata" MUST NOT include any sensitive data unsuitable for
   public dissemination in those data paths.

   Because of the same LAN, and as possibility that scalable read-only access might be
   necessary to fulfill the
   membership propagates through scalability goals for a multicast-capable network, it
   ordinarily gets aggregated DORMS server, data
   under these paths MAY be cached or replicated by numerous external
   entities, so owners of such data SHOULD NOT assume such data can be
   kept secret when provided by DORMS servers anywhere under the "ietf-
   dorms:metadata" path even if access controls are used with other end users.

   However, a RESTCONF connection is a unicast connection,
   authenticated clients unless additional operational procedures and exposes a
   different set of information to
   restrictions are defined and implemented that can effectively control
   the operator dissemination of the RESTCONF server,
   including IP address secret data.  DORMS alone does not provide
   any such mechanisms, and timing about the requests made.  Where users of DORMS
   access becomes required to succeed a multicast join, as expected in a
   browser deployment, this can expose new information about end users
   relative to services based solely on multicast streams.

   In some deployments it may be possible to use a proxy that aggregates
   many end users when the aggregate privacy characteristics are needed
   by end users.

6.  IANA Considerations

6.1.  The YANG Module Names Registry

   This document adds one YANG module expected not to the "YANG Module Names"
   registry maintained at <https://www.iana.org/assignments/yang-
   parameters>.  The be
   following registrations are made, per the format any such mechanisms in
   Section 14 of [RFC6020]:

         name:      ietf-dorms
         namespace: urn:ietf:params:xml:ns:yang:ietf-dorms
         prefix:    dorms
         reference: I-D.draft-jholland-mboned-dorms

6.2.  The Service Name and Transport Protocol Port Number Registry

   This document adds one service name to the "Service Name and
   Transport Protocol Port Number Registry" maintained at
   <https://www.iana.org/assignments/service-names-port-numbers>. absence of additional
   assurances.

7.3.  Secure Communications

   The
   following registrations are made, per the format in provisions of Section 8.1.1 2 of [RFC8040] provide secure communication
   requirements that are already required of
   [RFC6335]:

     Service Name:            dorms
     Transport Protocol(s):   TCP
     Assignee:                IESG <iesg@ietf.org>
     Contact:                 IETF Chair <chair@ietf.org>
     Description:             This service name is used to construct the
                              SRV service label "_dorms" for discovering DORMS servers.
     Reference:               I-D.draft-jholland-mboned-dorms
     Port Number:             N/A
     Service Code:            N/A
     Known Unauthorized Uses: N/A
     Assignment Notes:        This protocol uses HTTPS as a substrate.

7.  Security Considerations

7.1.  Secure Communications servers, since they
   are RESTCONF servers.  All RESTCONF requirements and security
   considerations remain in force for DORMS servers.

   It is intended that security related metadata about the SSM channels
   will
   such as public keys for use with cryptographic algorithms may be
   delivered over the RESTCONF connection, and that information
   available from this connection can be used as a trust anchor.  The provisions
   secure transport provided by these minimum requirements are relied
   upon to provide authenticated delivery of these trust anchors, once a
   connection with a trusted DORMS server has been established.

7.4.  Record-Spoofing

   When using the DNS Boostrap method of discovery described in
   Section 2 2.1, the SRV resource record contains information that SHOULD
   be communicated to the DORMS client without being modified.  The
   method used to ensure the result was unmodified is up to the client.

   There must be a trust relationship between the end consumer of [RFC8040] provide this
   resource record and the DNS server.  This relationship may be end-to-
   end DNSSEC validation or a secure communication
   requirements connection to a trusted DNS server
   that are already required provides end-to-end safety to prevent record-spoofing of the
   response from the trusted server.  The connection to the trusted
   server can use any secure channel, such as with a TSIG [RFC2845] or
   SIG(0) [RFC2931] channel, a secure local channel on the host, DNS
   over TLS [RFC7858], DNS over HTTPS [RFC8484], or some other mechanism
   that provides authentication of the RR.

   If a DORMS servers, since they
   are RESTCONF servers.  All RESTCONF requirements client accepts a maliciously crafted SRV record, the
   client could connect to a server controlled by the attacker, and security
   considerations remain in force for use
   metadata provided by them.  The consequences of trusting maliciously
   crafted metadata could range from attacks against the DORMS servers.

7.2.  Exposure client's
   parser of Metadata

   Although some the metadata (via malicious constructions of the formatting
   of the data) to arbitrary disruption of the decisions the DORMS servers MAY restrict access based on
   client
   identity, makes as a result of processing validly constructed metadata.

   Clients MAY use other secure methods to explicitly associate an (S,G)
   with a set of DORMS server hostnames, such as a configured mapping or
   an alternative trusted lookup service.

7.5.  CORS considerations

   As described in Section 2.5 of [RFC8040], many 2.3.5, it's RECOMMENDED that DORMS servers will
   provide appropriate restrictions to ensure only authorized web pages
   access metadata for their (S,G)s from the widely deployed base of
   secure browsers that use the ietf-dorms YANG model CORS protocol according to publish information
   without restriction, and even DORMS servers requiring client
   authentication will inherently, because of
   [whatwg-fetch].

   Providing '*' for the purpose of DORMS, be
   providing allowed origins exposes the DORMS DORMS-based
   metadata to potentially many receivers.

   Accordingly, future YANG modules that augment data paths under "ietf-
   dorms:metadata" MUST NOT include any sensitive data unsuitable for
   public dissemination access by scripts in those data paths.  Because of all web pages, which opens the
   possibility of certain kinds of attacks against networks where
   browsers have support for joining multicast (S,G)s.

   If the authentication for an (S,G) relies on DORMS-based metadata
   (for example, as defined in [I-D.draft-ietf-mboned-ambi-00]), an
   unauthorized web page that scalable read-only access might be necessary tries to fulfill join an (S,G) not permitted by
   the
   scalability goals CORS headers for a the DORMS server, data under these paths MAY be
   cached or replicated by numerous external entities, so owners of such
   data SHOULD NOT assume it can server will be kept secret when provided by DORMS
   servers anywhere under prevented from
   subscribing to the "ietf-dorms:metadata" path, even if they
   are authenticating clients.

7.3.  DNS Bootstrapping

   The DNS bootstrap phase relies channels.

   If an unauthorized site is not prevented from subscribing, code on DNS for
   the reverse IP tree.  When
   using DNS to discover a DORMS server's domain name, there must be site (for example a
   trust relationship between malicious advertisement) could request
   subscriptions from many different (S,G)s, overflowing limits on the end consumer
   joining of this resource record (S,G)s and disrupting the DNS server.  This relationship may be end-to-end DNSSEC
   validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel delivery of multicast traffic
   for legitimate use.

   Further, if the malicious script can be distributed to another
   secure source, many different
   users within the same receiving network, the script could coordinate
   an attack against the network as a secure local channel on whole by joining disjoint sets of
   (S,G)s from different users within the host, DNS over TLS
   [RFC7858] or HTTPS [RFC8484], or some other secure mechanism.

   If receiving network.  The
   distributed subscription requests across the SRV Resource Record cannot be authenticated, it may be
   possible receiving network could
   overflow limits for an attacker who can spoof the resource record to perform receiving network as a denial whole, essentially
   causing the websites displaying the ad to participate in an
   overjoining attack (see Appendix A of service
   [I-D.draft-ietf-mboned-cbacc-00]).

   Even if network safety mechanisms protect the network from the worst
   effects of oversubscription, the population counts for the receiver multicast
   subscriptions could be disrupted by providing wrong or missing
   authentication metadata.  An attacker who can also inject this kind of attack, and
   therefore push out legitimately requested traffic for
   (S,G)s, that's being
   consumed by real users.  For a legitimately popular event, this could
   cause a widespread disruption to the service if it's successfully
   pushed out.

   A denial of service attack of this sort would also be able thwarted by
   restricting the access to provide false content in (S,G)s to authorized websites through the data
   stream, so an attacker who can perform both could provide
   authenticated false content by authenticating with a trust anchor
   from an attacker-controlled DORMS server.

   Clients MAY
   use other secure methods to explicitly associate an (S,G)
   with a set of DORMS server hostnames, such as a configured mapping or
   an alternative trusted lookup service. properly restricted CORS headers.

8.  Acknowledgements

   Thanks to Christian Worm Mortensen Mortensen, Dino Farinacci, and Lenny
   Guiliano for some their very helpful comments and
   review. reviews.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8294]  Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
              "Common YANG Data Types for the Routing Area", RFC 8294,
              DOI 10.17487/RFC8294, December 2017,
              <https://www.rfc-editor.org/info/rfc8294>.

   [W3C.REC-cors-20140116]
              Kesteren, A., "Cross-Origin Resource Sharing", World Wide
              Web Consortium Recommendation REC-cors-20140116, January
              2014, <http://www.w3.org/TR/2014/REC-cors-20140116>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [whatwg-fetch]
              "WHATWG Fetch Living Standard", October 2020,
              <https://fetch.spec.whatwg.org/>.

9.2.  Informative References

   [I-D.draft-jholland-cb-assisted-cc-01]

   [I-D.draft-ietf-mboned-ambi-00]
              Holland, J. and K. Rose, "Asymmetric Manifest Based
              Integrity", draft-ietf-mboned-ambi-00 (work in progress),
              March 2020.

   [I-D.draft-ietf-mboned-cbacc-00]
              Holland, J., "Circuit Breaker Assisted Congestion Control
              (CBACC): Protocol Specification", draft-jholland-cb-
              assisted-cc-01
              Control", draft-ietf-mboned-cbacc-00 (work in progress), April 2017.
              March 2020.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <https://www.rfc-editor.org/info/rfc2845>.

   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
              2000, <https://www.rfc-editor.org/info/rfc2931>.

   [RFC3040]  Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040,
              DOI 10.17487/RFC3040, January 2001,
              <https://www.rfc-editor.org/info/rfc3040>.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
              <https://www.rfc-editor.org/info/rfc3376>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
              August 2006, <https://www.rfc-editor.org/info/rfc4604>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/info/rfc4607>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [RFC6415]  Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
              RFC 6415, DOI 10.17487/RFC6415, October 2011,
              <https://www.rfc-editor.org/info/rfc6415>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [whatwg-fetch]
              Kesteren, A., "WHATWG Fetch Living Standard", August 2019,
              <https://fetch.spec.whatwg.org/>.

Author's Address

   Jake Holland
   Akamai Technologies, Inc.
   150 Broadway
   Cambridge, MA 02144
   United States of America

   Email: jakeholland.net@gmail.com