WG Working Group A. Mayer Internet-Draft Univ. of Rome Tor Vergata / CNIT / Common Net Intended status: Experimental S. Salsano Expires: 17 September 2026 Univ. of Rome Tor Vergata / CNIT 16 March 2026 Global Opaque Block for IOAM Pre-allocated Trace Option draft-mayer-ioam-gob-00 Abstract Extensible metadata carried within the IOAM Pre-allocated Trace Option (PTO) can support packet-level, flow-level, or path-level processing beyond per-node trace data. This document defines the Global Opaque Block (GOB), an extension to the IOAM PTO that introduces a single pre-allocated global metadata region placed between the PTO fixed header and the node data list. The GOB carries an explicit length and schema identifier, preserves the pre-allocated PTO processing model, and can be used to transport Extensible In-band Processing (EIP) Information Elements or other structured metadata formats. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://eip- home.github.io/ioam-gob/draft-mayer-ioam-gob.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mayer-ioam-gob/. Discussion of this document takes place on the EIP SIG mailing list (mailto:eip@cnit.it), which is archived at http://postino.cnit.it/ cgi-bin/mailman/private/eip/. Source for this draft and an issue tracker can be found at https://github.com/eip-home/ioam-gob. 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/. Mayer & Salsano Expires 17 September 2026 [Page 1] Internet-Draft IOAM GOB March 2026 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 17 September 2026. Copyright Notice Copyright (c) 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4. GOB Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PTO Layout with GOB . . . . . . . . . . . . . . . . . . . 5 4.2. GOB Header Fields . . . . . . . . . . . . . . . . . . . . 5 4.3. Byte-Level Layout . . . . . . . . . . . . . . . . . . . . 6 5. Length and Alignment Rules . . . . . . . . . . . . . . . . . 8 5.1. GOB Length . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Internal PTO Offsets . . . . . . . . . . . . . . . . . . 8 5.3. IOAM Option Length and Hop-by-Hop Header Length . . . . . 9 5.4. Alignment Semantics . . . . . . . . . . . . . . . . . . . 9 5.5. Preservation of PTO Semantics . . . . . . . . . . . . . . 10 6. Processing Semantics . . . . . . . . . . . . . . . . . . . . 10 6.1. Ingress Node Behavior . . . . . . . . . . . . . . . . . . 10 6.2. Transit Node Behavior . . . . . . . . . . . . . . . . . . 11 6.3. Egress or Collector Behavior . . . . . . . . . . . . . . 11 7. Relation to PTO Semantics . . . . . . . . . . . . . . . . . . 11 8. Schema Semantics and Extensibility . . . . . . . . . . . . . 12 9. Integration with EIP . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Mayer & Salsano Expires 17 September 2026 [Page 2] Internet-Draft IOAM GOB March 2026 1. Introduction The IOAM Pre-allocated Trace Option (PTO) defined in [RFC9197] and [RFC9486] provides a structured way to carry in-band operational and telemetry information along a packet path. In the PTO model, the encapsulating node pre-allocates space for node data that can be filled by IOAM-capable nodes along the path. This document defines an extension to the IOAM PTO called the Global Opaque Block (GOB). The GOB is a global metadata region that appears once in the PTO, immediately after the PTO fixed header and before the per-node node data list. The GOB is identified by a presence bit in the PTO header and includes its own length and schema fields. The GOB enables the carriage of structured global metadata within the IOAM PTO, while preserving the existing PTO processing model for per- node trace data. In particular, the GOB can carry Extensible In-band Processing (EIP) Information Elements or other schema-driven metadata formats, without modifying the semantics of the node data list. The GOB is pre-allocated by the encapsulating node. Transit nodes MAY read or update the GOB payload, subject to the bounds established at encapsulation time, but they MUST NOT alter the overall GOB size or the layout of the enclosing PTO option. This document specifies the GOB format, length and alignment rules, and processing behavior for encapsulating, transit, and egress or collector nodes. 2. Conventions and Definitions 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. The following terms are used in this document: GOB: Global Opaque Block. A structured global metadata region inserted into the IOAM PTO. GOB Header: The 4-octet fixed header of the GOB, containing the GOB Len and Schema fields. GOB Payload: The payload that follows the GOB Header. Its size is determined by the GOB Len field. Mayer & Salsano Expires 17 September 2026 [Page 3] Internet-Draft IOAM GOB March 2026 PTO: The IOAM Pre-allocated Trace Option defined in [RFC9197] and [RFC9486]. Node Data List: The sequence of pre-allocated per-node data slots defined by the PTO format. Ingress Node: The encapsulating node that inserts the IOAM PTO and, when present, allocates and initializes the GOB. Transit Node: An IOAM-capable node along the path that may process the PTO and may read or update the GOB payload. Egress or Collector Node: A node that removes, terminates, exports, or otherwise interprets the IOAM information carried in the packet. Schema: A 24-bit identifier that specifies how the GOB Payload is to be interpreted. 3. Design Overview The GOB extends the IOAM PTO with a global metadata area that is logically distinct from the per-node node data list. It is intended for metadata that applies to the packet, flow, or path as a whole, rather than to a specific transit node. The GOB appears at most once in a PTO option. When present, it is placed immediately after the PTO fixed header and before the start of the node data list. The GOB consists of a fixed 4-octet header followed by a variable-length payload. The GOB preserves the pre-allocated nature of the PTO model. The ingress node allocates the GOB space at encapsulation time and determines its size, its schema, and the overall PTO layout. Transit nodes MAY modify the contents of the GOB payload, but MUST NOT modify the GOB Len field, the Schema field, or any PTO fixed-header fields that precede the GOB. The GOB is intended to support structured metadata formats. One relevant use case is the carriage of Extensible In-band Processing (EIP) Information Elements, but the mechanism is not restricted to EIP and may be used with other schema-driven payload formats. The addition of the GOB does not change the semantics of the per-node node data list. The GOB complements the PTO by adding a global opaque area while leaving the existing per-node trace structure intact. Mayer & Salsano Expires 17 September 2026 [Page 4] Internet-Draft IOAM GOB March 2026 4. GOB Format 4.1. PTO Layout with GOB When the Global Opaque Block (GOB) is present, the IOAM Pre-allocated Trace Option (PTO) is extended by inserting a single GOB between the PTO fixed header and the Node Data List. The resulting layout is: 1. PTO fixed header 2. GOB Header 3. GOB Payload 4. Node Data List 5. Tail padding, if required to satisfy alignment of the enclosing Hop-by-Hop Options header The GOB is indicated by the G bit in the PTO fixed header. If the G bit is clear, no GOB is present and PTO processing follows the base PTO format. The GOB appears at most once in a PTO option. 4.2. GOB Header Fields The GOB Header is 4 octets long and contains the following fields: GOB Len: An 8-bit field that specifies the size of the GOB Payload in units of 4 octets. Schema: A 24-bit field that identifies the format of the GOB Payload. The total size of the GOB is therefore: GOB_PLEN = GOB_Len * 4 GOB_SIZE = 4 + GOB_PLEN where the first 4 octets correspond to the GOB Header itself. Mayer & Salsano Expires 17 September 2026 [Page 5] Internet-Draft IOAM GOB March 2026 The Schema field allows the GOB Payload to be interpreted according to a structured format. One important use case is the carriage of Extensible In-band Processing (EIP) Information Elements, but the GOB is not limited to EIP and may carry other schema-driven metadata formats. A Schema value of 0 indicates a locally defined or domain-specific format. 4.3. Byte-Level Layout The following figure shows the byte-level layout of the IOAM PTO with the GOB present. Offset 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | PadN Opt | PadN OptLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | IOAM Opt Len | Reserved | IOAM Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID (16b) |NodeLen | Flags |RemainingLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM Trace-Type (24b) |Reserved |Ve |G| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GOB Len (8b) | Schema (24b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GOB Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Node Data List ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IOAM PTO with Global Opaque Block (GOB) More explicitly, the internal structure is: Mayer & Salsano Expires 17 September 2026 [Page 6] Internet-Draft IOAM GOB March 2026 Offset 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | PadN Opt | PadN OptLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opt Type | IOAM Opt Len | Reserved | IOAM Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | Namespace-ID (16b) |NodeLen | Flags |RemainingLen | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (A) | IOAM Trace-Type (24b) |Reserved |Ve |G| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ GOB_HDR | GOB Len (8b) | Schema (24b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | P Y = | GOB Payload | a GOB_SIZE | | y ~ ~ l | | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | | | | Node Data List [0] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | | a | Node Data List [1] | t | | a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p | | a | Node Data List [n-1] | c | | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Node Data List [n] | | | | | Y' +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | PadN Opt | PadN OptLen | Padding 16 bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ALG(Y',8) \_________________________8-byte aligned ________________________/ = Y'' Figure 2: Detailed PTO layout with GOB, Node Data List, and tail padding Mayer & Salsano Expires 17 September 2026 [Page 7] Internet-Draft IOAM GOB March 2026 The GOB Header is placed immediately after the PTO fixed header. The GOB Payload immediately follows the GOB Header. The Node Data List begins immediately after the GOB Payload. Any final tail padding is added only to satisfy alignment requirements of the enclosing Hop-by- Hop Options header. 5. Length and Alignment Rules This section defines the length relations used when the GOB is present in the IOAM PTO. 5.1. GOB Length The GOB Payload length is determined by the GOB Len field: GOB_PLEN = GOB_Len * 4 The total GOB size, including the fixed 4-octet GOB Header, is: GOB_SIZE = 4 + GOB_PLEN The GOB Len field is set by the ingress node at encapsulation time. Transit nodes MAY modify the content of the GOB Payload, but MUST NOT modify the GOB Len field and therefore MUST NOT alter the total GOB size. 5.2. Internal PTO Offsets Let: * Y be the offset immediately following the GOB Payload; * Y' be the offset immediately following the Node Data List; * Y'' be the IOAM option length rounded up to the next multiple of 8 octets. Then: Y = (sizeof(IOAM_TLV) - 2) + sizeof(IOAM_PTO_HDR) + GOB_SIZE Y' = Y + RemainingLen * 4 Y'' = ALIGN(Y', 8) In these expressions: * sizeof(IOAM_TLV) - 2 excludes the Option Type and Option Length octets already accounted for in the option layout; Mayer & Salsano Expires 17 September 2026 [Page 8] Internet-Draft IOAM GOB March 2026 * sizeof(IOAM_PTO_HDR) is the fixed PTO header size; * RemainingLen retains its PTO meaning and determines the amount of pre-allocated space associated with the Node Data List. The Node Data List therefore starts immediately after the GOB and spans RemainingLen * 4 octets. 5.3. IOAM Option Length and Hop-by-Hop Header Length The IOAM Option Length field MUST be set to Y'', that is, to the total internal length of the IOAM option after rounding up to the required alignment. The enclosing Hop-by-Hop Options header length is derived from the total size of the header, including: * the 2-octet Next Header and Hdr Ext Len fields; * any PadN option used to align the start of the IOAM option; * the IOAM option itself, including any final tail padding. Let HBH_LEN denote the total Hop-by-Hop Options header size in octets. Then: HBH_LEN = ALIGN(4 + sizeof(IOAM_PTO_HDR) + sizeof(GOB_HDR) + GOB_Len * 4 + RemainingLen * 4, 8) where the leading 4 octets account for: * 2 octets for Next Header and Hdr Ext Len; * 2 octets for the PadN option that aligns the IOAM option start. The IPv6 Hdr Ext Len field is encoded as: Hdr Ext Len = HBH_LEN / 8 - 1 5.4. Alignment Semantics As specified in [RFC8200], the Hop-by-Hop Options header is encoded so that its total length is a multiple of 8 octets, and the Hdr Ext Len field carries that length in 8-octet units, not including the first 8 octets. Mayer & Salsano Expires 17 September 2026 [Page 9] Internet-Draft IOAM GOB March 2026 The final tail padding used to align the enclosing Hop-by-Hop Options header to an 8-octet boundary is not part of the GOB and is not part of the Node Data List. More specifically: * Y identifies the end of the GOB; * Y' identifies the end of the Node Data List; * Y'' identifies the aligned end of the IOAM option. The difference between Y' and Y'' is due only to final alignment padding and does not carry GOB or node-data semantics. 5.5. Preservation of PTO Semantics The presence of the GOB does not alter the semantics of RemainingLen or the pre-allocated nature of the PTO. The ingress node determines, at encapsulation time: * the GOB size; * the start of the Node Data List; * the size of the Node Data List; * the final aligned IOAM option length. Transit nodes operate only within the pre-allocated bounds of the GOB Payload and the Node Data List, and MUST NOT change the overall layout of the PTO option. In this way, the pre-allocated model of the PTO is preserved while extending the option with a structured global metadata region. 6. Processing Semantics 6.1. Ingress Node Behavior An ingress node that inserts a GOB into the PTO: * MUST set the G bit to 1; * MUST allocate the full GOB space at encapsulation time; * MUST set the GOB Len field; Mayer & Salsano Expires 17 September 2026 [Page 10] Internet-Draft IOAM GOB March 2026 * MUST set the Schema field; * MUST determine the final PTO layout, including the GOB, the Node Data List, and any required tail padding. The ingress node MAY initialize the GOB Payload with structured metadata, zero values, or other schema-defined initial content. 6.2. Transit Node Behavior A transit node that processes a PTO containing a GOB: * MAY read the GOB Payload; * MAY update fields within the GOB Payload, subject to the schema in use; * MUST NOT modify the GOB Len field; * MUST NOT modify the Schema field; * MUST NOT modify PTO fixed-header fields that precede the GOB; * MUST NOT change the overall size or layout of the PTO option. A transit node MUST confine any GOB update to the pre-allocated GOB Payload bounds established by the ingress node. 6.3. Egress or Collector Behavior An egress or collector node that processes a PTO containing a GOB: * MAY parse the GOB Payload according to the Schema field; * MAY export the GOB content as structured metadata or as raw bytes; * MAY ignore the GOB Payload if the Schema value is unknown or not supported. If the Schema value is unknown, the node MUST NOT infer semantics beyond the presence and length of the GOB. 7. Relation to PTO Semantics The GOB preserves the pre-allocated semantics of the IOAM PTO. Mayer & Salsano Expires 17 September 2026 [Page 11] Internet-Draft IOAM GOB March 2026 The ingress node continues to determine the overall PTO allocation at encapsulation time. This includes the size of the node data list and, when present, the size of the GOB. Transit nodes operate only within the pre-allocated space and do not change the overall layout of the PTO. The Node Data List retains its existing semantics and processing model. The GOB does not redefine the per-node trace data structure and does not replace the node data list. Instead, it introduces a distinct global metadata region placed before the node data list. In this sense, the pre-allocated nature of the PTO applies both to the per-node trace space and to the GOB. The GOB extends the PTO with a global opaque area while preserving the original PTO processing model. 8. Schema Semantics and Extensibility The Schema field identifies the format of the GOB Payload. A Schema value may identify: * a sequence of EIP Information Elements; * another structured metadata format defined by a specification; * a locally defined or domain-specific format. This document defines the GOB container, but does not define the internal syntax of individual schema-specific payloads. The semantics of the GOB Payload therefore depend on the specification associated with the Schema value in use. Future specifications may define registries, allocation policies, or schema-specific processing rules for GOB Payload formats. 9. Integration with EIP One important use of the GOB is the carriage of Extensible In-band Processing (EIP) Information Elements. The GOB provides a natural container for EIP within the IOAM PTO because it offers a single global metadata region with explicit length and schema identification, distinct from the per-node trace data. This makes it suitable for metadata that is flow-level, packet-level, or path-level rather than node-local. Mayer & Salsano Expires 17 September 2026 [Page 12] Internet-Draft IOAM GOB March 2026 The relationship between EIP and GOB is architectural rather than exclusive. The GOB can carry EIP Information Elements, but it may also carry other structured metadata formats. 10. Security Considerations The GOB introduces a global metadata region that may be read or modified by on-path nodes. Unauthorized access to, or modification of, the GOB Payload can affect telemetry interpretation, service behavior, or policy enforcement. For this reason, deployments of the GOB SHOULD be limited to controlled or trusted domains, consistent with the limited-domain assumptions often applied to IOAM deployments. The security implications of the GOB Payload also depend on the Schema in use. Some schemas may carry purely observational metadata, while others may influence packet treatment or convey more sensitive information. Schema-specific specifications SHOULD describe any additional confidentiality, integrity, or authorization requirements. 11. IANA Considerations This document defines the Global Opaque Block (GOB) as an extension to the IOAM Pre-allocated Trace Option. This version of the document does not request IANA actions. Future versions of this document may request updates to the relevant IOAM or IPv6 registries related to G-bit usage and associated Schema handling. 12. References 12.1. Normative References [IANA-ioam-types] IANA, "IOAM Data Field Types", n.d., . [IANA-ipv6-parameters] IANA, "Internet Protocol Version 6 (IPv6) Parameters", n.d., . Mayer & Salsano Expires 17 September 2026 [Page 13] Internet-Draft IOAM GOB March 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023, . 12.2. Informative References [draft-eip-arch] al., S. S. et., "Extensible In-band Processing (EIP) Architecture and Framework", Internet-Draft draft-eip- arch, 2026, . [salsano2025eipioam] Salsano, S., Mayer, A., Sidoretti, G., Loreti, P., Bracciale, L., ElBakoury, H., and D. R. Lopez, "Integrating Extensible In-Band Processing (EIP) into the IOAM Framework: A Unified Approach to In-Packet Telemetry and Metadata", IEEE CSCN 2025 Conference, 2025. Acknowledgments TBD. Authors' Addresses Andrea Mayer Univ. of Rome Tor Vergata / CNIT / Common Net Email: andrea.mayer@uniroma2.it Mayer & Salsano Expires 17 September 2026 [Page 14] Internet-Draft IOAM GOB March 2026 Stefano Salsano Univ. of Rome Tor Vergata / CNIT Email: stefano.salsano@uniroma2.it Mayer & Salsano Expires 17 September 2026 [Page 15]