idnits 2.17.1 draft-jholland-mboned-dorms-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 411 has weird spacing: '...address ine...' == Line 413 has weird spacing: '...address rt-...' == Line 415 has weird spacing: '...rw port ine...' -- The document date (August 27, 2019) is 1702 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6991' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC8294' is defined on line 673, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track August 27, 2019 5 Expires: February 28, 2020 7 Discovery Of Restconf Metadata for Source-specific multicast 8 draft-jholland-mboned-dorms-00 10 Abstract 12 This document defines DORMS (Discovery Of Restconf Metadata for 13 Source-specific multicast), a method to discover and retrieve 14 extensible metadata about source-specific multicast channels using 15 RESTCONF. The reverse IP DNS zone for a multicast sender's IP 16 address is configured to use SRV resource records to advertise the 17 hostname of a RESTCONF server that publishes metadata according to a 18 new YANG module with support for extensions. A new service name and 19 the new YANG module are defined. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 28, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Discovery and Metdata Retrieval . . . . . . . . . . . . . . . 4 59 2.1. DNS Bootstrap . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. RESTCONF Bootstrap . . . . . . . . . . . . . . . . . . . 5 61 2.2.1. Root Resource Discovery . . . . . . . . . . . . . . . 5 62 2.2.2. Yang Library Version . . . . . . . . . . . . . . . . 6 63 2.2.3. Yang Library Contents . . . . . . . . . . . . . . . . 6 64 2.2.4. Metadata Retrieval . . . . . . . . . . . . . . . . . 7 65 3. Scalability Considerations . . . . . . . . . . . . . . . . . 8 66 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2. Data Scoping . . . . . . . . . . . . . . . . . . . . . . 9 68 4. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. Yang Tree . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Yang Module . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. The YANG Module Names Registry . . . . . . . . . . . . . 12 74 6.2. The Service Name and Transport Protocol Port Number 75 Registry . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7.1. Secure Communications . . . . . . . . . . . . . . . . . . 13 78 7.2. Exposure of Metadata . . . . . . . . . . . . . . . . . . 13 79 7.3. DNS Bootstrapping . . . . . . . . . . . . . . . . . . . . 14 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 9.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 This document defines DORMS (Discovery Of Restconf Metadata for 89 Source-specific multicast). 91 A DORMS service is a RESTCONF [RFC8040] service that provides read 92 access to data in the "ietf-dorms" YANG [RFC7950] model defined in 93 Section 4. This model, along with optional extensions defined in 94 other documents, provide an extensible set of information about 95 multicast data streams. 97 This document defines the "dorms" service name for use with the SRV 98 DNS Resource Record (RR) type [RFC2782]. A sender offering a DORMS 99 service to publish metadata SHOULD configure at least one SRV RR for 100 the "_dorms._tcp" subdomain in the reverse IP DNS zone for the source 101 IP of its multicast channel to advertise a hostname for a DORMS 102 server that can provide metadata for the sender's source-specific 103 multicast traffic. Doing so enables receivers and middleboxes to 104 discover and query a DORMS server as described in Section 2. 106 The goal is to provide an extensible framework for attaching 107 information necessary for the correct processing of multicast data 108 channels, both for middle boxes forwarding the traffic, and for 109 receivers subscribing to traffic (hereafter called "clients"). 111 1.1. Background 113 The reader is assumed to be familiar with the basic DNS concepts 114 described in [RFC1034], [RFC1035], and the subsequent documents that 115 update them, as well as the use of the SRV Resource Record type as 116 described in [RFC2782]. 118 The reader is also assumed to be familiar with the concepts and 119 terminology regarding source-specific multicast as described in 120 [RFC4607] and the use of IGMPv3 [RFC3376] and MLDv2 [RFC3810] for 121 group management of source-specific multicast channels, as described 122 in [RFC4604]. 124 The reader is also assumed to be familiar with the concepts and 125 terminology for RESTCONF [RFC8040] and YANG [RFC7950]. 127 1.2. Terminology 129 +--------+----------------------------------------------------------+ 130 | Term | Definition | 131 +--------+----------------------------------------------------------+ 132 | (S,G) | A source-specific multicast channel, as described in | 133 | | [RFC4607]. A pair of IP addresses with a source host IP | 134 | | and destination group IP. | 135 | | | 136 | RR | A DNS Resource Record, as described in [RFC1034] | 137 | | | 138 | RRType | A DNS Resource Record Type, as described in [RFC1034] | 139 | | | 140 | SSM | Source-specific multicast, as described in [RFC4607] | 141 +--------+----------------------------------------------------------+ 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119] and [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Discovery and Metdata Retrieval 151 A client that needs metadata about a (S,G) MAY attempt to discover 152 metadata for the (S,G) using the mechanisms defined here, and MAY use 153 the metadata received to manage the forwarding or processing of the 154 packets in the channel. 156 2.1. DNS Bootstrap 158 The DNS Bootstrap step is how a client discovers an appropriate 159 RESTCONF server, given the source address of an (S,G). Use of the 160 DNS Bootstrap is OPTIONAL for clients with an alternate method of 161 obtaining a RESTCONF hostname for a DORMS server with metadata for an 162 (S,G). 164 This mechanism only works for source-specific multicast (SSM) 165 channels. The source address of the (S,G) is reversed and used as an 166 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 167 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 168 described in Section 2.5 of [RFC3596]). 170 When a receiver or middle box needs metadata for an (S,G), for 171 example when handling a new join for that (S,G) and looking up 172 authentication methods available, a receiver or middlebox can issue a 173 DNS query for a SRV RR using the "dorms" service name with the domain 174 from the reverse mapping tree, combining them as described in 175 [RFC2782]. 177 For example, while handling a join for (203.0.113.15, 232.1.1.1), a 178 receiver would perform a DNS query for the SRV RRType for the domain: 180 _dorms._tcp.15.113.0.203.in-addr.arpa. 182 The DNS response for this domain might return a record such as: 184 SRV 0 1 443 dorms-restconf.example.com. 186 This response informs the receiver that a DORMS server SHOULD be 187 reachable at dorms-restconf.example.com on port 443. Multiple SRV 188 records are handled as described by [RFC2782]. 190 A sender providing DORMS discovery SHOULD publish at least one SRV 191 record in the reverse DNS zone for each source address of the 192 multicast channels it is sending, in order to advertise the hostname 193 of the DORMS server to receivers and middle boxes. The DORMS servers 194 advertised SHOULD be configured with metadata for all the groups sent 195 from the same source IP address that have metadata published with 196 DORMS. 198 2.2. RESTCONF Bootstrap 200 Once a DORMS host has been chosen (whether via an SRV RR from a DNS 201 response or via some other method), RESTCONF provides all the 202 information necessary to determine the versions and url paths for 203 metadata from the server. A walkthrough is provided here for a 204 sequence of example requests and responses from a receiver connecting 205 to a new DORMS server. 207 2.2.1. Root Resource Discovery 209 As described in Section 3.1 of [RFC8040] and [RFC6415], the RESTCONF 210 server provides the link to the RESTCONF api entry point via the 211 "/.well-known/host-meta" or "/.well-known/host-meta.json" resource. 213 Example: 215 The receiver might send: 217 GET /.well-known/host-meta.json HTTP/1.1 218 Host: dorms-restconf.example.com 219 Accept: application/json 221 The server might respond as follows: 223 HTTP/1.1 200 OK 224 Date: Tue, 27 Aug 2019 20:56:00 GMT 225 Server: example-server 226 Cache-Control: no-cache 227 Content-Type: application/json 229 { 230 "links":[ 231 { 232 "rel":"restconf", 233 "href":"/top/restconf" 234 } 235 ] 236 } 238 2.2.2. Yang Library Version 240 As described in Section 3.3.3 of [RFC8040], the yang-library-version 241 leaf is required by RESTCONF, and can be used to determine the schema 242 of the ietf-yang-library module: 244 Example: 246 The receiver might send: 248 GET /top/restconf/yang-library-version HTTP/1.1 249 Host: dorms-restconf.example.com 250 Accept: application/yang-data+json 252 The server might respond as follows: 254 HTTP/1.1 200 OK 255 Date: Tue, 27 Aug 2019 20:56:01 GMT 256 Server: example-server 257 Cache-Control: no-cache 258 Content-Type: application/yang-data+json 260 { 261 "ietf-restconf:yang-library-version": "2016-06-21" 262 } 264 TBD: We might need a method for learning a specific restconf server 265 or resource path that supports a version the client knows how to use, 266 in the case the client is older than the server after a new yang- 267 library version is released... Can this be just retry with a hold- 268 down on specific hostnames, so that you can find a lower priority 269 older server from the SRV records, or is signaling that can find or 270 negotiate an explicit version as part of the lookup going to be 271 necessary? -jake 2019-08-26 273 2.2.3. Yang Library Contents 275 After checking that the version of the yang-library module will be 276 understood by the receiver, the client can check that the desired 277 metadata module is available on the DORMS server by fetching the 278 module-state resource from the ietf-yang-library module. 280 Example: 282 The receiver might send: 284 GET /top/restconf/data/ietf-yang-library:modules-state/\ 285 module=ietf-dorms,2016-08-15 286 Host: dorms-restconf.example.com 287 Accept: application/yang-data+json 289 The server might respond as follows: 291 HTTP/1.1 200 OK 292 Date: Tue, 27 Aug 2019 20:56:02 GMT 293 Server: example-server 294 Cache-Control: no-cache 295 Content-Type: application/yang-data+json 297 { 298 "ietf-yang-library:module": [ 299 { 300 "conformance-type": "implement", 301 "name": "ietf-dorms", 302 "namespace": "urn:ietf:params:xml:ns:yang:ietf-dorms", 303 "revision": "2019-08-25", 304 "schema": 305 "https://example.com/yang/ietf-dorms@2019-08-25.yang" 306 } 307 ] 308 } 310 Other modules required or desired by the client also can be checked 311 in a similar way, or the full set of available modules can be 312 retrieved by not providing a key for the "module" list. 314 2.2.4. Metadata Retrieval 316 Once the expected DORMS version is confirmed, the client can retrieve 317 the metadata specific to the desired (S,G). 319 Example: 321 The receiver might send: 323 GET /top/restconf/data/ietf-dorms:metadata/\ 324 sender=203.0.113.15/group=232.1.1.1 325 Host: dorms-restconf.example.com 326 Accept: application/yang-data+json 328 The server might respond as follows: 330 HTTP/1.1 200 OK 331 Date: Tue, 27 Aug 2019 20:56:02 GMT 332 Server: example-server 333 Cache-Control: no-cache 334 Content-Type: application/yang-data+json 336 { 337 "ietf-dorms:group": [ 338 { 339 "group-address":"232.1.1.1", 340 "udp-stream":[ 341 { 342 "port":"5001" 343 } 344 ] 345 } 346 ] 347 } 349 Note that when other modules are installed on the DORMS server that 350 extend the ietf-dorms module, other fields MAY appear inside the 351 response. This is the primary mechanism for providing extensible 352 metadata for an (S,G), so clients SHOULD ignore fields they do not 353 understand. 355 As mentioned in Section 3.2, most clients SHOULD use data resource 356 identifiers in the request URI as in the above example, in order to 357 retrieve metadata for only the targeted (S,G)s. 359 3. Scalability Considerations 361 3.1. Provisioning 363 In contrast to many common RESTCONF deployments that are intended to 364 provide configuration management for a service to a narrow set of 365 authenticated administrators, DORMS servers often provide read-only 366 metadata for public access, or for a very large set of end receivers, 367 since it provides metadata in support of multicast data streams and 368 multicast can scale to very large audiences. 370 Operators are advised to provision the DORMS service in a way that 371 will scale appropriately to the size of the expected audience. 372 Specific advice on such scaling is out of scope for this document, 373 but some of the mechanisms outlined in [RFC3040] or other online 374 resources might be useful, depending on the expected number of 375 receivers. 377 3.2. Data Scoping 379 In the absence of contextual information, clients SHOULD issue 380 narrowed requests for DORMS resources by following the format from 381 Section 3.5.3 of [RFC8040] to encode data resource identifiers in the 382 request URI. This avoids downloading excessive data, since the DORMS 383 server may provide metadata for many (S,G)s, possibly from many 384 different senders. 386 However, clients MAY use heuristics or out of band information about 387 the service to issue requests for (S,G) metadata narrowed only by the 388 source-address, or not narrowed at all. Depending on the request 389 patterns and the contents of the data store, this may result in fewer 390 round trips or less overhead, and can therefore be helpful behavior 391 for scaling purposes. Servers MAY restrict or throttle client access 392 based on the client certificate presented (if any), or based on 393 heuristics that take note of client request patterns. 395 A complete description of the heuristics for clients and servers to 396 meet their scalability goals is out of scope for this document. 398 4. YANG Model 400 The primary purpose of the YANG model defined here is to serve as a 401 scaffold for the more useful metadata that will extend it. Currently 402 known use cases include providing authentication information and bit- 403 rate information for use by receivers and middle boxes, but more use 404 cases are anticipated. 406 4.1. Yang Tree 408 module: ietf-dorms 409 +--rw metadata 410 +--rw sender* [source-address] 411 +--rw source-address inet:ip-address 412 +--rw group* [group-address] 413 +--rw group-address rt-types:ip-multicast-group-address 414 +--rw udp-stream* [port] 415 +--rw port inet:port-number 417 DORMS Tree Diagram 419 4.2. Yang Module 421 file ietf-dorms@2019-08-28.yang 422 module ietf-dorms { 423 yang-version 1.1; 424 namespace "urn:ietf:params:xml:ns:yang:ietf-dorms"; 425 prefix "dorms"; 427 import ietf-inet-types { 428 prefix "inet"; 429 reference "RFC 6991 Section 4"; 430 } 432 import ietf-routing-types { 433 prefix "rt-types"; 434 reference "RFC 8294"; 435 } 437 organization "IETF"; 439 contact 440 "Author: Jake Holland 441 442 "; 444 description 445 "Copyright (c) 2019 IETF Trust and the persons identified as 446 authors of the code. All rights reserved. 448 Redistribution and use in source and binary forms, with or 449 without modification, is permitted pursuant to, and subject to 450 the license terms contained in, the Simplified BSD License set 451 forth in Section 4.c of the IETF Trust's Legal Provisions 452 Relating to IETF Documents 453 (https://trustee.ietf.org/license-info). 455 This version of this YANG module is part of RFC XXXX 456 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 457 for full legal notices. 459 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 460 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 461 'MAY', and 'OPTIONAL' in this document are to be interpreted as 462 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 463 they appear in all capitals, as shown here. 465 This module contains the definition for the DORMS data type. 466 It provides out of band metadata about SSM channels."; 468 revision 2019-08-25 { 469 description "Initial revision."; 470 reference 471 ""; 472 // "I-D.draft-jholland-mboned-dorms"; 473 } 475 container metadata { 476 description "Metadata scaffold for source-specific multicast 477 channels."; 478 list sender { 479 key source-address; 480 description "Sender for DORMS"; 482 leaf source-address { 483 type inet:ip-address; 484 mandatory true; 485 description 486 "The source IP address of a multicast sender."; 487 } 489 list group { 490 key group-address; 491 description "Metadata for a DORMS (S,G)."; 493 leaf group-address { 494 type rt-types:ip-multicast-group-address; 495 mandatory true; 496 description "The group IP address for an (S,G)."; 497 } 499 list udp-stream { 500 key "port"; 501 description 502 "Metadata for UDP traffic on a specific port."; 503 leaf port { 504 type inet:port-number; 505 mandatory true; 506 description 507 "The UDP port of a data stream in an (S,G)."; 508 } 509 } 510 } 511 } 512 } 513 } 514 516 5. Privacy Considerations 518 In the typical case, the mechanisms defined in this document provide 519 a standardized way to discover information that is already available 520 in other ways. 522 However, depending on the metadata provided by the server, observers 523 may be able to more easily associate traffic from an (S,G) with the 524 content contained within the (S,G). At the subscriber edge of a 525 multicast-capable network, where the network operator has the 526 capability to localize a IGMP [RFC3376] or MLD [RFC3810] channel 527 subscription to a specific user or location by MAC address or source 528 IP address, the structured publishing of metadata may make it easier 529 to automate collection of data about the content a receiver is 530 consuming. 532 RESTCONF communication will expose to the controller of the RESTCONF 533 server information about the consumers of content that is not 534 otherwise available from multicast subscription to a channel, such as 535 the remote IP address and timing information. 537 6. IANA Considerations 539 6.1. The YANG Module Names Registry 541 This document adds one YANG module to the "YANG Module Names" 542 registry maintained at . The following registrations are made, per the format in 544 Section 14 of [RFC6020]: 546 name: ietf-dorms 547 namespace: urn:ietf:params:xml:ns:yang:ietf-dorms 548 prefix: dorms 549 reference: I-D.draft-jholland-mboned-dorms 551 6.2. The Service Name and Transport Protocol Port Number Registry 553 This document adds one service name to the "Service Name and 554 Transport Protocol Port Number Registry" maintained at 555 . The 556 following registrations are made, per the format in Section 8.1.1 of 557 [RFC6335]: 559 Service Name: dorms 560 Transport Protocol(s): TCP 561 Assignee: IESG 562 Contact: IETF Chair 563 Description: This service name is used to construct the 564 SRV service label "_dorms" for discovering 565 DORMS servers. 566 Reference: I-D.draft-jholland-mboned-dorms 567 Port Number: N/A 568 Service Code: N/A 569 Known Unauthorized Uses: N/A 570 Assignment Notes: This protocol uses HTTPS as a substrate. 572 7. Security Considerations 574 7.1. Secure Communications 576 It is intended that security related metadata about the SSM channels 577 will be delivered over the RESTCONF connection, and that information 578 available from this connection can be used as a trust anchor. 580 The provisions of Section 2 of [RFC8040] provide secure communication 581 requirements that are already required of DORMS servers, since they 582 are RESTCONF servers. All RESTCONF requirements and security 583 considerations remain in force for DORMS servers. 585 7.2. Exposure of Metadata 587 Although some DORMS servers MAY restrict access based on client 588 identity, as described in Section 2.5 of [RFC8040], many DORMS 589 servers will use the ietf-dorms YANG model to publish information 590 without restriction, and even DORMS servers requiring client 591 authentication will inherently, because of the purpose of DORMS, be 592 providing the DORMS metadata to potentially many receivers. 594 Accordingly, future YANG modules that augment data paths under "ietf- 595 dorms:metadata" MUST NOT include any sensitive data unsuitable for 596 public dissemination in those data paths. Because of the possibility 597 that scalable read-only access might be necessary to fulfill the 598 scalability goals for a DORMS server, data under these paths MAY be 599 cached or replicated by numerous external entities, so owners of such 600 data SHOULD NOT assume it can be kept secret when provided by DORMS 601 servers anywhere under the "ietf-dorms:metadata" path, even if they 602 are authenticating clients. 604 7.3. DNS Bootstrapping 606 The DNS bootstrap phase relies on DNS for the reverse IP tree. When 607 using DNS to discover a DORMS server's domain name, there must be a 608 trust relationship between the end consumer of this resource record 609 and the DNS server. This relationship may be end-to-end DNSSEC 610 validation, a TSIG [RFC2845] or SIG(0) [RFC2931] channel to another 611 secure source, a secure local channel on the host, DNS over TLS 612 [RFC7858] or HTTPS [RFC8484], or some other secure mechanism. 614 If the SRV Resource Record cannot be authenticated, it may be 615 possible for an attacker who can spoof the resource record to perform 616 a denial of service for the receiver by providing wrong or missing 617 authentication metadata. An attacker who can also inject traffic for 618 (S,G)s, would also be able to provide false content in the data 619 stream, so an attacker who can perform both could provide 620 authenticated false content by authenticating with a trust anchor 621 from an attacker-controlled DORMS server. 623 Clients MAY use other secure methods to explicitly associate an (S,G) 624 with a set of DORMS server hostnames, such as a configured mapping or 625 an alternative trusted lookup service. 627 TBD: do we need CORS [whatwg-fetch] on the DORMS server? Perhaps in 628 a new URI path, or maybe on /.well-known/host-meta? (Suppose evil 629 Javascript joins someone else's stream, providing a correct DORMS 630 hostname-should DORMS get an Origin header and have the option to 631 block?) 633 8. Acknowledgements 635 Thanks to Christian Mortensen for some very helpful comments and 636 review. 638 9. References 640 9.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 648 specifying the location of services (DNS SRV)", RFC 2782, 649 DOI 10.17487/RFC2782, February 2000, 650 . 652 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 653 "DNS Extensions to Support IP Version 6", STD 88, 654 RFC 3596, DOI 10.17487/RFC3596, October 2003, 655 . 657 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 658 RFC 6991, DOI 10.17487/RFC6991, July 2013, 659 . 661 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 662 RFC 7950, DOI 10.17487/RFC7950, August 2016, 663 . 665 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 666 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 674 "Common YANG Data Types for the Routing Area", RFC 8294, 675 DOI 10.17487/RFC8294, December 2017, 676 . 678 9.2. Informative References 680 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 681 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 682 . 684 [RFC1035] Mockapetris, P., "Domain names - implementation and 685 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 686 November 1987, . 688 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 689 Wellington, "Secret Key Transaction Authentication for DNS 690 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 691 . 693 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 694 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 695 2000, . 697 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 698 Replication and Caching Taxonomy", RFC 3040, 699 DOI 10.17487/RFC3040, January 2001, 700 . 702 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 703 Thyagarajan, "Internet Group Management Protocol, Version 704 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 705 . 707 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 708 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 709 DOI 10.17487/RFC3810, June 2004, 710 . 712 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 713 Group Management Protocol Version 3 (IGMPv3) and Multicast 714 Listener Discovery Protocol Version 2 (MLDv2) for Source- 715 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 716 August 2006, . 718 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 719 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 720 . 722 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 723 the Network Configuration Protocol (NETCONF)", RFC 6020, 724 DOI 10.17487/RFC6020, October 2010, 725 . 727 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 728 Cheshire, "Internet Assigned Numbers Authority (IANA) 729 Procedures for the Management of the Service Name and 730 Transport Protocol Port Number Registry", BCP 165, 731 RFC 6335, DOI 10.17487/RFC6335, August 2011, 732 . 734 [RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 735 RFC 6415, DOI 10.17487/RFC6415, October 2011, 736 . 738 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 739 and P. Hoffman, "Specification for DNS over Transport 740 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 741 2016, . 743 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 744 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 745 . 747 [whatwg-fetch] 748 Kesteren, A., "WHATWG Fetch Living Standard", August 2019, 749 . 751 Author's Address 753 Jake Holland 754 Akamai Technologies, Inc. 755 150 Broadway 756 Cambridge, MA 02144 757 United States of America 759 Email: jakeholland.net@gmail.com