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

Mboned                                                        J. Holland
Internet-Draft                                                   K. Rose
Intended status: Standards Track               Akamai Technologies, Inc.
Expires: 20 April 2026                                         M. Franke
                                                               TU Berlin
                                                         17 October 2025

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

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 20 April 2026.

Copyright Notice

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

Holland, et al.           Expires 20 April 2026                 [Page 1]
Internet-Draft                    DORMS                     October 2025

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Motivation and Use Cases  . . . . . . . . . . . . . . . .   4
       1.3.1.  Provisioning and Oversubscription Protection  . . . .   5
       1.3.2.  Authentication  . . . . . . . . . . . . . . . . . . .   5
       1.3.3.  Content Description . . . . . . . . . . . . . . . . .   5
     1.4.  Notes for Contributors and Reviewers  . . . . . . . . . .   5
       1.4.1.  Venues for Contribution and Discussion  . . . . . . .   6
   2.  Discovery and Metadata Retrieval  . . . . . . . . . . . . . .   6
     2.1.  Channel Discovery . . . . . . . . . . . . . . . . . . . .   6
     2.2.  DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  RESTCONF Bootstrap  . . . . . . . . . . . . . . . . . . .   8
       2.3.1.  Root Resource Discovery . . . . . . . . . . . . . . .   8
       2.3.2.  YANG Library Version  . . . . . . . . . . . . . . . .   9
       2.3.3.  YANG Library Contents . . . . . . . . . . . . . . . .  10
       2.3.4.  Metadata Retrieval  . . . . . . . . . . . . . . . . .  11
       2.3.5.  Cross Origin Resource Sharing (CORS)  . . . . . . . .  12
   3.  YANG Model  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  YANG Tree . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.2.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     4.1.  YANG Model Considerations . . . . . . . . . . . . . . . .  12
     4.2.  Exposure of Metadata  . . . . . . . . . . . . . . . . . .  14
     4.3.  Secure Communications . . . . . . . . . . . . . . . . . .  14
     4.4.  Record-Spoofing . . . . . . . . . . . . . . . . . . . . .  15
     4.5.  CORS considerations . . . . . . . . . . . . . . . . . . .  15
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
     5.1.  Linking Content to Traffic Streams  . . . . . . . . . . .  16
     5.2.  Linking Multicast Subscribers to Unicast Connections  . .  17
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  17
     6.1.  Provisioning  . . . . . . . . . . . . . . . . . . . . . .  17
     6.2.  Data Scoping  . . . . . . . . . . . . . . . . . . . . . .  18
     6.3.  Ignore List . . . . . . . . . . . . . . . . . . . . . . .  18
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  The YANG Module Names Registry  . . . . . . . . . . . . .  19
     7.2.  The XML Registry  . . . . . . . . . . . . . . . . . . . .  19
     7.3.  The Service Name and Transport Protocol Port Number
           Registry  . . . . . . . . . . . . . . . . . . . . . . . .  19
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20

Holland, et al.           Expires 20 April 2026                 [Page 2]
Internet-Draft                    DORMS                     October 2025

     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  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 3.  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 does not prohibit the use of the "ietf-dorms" model
   with other protocols such as NETCONF [RFC6241], CORECONF
   [I-D.draft-ietf-core-comi], or gNMI
   [I-D.draft-openconfig-rtgwg-gnmi-spec], but the semantics of using
   the model over those protocols is out of scope for this document.
   This document only defines the discovery and use of the "ietf-dorms"
   YANG model in RESTCONF.

   This document defines the "dorms" service name for use with the SRV
   DNS Resource Record (RR) type [RFC2782].  A sender 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 used by some active multicast traffic.  The domain name in one of
   these SRV records provides a hostname corresponding to a DORMS server
   that can provide metadata for the sender's source-specific multicast
   traffic.  Publishing such a RR enables DORMS clients to discover and
   query a DORMS server as described in Section 2.

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 [RFC9776] and MLDv2 [RFC9777] for
   group management of source-specific multicast channels, as described
   in [RFC4604].

Holland, et al.           Expires 20 April 2026                 [Page 3]
Internet-Draft                    DORMS                     October 2025

   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   |
       | client | with DORMS servers to fetch metadata about      |
       |        | (S,G)s.                                         |
       +--------+-------------------------------------------------+
       |  DORMS | A RESTCONF server that implements the ietf-     |
       | server | dorms YANG 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]                                       |
       +--------+-------------------------------------------------+

                                 Table 1

   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.

1.3.  Motivation and Use Cases

   DORMS provides a framework that can be extended to publish
   supplemental information about multicast traffic in a globally
   discoverable manner.  This supplemental information may be needed by
   entities involved in the delivery or processing of the traffic to
   ensure it is handled in accordance with their operational or policy
   requirements.

Holland, et al.           Expires 20 April 2026                 [Page 4]
Internet-Draft                    DORMS                     October 2025

   Detailing the specifics of all known possible extensions is out of
   scope for this document except to note that a range of possible use
   cases are expected and they may be supported by a variety of
   different future extensions.  But a few example use cases are
   provided below for illustration.

1.3.1.  Provisioning and Oversubscription Protection

   One use case for DORMS is when a network that is capable of
   forwarding multicast traffic may need to take provisioning actions or
   make admission control decisions based on the expected bitrate of the
   traffic in order to prevent oversubscription of constrained devices
   in the network.  In such a case, the network in question could learn
   these bitrates from the metadata provided by DORMS.
   [I-D.draft-ietf-mboned-cbacc] defines some DORMS extensions to
   support this use case.

1.3.2.  Authentication

   Another use case for DORMS is providing information for use in
   authenticating the multicast traffic before accepting it for
   forwarding by a network device, or for processing by a receiving
   application.  As DORMS metadata is transmitted over a secure and
   authenticated connection, it can act as a security anchor for data
   required to verify the authenticity of multicast packets.
   [I-D.draft-ietf-mboned-ambi] defines some DORMS extensions to support
   this use case.

1.3.3.  Content Description

   Another use case for DORMS is describing the contents carried by a
   multicast traffic channel.  The content description could include
   information about the protocols or applications that can be used to
   consume the traffic, or information about the media carried (e.g.
   information based on the Dublin Core Metadata Element Set [RFC5013]),
   or could make assertions about the legal status of the traffic within
   specific contexts.

1.4.  Notes for Contributors and Reviewers

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

   This section is to provide references to make it easier to review the
   development and discussion on the draft so far.

Holland, et al.           Expires 20 April 2026                 [Page 5]
Internet-Draft                    DORMS                     October 2025

1.4.1.  Venues for Contribution and Discussion

   This document is in the Github repository at:

   https://github.com/GrumpyOldTroll/ietf-dorms-cluster

   Readers are welcome to 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 Note Well
   before contributing: https://datatracker.ietf.org/submit/note-well/

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

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

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

2.  Discovery and Metadata 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 received to manage the forwarding or processing of the
   packets in the channel.

2.1.  Channel Discovery

   DORMS provides a method for clients to fetch metadata about (S,G)s
   that are already known to the clients.  In general, a DORMS client
   might learn of an (S,G) by any means, so describing all possible
   methods a DORMS client might use to discover a set of (S,G)s for
   which it wants metadata is out of scope for this document.

   But for example, a multicast receiver application that is a DORMS
   client might learn about an (S,G) by getting signals from inside the
   application logic, such as a selection made by a user, or a scheduled
   API call that reacts to updates in a library provided by a service
   operator.

   As another example, an on-path router that’s a DORMS client might
   instead learn about an (S,G) by receiving a PIM message or an IGMP or
   MLD membership report indicating a downstream client has tried to
   subscribe to an (S,G).  Such a router might use information learned
   from the DORMS metadata to make an access control decision about
   whether to propagate the join further upstream in the network.

Holland, et al.           Expires 20 April 2026                 [Page 6]
Internet-Draft                    DORMS                     October 2025

   Other approaches for learning relevant (S,G)s could be driven by
   monitoring a route reflector to discover channels that are being
   actively forwarded, for a purpose such as monitoring network health.

2.2.  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 hostname of a trusted DORMS server that has information
   about a target (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 DORMS client needs metadata for an (S,G), for example when
   handling a new join for that (S,G) and looking up the authentication
   methods that are available, the DORMS client can issue a DNS query
   for an SRV RR using the "dorms" service name with the domain from the
   reverse mapping tree, combining them as described in [RFC2782].

   For example, a client looking for metadata about the channel with a
   source IP of 2001:db8::a and the group address of ff3e::8000:d, the
   client would start the DNS bootstrap step by performing a query for
   the SRV RRType for the following domain (after removing the line
   break inserted for editorial reasons):

        _dorms._tcp.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
                    0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

   Or for an IPv4 (S,G) with a source address of 203.0.113.4, the DORMS
   client would request the SRV record from the in-addr.arpa tree
   instead:

        _dorms._tcp.4.113.0.203.in-addr.arpa.

   In either case, the DNS response for this domain might return a
   record such as this:

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

   This response informs the client that a 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 are handled as described by [RFC2782].

Holland, et al.           Expires 20 April 2026                 [Page 7]
Internet-Draft                    DORMS                     October 2025

   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
   of the DORMS server to DORMS clients.  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.

   When performing the SRV lookup, any CNAMEs or DNAMEs found MUST be
   followed.  This is necessary to support zone delegation.  Some
   examples outlining this need are described in [RFC2317].

2.3.  RESTCONF Bootstrap

   Once a DORMS server 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 between a DORMS client and
   a new DORMS server.

2.3.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 client 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:

Holland, et al.           Expires 20 April 2026                 [Page 8]
Internet-Draft                    DORMS                     October 2025

         HTTP/1.1 200 OK
         Date: Tue, 09 Jul 2025 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 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 client 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, 09 Jul 2025 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 DORMS client determines through examination of the yang-library-
   version that it may not understand the responses of the server due to
   a version mismatch, the server qualifies as a candidate for adding to
   an ignore list as described in Section 6.3.

Holland, et al.           Expires 20 April 2026                 [Page 9]
Internet-Draft                    DORMS                     October 2025

2.3.3.  YANG Library Contents

   After checking that it supports the version of the yang-library
   module offered by the server, the client can check that the desired
   metadata modules are available on the DORMS server by fetching the
   module-state resource from the ietf-yang-library module.

   Example:

   The client might send:

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

   The server might respond as follows:

       HTTP/1.1 200 OK
       Date: Tue, 09 Jul 2025 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": "2025-09-15",
             "schema":
                 "https://example.com/yang/ietf-dorms@2025-09-15.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.  If a DORMS
   client that requires the presence of certain modules to perform its
   function discovers the required modules are not present on a server,
   that server qualifies for inclusion in an ignore list according to
   Section 6.3.

Holland, et al.           Expires 20 April 2026                [Page 10]
Internet-Draft                    DORMS                     October 2025

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 client might send:

         GET /top/restconf/data/ietf-dorms:dorms/metadata/\
             sender=2001:db8::a/group=ff3e::8000:1
         Host: dorms-restconf.example.com
         Accept: application/yang-data+json

   The server might respond as follows:

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

         {
           "ietf-dorms:group": [
             {
               "group-address":"ff3e::8000: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 6.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.

Holland, et al.           Expires 20 April 2026                [Page 11]
Internet-Draft                    DORMS                     October 2025

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 publicly
   reachable DORMS servers.  A review of some of the potential
   consequences of unrestricted CORS access is given in Section 4.5.

3.  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.  See
   Section 1.3 for some example use cases that can be enabled by the use
   of DORMS extensions.

3.1.  YANG Tree

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

   YANG-TREE ietf-dorms.yang

                        Figure 1: DORMS Tree Diagram

3.2.  YANG Module

   YANG-MODULE ietf-dorms.yang

4.  Security Considerations

4.1.  YANG Model Considerations

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

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations to these data nodes
   (e.g., via HTTP POST/PUT/PATCH/DELETE methods) without proper
   protection can have a negative effect on network operations.  These
   are the subtrees and data nodes and their sensitivity/vulnerability:

   Subtrees:

Holland, et al.           Expires 20 April 2026                [Page 12]
Internet-Draft                    DORMS                     October 2025

   *  /dorms/metadata

   *  /dorms/metadata/sender

   *  /dorms/metadata/sender/group

   *  /dorms/metadata/sender/group/udp-stream

   Data nodes:

   *  /dorms/metadata/sender/source-address

   *  /dorms/metadata/sender/group/group-address

   *  /dorms/metadata/sender/group/udp-stream/port

   These data nodes refer to the characteristics of a stream of data
   packets being sent on a multicast channel.  If an unauthorized or
   incorrect edit is made, receivers would no longer be able to
   associate the data stream to the correct metadata, resulting in a
   denial-of-service for end users that rely on the metadata to properly
   process the data packets.  Therefore, DORMS servers MUST constrain
   write access to ensure that unauthorized users cannot edit the data
   published by the server.

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.  DORMS servers SHOULD use
   NACM to constrain write accesses if NETCONF or RESTCONF are
   configured to offer any write access at all.

   However, note that scalability considerations described in
   Section 6.1 might make the naive use of NACM intractable in many
   deployments, for a broadcast use case.  So alternative methods to
   constrain write access to the metadata MAY be used instead of or in
   addition to NACM.  For example, some deployments that use a CDN or
   caching layer of discoverable DORMS servers might uniformly provide
   read-only access through the caching layer, and require the trusted
   writers of configuration to use an alternate method for accessing the
   underlying database such as connecting directly to the origin, or
   requiring the use of a non-RESTCONF mechanism (such as an HTTPS API
   requiring some kind of client authentication) for editing the
   contents of the metadata.

   The data nodes defined in this YANG module are writable because some
   deployments might manage the contents in the database by using normal
   RESTCONF editing operations with NACM, but in typical deployments it

Holland, et al.           Expires 20 April 2026                [Page 13]
Internet-Draft                    DORMS                     October 2025

   is expected that DORMS clients will generally have read-only access.
   For the reasons and requirements described in Section 4.2, none of
   the data nodes in the DORMS module or its extensions contain
   sensitive data.

   DORMS servers MAY provide read-only access to clients for publicly
   available metadata without authenticating the clients.  That is,
   under the terms in Section 2.5 of [RFC8040] read-only access to
   publicly available data MAY be treated as unprotected resources.

4.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 be providing the DORMS metadata to a
   multitude of multicast receivers acting as DORMS clients.

   Accordingly, future YANG modules that augment data paths under "ietf-
   dorms:dorms" 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 such data can be
   kept secret when provided by DORMS servers anywhere under the "ietf-
   dorms:dorms" path even if access controls are used with authenticated
   clients unless additional operational procedures and restrictions are
   defined and implemented that can effectively control the
   dissemination of the secret data.  DORMS alone does not provide any
   such mechanisms, and users of DORMS can be expected not to be
   following any such mechanisms in the absence of additional
   assurances.

4.3.  Secure Communications

   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.

Holland, et al.           Expires 20 April 2026                [Page 14]
Internet-Draft                    DORMS                     October 2025

   It is intended that security-related metadata about the SSM channels
   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
   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.

4.4.  Record-Spoofing

   When using the DNS Bootstrap method of discovery described in
   Section 2.2, the SRV resource record contains information that MUST
   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 this
   resource record and the DNS server.  This relationship may be end-to-
   end DNSSEC validation or a secure connection to a trusted resolver
   that itself makes use of mechanisms for ensuring RR integrity (e.g.,
   by enforcing DNSSEC validation on recursive requests) to prevent
   record-spoofing of the response from the trusted server.  The
   connection to this trusted resolver can use any secure channel, such
   as with a TSIG [RFC8945] or SIG(0) [RFC2931] channel, a secure local
   channel on the host, DNS over TLS [RFC7858], or DNS over HTTPS
   [RFC8484].  Any combination of mechanisms may be employed that
   together guarantee end-to-end integrity of the intended RR.

   If a DORMS client accepts a maliciously crafted SRV record, the
   client could connect to a server controlled by the attacker, and use
   metadata provided by them.  The consequences of trusting maliciously
   crafted metadata could range from attacks against the DORMS client's
   parser of the metadata (via malicious constructions of the formatting
   of the data) to arbitrary disruption of the decisions the DORMS
   client 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.

4.5.  CORS considerations

   As described in Section 2.3.5, it is RECOMMENDED that DORMS servers
   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 CORS protocol according to
   [whatwg-fetch].

Holland, et al.           Expires 20 April 2026                [Page 15]
Internet-Draft                    DORMS                     October 2025

   Providing '*' for the allowed origins exposes the DORMS-based
   metadata to access by scripts in 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]), an
   unauthorized web page that tries to join an (S,G) not permitted by
   the CORS headers for the DORMS server will be prevented from
   subscribing to the channels.

   If an unauthorized site is not prevented from subscribing, code on
   the site (for example a malicious advertisement) could request
   subscriptions from many different (S,G)s, overflowing limits on the
   joining of (S,G)s and disrupting the delivery of multicast traffic
   for legitimate use.

   Further, if the malicious script can be distributed to many different
   users within the same receiving network, the script could coordinate
   an attack against the network as a whole by joining disjoint sets of
   (S,G)s from different users within the receiving network.  The
   distributed subscription requests across the receiving network could
   overflow limits for the receiving network as a whole, essentially
   causing the websites displaying the ad to participate in an
   overjoining attack (see Appendix A of [I-D.draft-ietf-mboned-cbacc]).

   Even if network safety mechanisms protect the network from the worst
   effects of oversubscription, the population counts for the multicast
   subscriptions could be disrupted by this kind of attack, and
   therefore push out legitimately requested traffic that's being
   consumed by real users.  For a legitimately popular event, this could
   cause a widespread disruption to the service if it is successfully
   pushed out.

   A denial-of-service attack of this sort would be thwarted by
   restricting the access to (S,G)s to authorized websites through the
   use of properly restricted CORS headers.

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.

Holland, et al.           Expires 20 April 2026                [Page 16]
Internet-Draft                    DORMS                     October 2025

   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 [RFC9776] or MLD [RFC9777] 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 for a successful multicast join (for example,
   as expected in a browser deployment), this can expose new information
   about end users relative to services based solely on multicast
   streams.  The information disclosure occurs by giving the DORMS
   service operator information about the client's IP and the channels
   the client queried.  Additionally, an on-path observer may infer
   multicast subscription intent by observing client traffic directed to
   a known DORMS server.

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

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

Holland, et al.           Expires 20 April 2026                [Page 17]
Internet-Draft                    DORMS                     October 2025

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

6.2.  Data Scoping

   Except as outlined below, 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 that possess out-of-band knowledge about the
   expected content scope MAY issue (S,G) metadata requests that are
   filtered only by the source address, or that are unfiltered
   altogether.  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.  In general, engaging in this behavior requires
   some administrative configuration or some optimization heuristics
   that can recover from unexpected results.

   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.

6.3.  Ignore List

   If a DORMS client reaches a DORMS server but determines through
   examination of responses from that DORMS server that it may not
   understand or be able to use the responses of the server (for example
   due to an issue like a version mismatch or modules that are missing
   but are required for the DORMS client's purposes), the client MAY add
   this server to an ignore list and reject servers in its ignore list
   during future discovery attempts.

Holland, et al.           Expires 20 April 2026                [Page 18]
Internet-Draft                    DORMS                     October 2025

   A client using the DNS Bootstrap discovery method in Section 2.2
   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 end up selecting a server 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 ignore list is maintained, entries SHOULD time out and allow
   for re-checking after a configurable hold-down time that has a
   default value no shorter than 1 hour and no longer than 24 hours.

7.  IANA Considerations

7.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-ietf-mboned-dorms

7.2.  The XML Registry

   This document adds the following registration to the "ns" subregistry
   of the "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 requested URI is an XML namespace.

7.3.  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, et al.           Expires 20 April 2026                [Page 19]
Internet-Draft                    DORMS                     October 2025

        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

8.  Acknowledgements

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

   Part of this work was supported by the Federal Ministry of Research,
   Technology and Space in the programme of “Souverän.  Digital.
   Vernetzt.” Joint project 6G-RIC, project identification number:
   16KISK030.

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/rfc/rfc2119>.

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317,
              DOI 10.17487/RFC2317, March 1998,
              <https://www.rfc-editor.org/rfc/rfc2317>.

   [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/rfc/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/rfc/rfc3596>.

Holland, et al.           Expires 20 April 2026                [Page 20]
Internet-Draft                    DORMS                     October 2025

   [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/rfc/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

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

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/rfc/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/rfc/rfc8174>.

   [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/rfc/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/rfc/rfc8341>.

   [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/rfc/rfc8446>.

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

9.2.  Informative References

   [I-D.draft-ietf-core-comi]
              Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
              and C. Bormann, "CoAP Management Interface (CORECONF)",
              Work in Progress, Internet-Draft, draft-ietf-core-comi-20,
              6 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-core-comi-20>.

Holland, et al.           Expires 20 April 2026                [Page 21]
Internet-Draft                    DORMS                     October 2025

   [I-D.draft-ietf-mboned-ambi]
              Holland, J., Rose, K., and M. Franke, "Asymmetric Manifest
              Based Integrity", Work in Progress, Internet-Draft, draft-
              ietf-mboned-ambi-05, 17 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-
              ambi-05>.

   [I-D.draft-ietf-mboned-cbacc]
              Holland, J., Rose, K., and M. Franke, "Circuit Breaker
              Assisted Congestion Control", Work in Progress, Internet-
              Draft, draft-ietf-mboned-cbacc-06, 17 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-
              cbacc-06>.

   [I-D.draft-openconfig-rtgwg-gnmi-spec]
              Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack,
              C., and C. Morrow, "gRPC Network Management Interface
              (gNMI)", Work in Progress, Internet-Draft, draft-
              openconfig-rtgwg-gnmi-spec-01, 5 March 2018,
              <https://datatracker.ietf.org/doc/html/draft-openconfig-
              rtgwg-gnmi-spec-01>.

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

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

   [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/rfc/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/rfc/rfc3040>.

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

   [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/rfc/rfc4604>.

Holland, et al.           Expires 20 April 2026                [Page 22]
Internet-Draft                    DORMS                     October 2025

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

   [RFC5013]  Kunze, J. and T. Baker, "The Dublin Core Metadata Element
              Set", RFC 5013, DOI 10.17487/RFC5013, August 2007,
              <https://www.rfc-editor.org/rfc/rfc5013>.

   [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/rfc/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/rfc/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/rfc/rfc7858>.

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

   [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
              Gudmundsson, O., and B. Wellington, "Secret Key
              Transaction Authentication for DNS (TSIG)", STD 93,
              RFC 8945, DOI 10.17487/RFC8945, November 2020,
              <https://www.rfc-editor.org/rfc/rfc8945>.

   [RFC9776]  Haberman, B., Ed., "Internet Group Management Protocol,
              Version 3", STD 100, RFC 9776, DOI 10.17487/RFC9776, March
              2025, <https://www.rfc-editor.org/rfc/rfc9776>.

   [RFC9777]  Haberman, B., Ed., "Multicast Listener Discovery Version 2
              (MLDv2) for IPv6", STD 101, RFC 9777,
              DOI 10.17487/RFC9777, March 2025,
              <https://www.rfc-editor.org/rfc/rfc9777>.

Authors' Addresses

Holland, et al.           Expires 20 April 2026                [Page 23]
Internet-Draft                    DORMS                     October 2025

   Jake Holland
   Akamai Technologies, Inc.
   145 Broadway
   Cambridge, MA 02144,
   United States of America
   Email: jakeholland.net@gmail.com

   Kyle Rose
   Akamai Technologies, Inc.
   145 Broadway
   Cambridge, MA 02144,
   United States of America
   Email: krose@krose.org

   Max Franke
   TU Berlin
   Germany
   Email: mfranke@inet.tu-berlin.de

Holland, et al.           Expires 20 April 2026                [Page 24]