RFC 9388 PROPOSED STANDARD CDNI · FOOTPRINTS · METADATA

CDNI Footprints: Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union

Two new ways to describe where a downstream CDN can serve: a state or province code, and a union that combines footprint types.

On rfc-editor.org ↗
PUBLISHED
July 2023
AUTHORS
N. Sopher, S. Mishra
STREAM
IETF
BUILDS ON
RFC 8008 — CDNI Footprint & Caps
NEW FOOTPRINT TYPES
subdivisioncode and footprintunion
SUBDIVISION CODE FORM
country code, hyphen, up to three alphanumeric characters
EXAMPLE CODES
ca-on, us-ny
NESTED UNIONS
Not allowed (MUST NOT)
DOI
10.17487/RFC9388

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                         N. Sopher
Request for Comments: 9388                                         Qwilt
Updates: 8008                                                  S. Mishra
Category: Standards Track                                        Verizon
ISSN: 2070-1721                                                July 2023


Content Delivery Network Interconnection (CDNI) Footprint Types: Country
                  Subdivision Code and Footprint Union

Abstract

   Open Caching architecture is a use case of Content Delivery Network
   Interconnection (CDNI) in which the commercial Content Delivery
   Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer
   serves as the downstream CDN (dCDN).  RFC 8006 defines footprint
   types that are used for footprint objects as part of the Metadata
   interface (MI).  The footprint types are also used for the Footprint
   & Capabilities Advertisement interface (FCI) as defined in RFC 8008.
   This document defines two new footprint types.  The first footprint
   type defined is an ISO 3166-2 country subdivision code.  Defining
   this country subdivision code improves granularity for delegation as
   compared to the ISO 3166-1 country code footprint type defined in RFC
   8006.  The ISO 3166-2 country subdivision code is also added as a new
   entity domain type in the "ALTO Entity Domain Types" registry defined
   in Section 7.4 of RFC 9241.  The second footprint type defines a
   footprint union to aggregate footprint objects.  This allows for
   additive semantics over the narrowing semantics defined in Appendix B
   of RFC 8008 and therefore updates RFC 8008.  The two new footprint
   types are based on the requirements raised by Open Caching but are
   also applicable to CDNI use cases in general.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9388.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include 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
     1.1.  Terminology
     1.2.  Requirements Language
   2.  CDNI Metadata Additional Footprint Types
     2.1.  CDNI Metadata "subdivisioncode" Footprint Type
       2.1.1.  CDNI Metadata "subdivisioncode" Data Type
         2.1.1.1.  CDNI Metadata "subdivisioncode" Data Type
                 Description
       2.1.2.  CDNI Metadata "subdivisioncode" Footprint Type
               Description
     2.2.  CDNI Metadata "footprintunion" Footprint Type
       2.2.1.  CDNI Metadata "footprintunion" Data Type
       2.2.2.  CDNI Metadata "footprintunion" Footprint Type
               Description
   3.  ALTO Property Map Service Entity
     3.1.  SUBDIVISIONCODE Domain
       3.1.1.  Entity Domain Type
       3.1.2.  Domain-Specific Entity Identifiers
       3.1.3.  Hierarchy and Inheritance
   4.  IANA Considerations
     4.1.  CDNI Metadata Footprint Types
     4.2.  ALTO Entity Domain Types
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Introduction

   The Streaming Video Technology Alliance [SVTA] is a global
   association that works to solve streaming video challenges in an
   effort to improve end-user experience and adoption.  The Open Caching
   Working Group [OCWG] of the SVTA is focused on the delegation of
   video delivery requests from commercial Content Delivery Networks
   (CDNs) to a caching layer at the ISP's network.  Open Caching
   architecture is a specific use case of Content Delivery Network
   Interconnection (CDNI) where the commercial CDN is the upstream CDN
   (uCDN) and the ISP caching layer is the downstream CDN (dCDN).  The
   "Open Caching Request Routing Functional Specification" [OC-RR]
   defines the Request Routing process and the interfaces that are
   required for its provisioning.  This document defines and registers
   CDNI Footprint and Capabilities objects [RFC8008] that are required
   for Open Caching Request Routing.

   For consistency with other CDNI documents, this document follows the
   CDNI convention of using "uCDN" and "dCDN" to represent the
   commercial CDN and ISP caching layer, respectively.

   This document registers two CDNI Metadata footprint types
   (Section 7.2 of [RFC8006]) for the defined objects:

   *  Country subdivision code footprint type (e.g., for a dCDN
      advertising a footprint that is specific to a state in the United
      States of America)

   *  Footprint union footprint type (for a dCDN advertising a footprint
      that consists of a group built from multiple footprint types,
      e.g., both IPv4 and IPv6 client subnets)

1.1.  Terminology

   The following terms are used throughout this document:

   CDN:  Content Delivery Network

   Additionally, this document reuses the terminology defined in
   [RFC6707], [RFC7336], [RFC8006], and [RFC8008].  Specifically, we use
   the following CDNI abbreviations:

   uCDN:  upstream CDN (see [RFC7336])

   dCDN:  downstream CDN (see [RFC7336])

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  CDNI Metadata Additional Footprint Types

   Section 5 of [RFC8008] describes the Footprint & Capabilities
   Advertisement interface (FCI) Capability Advertisement object, which
   includes an array of CDNI footprint objects.  Each such object has a
   footprint type and a footprint value, as described in Section 4.2.2.2
   of [RFC8006].  This document defines additional footprint types,
   beyond those mentioned in [RFC8006].

2.1.  CDNI Metadata "subdivisioncode" Footprint Type

   Section 4.3.8 of [RFC8006] specifies the "countrycode" footprint type
   for listing [ISO3166-1] alpha-2 codes.  Using footprint objects of
   this type, one can define an FCI Capability Advertisement object
   footprint constraint that matches a specific country.  This document
   defines the "subdivisioncode" simple data type as well as a footprint
   type, allowing the dCDN to define constraints that match geographic
   areas with better granularity, specifically using the [ISO3166-2]
   country subdivision codes.

2.1.1.  CDNI Metadata "subdivisioncode" Data Type

   The "subdivisioncode" data type specified in Section 2.1.1.1
   describes a country-specific subdivision using a code as defined in
   [ISO3166-2].  The data type is added to the list of data types
   described in Section 4.3 of [RFC8006] that are used as properties of
   CDNI Metadata objects.

2.1.1.1.  CDNI Metadata "subdivisioncode" Data Type Description

   An [ISO3166-2] code in lowercase.  Each code consists of two parts
   separated by a hyphen.  As per [ISO3166-2], the first part is the
   [ISO3166-1] code of the country and the second part is a string of up
   to three alphanumeric characters.

   Type:  String

   Example country subdivision codes:
      *  "ca-on"

      *  "us-ny"

2.1.2.  CDNI Metadata "subdivisioncode" Footprint Type Description

   The "subdivisioncode" simple data type specified in Section 2.1.1 is
   added to the data types listed as footprint types in Section 4.2.2.2
   of [RFC8006].

   Figure 1 is an example using a footprint object of type
   "subdivisioncode".  The footprint object in this example creates a
   constraint that matches clients in the state of either New Jersey or
   New York, USA (ISO [ISO3166-2] codes "US-NJ" and "US-NY",
   respectively).

   {
     "capabilities": [
       {
         "capability-type": <CDNI capability object type>,
         "capability-value": <CDNI capability object>,
         "footprints": [
             {
                 "footprint-type": "subdivisioncode",
                 "footprint-value": ["us-nj", "us-ny"]
             }
         ]
       }
     ]
   }

        Figure 1: Illustration of Country Subdivision Code Footprint
                               Advertisement

2.2.  CDNI Metadata "footprintunion" Footprint Type

   As described in Section 5 of [RFC8008], the FCI Capability
   Advertisement object includes an array of CDNI footprint objects.
   Appendix B of [RFC8008] specifies the semantics for Footprint
   Advertisement such that multiple footprint constraints are additive.
   This implies that the advertisement of different footprint types
   narrows the dCDN's candidacy cumulatively.

   Sections 4.3.5 and 4.3.6 of [RFC8006] specify the "ipv4cidr" and the
   "ipv6cidr" footprint types, respectively, for listing IP unscoped
   address blocks.  Using footprint objects of these types, one can
   define FCI Capability Advertisement object footprint constraints that
   match either IPv4 or IPv6 clients, but not both.  This is due to the
   described "narrowing" semantic of the Footprint Objects array, as
   described in Appendix B of [RFC8008], that prevents the usage of
   these objects together to create a footprint constraint that matches
   IPv4 clients with IPv6 clients.

   Figure 2 is an example attempting to create an object that matches
   IPv4 clients of subnet "192.0.2.0/24" as well as IPv6 clients of
   subnet "2001:db8::/32".  Such a definition results in an empty list
   of clients, as the constraints are additives and a client address
   cannot be both IPv4 and IPv6.

   {
     "capabilities": [
       {
         "capability-type": <CDNI capability object type>,
         "capability-value": <CDNI capability object>,
         "footprints": [
             {
                 "footprint-type": "ipv4cidr",
                 "footprint-value": ["192.0.2.0/24"]
             },
             {
                 "footprint-type": "ipv6cidr",
                 "footprint-value": ["2001:db8::/32"]
             }
         ]
       }
     ]
   }

            Figure 2: Example of Narrowing Semantic Illustrating
                     Advertisement of a Null Footprint

   To overcome the described limitation and allow a list of footprint
   constraints that match both IPv4 and IPv6 client subnets, this
   document defines the "footprintunion" footprint type.  This footprint
   type allows the collection of multiple footprint-objects into a
   unified object.  Therefore, it resolves the above limitation and can
   be particularly applicable to unify semantically related objects: for
   example, an IPv4 CIDR together with an IPv6 CIDR or a country code
   together with a country subdivision code.

   Note: to avoid implementation complexity, a "footprintunion" MUST NOT
   list any "footprintunion" as a value.  As a union of unions is simply
   a union, this syntactic restriction does not result with any semantic
   limitation.

2.2.1.  CDNI Metadata "footprintunion" Data Type

   The "footprintunion" data type is based on the footprint object
   already defined in Section 4.2.2.2 of [RFC8006].  The footprint value
   for a "footprintunion" object is an array of footprint objects, where
   the footprint objects MUST be of any footprint type other than
   "footprintunion".

2.2.2.  CDNI Metadata "footprintunion" Footprint Type Description

   The "footprintunion" data type specified in Section 2.2.1 is added to
   the data types listed as footprint types in Section 4.2.2.2 of
   [RFC8006].

   Figure 3 is an example using a footprint union combining both IPv4
   and IPv6 client subnets.

   {
     "capabilities": [
       {
         "capability-type": <CDNI capability object type>,
         "capability-value": <CDNI capability object>,
         "footprints": [
           {
             "footprint-type": "footprintunion",
             "footprint-value": [
               {
                 "footprint-type": "ipv4cidr",
                 "footprint-value": ["192.0.2.0/24"]
               },
               {
                 "footprint-type": "ipv6cidr",
                 "footprint-value": ["2001:db8::/32"]
               }
             ]
           }
         ]
       }
     ]
   }

        Figure 3: Example of an Advertisement of Footprint Union for
       Multiple Classless Inter-Domain Routing (CIDR) Footprint Types

   The footprint union also enables composing of footprint objects based
   on the country code and country subdivision code.  In Figure 4, we
   create a constraint covering autonomous system 64496 within the USA
   (ISO alpha-2 code "US" as described in [ISO3166-1]) and the Ontario
   province of Canada (ISO code "CA-ON" as described in [ISO3166-2]).

   {
     "capabilities": [
       {
         "capability-type": <CDNI capability object type>,
         "capability-value": <CDNI capability object>,
         "footprints": [
           {
             "footprint-type": "asn",
             "footprint-value": ["as64496"]
           },
           {
             "footprint-type": "footprintunion",
             "footprint-value": [
               {
                 "footprint-type": "countrycode",
                 "footprint-value": ["us"]
               },
               {
                 "footprint-type": "subdivisioncode",
                 "footprint-value": ["ca-on"]
               }
             ]
           }
         ]
       }
     ]
   }

   Figure 4: Example of an Advertisement of Footprint Union for Multiple
                        Geographical Footprint Types

3.  ALTO Property Map Service Entity

   Section 6 of [RFC9241] describes how to represent footprint objects
   as entities in the ALTO property map.  The approach is to represent
   the footprint type as an entity domain type of the ALTO entity and
   the footprint value as its domain-specific identifier.  [RFC9241]
   further refers to the representation of footprint objects of types
   "asn" and "countrycode".  Here, we extend this definition to the
   "subdivisioncode" footprint type.

3.1.  SUBDIVISIONCODE Domain

   The SUBDIVISIONCODE domain associates property values that define
   codes for the names of the principal subdivisions.

3.1.1.  Entity Domain Type

   The entity domain type of the SUBDIVISIONCODE domain is
   "subdivisioncode" (in lowercase).

3.1.2.  Domain-Specific Entity Identifiers

   The entity identifier of an entity in a SUBDIVISIONCODE is encoded as
   an alpha-2 [ISO3166-1] country code, followed by a separator and up
   to three alphanumeric characters.

3.1.3.  Hierarchy and Inheritance

   There is no hierarchy or inheritance for properties associated with
   country subdivision codes.

4.  IANA Considerations

4.1.  CDNI Metadata Footprint Types

   Section 7.2 of [RFC8006] specifies the "CDNI Metadata Footprint
   Types" subregistry within the "Content Delivery Network
   Interconnection (CDNI) Parameters" registry.

   This document registers two footprint types in that subregistry as
   defined in Sections 2.1 and 2.2:

     +=================+=================================+===========+
     | Footprint Type  | Description                     | Reference |
     +=================+=================================+===========+
     | subdivisioncode | ISO 3166-2 country subdivision  | RFC 9388  |
     |                 | code: alpha-2 country code,     |           |
     |                 | followed by a hyphen-minus and  |           |
     |                 | up to 3 characters from A-Z;0-9 |           |
     |                 | as a code within the country    |           |
     +-----------------+---------------------------------+-----------+
     | footprintunion  | A combination of other          | RFC 9388  |
     |                 | footprint objects               |           |
     +-----------------+---------------------------------+-----------+

          Table 1: Additions to the CDNI Metadata Footprint Types
                                Subregistry

4.2.  ALTO Entity Domain Types

   Section 12.3 of [RFC9240] creates the "ALTO Entity Domain Types"
   subregistry within the "Application-Layer Traffic Optimization (ALTO)
   Protocol" registry.

   This document registers an additional ALTO Entity Domain Type within
   that subregistry:

    +=================+============+=============+==========+=========+
    | Identifier      | Entity     | Hierarchy   | Media    | Mapping |
    |                 | Identifier | and         | Type of  | to ALTO |
    |                 | Encoding   | Inheritance | Defining | Address |
    |                 |            |             | Resource | Type    |
    +=================+============+=============+==========+=========+
    | subdivisioncode | See RFC    | None        | None     | false   |
    |                 | 9388,      |             |          |         |
    |                 | Section    |             |          |         |
    |                 | 3.1.2      |             |          |         |
    +-----------------+------------+-------------+----------+---------+

       Table 2: Addition to the ALTO Entity Domain Types Subregistry

5.  Security Considerations

   This specification is in accordance with "Content Delivery Network
   Interconnection (CDNI) Metadata" and "Content Delivery Network
   Interconnection (CDNI) Request Routing: Footprint and Capabilities
   Semantics".  As such, it is subject to the security and
   confidentiality considerations as defined in Section 8 of [RFC8006]
   and in Section 7 of [RFC8008], respectively.

6.  References

6.1.  Normative References

   [ISO3166-1]
              ISO, "Codes for the representation of names of countries
              and their subdivisions -- Part 1: Country code",
              ISO 3166-1:2020, Edition 4, August 2020,
              <https://www.iso.org/standard/72482.html>.

   [ISO3166-2]
              ISO, "Codes for the representation of names of countries
              and their subdivisions -- Part 2: Country subdivision
              code", ISO 3166-2:2020, Edition 4, August 2020,
              <https://www.iso.org/standard/72483.html>.

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

   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "Content Delivery Network Interconnection (CDNI)
              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
              <https://www.rfc-editor.org/info/rfc8006>.

   [RFC8008]  Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
              R., and K. Ma, "Content Delivery Network Interconnection
              (CDNI) Request Routing: Footprint and Capabilities
              Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
              <https://www.rfc-editor.org/info/rfc8008>.

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

   [RFC9240]  Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K.
              Gao, "An Extension for Application-Layer Traffic
              Optimization (ALTO): Entity Property Maps", RFC 9240,
              DOI 10.17487/RFC9240, July 2022,
              <https://www.rfc-editor.org/info/rfc9240>.

   [RFC9241]  Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang,
              "Content Delivery Network Interconnection (CDNI) Footprint
              and Capabilities Advertisement Using Application-Layer
              Traffic Optimization (ALTO)", RFC 9241,
              DOI 10.17487/RFC9241, July 2022,
              <https://www.rfc-editor.org/info/rfc9241>.

6.2.  Informative References

   [OC-RR]    Finkelman, O., Ed., Zurat, B., Sahar, D., Klein, E.,
              Hofmann, J., Ma, K.J., Stock, M., Mishra, S., and Y.
              Gressel, "Open Caching - Request Routing Functional
              Specification", Version 2.0, 15 January 2021,
              <https://www.svta.org/product/open-cache-request-routing-
              functional-specification/>.

   [OCWG]     SVTA, "Open Caching", <https://opencaching.svta.org/>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <https://www.rfc-editor.org/info/rfc6707>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <https://www.rfc-editor.org/info/rfc7336>.

   [SVTA]     SVTA, "Streaming Video Technology Alliance",
              <https://www.svta.org/>.

Acknowledgements

   The authors would like to express their gratitude to Ori Finkelman
   and Kevin J. Ma for their guidance and reviews throughout the
   development of this document.  We would also like to thank all the
   Area Directors for their review and feedback in improving this
   document.

Authors' Addresses

   Nir B. Sopher
   Qwilt
   6, Ha'harash
   Hod HaSharon 4524079
   Israel
   Email: nir@apache.org


   Sanjay Mishra
   Verizon
   13100 Columbia Pike
   Silver Spring, MD 20904
   United States of America
   Email: sanjay.mishra@verizon.com

AI ELI5

On this page
PROBLEMCDN Interconnection footprints could name a whole country but not a state or province, and listing both IPv4 and IPv6 subnets together produced an empty footprint because multiple footprint constraints narrow each other.
MECHANISMThe RFC adds a subdivisioncode footprint type that uses ISO 3166-2 codes such as us-ny, and a footprintunion type that bundles several footprint objects so they add up instead of narrowing.
WHY IT MATTERSOpen Caching can describe a downstream CDN's reach with finer granularity and mixed footprint types. The RFC updates RFC 8008 and registers both types with IANA.

§1Why Open Caching Needs New Footprints

In Open Caching, a commercial Content Delivery Network (CDN) hands video delivery requests to a caching layer inside an ISP's network. In CDN Interconnection (CDNI) terms the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).

The dCDN advertises where it can serve using footprint objects, each with a footprint type and a footprint value. RFC 8006 defines the footprint types and RFC 8008 defines the advertisement interface. This RFC registers two more types: a country subdivision code, and a footprint union that groups footprints built from several types.

A big video company asks a local internet provider to help deliver videos. The provider needs better ways to say which neighbourhoods it covers.

§2.1The subdivisioncode Footprint Type

RFC 8006 already has a countrycode footprint type for ISO 3166-1 alpha-2 country codes. A country is a coarse unit, so this RFC adds the subdivisioncode data type, based on ISO 3166-2 country subdivision codes.

A value is written in lowercase and has two parts separated by a hyphen. The first part is the ISO 3166-1 country code and the second part is a string of up to three alphanumeric characters. The RFC's examples are ca-on and us-ny. Its advertisement example uses the footprint value ["us-nj", "us-ny"] to match clients in New Jersey or New York.

Instead of saying only the country, you can now say the state or province too, like writing the state on a letter as well as the country.

§2.2The footprintunion Footprint Type

Under the semantics in Appendix B of RFC 8008, several footprint constraints in one list are additive, which narrows the dCDN's candidacy cumulatively. That breaks an obvious case: an ipv4cidr object and an ipv6cidr object in the same list can never match any client, because an address cannot be both IPv4 and IPv6. The RFC shows this as an advertisement of a null footprint.

The footprintunion type fixes this. Its footprint value is an array of footprint objects, and the union matches what any of them matches. The RFC gives two uses: an IPv4 CIDR together with an IPv6 CIDR, and a country code together with a country subdivision code. A union can sit next to other footprints in the list, for example an asn object, which still narrows as before.

A footprintunion MUST NOT list another footprintunion as a value. A union of unions is just a union, so the rule removes implementation complexity without losing expressiveness.

A union is a bag that holds several lists of places. Anything on any list in the bag counts, but you cannot put a bag inside a bag.

FOOTPRINT UNION OF IPV4 AND IPV6 (FROM THE RFC)
footprintunion advertisement
{
  "footprint-type": "footprintunion",
  "footprint-value": [
    {
      "footprint-type": "ipv4cidr",
      "footprint-value": ["192.0.2.0/24"]
    },
    {
      "footprint-type": "ipv6cidr",
      "footprint-value": ["2001:db8::/32"]
    }
  ]
}

§3Representation in ALTO Property Maps

RFC 9241 describes how footprint objects become entities in an Application-Layer Traffic Optimization (ALTO) property map, with the footprint type as the entity domain type and the footprint value as the domain-specific identifier. This RFC extends that to subdivisioncode.

The new SUBDIVISIONCODE domain has the entity domain type subdivisioncode in lowercase. An identifier is an alpha-2 ISO 3166-1 country code, then a separator, then up to three alphanumeric characters. There is no hierarchy or inheritance for properties of country subdivision codes.

The same state-code idea also works in a second system that keeps lists about network places, using the same naming rule.

§4IANA Registrations

The RFC adds two entries to the "CDNI Metadata Footprint Types" subregistry from RFC 8006: subdivisioncode (an ISO 3166-2 code made of an alpha-2 country code, a hyphen-minus and up to 3 characters from A-Z and 0-9) and footprintunion (a combination of other footprint objects).

It also registers subdivisioncode in the "ALTO Entity Domain Types" subregistry created by RFC 9240, with hierarchy and inheritance set to None and mapping to ALTO address type set to false.

The two new kinds of place lists get official names in public registries, so everyone spells them the same way.

§5Security Considerations

This specification adds no new security machinery. It is subject to the security and confidentiality considerations in Section 8 of RFC 8006 for CDNI Metadata and in Section 7 of RFC 8008 for footprint and capabilities semantics.

The new place lists follow the same safety rules as the older ones, with nothing extra added.

§7References