RFC 8804

Content Delivery Network Interconnection (CDNI) Request Routing Extensions

📅 published September 2020, from ietf

📡 RFC 8804: CDNI Request Routing Extensions 💖

okay bestie, let's get into it ✨ this one is written by O. Finkelman (Qwilt) and S. Mishra (Verizon) 🫶 it's a Standards Track doc from September 2020, and it's an official Internet Standard in the making 🔥

it doesn't obsolete anything and it doesn't update anything either, so it's a fresh start 🌸 its ISSN is 2070-1721, if you ever need to look it up 🎀

The IETF is the group making the rules here, and the document reflects consensus from the community after public review and approval by the IESG 💅 more about standards is in Section 2 of RFC 7841 💜 errata and feedback live at https://www.rfc-editor.org/info/rfc8804 🦋

Copyright is held by the IETF Trust and the authors, all rights reserved, and the document is subject to BCP 78 and the IETF Trust's Legal Provisions 💀 if you pull code out of it, it has to include the Simplified BSD License text (Section 4.e of the Trust Legal Provisions) and comes with no warranty 🙈

Table of Contents ✨

1.  Introduction
  1.1.  Terminology
  1.2.  Requirements Language
2.  Redirect Target Capability
  2.1.  DNS Redirect Target
  2.2.  HTTP Redirect Target
  2.3.  Properties of Redirect Target Capability Object
  2.4.  DnsTarget Object
    2.4.1.  DnsTarget Example
  2.5.  HttpTarget Object
    2.5.1.  HttpTarget Example
  2.6.  Usage Example
3.  Fallback Target Server Address
  3.1.  Properties of Fallback Target Generic Metadata Object
  3.2.  Usage Example
  3.3.  uCDN Addressing Considerations
4.  IANA Considerations
  4.1.  CDNI Payload Types
    4.1.1.  CDNI FCI RedirectTarget Payload Type
    4.1.2.  CDNI MI FallbackTarget Payload Type
5.  Security Considerations
  5.1.  Confidentiality and Privacy
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🎀

okay so the Streaming Video Alliance [SVA] is a global group that works on streaming video problems to make the end-user experience better and help things get adopted 🌈 inside it, the Open Caching Working Group [OCWG] is all about handing off video delivery requests from commercial CDNs to a caching layer that lives in the ISP's network 🧚

so the Open Caching setup is a specific CDNI use case where the commercial CDN is the uCDN (upstream) and the ISP caching layer is the dCDN (downstream) 💜 the Open Caching Request Routing Functional Specification [OC-RR] is where the Request Routing process and the interfaces it needs for provisioning are spelled out 🔥

this document defines the CDNI metadata object [RFC8006] and the CDNI Footprint and Capabilities object [RFC8008] that Open Caching Request Routing needs 💅 there are two pieces:

  • Redirect Target Capability ✨ (for the dCDN to advertise its redirect target address)
  • Fallback Target Metadata 🦋 (for the uCDN to configure its fallback target address)

it also registers CDNI Payload Types [RFC7736] for these objects 🫶 and to stay consistent with the other CDNI docs, it keeps the uCDN and dCDN naming, meaning commercial CDN and ISP caching layer 🌸

1.1. Terminology 💖

these are the terms used all through the doc:

  • FQDN: Fully Qualified Domain Name
  • CDN: Content Delivery Network

it also borrows terminology from [RFC6707], [RFC7336], [RFC8006], [RFC8007], and [RFC8008] 🎀 the CDNI acronyms are:

  • FCI: Footprint & Capabilities Advertisement interface (see [RFC8008])
  • MI: Metadata Interface (see [RFC8006])
  • uCDN: Upstream CDN (see [RFC7336])
  • dCDN: Downstream CDN (see [RFC7336])
  • RT: Redirection Target. The endpoint for redirection from uCDN to dCDN.
  • RR: Request Router. An element that routes user requests, usually with an HTTP redirect or a DNS CNAME, depending on the use case.

1.2. Requirements Language 🔥

okay this part is important bestie 🙈 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like that 💅

2. Redirect Target Capability ✨

so iterative CDNI request redirection is defined in Section 1.1 of [RFC7336] and has examples in Sections 3.2 and 3.4 of [RFC7336] 🦋 Section 2 of [RFC7975] defines a Redirection Target (RT) for recursive request redirection like this:

|  The endpoint to which the User Agent is redirected.  In CDNI, an
|  RT may point to a number of different components, some examples
|  include a surrogate in the same CDN as the request router, a
|  request router in a dCDN, or a surrogate in a dCDN.

this doc uses that same RT definition for the iterative request redirect use case 💜 this use case needs the uCDN to be given the RT address so it can redirect to the dCDN 🌸 RT addresses can differ between footprints (say, different regions) and can change over time (like when there are network problems) 😭 because it's so variable and dynamic, advertising it at bootstrap might not work well 🙈 a more dynamic, footprint-oriented interface is needed 🧚 Section 4.3 of [RFC7336] suggests the FCI [RFC8008] could take on that role, so that's what this doc does 🎀 the FCI is used to advertise the redirect target address 🫶

here are the use cases 👑

  • Footprint: the dCDN may want a different target for each footprint 💖 a dCDN can span lots of geographies, and this makes it easier to send client requests to a nearby request router 🦋 you could do it with one canonical name and "Geo DNS" (same hostname resolving to different IPs in different places), but that has limits 💀 for example, a client might be using a third-party DNS resolver so the redirector can't tell where the client is, or Geo DNS might be too coarse for what the app needs 😭
  • Scaling: the dCDN may scale its Request Routing service by deploying more request routers in new locations and advertising them through an updatable interface like the FCI ✨

the Redirect Target capability object tells the uCDN which target address to use to send a client to the dCDN 🧚 a target can be attached to one specific uCDN host, to a list of uCDN hosts, or be used globally for every host of the uCDN 🌈

⚠️ when the dCDN attaches the redirect target to a specific uCDN host or a list of uCDN hosts, the dCDN MUST advertise those hosts inside the Redirect Target capability object as "redirecting-hosts" 💅 in that case the uCDN can only redirect to that dCDN address if the User Agent's request was for one of those uCDN hosts 🙈

if the Redirect Target capability object has no target, or the target is empty, the uCDN MUST read that as "no target available for these uCDN hosts for the specified footprint" 💀 and if a target was already advertised in a previous FCI object, the uCDN MUST treat it as an update that deletes the previous redirect target 😭

2.1. DNS Redirect Target 🦋

a DNS redirect target is an FQDN used as an alias in a CNAME record response (see [RFC1034]) from the uCDN DNS router 🎀 quick note: DNS routers make routing decisions based on either the DNS resolver's IP address or the client IP subnet when EDNS0 client-subnet (ECS) is used (see [RFC7871]) 🧚 the dCDN can advertise redirect targets and footprints to cover both cases, so the uCDN resolution sends the DNS query to different dCDN CNAMEs depending on client subnet or dCDN resolver IP address 💜 this also lets the dCDN DNS optimise resolution by localising the target CNAMEs 🌸

a uCDN implementation SHOULD prefer routing based on client IP subnet when the ECS option is present 🫶 a dCDN implementation that uses the ECS option MUST be aware of the privacy drawbacks listed in Section 2 of [RFC7871] and SHOULD follow the guidelines in Section 11.1 of [RFC7871] 🔥

2.2. HTTP Redirect Target 🌈

an HTTP redirect target is the URI used as the value of the Location header in an HTTP redirect 3xx response, usually a 302 (Found) (see Section 7.1.2 of [RFC7231] and Section 6.4 of [RFC7231]) ✨

Part 1 of 4. More parts are coming, so stay tuned bestie 💖🧚

2.3. Properties of Redirect Target Capability Object 🎀

okay so the Redirect Target capability object is a little bundle with three properties, and they all work together like a girl group 💅

  • redirecting-hosts 🌸
    • Description: One or more uCDN hosts to which this redirect target is attached. A redirecting host SHOULD be a host that was published in a HostMatch object by the uCDN as defined in Section 4.1.2 of [RFC8006].
    • Type: A list of Endpoint objects (see Section 4.3.3 of [RFC8006])
    • Mandatory-to-Specify: No. If absent or empty, the redirect target applies to all hosts of the redirecting uCDN.
  • dns-target 🦋
    • Description: Target CNAME record for DNS redirection.
    • Type: DnsTarget object (see Section 2.4)
    • Mandatory-to-Specify: No. If the dns-target is absent or empty, the uCDN MUST interpret it as "no dns-target available".
  • http-target 🧚
    • Description: Target URI for an HTTP redirect.
    • Type: HttpTarget object (see Section 2.5)
    • Mandatory-to-Specify: No. If the http-target is absent or empty, the uCDN MUST interpret it as "no http-target available".

Here's an example of a Redirect Target capability object serialization that advertises a dCDN target address attached to a specific list of uCDN "redirecting-hosts". Any uCDN host on that list can redirect to the advertised dCDN redirect target 🫶. The capabilities object is serialized as a JSON object, as defined in Section 5.1 of [RFC8008].

{
  "capabilities": [
    {
      "capability-type": "FCI.RedirectTarget",
      "capability-value": {
          "redirecting-hosts": [
             "a.service123.ucdn.example.com",
             "b.service123.ucdn.example.com"
          ],
          "dns-target": {
             "host": "service123.ucdn.dcdn.example.com"
          },
          "http-target": {
              "host": "us-east1.dcdn.example.com",
              "path-prefix": "/cache/1/",
              "include-redirecting-host": true
          }
      },
      "footprints": [
          <Footprint objects>
      ]
    }
  ]
}

2.4. DnsTarget Object 🌈

the DnsTarget object is the thing that tells the DNS response where to delegate from the uCDN over to the dCDN. It's giving routing realness 😭

  • host 💖
    • Description: The host property is a hostname or an IP address, without a port number.
    • Type: Endpoint object as defined in Section 4.3.3 of [RFC8006], with the limitation that it SHOULD NOT include a port number and, in case a port number is present, the uCDN MUST ignore it.
    • Mandatory-to-Specify: Yes.

2.4.1. DnsTarget Example 🍓

Here's what a DnsTarget object looks like in practice:

{
   "host": "service123.ucdn.dcdn.example.com"
}

Next up is a DNS query for the uCDN address "a.service123.ucdn.example.com" plus the CNAME redirection response that comes back. Sooo cute, right? 🥹

Query:
a.service123.ucdn.example.com:
type A, class IN

Response:
NAME: a.service123.ucdn.example.com, TYPE: CNAME, CLASS: IN,
TTL: 120, RDATA: service123.ucdn.dcdn.example.com

2.5. HttpTarget Object 🦋

the HttpTarget object holds everything needed to build the target Location URI for HTTP redirection. Main character energy, honestly 👑

  • host 🌸
    • Description: Hostname or IP address and an optional port, i.e., the host and port of the authority component of the URI as described in Section 3.2 of [RFC3986].
    • Type: Endpoint object as defined in Section 4.3.3 of [RFC8006].
    • Mandatory-to-Specify: Yes.
  • scheme 💜
    • Description: A URI scheme to be used in the redirect response location construction. When present, the uCDN MUST use the provided scheme for HTTP redirection to the dCDN.
    • Type: A URI scheme as defined in Section 3.1 of [RFC3986], represented as a JSON string. The scheme MUST be either "http" or "https".
    • Mandatory-to-Specify: No. If this property is absent or empty, the uCDN request router MUST use the same scheme as was used in the original request before redirection.
  • path-prefix 🎀
    • Description: A path prefix for the HTTP redirect Location header. The original path is appended after this prefix.
    • Type: A prefix of a path-absolute as defined in Section 3.3 of [RFC3986]. The prefix MUST end with a trailing slash to indicate the end of the last path segment in the prefix.
    • Mandatory-to-Specify: No. If this property is absent or empty, the uCDN MUST NOT prepend a path-prefix to the original content path, i.e., the original path MUST appear in the Location URI right after the authority component.
  • include-redirecting-host 🧚
    • Description: A flag indicating whether or not to include the redirecting host as the first path segment after the path-prefix. If set to true and a "path-prefix" is used, the uCDN redirecting host MUST be added as a separate path segment after the path-prefix and before the original URL path. If set to true and there is no path-prefix, the uCDN redirecting host MUST be prepended as the first path segment in the redirect URL.
    • Type: Boolean.
    • Mandatory-to-Specify: No. Default value is False.

2.5.1. HttpTarget Example ✨

This example of the HttpTarget object has a "scheme", a "path-prefix", and an "include-redirecting-host" property:

{
   "host": "us-east1.dcdn.example.com",
   "scheme": "https",
   "path-prefix": "/cache/1/",
   "include-redirecting-host": true
}

Now the full picture 🔥. Here's an HTTP request for content at the uCDN host "a.service123.ucdn.example.com", plus the HTTP response with a Location header that sends the client over to the dCDN. That Location header is built using the HttpTarget object from the example above.

Request:
GET /vod/1/movie.mp4 HTTP/1.1
Host: a.service123.ucdn.example.com

Response:
HTTP/1.1 302 Found
Location: https://us-east1.dcdn.example.com/cache/1/
a.service123.ucdn.example.com/vod/1/movie.mp4

2.6. Usage Example 💅

before any requests can get routed from the uCDN to the dCDN, the two CDNs have to swap service configurations. It's a whole handshake situation 🤝. The uCDN uses the MI to advertise its hosts to the dCDN out-of-band. Each host is designated by a hostname and has its own specific metadata (see Section 4.1.2 of [RFC8006]). Then the dCDN uses the FCI to advertise, also out-of-band, the redirect target address defined in Section 2.3 for the relevant uCDN hosts. Below is a generalized example of the message flow between a uCDN and a dCDN. To keep things simple, we're only looking at the sequence of messages between the uCDN and dCDN, not how they actually get passed around 🌸.

  dCDN                                                    uCDN
    +                                                       +
    |                                                       |
(1) | MI:  host: s123.ucdn.example.com                      |
    |      host-metadata: < metadata >                      |
    <-------------------------------------------------------+
    |                                                       |
(2) | FCI:  capability-type: FCI.RedirectTarget             |
    |       redirecting-hosts: s123.ucdn.example.com        |
    |       target host: us-east1.dcdn.example.com          |
    +------------------------------------------------------->
    |                                                       |
    |                                                       |
    +                                                       +

Figure 1: Redirect Target Address Advertisement

Here's the breakdown:

  1. The uCDN advertises a host (s123.ucdn.example.com) with the host metadata.
  2. The dCDN advertises its FCI objects to the uCDN, including a Redirect Target capability object that contains the redirect target address (us-east1.dcdn.example.com) specified for that uCDN host.

Once the redirect target is set, the uCDN can start redirecting user requests to the dCDN 🦋. The next diagram is a generic sequence of redirection that uses the host and redirect target advertised in Figure 1.

End User                  dCDN                   uCDN RR
    +                       +                       +
    |                       |                       |
(1) | Request sent s123.ucdn.example.com            |
    +-----------------------+----------------------->
    |                       |                       |
(2) | Redirect to us-east1.dcdn.example.com         |
    <-----------------------+-----------------------+
    |                       |                       |
(3) | Request us-east1.dcdn.example.com             |
    +----------------------->                       |
    |                       |                       |
(4) | Response              |                       |
    <-----------------------+                       |
    |                       |                       |
    +                       +                       +

Figure 2: Generic Request Redirection Sequence

And the explanation for that one:

  1. The End User sends a request (DNS or HTTP) to the uCDN Request Router (RR).
  2. Using the previously advertised Redirect Target, the uCDN redirects the request to the dCDN.
  3. The End User sends a request to the dCDN.
  4. The dCDN either sends a response or reroutes it, for example, to a dCDN surrogate.

3. Fallback Target Server Address ✨

okay bestie, so Open Caching needs the uCDN to hand the dCDN a fallback target server 🦋 for when the dCDN just can't handle a request. 🫶 To avoid redirect loops (which are a whole nightmare 💀), the fallback target's address at the uCDN MUST be different from the original uCDN address the client got bounced from to the dCDN. 💅 And when the client lands on the fallback target, the uCDN MUST avoid further redirection. no more bouncing, periodt 🔥

The Fallback Target is defined as a generic metadata object (see Section 3.2 of [RFC8006]) 🌸

Use cases:

  • Failover 💔: A dCDN request router gets a request but has no caches to route it to. This can happen with failures or temporary network overload 😭
  • No coverage 🗺️: A dCDN request router gets a request from a client who is inside the footprint but not covered by the dCDN caches, or outside the dCDN footprint coverage. In those cases, the router MAY choose to redirect the request back to the uCDN fallback address. (the router gets to decide, ooh 👑)
  • Error 🙈: A cache might get a request it can't properly serve, like if some of the metadata objects for that service weren't acquired properly. In that case, the cache's "default action" MAY be to "redirect back to uCDN". 🧚

The Fallback Target metadata object tells the dCDN which target address to redirect a client to when it falls back to the uCDN. 💖 The fallback target address is represented as an Endpoint object as defined in Section 4.3.3 of [RFC8006] ✨

In DNS redirection, a CNAME record is used as the fallback target address. 🎀

In HTTP redirection, a hostname is used as the fallback target address. 🌈

When using HTTP redirect to route a client request back to the uCDN, it is the dCDN's responsibility to use the original URL path as the client would have used for the original uCDN request. 💅 That means stripping, if needed, the dCDN path-prefix and/or the uCDN hostname from the redirect URL that may have been used to request the content from the dCDN. main character handling 👑

3.1. Properties of Fallback Target Generic Metadata Object 🦋

okay so the MI.FallbackTarget generic metadata object has two properties 💜

Property: host 🌸

  • Description: Target address to which the dCDN can redirect the client.
  • Type: Endpoint object as defined in Section 4.3.3 of [RFC8006], with the limitation that in case of DNS delegation, it SHOULD NOT include a port number, and in case a port number is present, the dCDN MUST ignore it. (ngl this is a lowkey important detail 🙈)
  • Mandatory-to-Specify: Yes.

Property: scheme 🧚

  • Description: A URI scheme to be used in the redirect response location construction. When present, the dCDN MUST use this scheme in case of HTTP redirection to the uCDN fallback address.
  • Type: A URI scheme as defined in Section 3.1 of [RFC3986], represented as a JSON string. The scheme MUST be either "http" or "https". 🍓
  • Mandatory-to-Specify: No. In case of HTTP redirection to fallback, if this property is absent or empty, the dCDN redirecting entity MUST use the same scheme as in the request received by the dCDN. it's giving flexibility ✨

Here's an example of an MI.FallbackTarget generic metadata object that designates the host address the dCDN should use as fallback address to redirect back to the uCDN 🫶

{
    "generic-metadata-type": "MI.FallbackTarget",
    "generic-metadata-value":
    {
        "host": "fallback-a.service123.ucdn.example",
        "scheme": "https"
    }
}

3.2. Usage Example 🌈

the uCDN advertises the fallback target address to the dCDN out-of-band 🦋, so the dCDN can redirect a request back to the uCDN if it can't serve it. Using the MI, the uCDN advertises its hosts to the dCDN, along with their specific host metadata (see Section 4.1.2 of [RFC8006]). The Fallback Target generic metadata object is encapsulated within the "host-metadata" property of each host. Here's a message flow between a uCDN and a dCDN. For simplicity, we focus on the sequence of messages between the uCDN and dCDN, not on how they are passed. 💅

  dCDN                                                    uCDN
    +                                                       +
    |                                                       |
(1) | MI:  host: s123.ucdn.example.com                      |
    |      host-metadata:                                   |
    |          < metadata objects >                         |
    |          < MI.FallbackTarget                          |
    |            host: fallback-a.service123.ucdn.example > |
    |          < metadata objects >                         |
    <-------------------------------------------------------+
    |                                                       |
(2) | FCI:  capability-type: FCI.RedirectTarget             |
    |       redirecting-hosts: s123.ucdn.example.com        |
    |       target host: us-east1.dcdn.example.com          |
    +------------------------------------------------------->
    |                                                       |
    |                                                       |
    +                                                       +

       Figure 3: Advertisement of Host Metadata with Fallback Target

Explanation:

  • (1) The uCDN advertises a host (s123.ucdn.example.com) with the host metadata. The host-metadata property contains an MI.FallbackTarget generic metadata object. 🎀
  • (2) The dCDN advertises its FCI objects to the uCDN, including a Redirect Target capability object that contains the redirect target address (us-east1.dcdn.example.com) specified for that uCDN host. 🌸

Here's a generic sequence of redirection using the configurations that were advertised in Figure 3. In this case, the dCDN redirects back to the uCDN fallback target address. 💜

End User              dCDN            uCDN fallback          uCDN RR
    +                   +                   +                   +
    |                   |                   |                   |
(1) | Request sent s123.ucdn.example.com    |                   |
    +-------------------+-------------------+------------------->
    |                   |                   |                   |
(2) | Redirect to us-east1.dcdn.example.com |                   |
    <-------------------+-------------------+-------------------+
    |                   |                   |                   |
(3) | Request us-east1.dcdn.example.com     |                   |
    +------------------->                   |                   |
    |                   |                   |                   |
(4) | Redirect back to fallback-a.service123.ucdn.example       |
    <-------------------+                   |                   |
    |                   |                   |                   |
(5) | Request fallback-a.service123.ucdn.example                |
    +--------------------------------------->                   |
    |                   |                   |                   |
(6) | Response          |                   |                   |
    <-------------------+-------------------+                   |
    |                   |                   |                   |
    +                   +                   +                   +

              Figure 4: Redirection to Fallback Target

Explanation:

  • (1) The End User sends a request (DNS or HTTP) to the uCDN Request Router (RR). 🧚
  • (2) Using the previously advertised Redirect Target, the uCDN redirects the request to the dCDN. 💖
  • (3) The End User sends a request to the dCDN. ✨
  • (4) The dCDN cannot handle the request and therefore redirects it back to the uCDN fallback target address. 💀
  • (5) The End User sends the request to the uCDN fallback target address. 🦋
  • (6) The uCDN either sends a response or reroutes it, for example, to a uCDN surrogate. 👑

3.3. uCDN Addressing Considerations 🌈

When advertising fallback addresses to the dCDN, the uCDN SHOULD consider the failure use cases that may lead the dCDN to route requests to uCDN fallback. In extreme dCDN network failures or under denial-of-service (DoS) attacks, requests coming from a large segment or multiple segments of the dCDN may be routed back to the uCDN. The uCDN SHOULD therefore design its fallback addressing scheme and its available resources accordingly. A favorable approach would be for the uCDN to use a different fallback target address for each uCDN host, enabling it to load balance the requests using the same methods as it would for its original hosts. See Sections 4.1.2 and 4.1.3 of [RFC8006] for a detailed description of how to use GenericMetadata objects within the HostMatch object advertised in the HostIndex of the uCDN. 💅

4. IANA Considerations 🎀

4.1. CDNI Payload Types 🌸

IANA has registered the following CDNI Payload Types in the "CDNI Payload Types" registry defined in [RFC7736]:

                 +====================+===============+
                 | Payload Type       | Specification |
                 +====================+===============+
                 | FCI.RedirectTarget | RFC 8804      |
                 +--------------------+---------------+
                 | MI.FallbackTarget  | RFC 8804      |
                 +--------------------+---------------+

                                Table 1

4.1.1. CDNI FCI RedirectTarget Payload Type 🦋

  • Purpose: The purpose of this payload type is to distinguish FCI advertisement objects for redirect target.
  • Interface: FCI
  • Encoding: See Section 2.3.

4.1.2. CDNI MI FallbackTarget Payload Type 🧚

  • Purpose: The purpose of this payload type is to distinguish FallbackTarget MI objects (and any associated capability advertisement).
  • Interface: MI/FCI
  • Encoding: See Section 3.1.

5. Security Considerations 💀

This specification defines extensions to the CDNI Metadata Interface (MI) and the Footprint & Capabilities Advertisement interface (FCI). As such, it is subject to the security and privacy considerations defined in Section 8 of [RFC8006] and in Section 7 of [RFC8008], respectively. 🔥

5.1. Confidentiality and Privacy 🙈

The Redirect Target capability object potentially reveals information about the internal structure of the dCDN network. A third party could intercept the FCI transactions and use the information to attack the dCDN. The same is also true for the Fallback Target generic metadata object, as it may reveal information about the internal structure of the uCDN, exposing it to external exploits. 😭

Implementations of the FCI and MI MUST therefore use strong authentication and encryption and strictly follow the directions for securing the interface as defined for the Metadata Interface in Section 8.3 of [RFC8006]. 🚨

6. References 📚

6.1. Normative References ✨

okay bestie, this is the reading list the spec leans on hardest 📚 every entry keeps its full details, no cap 💅

6.2. Informative References ✨

these ones are the extra context, the "ooh, go read this too" picks 🌸🙈

Acknowledgements ✨

big thank-yous time 🫶 The authors thank Nir B. Sopher for reality checks against production use cases, and they say his contribution is significant to this document 🙌 They also thank Ben Niven-Jenkins for his review and feedback, and Kevin J. Ma for his guidance throughout the development of this document, including his regular reviews 💜

Authors' Addresses 💌

Ori Finkelman
Qwilt
6, Ha'harash
Hod HaSharon 4524079
Israel

Email: ori.finkelman.ietf@gmail.com


Sanjay Mishra
Verizon
13100 Columbia Pike
Silver Spring, MD 20904
United States of America

Email: sanjay.mishra@verizon.com
📦 where this page comes from