[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Mboned                                                        J. Holland
Internet-Draft                                 Akamai Technologies, Inc.
Intended status: Standards Track                         August 27, 2019
Expires: February 28, 2020


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

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 February 28, 2020.

Copyright Notice

   Copyright (c) 2019 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



Holland                 Expires February 28, 2020               [Page 1]


Internet-Draft                    DORMS                      August 2019


   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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Discovery and Metdata Retrieval . . . . . . . . . . . . . . .   4
     2.1.  DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  RESTCONF Bootstrap  . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Root Resource Discovery . . . . . . . . . . . . . . .   5
       2.2.2.  Yang Library Version  . . . . . . . . . . . . . . . .   6
       2.2.3.  Yang Library Contents . . . . . . . . . . . . . . . .   6
       2.2.4.  Metadata Retrieval  . . . . . . . . . . . . . . . . .   7
   3.  Scalability Considerations  . . . . . . . . . . . . . . . . .   8
     3.1.  Provisioning  . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Data Scoping  . . . . . . . . . . . . . . . . . . . . . .   9
   4.  YANG Model  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Yang Tree . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Yang Module . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  The YANG Module Names Registry  . . . . . . . . . . . . .  12
     6.2.  The Service Name and Transport Protocol Port Number
           Registry  . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     7.1.  Secure Communications . . . . . . . . . . . . . . . . . .  13
     7.2.  Exposure of Metadata  . . . . . . . . . . . . . . . . . .  13
     7.3.  DNS Bootstrapping . . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

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.




Holland                 Expires February 28, 2020               [Page 2]


Internet-Draft                    DORMS                      August 2019


   This document defines the "dorms" service name for use with the SRV
   DNS Resource Record (RR) type [RFC2782].  A sender offering 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 multicast channel to advertise a hostname for a DORMS
   server that can provide metadata for the sender's source-specific
   multicast traffic.  Doing so enables receivers and middleboxes 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.                                |
   |        |                                                          |
   |     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



Holland                 Expires February 28, 2020               [Page 3]


Internet-Draft                    DORMS                      August 2019


   "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 that needs metadata about a (S,G) MAY attempt to discover
   metadata for the (S,G) using the mechanisms defined here, and MAY use
   the metadata received to manage the forwarding or processing of the
   packets in the channel.

2.1.  DNS Bootstrap

   The DNS Bootstrap step is how a client discovers an appropriate
   RESTCONF server, given the source address of an (S,G).  Use of the
   DNS Bootstrap is OPTIONAL for clients with an alternate method of
   obtaining a RESTCONF hostname for a DORMS server with metadata for an
   (S,G).

   This mechanism only works for source-specific multicast (SSM)
   channels.  The source address of the (S,G) is reversed and used as an
   index into one of the reverse mapping trees (in-addr.arpa for IPv4,
   as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as
   described in Section 2.5 of [RFC3596]).

   When a receiver or middle box needs metadata for an (S,G), for
   example when handling a new join for that (S,G) and looking up
   authentication methods available, a receiver or middlebox can issue a
   DNS query for a SRV RR using the "dorms" service name with the domain
   from the reverse mapping tree, combining them as described in
   [RFC2782].

   For example, while handling a 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 domain might return a record such as:

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

   This response informs the receiver that a DORMS server SHOULD be
   reachable at dorms-restconf.example.com 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 for each source address of the
   multicast channels it is sending, in order to advertise the hostname



Holland                 Expires February 28, 2020               [Page 4]


Internet-Draft                    DORMS                      August 2019


   of the DORMS server 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 that have metadata published with
   DORMS.

2.2.  RESTCONF Bootstrap

   Once a DORMS host has been chosen (whether via an SRV RR from a DNS
   response or via some other method), RESTCONF provides all the
   information necessary to determine the versions and url paths for
   metadata from the server.  A walkthrough is provided here for a
   sequence of example requests and responses from a receiver connecting
   to a new 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 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

   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"
             }
           ]
         }







Holland                 Expires February 28, 2020               [Page 5]


Internet-Draft                    DORMS                      August 2019


2.2.2.  Yang Library Version

   As described in Section 3.3.3 of [RFC8040], the yang-library-version
   leaf is required by RESTCONF, and can be used to determine the 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"
         }

   TBD: We might need a method for learning a specific restconf server
   or resource path that supports a version the client knows how to use,
   in the case the client is older than the server after a new yang-
   library version is released...  Can this be just retry with a hold-
   down on specific hostnames, so that you can find a lower priority
   older server from the SRV records, or is signaling that can find or
   negotiate an explicit version as part of the lookup going to be
   necessary? -jake 2019-08-26

2.2.3.  Yang Library Contents

   After checking that the version of the yang-library module will be
   understood by the receiver, the client can check that the desired
   metadata module is available on the DORMS server by fetching the
   module-state resource from the ietf-yang-library module.

   Example:

   The receiver might send:






Holland                 Expires February 28, 2020               [Page 6]


Internet-Draft                    DORMS                      August 2019


         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 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 desired by the client also can be checked
   in a similar way, or the full set of available modules can be
   retrieved by not providing a key for the "module" list.

2.2.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:






Holland                 Expires February 28, 2020               [Page 7]


Internet-Draft                    DORMS                      August 2019


         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.

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.





Holland                 Expires February 28, 2020               [Page 8]


Internet-Draft                    DORMS                      August 2019


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.  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 use cases include providing authentication information and bit-
   rate information for use by receivers and middle boxes, but more use
   cases are anticipated.

4.1.  Yang Tree

   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@2019-08-28.yang
 module ietf-dorms {
     yang-version 1.1;



Holland                 Expires February 28, 2020               [Page 9]


Internet-Draft                    DORMS                      August 2019


     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";

     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
             "";



Holland                 Expires February 28, 2020              [Page 10]


Internet-Draft                    DORMS                      August 2019


             // "I-D.draft-jholland-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>








Holland                 Expires February 28, 2020              [Page 11]


Internet-Draft                    DORMS                      August 2019


5.  Privacy Considerations

   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 a IGMP [RFC3376] or MLD [RFC3810] channel
   subscription to a specific user or location 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.

   RESTCONF communication will expose to the controller of the RESTCONF
   server information about the consumers of content that is not
   otherwise available from multicast subscription to a channel, such as
   the remote IP address and timing information.

6.  IANA Considerations

6.1.  The YANG Module Names Registry

   This document adds one YANG module to the "YANG Module Names"
   registry maintained at <https://www.iana.org/assignments/yang-
   parameters>.  The following registrations are made, per the format 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>.  The
   following registrations are made, per the format in Section 8.1.1 of
   [RFC6335]:









Holland                 Expires February 28, 2020              [Page 12]


Internet-Draft                    DORMS                      August 2019


     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

   It is intended that security related metadata about the SSM channels
   will be delivered over the RESTCONF connection, and that information
   available from this connection can be used as a trust anchor.

   The provisions of Section 2 of [RFC8040] provide secure communication
   requirements that are already required of DORMS servers, since they
   are RESTCONF servers.  All RESTCONF requirements and security
   considerations remain in force for DORMS servers.

7.2.  Exposure of 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 ietf-dorms YANG model to publish information
   without restriction, and even DORMS servers requiring client
   authentication will inherently, because of the purpose of DORMS, be
   providing the DORMS 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 in those data paths.  Because of the possibility
   that scalable read-only access might be necessary to fulfill the
   scalability goals for a 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 be kept secret when provided by DORMS
   servers anywhere under the "ietf-dorms:metadata" path, even if they
   are authenticating clients.







Holland                 Expires February 28, 2020              [Page 13]


Internet-Draft                    DORMS                      August 2019


7.3.  DNS Bootstrapping

   The DNS bootstrap phase relies on DNS for the reverse IP tree.  When
   using DNS to discover a DORMS server's domain name, there must be a
   trust relationship between the end consumer of this resource record
   and the DNS server.  This relationship may be end-to-end DNSSEC
   validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another
   secure source, a secure local channel on the host, DNS over TLS
   [RFC7858] or HTTPS [RFC8484], or some other secure mechanism.

   If the SRV Resource Record cannot be authenticated, it may be
   possible for an attacker who can spoof the resource record to perform
   a denial of service for the receiver by providing wrong or missing
   authentication metadata.  An attacker who can also inject traffic for
   (S,G)s, would also be able to provide false content in 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.

   TBD: do we need CORS [whatwg-fetch] on the DORMS server?  Perhaps in
   a new URI path, or maybe on /.well-known/host-meta?  (Suppose evil
   Javascript joins someone else's stream, providing a correct DORMS
   hostname-should DORMS get an Origin header and have the option to
   block?)

8.  Acknowledgements

   Thanks to Christian Mortensen for some very helpful comments and
   review.

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>.




Holland                 Expires February 28, 2020              [Page 14]


Internet-Draft                    DORMS                      August 2019


   [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>.

9.2.  Informative References

   [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>.







Holland                 Expires February 28, 2020              [Page 15]


Internet-Draft                    DORMS                      August 2019


   [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>.

   [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>.






Holland                 Expires February 28, 2020              [Page 16]


Internet-Draft                    DORMS                      August 2019


   [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


































Holland                 Expires February 28, 2020              [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/