Secure Hybrid Network Monitoring - Path Characteristics Service
draft-oiwa-path-characteristics-service-01

Network Working Group                                            Y. OIWA
Internet-Draft                                                AIST Japan
Intended status: Experimental                                   S. Kanno
Expires: 7 January 2027                                        Y. Sakemi
                                                             GMO CONNECT
                                                             6 July 2026

    Secure Hybrid Network Monitoring - Path Characteristics Service
               draft-oiwa-path-characteristics-service-01

Abstract

   "Secure hybrid network monitoring – Problem statement"
   [I-D.oiwa-secure-hybrid-network] identifies challenges in securing
   and monitoring networks deployed across hybrid and mixed cloud
   environments.  This document introduces the Path Characteristics
   Service (PCS), a service that enables applications and operators to
   verify whether a given network path conforms to their declared
   requirements ("intent") regarding security, compliance, and
   operational properties.  Unlike traditional network monitoring, PCS
   does not expose raw network state; instead, it evaluates the user's
   intent against the actual path characteristics and returns a
   conformance result (match or no-match).  This intent matching
   approach allows multi-stakeholder environments to verify path
   properties without disclosing sensitive internal infrastructure
   details.  This document describes an architecture and interfaces for
   PCS; it expresses recommended behaviors and constraints using the
   normative keywords of BCP 14, but does not specify a wire protocol or
   its encoding.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2027.

OIWA, et al.             Expires 7 January 2027                 [Page 1]
Internet-Draft                 SHNM - PCS                      July 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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   5
   2.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Intent Matching Model . . . . . . . . . . . . . . . . . .   6
     2.2.  Architecture Design Goals . . . . . . . . . . . . . . . .   7
     2.3.  System Capabilities . . . . . . . . . . . . . . . . . . .   8
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Overlay and Underlay Path Views . . . . . . . . . . . . .   9
   4.  Recursive Composition of PCS  . . . . . . . . . . . . . . . .  10
     4.1.  Service Scope . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  PCS-to-PCS Query Flow . . . . . . . . . . . . . . . . . .  11
     4.3.  Stop Conditions and Loop Prevention . . . . . . . . . . .  12
     4.4.  Security, Trust, and Provenance in Recursion  . . . . . .  12
     4.5.  Result Composition and Conflict Handling  . . . . . . . .  13
     4.6.  Example Fields  . . . . . . . . . . . . . . . . . . . . .  13
     4.7.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  15
   5.  Roles and Responsibilities  . . . . . . . . . . . . . . . . .  15
   6.  PCS Main Functions  . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Per-Hop Evidence Representation . . . . . . . . . . . . .  17
   7.  Path Characteristics Service (PCS)  . . . . . . . . . . . . .  18
     7.1.  Identification and Authentication . . . . . . . . . . . .  18
     7.2.  Subscription for Intent Matching Updates  . . . . . . . .  19
   8.  PCS Query . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  PCS Query Data Model  . . . . . . . . . . . . . . . . . .  20
       8.1.1.  Top-Level Structure . . . . . . . . . . . . . . . . .  20
       8.1.2.  Field Definitions . . . . . . . . . . . . . . . . . .  21
       8.1.3.  Synchronous Query Example . . . . . . . . . . . . . .  24
       8.1.4.  Example Query with Multiple Candidates  . . . . . . .  25
   9.  PCS Response  . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  PCS Response Data Model . . . . . . . . . . . . . . . . .  25
       9.1.1.  Top-Level Structure . . . . . . . . . . . . . . . . .  26
       9.1.2.  Field Definitions . . . . . . . . . . . . . . . . . .  26

OIWA, et al.             Expires 7 January 2027                 [Page 2]
Internet-Draft                 SHNM - PCS                      July 2026

       9.1.3.  Match Response Example  . . . . . . . . . . . . . . .  32
       9.1.4.  No-Match Response Example . . . . . . . . . . . . . .  32
       9.1.5.  Streaming Notification Event Model  . . . . . . . . .  33
       9.1.6.  Webhook Example . . . . . . . . . . . . . . . . . . .  33
       9.1.7.  Notes for Standardization . . . . . . . . . . . . . .  34
     9.2.  Intent Matching Verification Levels . . . . . . . . . . .  34
       9.2.1.  Traced present  . . . . . . . . . . . . . . . . . . .  35
       9.2.2.  Transparent present . . . . . . . . . . . . . . . . .  35
       9.2.3.  Traceable opaque present  . . . . . . . . . . . . . .  35
       9.2.4.  Opaque present  . . . . . . . . . . . . . . . . . . .  35
       9.2.5.  Traceable opaque future . . . . . . . . . . . . . . .  35
       9.2.6.  Opaque future . . . . . . . . . . . . . . . . . . . .  36
   10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  36
     10.1.  Case 1: Data Residency / Sovereignty Compliance  . . . .  36
     10.2.  Case 2: Critical Infrastructure Operator Validation  . .  37
     10.3.  Case 3: Incident Forensics and Audit . . . . . . . . . .  37
     10.4.  Future Use Case Candidates . . . . . . . . . . . . . . .  38
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  38
     11.1.  Service Scope and Probing Prevention . . . . . . . . . .  39
     11.2.  Recursion Depth Information Leakage  . . . . . . . . . .  39
     11.3.  Geographic Constraint Design Rationale . . . . . . . . .  40
     11.4.  Telemetry Ingestion  . . . . . . . . . . . . . . . . . .  40
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  40
     13.2.  Informative References . . . . . . . . . . . . . . . . .  41
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  41
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

1.  Introduction

   Virtualized resources such as cloud computing infrastructure are
   rapidly replacing traditional network and computing environments,
   including on-premises servers and locally managed clusters.  In
   hybrid and multi-cloud deployments [ISO-IEC-5140], the physical
   characteristics of resources — e.g., server location, local network
   topology, or the operators of network devices — are typically hidden
   from users in exchange for flexibility, redundancy, and cost
   benefits.  At the same time, cryptographic protection mechanisms such
   as TLS or IPsec are widely used to secure communications into and out
   of these systems.

   However, as identified in [I-D.oiwa-secure-hybrid-network], there
   remain many cases where application-level security depends not only
   on encrypted communication channels but also on specific properties
   of the underlying network and intermediate nodes.  Examples include:

OIWA, et al.             Expires 7 January 2027                 [Page 3]
Internet-Draft                 SHNM - PCS                      July 2026

   *  Sensitivity to traffic analysis, where encrypted flows may still
      leak metadata;

   *  Legal or regulatory requirements mandating that certain properties
      (e.g., jurisdiction, physical location, or operational control) be
      verifiable;

   *  Threats such as Denial-of-Service (DoS) attacks, which cannot be
      prevented solely through encryption.

   In non-virtualized, self-managed networks, operators can use existing
   mechanisms (e.g., NETCONF, path validation) to obtain status and
   operational information about network components.  These mechanisms
   are not sufficient in modern hybrid or multi-cloud settings, where
   visibility into the underlying infrastructure is significantly
   limited.

   To address these gaps, this document introduces the Path
   Characteristics Service (PCS) as a technical approach for
   continuously verifying that the network paths used in complex
   environments such as hybrid or multi-cloud deployments conform to the
   user’s declared requirements (intent).  PCS is intended to provide a
   common framework for securely evaluating path-level conformance,
   thereby enabling high-security applications to maintain trust in the
   network even in the presence of virtualization and limited direct
   control.

   This document builds upon the problem statement and gap analysis
   presented in [I-D.oiwa-secure-hybrid-network], and outlines a
   potential PCS architecture and its role in addressing the identified
   challenges.

   PCS is a service for verifying whether the characteristics of network
   paths used by an application or tenant conform to the user’s declared
   intent.  In this document, “path characteristics” include properties
   that can affect security or compliance (e.g., jurisdictional
   residency, operator identity along the path, path segments and
   facilities traversed, transport security properties, or exposure to
   known risks). “Intent” refers to the set of declarative requirements
   that a PCS Client submits, describing the desired or required
   properties of a network path.  PCS defines:

   *  (1) a data model and processing model for using path-related
      evidence already produced by existing telemetry mechanisms (e.g.,
      IPFIX, NETCONF, gNMI, BGP-LS, SNMP),

   *  (2) methods to reconstruct a coherent view of the path and its
      attributes from such evidence,

OIWA, et al.             Expires 7 January 2027                 [Page 4]
Internet-Draft                 SHNM - PCS                      July 2026

   *  (3) an intent matching mechanism that evaluates whether a given
      path conforms to the user’s declared intent and returns a
      conformance result (match or no-match).

   A key design principle of PCS is that it does not return raw network
   state to the requesting client.  Instead, it returns the result of
   evaluating the user’s intent against the actual path characteristics.
   This approach prevents the disclosure of sensitive internal network
   details (e.g., ISP topology, internal routing structure) while still
   providing actionable conformance information.

   PCS does not mandate a specific transport or routing technology, is
   not itself a traffic-measurement protocol, and does not replace
   existing routing- or control-plane security mechanisms.  The
   acquisition of raw telemetry from network elements is performed by
   existing telemetry mechanisms and is outside the scope of PCS; PCS
   only gathers already-acquired telemetry into a form usable for intent
   evaluation.  PCS provides a verifiable interface and data model that
   higher-layer systems can use to reason about path trust and to
   trigger operational actions.

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

   Normative keywords in this document apply to PCS architectural
   behavior and to its security and privacy properties; they do not
   define a specific wire protocol binding or encoding.

   The following terms are used throughout this document:

   Intent:  A declarative set of requirements submitted by a PCS Client,
      describing the desired or required properties of a network path
      (e.g., jurisdictional constraints, operator restrictions, latency
      thresholds).  Note: PCS uses "intent" in a narrower, query-scoped
      sense compared to the broader lifecycle-oriented definition in
      Intent-Based Networking [RFC9315].  In PCS, an intent is a single
      declarative query evaluated against current path characteristics,
      rather than a persistent network-wide policy objective.

   Intent Matching:  The process by which a PCS Server evaluates whether
      the actual characteristics of a network path conform to the
      client's declared intent, returning a conformance result (match or
      no-match) rather than raw network state.

OIWA, et al.             Expires 7 January 2027                 [Page 5]
Internet-Draft                 SHNM - PCS                      July 2026

   Service Scope:  The predefined set of intent types and path
      properties that a PCS Server is authorized and configured to
      evaluate, as agreed upon between the PCS operator and its clients.

   Acquire:  The extraction of raw telemetry from network elements,
      performed by existing telemetry mechanisms (e.g., IPFIX, NETCONF,
      gNMI, BGP-LS, SNMP) using their own push (export or streaming) or
      pull (query or polling) models.  Telemetry acquisition — including
      specific styles sometimes called telemetry fetch (pull) or
      telemetry capture (observation) — is outside the scope of PCS.
      PCS does not define how telemetry is acquired.

   Gather:  The PCS Server's internal process of aggregating and
      normalizing already-acquired telemetry into a form usable for
      intent evaluation (a PathView).  Gathering is performed within the
      scope of PCS; it consumes telemetry produced by existing
      mechanisms and does not itself acquire telemetry from the network.
      In short, PCS gathers already-acquired telemetry into a form
      usable for judgment; it does not acquire telemetry from the
      network.

   PathView:  An internal data structure assembled by the PCS Server
      that represents the reconstructed end-to-end path and its per-
      segment attributes (e.g., operator identity, geolocation, security
      properties, metrics).  A PathView is built from per-hop telemetry
      evidence made available by operator-controlled telemetry
      mechanisms in the operator's domain (e.g., IPFIX, gNMI, BGP-LS)
      and gathered by the PCS Server and, where recursive composition is
      used, from conformance results received from other PCS Servers.
      The PathView serves as the input to the PCS Server's intent
      matching engine.  By default, the PathView is not disclosed to PCS
      Clients; it may be included in a response only when the service
      scope permits and the return_pathview option is enabled.

2.  Design Principles

2.1.  Intent Matching Model

   The core design principle of PCS is the intent matching model: PCS
   does not return raw network state or detailed internal topology to
   the requesting client.  Instead, the client declares its requirements
   (intent) — such as jurisdictional constraints, approved operators, or
   latency thresholds — and PCS evaluates whether the actual path
   characteristics satisfy that intent.  The result is a conformance
   decision (match or no-match), optionally accompanied by a
   verification level and provenance metadata.

   This model provides two key benefits:

OIWA, et al.             Expires 7 January 2027                 [Page 6]
Internet-Draft                 SHNM - PCS                      July 2026

   Privacy preservation:  By returning only conformance results rather
      than detailed network state, PCS prevents the disclosure of
      sensitive internal infrastructure information (e.g., ISP topology,
      internal AS structure, router-level details) to external parties.

   Interoperability across trust boundaries:  In multi-stakeholder
      environments, each operator can participate in PCS without being
      forced to reveal proprietary network details.  Operators respond
      to intent queries within their pre-agreed service scope,
      maintaining operational independence while enabling end-to-end
      path verification.

2.2.  Architecture Design Goals

   To address the gaps identified above, this document describes a
   distributed architecture for assuring the network operation integrity
   for mixed and hybrid cloud applications.  Such a system should:

   *  Have a modeling of the network infrastructure in two dimensions:
      one axis in parallel to the network paths and forwarding
      directions, and the other axis for the layers of protocols.

   *  Have enough knowledge on the complex dependency of software and
      protocols; not only the network packet-forwarding technologies but
      also surrounding areas such as addressing and DNS must be covered.

   *  Have explicit handling of tunneling and virtualization aspects,
      both at the protocol level (e.g., VPNs, IP-IP, IPsec) and at the
      infrastructure level (IaC, Network-as-a-Service, Wavelength
      Division Multiplexing, etc.)

   *  Consolidate operation information at each operator's level and
      consider their pre-determined operation principles for evaluating
      integrity.

   *  Address management-oriented risks of infrastructure management,
      including non-network aspects.

   A possible implementation of such a system could leverage distributed
   network security coordination between operators and users of cloud
   and network infrastructure.  Rather than adopting a "disclose all"
   approach, this design would maintain both flexibility and efficiency
   for multi-cloud applications.

   In particular, PCS can clarify the status of monitored communications
   by employing standardized telemetry mechanisms as defined in
   [RFC9232].  By adopting these mechanisms, it becomes possible to
   gather, aggregate, and share relevant operational data about network

OIWA, et al.             Expires 7 January 2027                 [Page 7]
Internet-Draft                 SHNM - PCS                      July 2026

   paths and security status without extending the specifications of
   existing networks or exposing sensitive internal details.  This
   approach enables stakeholders to verify the integrity and security of
   communications across hybrid and multi-cloud environments, while
   respecting the confidentiality requirements of each operator.

2.3.  System Capabilities

   As a component of the Secure Hybrid Network Monitoring framework
   [I-D.oiwa-secure-hybrid-network], the Path Characteristics Service
   (PCS) SHOULD:

   *  Have the ability to declare intent (a set of required path
      properties) from an infrastructure user to infrastructure
      providers.  In a hybrid cloud or layered systems, it will include
      communications between operators of infrastructure/cloud systems.

   *  Have the ability to return a conformance result (match/no-match)
      for the current path status against the declared intent.

   *  Provide some choices on the transparency levels about the
      internals of the cloud service infrastructure, consistent with the
      intent matching model.

   *  Have some traceability provisions for troubleshooting, if there
      are opacities in intent matching replies.

   *  Have enough consideration for various tunneling and virtualization
      technologies.

   *  Have a bidirectional interface to system-level security management
      systems, such as Continuous Diagnostics and Mitigations (CDM)
      dashboards.

3.  Architecture Overview

   The PCS architecture is organized into three conceptual layers, shown
   in Figure 1:

   PCS Layer:  Hosts PCS Servers and Clients, which exchange intent-
      based queries and conformance responses.  A PCS Client submits its
      intent (declarative requirements) to a PCS Server.  Internally, a
      PCS Server gathers per-hop telemetry evidence made available by
      operator-controlled telemetry mechanisms, reconstructs PathViews,
      and feeds them into the intent matching engine.  PCS instances may
      also recursively query other PCS instances in adjacent
      administrative domains to obtain a broader or deeper view of the
      path.

OIWA, et al.             Expires 7 January 2027                 [Page 8]
Internet-Draft                 SHNM - PCS                      July 2026

   Telemetry Layer:  Comprises the existing telemetry mechanisms (e.g.,
      IPFIX [RFC7011], gNMI, BGP-LS, SNMP, NETCONF) that convey per-
      element network attributes from the Network Layer to the PCS
      Server.  PCS does not define a new telemetry-collection protocol;
      the choice of mechanism is an operator-internal concern and is
      outside the scope of PCS.  This layer may also include local
      caches and topology databases that assist in normalization.

   Network Layer:  Comprises the physical and virtual network elements
      such as routers, switches, links, VPN endpoints, and SDN-
      controlled domains.  These elements generate raw operational data
      (e.g., IPFIX flow records, BGP updates, interface statistics),
      which existing telemetry mechanisms convey to the PCS Server as
      per-hop evidence.

   +-----------------------------------------------------------+
   |                       PCS Layer                           |
   |   [PCS Client]  <-->  [PCS Server]  <-->  [PCS Server]    |
   |                  (gather + reconstruct +                  |
   |                   intent matching + PCS-to-PCS)           |
   +----------------------------^------------------------------+
                                | telemetry evidence
   +----------------------------|------------------------------+
   |             Telemetry Layer (outside PCS scope)           |
   |   existing mechanisms:  [IPFIX] [gNMI] [BGP-LS] [SNMP]    |
   |   [NETCONF]   [Cache]   [Topology DB]                     |
   +----------------------------^------------------------------+
                                | observed data
   +----------------------------|------------------------------+
   |                     Network Layer                         |
   |   [Routers/Switches]  [Links]  [VPNs]  [SDN Domains]      |
   +-----------------------------------------------------------+

                   Figure 1: Three-layer PCS architecture

3.1.  Overlay and Underlay Path Views

   In environments that include VPN tunnels, IP-IP tunnels, or other
   encapsulation mechanisms, a single end-to-end communication may
   traverse multiple layers of network infrastructure simultaneously.
   PCS recognizes that the same physical communication may present
   different path characteristics depending on the layer at which it is
   observed:

   Overlay view:  The path as seen at the tunnel or virtual network
      level.  From this perspective, a VPN tunnel appears as a single
      hop between its endpoints, regardless of the number of physical
      devices traversed underneath.

OIWA, et al.             Expires 7 January 2027                 [Page 9]
Internet-Draft                 SHNM - PCS                      July 2026

   Underlay view:  The path as seen at the physical network level.  This
      view reflects the actual intermediate routers, switches, and links
      that carry the encapsulated traffic.

   PCS evaluates intent against the appropriate layer based on the query
   context.  For example, a jurisdictional compliance intent may need to
   be evaluated at the underlay level (to verify physical locations of
   all intermediate nodes), while an operator validation intent may be
   satisfied at the overlay level (verifying only the VPN provider).
   The relationship between overlay and underlay views is inherently
   recursive and aligns with the nested path property model described
   for network tunnels and software-defined networks in this document.

   PCS also supports recursive composition across administrative
   boundaries, enabling coherent path evaluation even in deeply nested
   environments.  The recursive composition mechanism is described in
   Section 4.

4.  Recursive Composition of PCS

   PCS supports recursive composition, whereby a PCS Server MAY act as a
   client of other PCS Servers to obtain path-segment information across
   administrative boundaries.  This enables path characteristics to be
   gathered at multiple granularities: point-level (e.g., device, hop,
   facility) and administrative-domain-level (e.g., segment,
   administrative domain, cloud region).  A recursive PCS deployment can
   therefore provide a coherent PathView even in deeply nested
   environments (e.g., VPN-over-VPN, SDN slices over WAN, multi-cloud
   overlays).

4.1.  Service Scope

   A PCS Server responds to intent queries only within the bounds of a
   pre-agreed service scope (also referred to as a service menu).  The
   service scope defines the set of intent types, path properties, and
   geographic/topological ranges that a given PCS Server is authorized
   and configured to evaluate.

   *  A PCS Server MUST NOT respond to queries that fall outside its
      service scope.  For such queries, the server SHOULD return an
      error indicating that the requested evaluation is outside the
      agreed service scope (e.g., HTTP 403 or an equivalent PCS-level
      error code).

OIWA, et al.             Expires 7 January 2027                [Page 10]
Internet-Draft                 SHNM - PCS                      July 2026

   *  The PCS protocol itself is generic and does not constrain the set
      of possible intents.  However, each PCS deployment operates within
      a service-specific profile defined by the contractual relationship
      (e.g., SLA, connectivity agreement) between the PCS operator and
      its clients.

   *  This design prevents probing attacks, where an attacker might
      submit crafted queries to infer the internal structure of a
      network by observing which queries succeed and which fail.

   When a PCS Server receives a federated (PCS-to-PCS) sub-query, the
   responding server likewise evaluates the sub-query against its own
   service scope.  The responding server is an ISP or connectivity
   provider that answers PCS requests based on its SLA and contractual
   obligations with the requesting party.

4.2.  PCS-to-PCS Query Flow

   At a high level, a PCS Server receiving a client query proceeds as
   follows.  This description is illustrative and does not define
   protocol requirements.

   1.  Scope decomposition: Partition the end-to-end path into one or
       more sub-scopes (e.g., by AS / administrative domain, tunnel
       boundary, cloud region).

   2.  Local evidence collection: For sub-scopes under local
       administration, gather telemetry evidence made available by
       operator-controlled mechanisms in the operator's domain and
       reconstruct local PathView fragments.

   3.  Intent analysis and transformation: The PCS Server analyzes the
       client's intent in the context of its own network architecture
       and contractual relationships.  When delegating to downstream PCS
       Servers, it MAY transform (rewrite) the intent to match the
       downstream server's service scope and network context.  For
       example, a jurisdiction constraint expressed as a country-level
       requirement may be decomposed into AS-level sub-intents when
       delegated to transit providers.

   4.  Federated queries: For external sub-scopes, issue PCS-to-PCS sub-
       queries to authoritative PCS Servers for those domains, including
       the (possibly transformed) intent, freshness, and privacy
       constraints.

   5.  Composition: Merge local and federated intent matching results
       into a single conformance decision, preserving provenance and
       confidence metadata.

OIWA, et al.             Expires 7 January 2027                [Page 11]
Internet-Draft                 SHNM - PCS                      July 2026

   6.  Intent evaluation: Return the composed conformance result (match
       or no-match) to the client, along with applicable verification
       level and provenance chain.

   The following is a simplified message sketch for illustrative
   purposes:

Client -> PCS(Server-G): IntentQuery{target, intent, freshness}
PCS(Server-G):            analyze intent, decompose scope
PCS(Server-G) -> PCS(Server-A): SubIntentQuery{scope=A, intent'=transform(intent), trail}
PCS(Server-A):                 gather telemetry evidence, evaluate intent' against local PathView
PCS(Server-G) <- PCS(Server-A): IntentResult{A, match|no-match, verification, provenance}
PCS(Server-G) -> PCS(Server-B): SubIntentQuery{scope=B, intent'', trail}
PCS(Server-G) <- PCS(Server-B): IntentResult{B, match|no-match, ...}
PCS(Server-G):                 compose results
Client <- PCS(Server-G): Result{overall=match|no-match, verification, provenance_chain}

4.3.  Stop Conditions and Loop Prevention

   To avoid unbounded recursion, a PCS Server MUST implement explicit
   stop conditions and loop prevention.  The following mechanisms are
   RECOMMENDED:

   Recursion limit:  A request header "recursion_limit" (non-negative
      integer).  Each PCS Server decrements it when forwarding sub-
      queries.  If it reaches zero, further delegation MUST NOT occur;
      the server returns "incomplete=true" for unexplored scopes.

   Visited set / trail:  Each sub-query SHOULD carry an ordered "trail"
      including {request_id, caller_domain, scope}. A PCS Server MUST
      detect a cycle when its own administrative domain/scope appears
      again and terminate delegation for that branch.

   Scope contraction:  A PCS Server SHOULD only delegate the minimal
      missing scope.  Overlapping or redundant sub-queries SHOULD be
      coalesced to reduce fan-out.

   Cache with freshness:  Sub-query results MAY be cached with explicit
      "issued_at"/"exp" (or "fresh-until") metadata.  Reuse is allowed
      only if freshness requirements are met.

   Cut failure semantics:  When a sub-scope cannot be explored (timeout,
      policy denial, or recursion limit), the composed PathView MUST
      mark the segment as "opaque" and set "completeness=partial".

4.4.  Security, Trust, and Provenance in Recursion

   Authentication:  PCS-to-PCS exchanges MUST be mutually authenticated

OIWA, et al.             Expires 7 January 2027                [Page 12]
Internet-Draft                 SHNM - PCS                      July 2026

      (e.g., mTLS or equivalent).

   Authorization and least disclosure:  Responding servers MAY honor
      privacy constraints (e.g., return administrative-domain-level
      summaries instead of point-level details) while still signing the
      returned assertions.

   Provenance:  Each returned fragment SHOULD include a signed
      provenance block (issuer, scope, time, signature).  When
      composing, the caller MUST preserve the chain of provenance for
      third-party verification.

   Non-amplification:  A PCS Server MUST NOT act as an open relay.  Rate
      limits and request shaping SHOULD apply to delegated queries.

4.5.  Result Composition and Conflict Handling

   When multiple fragments overlap or disagree:

   Priority rules:  Prefer fragments issued by the authoritative
      administrative domain for that scope.  Otherwise, prefer newer and
      higher-confidence evidence.

   Conflict marking:  If conflicts remain, the composed PathView MUST
      annotate the affected elements with "conflict=true" and lower
      "confidence".

   Granularity reconciliation:  Administrative-domain-level evidence MAY
      satisfy policies that require only aggregate properties; point-
      level evidence is required when policies demand specific node
      attributes.

4.6.  Example Fields

   The following examples are illustrative.  A sub-query may include:

OIWA, et al.             Expires 7 January 2027                [Page 13]
Internet-Draft                 SHNM - PCS                      July 2026

   {
     "scope": {
       "domain": "AS65001",
       "segment": "vpn:1234"
     },
     "intent": {
       "requirements": [
         {
           "property": "geo.country",
           "op": "in",
           "values": ["XX"]
         },
         {
           "property": "operator",
           "op": "in",
           "values": ["AS65001", "AS65003"]
         }
       ]
     },
     "freshness": {
       "max_age": "300s"
     },
     "privacy": {
       "granularity": "domain"
     },
     "trail": [
       {
         "domain": "example.net",
         "req": "abc123"
       }
     ]
   }

   A sub-query response may include:

OIWA, et al.             Expires 7 January 2027                [Page 14]
Internet-Draft                 SHNM - PCS                      July 2026

   {
     "scope": {
       "domain": "AS65001"
     },
     "sub_result": "match",
     "verification": "TRACED_PRESENT",
     "provenance": {
       "issuer": "pcs.as65001.net",
       "issued_at": "2025-08-15T02:10Z",
       "sig": "..."
     },
     "completeness": "full",
     "confidence": 0.95
   }

4.7.  Non-Goals

   Recursive PCS does not attempt to:

   *  control routing or steer traffic;

   *  force disclosure of internal topology beyond the responder’s
      policy;

   *  guarantee global completeness in the presence of non-cooperating
      domains.

   Note: Recursive PCS enables operators to obtain point-level evidence
   where permitted, while still producing administrative-domain-level
   assertions when detailed disclosure is not available, thus delivering
   useful intent matching decisions even in deeply nested hybrid
   environments.

5.  Roles and Responsibilities

   This section defines the main roles in a PCS-enabled environment.
   The roles align with the three-layer model described in Figure 1.

   Network Operator / Domain Owner:  Responsible for the physical and
      virtual network infrastructure.  They control the disclosure
      policy for topology and telemetry data, and operate the telemetry
      mechanisms (e.g., IPFIX, gNMI) that expose network-element
      attributes within their administrative domain; the specific
      mechanisms used are outside the scope of PCS.  They are the
      authoritative source of truth for the properties of network
      elements within their administrative domain.  They define the
      service scope (see the Recursive Composition section) within which
      their PCS Server will respond to intent queries.

OIWA, et al.             Expires 7 January 2027                [Page 15]
Internet-Draft                 SHNM - PCS                      July 2026

   PCS Server:  Gathers per-hop telemetry evidence from existing
      mechanisms in the operator's domain, reconstructs PathViews (hop-
      list construction, conflict resolution, and gap-filling), and
      hosts the intent matching engine.  The PCS Server exposes the
      service interface to PCS Clients, handles authentication and
      authorization, and returns conformance results.  A PCS Server may
      recursively query other PCS Servers in adjacent domains, issuing
      and managing these PCS-to-PCS sub-queries itself.  Each PCS Server
      operates within its defined service scope (see the Recursive
      Composition section).

   PCS Client:  An application or system component that submits intent
      (declarative path requirements) to a PCS Server and receives a
      conformance result (match or no-match).  Clients may use this
      information to make operational or security decisions, such as
      accepting a compliant path or triggering an alert when intent is
      not satisfied.

6.  PCS Main Functions

   This section defines _what_ PCS does: the three conceptual processing
   stages that transform a client's intent into a conformance result.
   The operational mechanisms for accessing and interacting with PCS
   (authentication, subscription, etc.) are described separately in the
   next section.

   The PCS Server provides three main functional stages when processing
   an intent query:

   Gathering:  The PCS Server gathers per-hop telemetry evidence for the
      target path, as made available by operator-controlled telemetry
      mechanisms in the operator's domain (such as IPFIX, gNMI, BGP-LS,
      SNMP, or NETCONF), and correlates it.  The specific telemetry
      mechanisms and their transport are operator-internal concerns and
      are outside the scope of this specification.  Where recursive
      composition is needed, the PCS Server also issues PCS-to-PCS sub-
      queries to neighboring PCS Servers to obtain conformance results
      for segments outside the local administrative domain.  The per-hop
      evidence representation is described in Section 6.1.

   Reconstruction:  The PCS Server builds an end-to-end "PathView" from
      the gathered per-hop evidence.  Reconstruction may operate at
      different levels of abstraction.  Point-level view provides
      characteristics for each individual network element (e.g., router,
      link).  Administrative-domain-level view provides aggregated
      characteristics for an entire administrative domain or SDN
      segment; AS / administrative-domain-level information is the
      minimum required granularity, while individual router-level

OIWA, et al.             Expires 7 January 2027                [Page 16]
Internet-Draft                 SHNM - PCS                      July 2026

      details are optional and depend on the service profile and privacy
      policy of the responding operator.  The reconstruction process
      resolves conflicts, fills gaps using partial data, and ensures
      that the resulting PathView is internally consistent.

   Intent Matching:  Evaluates the reconstructed PathView against the
      client's declared intent and returns a conformance result (match,
      no-match, or unknown), optionally with a verification level and
      annotations explaining non-conformance or uncertainty.  The intent
      matching model is defined in the Design Principles section.  The
      PathView is an internal processing artifact of the PCS Server; by
      default, only the conformance result and its supporting metadata
      are returned to the client.  When the service scope permits and
      the return_pathview option is enabled, a summary or detailed
      PathView MAY be included in the response (see PCS Query options).

6.1.  Per-Hop Evidence Representation

   This section is informative.

   Per-hop evidence is the structured per-element telemetry made
   available by operator-controlled telemetry mechanisms and gathered by
   the PCS Server.  The PCS Server transforms this per-hop evidence into
   PathView segments by carrying forward the common attribute fields
   (hop identifier, operator, geo, metrics, security) and adding server-
   produced metadata (verification, provenance, confidence).  The
   "observed_at" and "evidence_sources" fields record when, and by which
   mechanism, the underlying telemetry was observed; they serve as
   inputs for provenance construction and do not appear in the resulting
   PathView segments.  Provenance metadata (issuer, signature,
   timestamp) is attached by the PCS Server when it assembles per-hop
   evidence into a PathView, because the PCS Server is the entity that
   asserts the trustworthiness of the composed path information to
   external parties.

   Operators may configure their telemetry mechanisms to include
   element-level provenance information where local policy requires per-
   element traceability (e.g., for internal audit or regulatory
   compliance).  This is a local operational decision and does not
   affect the PCS-to-PCS or PCS-to-Client interfaces.

   The following JSON example illustrates the per-hop evidence for a
   single router within AS 65001, as gathered by the PCS Server:

OIWA, et al.             Expires 7 January 2027                [Page 17]
Internet-Draft                 SHNM - PCS                      July 2026

   {
     "hop": "R1",
     "operator": "AS65001",
     "geo": {
       "country": "XX",
       "confidence_geo": 0.99
     },
     "metrics": {
       "latency": {"p99": 1.2}
     },
     "security": {
       "encryption": "IPsec",
       "integrity": "AES-256-GCM"
     },
     "observed_at": "2025-10-21T01:00:00Z",
     "evidence_sources": ["ipfix", "gnmi"]
   }

   The "evidence_sources" field indicates which telemetry mechanisms and
   data sources contributed to this per-hop evidence.  At the per-hop
   level these are typically telemetry protocols, including but not
   limited to IPFIX [RFC7011], gNMI, BGP-LS, SNMP, and NETCONF, ranging
   from primitive flow-export mechanisms to full configuration- and
   state-streaming protocols; at the response level (see the
   "evidence_sources" field in "metadata") they may also include
   auxiliary data sources such as geolocation databases or RPKI.  The
   per-hop evidence for a single element may combine data from multiple
   sources when the PCS Server correlates observations from different
   telemetry feeds for the same network element.

7.  Path Characteristics Service (PCS)

   The previous section defined the conceptual processing stages of PCS
   (Gathering, Reconstruction, Intent Matching).  This section describes
   the operational mechanisms through which clients access PCS:
   authentication, authorization, and subscription for ongoing
   conformance monitoring.

7.1.  Identification and Authentication

   *  PCS endpoints MUST be access-controlled and confidentiality-
      protected using secure protocols (e.g., TLS 1.3 or later).

   *  Clients MUST be strongly authenticated, for example via OAuth 2.1,
      mutual TLS (mTLS), or OpenID Connect.

   *  Authentication credentials SHOULD be bound to a specific
      connectivity channel, such as:

OIWA, et al.             Expires 7 January 2027                [Page 18]
Internet-Draft                 SHNM - PCS                      July 2026

      -  Physical (layer-1) leased lines,

      -  Layer-2 segments (e.g., VLAN, VXLAN),

      -  Virtual private network (VPN) tunnels,

      -  SD-WAN overlay paths.

   *  If multiple connectivity channels exist under a single business
      contract, multiple identifiers may be associated with a single
      authentication session.  The binding policy between identifiers
      and connectivity channels is a local operational matter and is
      outside the scope of this document.

7.2.  Subscription for Intent Matching Updates

   PCS protocols SHOULD support both:

   Streaming (push):  Clients subscribe to an intent query and receive
      updates when the conformance status changes (e.g., a previously
      matching path becomes non-conforming).

   Polling (pull):  Clients periodically re-evaluate intent conformance,
      with configurable intervals.

   Subscription parameters (e.g., polling interval, event triggers,
   maximum update rate) SHOULD be negotiable between the PCS Client and
   PCS Server.

8.  PCS Query

   A PCS Query is the primary mechanism by which a PCS Client submits
   its intent to a PCS Server for evaluation against the actual
   characteristics of a network path.

   A query typically includes:

   Target Path:  The path or set of candidate paths to be evaluated,
      identified by endpoints, AS-paths, or other topology identifiers.

   Intent:  A declarative set of requirements describing the desired
      path properties (e.g., jurisdiction constraints, approved
      operators, latency thresholds).  The intent is the core of the
      query and defines what the PCS Server evaluates.

   Query Constraints:  Optional parameters such as maximum acceptable
      data age or partial data acceptance.

OIWA, et al.             Expires 7 January 2027                [Page 19]
Internet-Draft                 SHNM - PCS                      July 2026

   The PCS Server processes the query by: 1.  Gathering per-hop
   telemetry evidence from existing mechanisms in the operator's domain
   and, if necessary, obtaining conformance results from other PCS
   Servers via recursive sub-queries. 2.  Reconstructing the PathView
   from the gathered evidence. 3.  Performing Intent Matching:
   evaluating whether the reconstructed PathView conforms to the
   client's declared intent.

   The server returns a PCS Response that contains:

   *  A conformance result (match, no-match, unknown, or partial for
      multi-candidate queries) for the overall query and for each intent
      requirement.

   *  A verification level indicating the confidence and verifiability
      of the result.

   *  Metadata such as data age, provenance chain, and completeness.

   *  Optionally, when the return_pathview option is enabled and
      permitted by service scope, a summary or detailed PathView.

   Depending on deployment and query complexity, PCS queries may be
   handled synchronously or asynchronously.  In the asynchronous case,
   the initial response includes a job identifier that can be used to
   retrieve results later.

   Access to PCS Query endpoints MUST be subject to authentication and
   authorization controls.  Queries that fall outside the PCS Server's
   service scope MUST be rejected with an appropriate error response.

8.1.  PCS Query Data Model

   This section is informative.  The terms REQUIRED and OPTIONAL below
   describe the structure of the data model for interoperability
   guidance, not protocol-level requirements.

   A PCS Query is a structured request sent by a PCS Client to a PCS
   Server, containing the client's intent (declarative path
   requirements) for evaluation against actual path characteristics.
   This section defines the JSON-based data structure for queries.

8.1.1.  Top-Level Structure

   A PCS Query object contains the following fields:

   *  "endpoints" (object, REQUIRED)

OIWA, et al.             Expires 7 January 2027                [Page 20]
Internet-Draft                 SHNM - PCS                      July 2026

   *  "intent" (object, REQUIRED)

   *  "path_hints" (object, OPTIONAL)

   *  "path_candidates" (array, OPTIONAL)

   *  "options" (object, OPTIONAL)

8.1.2.  Field Definitions

8.1.2.1.  endpoints

   This field is REQUIRED.  It identifies the source and destination of
   the path being queried.

   {
     "endpoints": {
       "from": {"type": "ip", "value": "10.1.1.10"},
       "to":   {"type": "ip", "value": "10.2.2.10"}
     }
   }

   Supported endpoint types:

   *  "ip": IPv4 / IPv6 address

   *  "fqdn": Fully qualified domain name

   *  "asn": Autonomous System Number

8.1.2.2.  intent

   This field is REQUIRED.  It declares the client's requirements for
   the network path.  PCS evaluates whether the path conforms to this
   intent.

{
  "intent": {
    "requirements": [
      {"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]},
      {"id": "latency-ok", "property": "latency.p99", "op": "lte", "value": 20}
    ],
    "freshness": {"max_age": "60s"},
    "privacy": {"granularity": "domain"}
  }
}

OIWA, et al.             Expires 7 January 2027                [Page 21]
Internet-Draft                 SHNM - PCS                      July 2026

   *  "requirements": Array of declarative intent expressions.  Each
      requirement specifies a property and a condition to be satisfied.
      Geographic constraints use a whitelist (inclusion) approach (e.g.,
      "op": "in") rather than a blacklist (exclusion) approach; this is
      a normative requirement specified in the Geographic Constraint
      Design Rationale (see Security Considerations), motivated by the
      fact that blacklist-based specifications risk omitting
      jurisdictions and thus failing to prevent unintended transit.
      Country codes are expected to follow ISO 3166-1.  Country codes
      used in examples in this document (XX, XY, ZZ) are drawn from the
      ISO 3166-1 user-assigned range (AA, QM–QZ, XA–XZ, ZZ) and do not
      represent actual countries.  Properties applicable to network
      nodes include, but are not limited to: operator, geo-location,
      supplier, model, hardware identifier, software name and version,
      and security status.  Properties applicable to network edges vary
      by category: physical edges may specify protocol type and
      operator; tunnels may additionally specify tunnel identification,
      protocol type, integrity/confidentiality protection strength, and
      nested path property requests for the underlying network;
      software-defined networks may specify the controlling software and
      its security status.  The full property namespace is extensible.

   The structured form shown above (a property, an operator, and a set
   of values) is the interchange representation of an intent requirement
   and is what the PCS Server evaluates against the PathView.  For
   simple comparisons this structured form is self-contained: a fixed
   set of operators (e.g., in, eq, lte) over an agreed property
   namespace yields an evaluator-independent, interoperable result.

   Richer intents, however, require conditions beyond flat comparisons
   -- for example, Boolean composition (AND/OR/NOT), set operations, and
   quantification over path segments (e.g., "every hop is in XX", "no
   hop is in ZZ").  For such conditions, interoperability depends on the
   constraint expression language used to express and evaluate them: two
   implementations using different evaluators may reach different
   results for the same intent.  A standardized, vendor-independent
   constraint expression language is therefore needed for full
   interoperability, and specifying it is an open standardization item
   that must be resolved before this specification can be finalized.

   [TODO: Define a vendor-independent, interoperable constraint
   expression language for intent conditions (either by profiling an
   existing language or by specifying a minimal standard one).  Until it
   is defined, the vendor dependency described below remains an
   unresolved gap toward standardization.]

OIWA, et al.             Expires 7 January 2027                [Page 22]
Internet-Draft                 SHNM - PCS                      July 2026

   As an interim measure, this revision uses Google's Common Expression
   Language (CEL) [CEL] as the constraint expression language for
   conditions that exceed the structured form above; implementations of
   this revision currently interoperate by evaluating such conditions
   with CEL.  This is a deliberate interim commitment to a single
   language, not a statement that any evaluator is acceptable.  The
   authors recognize that relying on CEL introduces a dependency on a
   single vendor-originated specification whose long-term stability and
   backward compatibility are not guaranteed under a recognized
   standards process.  This vendor dependency is a known issue that the
   authors intend to remove before standardization, as noted in the TODO
   above; CEL is used here because it is what the current implementation
   employs, not because the authors consider it the final choice.  The
   precise CEL evaluation profile -- how PathView attributes map to CEL
   variables, which language features are permitted, and how evaluation
   errors map to conformance results -- is not yet specified and is
   deferred to the standardization work called for above.

   The authors actively solicit input on candidate constraint/query
   expression languages -- in particular a stable, standards-based
   language able to express at least equality/inequality, set
   membership, Boolean combination, and quantification over path
   segments -- and intend to raise this as an open question in relevant
   venues (e.g., IETF hackathons and the OPS area). - "freshness":
   Maximum age of acceptable telemetry data. - "privacy.granularity": -
   "point": per-hop disclosure (if permitted by service scope) -
   "domain": aggregated administrative-domain-level disclosure - "none":
   minimal disclosure (conformance result only)

8.1.2.3.  options

   This field is OPTIONAL.  It controls execution behavior.

   {
     "options": {
       "recursion_limit": 0,
       "explain": true,
       "return_pathview": "full"
     }
   }

   Allowed values:

   *  recursion_limit: integer ≥ 0.  Note: this field is provided for
      advanced use cases but carries security implications.  Varying
      recursion limit values across queries may allow a client to infer
      properties of the internal network structure (e.g., number of
      intermediate ASes or network hierarchy depth).  PCS Servers are

OIWA, et al.             Expires 7 January 2027                [Page 23]
Internet-Draft                 SHNM - PCS                      July 2026

      expected to apply local policy to override or cap the client-
      specified value and not to expose the actual recursion depth used
      in the response metadata; these requirements are specified
      normatively in the Recursion Depth Information Leakage section
      (see Security Considerations).

   *  explain: boolean.  When true, non-conforming requirements include
      explanatory annotations.

   *  return_pathview: one of "none", "summary", or "full".  Controls
      whether a PathView is included in the response, subject to privacy
      and service scope constraints.  The combination of explain and
      return_pathview effectively determines the evaluation mode,
      controlling the level of detail returned beyond the basic
      conformance result.

8.1.2.4.  path_hints

   This field is OPTIONAL.  It provides client guidance for expected/
   desired routing paths.

   {
     "path_hints": {
       "as_path": [65001, 65003, 65002]
     }
   }

8.1.2.5.  path_candidates

   This field is OPTIONAL.  It allows bulk evaluation of multiple
   candidate paths within a single request.

  {
    "path_candidates": [
      {"id": "primary", "path_hints": {"as_path": [65001,65003,65002]}},
      {"id": "backup",  "path_hints": {"as_path": [65001,65004,65002]}}
    ]
  }

8.1.3.  Synchronous Query Example

   POST /v1/pcs/queries:run

OIWA, et al.             Expires 7 January 2027                [Page 24]
Internet-Draft                 SHNM - PCS                      July 2026

{
  "endpoints": {
    "from": {"type": "ip", "value": "10.1.1.10"},
    "to":   {"type": "ip", "value": "10.2.2.10"}
  },
  "intent": {
    "requirements": [
      {"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]},
      {"id": "latency-ok", "property": "latency.p99", "op": "lte", "value": 20}
    ],
    "freshness": {"max_age": "60s"},
    "privacy": {"granularity": "domain"}
  },
  "options": {
    "recursion_limit": 0,
    "explain": true,
    "return_pathview": "full"
  }
}

8.1.4.  Example Query with Multiple Candidates

{
  "endpoints": {
    "from": {"type":"ip", "value":"10.1.1.10"},
    "to":   {"type":"ip", "value":"10.2.2.10"}
  },
  "intent": {
    "requirements": [
      {"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]}
    ],
    "freshness": {"max_age":"60s"}
  },
  "path_candidates": [
    {"id":"primary", "path_hints":{"as_path":[65001,65003,65002]}},
    {"id":"backup",  "path_hints":{"as_path":[65001,65004,65002]}}
  ],
  "options": {"explain": true, "return_pathview": "summary"}
}

9.  PCS Response

9.1.  PCS Response Data Model

   This section is informative.  The terms REQUIRED and OPTIONAL below
   describe the structure of the data model for interoperability
   guidance, not protocol-level requirements.

OIWA, et al.             Expires 7 January 2027                [Page 25]
Internet-Draft                 SHNM - PCS                      July 2026

   A PCS Response contains the result of intent matching: whether the
   actual path characteristics conform to the client's declared intent.
   This section defines the JSON-based data model for responses
   including synchronous queries, asynchronous jobs, and streaming
   notifications.

9.1.1.  Top-Level Structure

   A PCS Response object contains the following fields:

   *  "query_id" (string, REQUIRED)

   *  "intent_results" (array, REQUIRED)

   *  "pathview" (object, OPTIONAL)

   *  "candidates" (array, OPTIONAL)

   *  "overall" (string, REQUIRED)

   *  "cache" (object, OPTIONAL)

   *  "verification" (string, OPTIONAL)

   *  "constructed_at" (timestamp, OPTIONAL)

   *  "metadata" (object, OPTIONAL)

   *  "message" (string, OPTIONAL)

   For single-path queries, "intent_results" and optionally "pathview"
   are present.  For multi-candidate queries, "candidates" is used
   instead, each containing its own "intent_results".

9.1.2.  Field Definitions

9.1.2.1.  pathview

   This field is OPTIONAL.  It represents the reconstructed end-to-end
   path and its attributes.

OIWA, et al.             Expires 7 January 2027                [Page 26]
Internet-Draft                 SHNM - PCS                      July 2026

Structure:

{
  "pathview": {
    "summary": {
      "completeness": "full | partial",
      "latency": {"p99": 8.7},
      "geo": {
        "countries": ["XX","XY"],
        "opaque_segments": 1
      }
    },
    "segments": [
      {
        "hop": "R1",
        "operator": "AS65001",
        "geo": {"country": "XX", "confidence_geo": 0.99},
        "metrics": {"latency": {"p99": 1.2}},
        "security": {"encryption": "IPsec", "integrity": "AES-256-GCM"},
        "verification": "TRACED_PRESENT",
        "provenance": {
          "issuer": "pcs.as65001.net",
          "issued_at": "2025-10-21T01:00:00Z"
        },
        "confidence": 0.95
      }
    ],
    "completeness": "full | partial",
    "constructed_at": "2025-10-21T01:00:03Z"
  }
}

   Descriptions:

   *  "segments": hop-level or segment-level information.  Each segment
      includes a "verification" field indicating the verification level
      of the evidence for that specific segment.  The response top-level
      "verification" is derived as the lowest (weakest) verification
      level across all segments.

   *  "verification" (per-segment): indicates the verification level for
      the evidence backing this segment.  Completeness is a binary
      property (full/partial) aggregated at the pathview level, whereas
      verification is a multi-level property that varies per segment and
      is therefore attached to individual segments.

   *  "provenance": mandatory metadata proving origin of each evidence
      fragment.

OIWA, et al.             Expires 7 January 2027                [Page 27]
Internet-Draft                 SHNM - PCS                      July 2026

   *  "confidence": numerical estimation combining multiple data
      sources.  Per-property confidence values (e.g., "confidence_geo")
      may appear alongside property-specific data to indicate the
      reliability of individual attributes.

   *  "summary": aggregate values to support privacy-preserving replies.

   *  "completeness" appears at both the summary level (within
      "summary") and the top level of "pathview".  The summary-level
      value reflects the completeness of aggregated data, while the top-
      level value reflects the overall completeness of the reconstructed
      path.

9.1.2.2.  intent_results

   This field is REQUIRED.  It contains an array of conformance results
   for each intent requirement.

   {
     "intent_results": [
       {
         "requirement_id": "xx-only",
         "result": "match | no-match | unknown",
         "explain": {
           "violations": [
             {"segment": "AS65004", "geo.country": "ZZ"}
           ]
         }
       }
     ]
   }

   *  "result":

      -  match: the requirement is satisfied

      -  no-match: at least one violation detected

      -  unknown: insufficient data (e.g., opaque segments within the
         path)

   *  "explain":
      Detailed reason for non-conformance, provided when the explain
      option is enabled.  Usable by external enforcement systems.

OIWA, et al.             Expires 7 January 2027                [Page 28]
Internet-Draft                 SHNM - PCS                      July 2026

9.1.2.3.  overall

   This field is REQUIRED.  It indicates the overall conformance outcome
   of the query.  For single-path queries, the value is derived from the
   "intent_results" array as follows:

   *  "match": all intent requirements have "result" = "match"

   *  "no-match": at least one intent requirement has "result" = "no-
      match"

   *  "unknown": no requirement has "result" = "no-match", but at least
      one has "result" = "unknown" (i.e., insufficient data to determine
      conformance for that requirement)

   For multi-candidate queries, an additional value is defined:

   *  "partial": at least one candidate has "overall" = "match" and at
      least one has "overall" = "no-match" or "unknown"

   Note: an opaque segment does not automatically produce "unknown".  If
   the operator responsible for that segment asserts conformance within
   its service scope, the corresponding requirement may still evaluate
   to "match" at an OPAQUE verification level. "unknown" is returned
   only when the PCS Server cannot determine conformance — for example,
   when a sub-scope is unreachable, the recursion limit is exhausted, or
   the responding operator's service scope does not cover the requested
   property.

9.1.2.4.  cache

   This field is OPTIONAL.  It indicates whether cached telemetry was
   used.

   {
     "cache": {
       "hit": false
     }
   }

9.1.2.5.  candidates

   This field is OPTIONAL.  It is used when evaluating multiple route
   candidates in bulk.

OIWA, et al.             Expires 7 January 2027                [Page 29]
Internet-Draft                 SHNM - PCS                      July 2026

   {
     "candidates": [
       {
         "id": "primary",
         "intent_results": [...],
         "overall": "match",
         "verification": "TRACED_PRESENT"
       },
       {
         "id": "backup",
         "intent_results": [...],
         "overall": "no-match",
         "verification": "OPAQUE_PRESENT"
       }
     ],
     "overall": "partial"
   }

   Each candidate includes its own "verification" field because
   different candidates traverse different paths and may be backed by
   different levels of evidence.  The response top-level "verification"
   for multi-candidate queries is derived as the lowest verification
   level across all candidates.

9.1.2.6.  metadata

   This field is OPTIONAL.  It provides optional additional metadata.

   {
     "metadata": {
       "recursion_limit_requested": 3,
       "delegation_structure": "chain",
       "evidence_sources": ["ipfix","gnmi","bgp-ls","geoip"],
       "freshness": {"max_age":"60s"}
     }
   }

   *  "recursion_limit_requested": OPTIONAL.  Echoes back the recursion
      limit value that was specified by the client in the query's
      "options.recursion_limit" field.  This field reflects the client's
      requested value, not the actual recursion depth used by the PCS
      Server.  PCS Servers do not populate this field with the actual
      recursion depth reached; this is a normative requirement specified
      in the Recursion Depth Information Leakage section (see Security
      Considerations).  If the PCS Server applied a local policy to
      override or cap the client-specified value, this field still
      reflects the original client-specified value, so as not to reveal
      whether an override was applied.

OIWA, et al.             Expires 7 January 2027                [Page 30]
Internet-Draft                 SHNM - PCS                      July 2026

   *  "delegation_structure": OPTIONAL.  Describes how recursive PCS-to-
      PCS queries were organized for this response.  Possible values
      are:

      -  "chain": sequential delegation (baton relay), where each PCS
         Server delegated to a single downstream PCS Server.

      -  "tree": parallel or fan-out delegation, where a PCS Server
         delegated to multiple downstream PCS Servers simultaneously.

      -  "direct": no delegation; all evidence was gathered locally.

      This field is informative and intended to assist clients in
      interpreting the provenance chain structure.  When the
      verification level is OPAQUE_PRESENT or OPAQUE_FUTURE, this field
      can be omitted, as the delegation structure is not relevant when
      only the conformance result is returned.  When the verification
      level is TRANSPARENT_PRESENT or higher (see the Intent Matching
      Verification Levels section for the ordering), the delegation
      structure is implicitly visible in the provenance chain and this
      field serves as a convenience.

   *  "evidence_sources": OPTIONAL.  Indicates which existing telemetry
      mechanisms and data sources contributed to constructing the
      PathView for this response (e.g., "ipfix", "gnmi", "bgp-ls",
      "rpki", "geoip").  This field is informational and does not imply
      that PCS defines or operates these mechanisms.

9.1.2.7.  query_id

   This field is REQUIRED.  It is a unique identifier assigned by the
   PCS Server to correlate this response with the original query.  For
   asynchronous queries, the query_id is also used to retrieve results
   by polling the job endpoint.

9.1.2.8.  verification

   This field is OPTIONAL.  It indicates the verification level of the
   overall conformance result, derived as the lowest (weakest)
   verification level across all path segments.  Possible values are
   defined in the Intent Matching Verification Levels section:
   TRACED_PRESENT, TRANSPARENT_PRESENT, TRACEABLE_OPAQUE_PRESENT,
   OPAQUE_PRESENT, TRACEABLE_OPAQUE_FUTURE, or OPAQUE_FUTURE.  When a
   PathView is included in the response, clients can inspect per-segment
   verification levels within "pathview.segments" to identify which
   segments constrain the overall level.

OIWA, et al.             Expires 7 January 2027                [Page 31]
Internet-Draft                 SHNM - PCS                      July 2026

9.1.2.9.  constructed_at

   This field is OPTIONAL.  It is a timestamp (ISO 8601 format)
   indicating when the PCS Server constructed this response.  Clients
   can use this value along with the "freshness" parameters to assess
   the timeliness of the result.

9.1.2.10.  message

   This field is OPTIONAL.  It is a human-readable string summarizing
   the conformance result, intended for logging, alerting, or operator
   dashboards.  The content of this field is informational and is not
   intended for automated decision-making; this is a normative
   requirement specified in Security Considerations (Information
   Disclosure).  Unlike the structured "explain" data within
   "intent_results" (which provides machine-parseable violation details
   per requirement), "message" provides a single natural-language
   summary of the overall result suitable for direct display to
   operators.

9.1.3.  Match Response Example

   {
     "query_id": "q-uc1-1",
     "cache": {"hit": false},
     "intent_results": [
       {
         "requirement_id": "xx-only",
         "result": "match"
       }
     ],
     "overall": "match",
     "verification": "TRACED_PRESENT",
     "constructed_at": "2025-10-21T01:00:03Z"
   }

9.1.4.  No-Match Response Example

OIWA, et al.             Expires 7 January 2027                [Page 32]
Internet-Draft                 SHNM - PCS                      July 2026

{
  "query_id": "q-uc1-2",
  "intent_results": [
    {
      "requirement_id": "xx-only",
      "result": "no-match",
      "explain": {
        "violations": [{"segment":"AS65004","geo.country":"ZZ"}]
      }
    }
  ],
  "overall": "no-match",
  "verification": "TRACED_PRESENT",
  "constructed_at": "2025-10-21T01:05:05Z",
  "message": "Intent (xx-only): non-conforming segment detected (AS65004, country=ZZ)"
}

9.1.5.  Streaming Notification Event Model

   Used for subscriptions (SSE/Webhook/WebSocket).  Each event includes
   a "verification" field so that the receiving operator or automation
   system can assess the confidence of the reported state change.  For
   example, a "no-match" event at TRACED_PRESENT warrants immediate
   action (strong evidence of violation), whereas the same event at
   OPAQUE_PRESENT may call for further investigation before triggering
   remediation.

9.1.5.1.  Event Structure

   {
     "event_id": "ev-20251021-001",
     "type": "intent.no-match | topology.change | latency.exceed",
     "occurred_at": "2025-10-21T01:05:05Z",
     "query_id": "q-uc1-2",
     "intent_results": [...],
     "overall": "no-match",
     "verification": "TRACED_PRESENT",
     "message": "xx-only intent violated (AS65004, country=ZZ)"
   }

9.1.6.  Webhook Example

   POST /v1/pcs/webhooks/events

OIWA, et al.             Expires 7 January 2027                [Page 33]
Internet-Draft                 SHNM - PCS                      July 2026

   {
     "event_id": "wh-20251021-001",
     "type": "intent.no-match",
     "occurred_at": "2025-10-21T01:05:05Z",
     "query_id": "q-uc1-2",
     "endpoints": {"from":"10.1.1.10","to":"10.2.2.10"},
     "intent_results": [...],
     "overall": "no-match",
     "verification": "TRACED_PRESENT",
     "message": "xx-only intent violated: AS65004"
   }

9.1.7.  Notes for Standardization

   *  HTTP paths and JSON examples in this document are illustrative and
      do not define a wire binding or encoding.

   *  Only field names and constraints may become normative in future
      revisions.

   *  Data model may be expressed in CDDL or JSON Schema in future
      revisions.

   *  The constraint expression language used to evaluate intent
      conditions (currently CEL) is expected to be replaced by, or
      profiled as, a vendor-independent standard language; see the
      intent field definition in this section.

9.2.  Intent Matching Verification Levels

   An intent matching response includes a verification level that
   indicates the degree of verifiability and temporal scope of the
   conformance result.  The verification levels are listed below from
   highest (most transparent and verifiable) to lowest:

   1.  TRACED_PRESENT — strongest evidence, present-time

   2.  TRANSPARENT_PRESENT — full path detail, present-time

   3.  TRACEABLE_OPAQUE_PRESENT — opaque with trace ID, present-time

   4.  OPAQUE_PRESENT — conformance result only, present-time

   5.  TRACEABLE_OPAQUE_FUTURE — opaque with trace ID, future commitment
       within service scope

   6.  OPAQUE_FUTURE — conformance result only, future commitment within
       service scope

OIWA, et al.             Expires 7 January 2027                [Page 34]
Internet-Draft                 SHNM - PCS                      July 2026

   When this document refers to a verification level being "higher" than
   another, it means the level appears earlier in the list above (i.e.,
   provides greater transparency and verifiability).

9.2.1.  Traced present

   For traced verification, the intent matching result is backed by a
   recorded trace of the actual path, signed by each traversed network
   node with their identifications.  This provides the strongest
   evidence that the intent requirements are satisfied at the present
   time.  This type of verification requires dedicated support for
   packet traces in every network node.

9.2.2.  Transparent present

   For transparent verification, the intent matching result is
   accompanied by a list of traversed nodes and edges with their
   properties relevant to the intent evaluation.  If the intent
   evaluation involves cascaded queries to other PCS Servers (e.g., for
   networks operated by third parties), the response includes the sub-
   results received from those servers.  This verification level
   confirms that the intent is satisfied at the present time.

9.2.3.  Traceable opaque present

   For traceable opaque verification, the intent matching result
   includes an opaque ID that corresponds to internal trace information.
   This ID can be used by operators to identify the records for
   troubleshooting in the future, without exposing the actual path
   details to the client.  The result confirms that the intent is
   satisfied at the present time.

9.2.4.  Opaque present

   For opaque verification, the intent matching result contains only the
   conformance decision (match or no-match) without any supporting path
   details or trace identifiers.  The result confirms that the intent is
   satisfied at the present time.

9.2.5.  Traceable opaque future

   For traceable opaque future verification, the intent matching result
   includes an opaque ID for future troubleshooting reference.  In
   addition, the responsible operator asserts, within its service scope,
   that the network is controlled so that the intent requirements are
   expected to remain satisfied even as dynamic routing changes occur.

OIWA, et al.             Expires 7 January 2027                [Page 35]
Internet-Draft                 SHNM - PCS                      July 2026

9.2.6.  Opaque future

   For opaque future verification, the intent matching result contains
   only the conformance decision (match or no-match).  Within its
   service scope, the responsible operator asserts that the network is
   controlled so that the intent requirements are expected to remain
   satisfied even as dynamic routing changes occur.

10.  Use Cases

   Secure Hybrid Network Monitoring with PCS will be shown with specific
   examples using several use cases.

10.1.  Case 1: Data Residency / Sovereignty Compliance

   Certain applications must ensure that communication paths remain
   entirely within a given legal jurisdiction.  For example, a financial
   institution may require that all customer data traffic remains within
   a specific jurisdiction, avoiding any transit through networks
   located in other countries.  The PCS Client declares this as an
   intent (e.g., geo.country IN ["XX"]) and submits it to the PCS
   Server.  PCS evaluates this intent by gathering geolocation evidence
   for each path segment and returning a conformance result.  If the
   intent is not matched (e.g., a segment is located outside the allowed
   set), the PCS Client can take preventive actions such as rejecting
   the path or raising an alert.

   PCS role:

   *  Receive intent declaring jurisdictional requirements from the PCS
      Client.

   *  Gather geolocation and jurisdiction evidence for each path segment
      from existing telemetry mechanisms.

   *  Perform intent matching to evaluate whether all segments satisfy
      the declared jurisdictional constraints.

   *  Return a conformance result (match or no-match) with the
      appropriate verification level.

OIWA, et al.             Expires 7 January 2027                [Page 36]
Internet-Draft                 SHNM - PCS                      July 2026

10.2.  Case 2: Critical Infrastructure Operator Validation

   Some sectors, such as healthcare or energy, require that only
   approved network operators be involved in the transport of sensitive
   data.  For example, a healthcare information system may require that
   all intermediate networks along a path are operated by organizations
   on a predefined whitelist.  The PCS Client declares this as an intent
   (e.g., operator IN ["AS65001", "AS65003"]) and PCS evaluates whether
   the actual path conforms.

   PCS role:

   *  Receive intent declaring approved operator requirements from the
      PCS Client.

   *  Gather operator identifiers and relevant cryptographic assertions
      from existing telemetry mechanisms and sources (e.g., RPKI,
      operator registries).

   *  Perform intent matching to evaluate whether all path segments are
      operated by approved entities.

   *  Return a conformance result (match or no-match) with the
      appropriate verification level.

10.3.  Case 3: Incident Forensics and Audit

   When a security incident occurs, operators may need to reconstruct
   and verify the network path characteristics at the time of the
   incident.  For example, during an investigation, a signed intent
   matching result and its associated provenance chain from PCS can be
   used as part of an evidence package to demonstrate whether the path
   conformed to the declared intent at a specific point in time.  This
   can also support regulatory audits that require verifiable historical
   conformance data.

   PCS role:

   *  Store intent matching results with associated provenance chains,
      cryptographic signatures, and timestamps.

   *  Provide mechanisms for retrieving historical conformance results
      for a given time window.

   *  Allow independent verification of historical evidence using
      signatures and trust anchors.

OIWA, et al.             Expires 7 January 2027                [Page 37]
Internet-Draft                 SHNM - PCS                      July 2026

10.4.  Future Use Case Candidates

   The following areas are candidates for additional use cases in future
   revisions of this document.  They correspond to the architecture
   design goals identified in the Design Principles section and are
   noted here to ensure they are not overlooked:

   *  Tunneling and virtualization verification: verifying that tunneled
      or virtualized path segments (e.g., VPN-over-VPN, SDN slices)
      satisfy intent requirements at both overlay and underlay levels.

   *  DNS and addressing dependency: evaluating whether DNS resolution
      paths and addressing infrastructure conform to declared intent
      (e.g., DNS-over-HTTPS enforcement, address assignment authority).

   *  Management-plane risk assessment: assessing non-network
      infrastructure risks (e.g., IaC configuration drift, cloud
      provider management access) as part of path conformance
      evaluation.

   *  DoS resilience verification: verifying that path characteristics
      include adequate DoS mitigation properties (e.g., scrubbing center
      presence, rate-limiting capabilities).

11.  Security Considerations

   The proposed "Secure Hybrid Network Monitoring - Path Characteristics
   Service" itself introduces several security considerations that have
   to be addressed:

   Information Disclosure:  The intent matching model is specifically
      designed to minimize information disclosure by returning
      conformance results (match/no-match) rather than raw network
      state.  However, the system must still carefully balance the need
      for explainability (e.g., violation annotations) with the
      protection of sensitive infrastructure information.  The human-
      readable message field in a PCS Response MUST NOT be used as the
      basis for automated decision-making; automated systems MUST
      instead use the structured intent_results (including explain)
      data.

   Trust Model:  Clear trust relationships must be established between
      different stakeholders in the hybrid cloud environment.  Each PCS
      Server operates within a defined service scope, and trust chains
      are maintained through provenance metadata and digital signatures.

   Authentication and Authorization:  Proper mechanisms must be in place

OIWA, et al.             Expires 7 January 2027                [Page 38]
Internet-Draft                 SHNM - PCS                      July 2026

      to ensure only authorized entities can submit intent queries and
      receive conformance results.  Authentication credentials SHOULD be
      bound to specific connectivity channels.

   Integrity Protection:  Intent data, conformance results, and
      provenance chains must be protected from tampering or
      manipulation.

   Intent Confidentiality:  The intent submitted by a PCS Client may
      reveal sensitive information about the client's security
      requirements or business logic.  PCS endpoints MUST protect intent
      data in transit and SHOULD restrict access to intent content based
      on authentication and authorization.

11.1.  Service Scope and Probing Prevention

   PCS Servers MUST only respond to queries within their pre-agreed
   service scope.  Queries that fall outside this scope MUST be rejected
   without providing information that could be used to infer the
   server's capabilities or internal network structure.  This prevents
   probing attacks, where an adversary systematically submits queries
   with varying parameters to map out the network topology or discover
   what properties a PCS Server can evaluate.

11.2.  Recursion Depth Information Leakage

   As described in Section 4, PCS supports recursive composition across
   administrative boundaries.  The recursion_limit parameter in PCS
   queries carries inherent security implications.  By varying the
   recursion depth across multiple queries and observing differences in
   response times, completeness, or conformance results, an adversary
   may be able to infer properties of the internal network structure,
   such as the number of intermediate autonomous systems, the depth of
   the network hierarchy, or the presence of specific transit
   relationships.

   To mitigate this risk:

   *  PCS Servers SHOULD apply their own local policy to override or cap
      the client-specified recursion_limit value.

   *  PCS Servers SHOULD NOT expose the actual recursion depth used or
      reached in the response metadata.

   *  PCS Servers MUST NOT populate response fields (e.g.,
      recursion_limit_requested) with the actual recursion depth used or
      reached.

OIWA, et al.             Expires 7 January 2027                [Page 39]
Internet-Draft                 SHNM - PCS                      July 2026

   *  PCS Servers MAY normalize response timing to reduce the
      information available through timing analysis.

   *  The specific security implications of the recursion_limit field
      should be documented in operational deployment guides.

11.3.  Geographic Constraint Design Rationale

   PCS intent specifications for geographic constraints MUST use a
   whitelist (inclusion) approach exclusively; blacklist (exclusion)
   specifications MUST NOT be used because they create a risk of
   omission: if a new jurisdiction or transit path is not included in
   the blacklist, traffic may traverse that jurisdiction without
   detection.  The whitelist approach is more robust because it requires
   explicit approval of each allowed jurisdiction, ensuring that any
   unlisted jurisdiction is automatically excluded.

11.4.  Telemetry Ingestion

   The PCS Server gathers per-hop evidence made available by operator-
   controlled telemetry mechanisms within the operator's administrative
   domain.  These mechanisms, their transport, and their protection are
   operator-internal concerns governed by the operator's policies and by
   the specifications of the mechanisms themselves (e.g., [RFC7011] for
   IPFIX, which recommends TLS/DTLS for its transport).  This document
   does not define telemetry-acquisition mechanisms or their security
   requirements.  Within the operator's trust boundary, the PCS Server
   is the entity that assembles this evidence into a PathView and
   asserts its trustworthiness to external parties through the
   provenance mechanisms described elsewhere in this document; the
   trustworthiness of inputs from individual telemetry mechanisms is
   established by operator-local controls.

12.  IANA Considerations

   This document has no IANA actions.

13.  References

13.1.  Normative References

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

OIWA, et al.             Expires 7 January 2027                [Page 40]
Internet-Draft                 SHNM - PCS                      July 2026

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

13.2.  Informative References

   [ISO-IEC-5140]
              ISO/IEC, "Information technology — Cloud computing —
              Multi-cloud and hybrid cloud vocabulary", ISO/
              IEC 5140:2024, 2024.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/rfc/rfc7011>.

   [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
              A. Wang, "Network Telemetry Framework", RFC 9232,
              DOI 10.17487/RFC9232, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9232>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/rfc/rfc9315>.

   [I-D.oiwa-secure-hybrid-network]
              Oiwa, Y., Kanno, S., and Y. Sakemi, "Secure hybrid network
              monitoring - Problem statement", Work in Progress,
              Internet-Draft, draft-oiwa-secure-hybrid-network-02, 7
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-oiwa-secure-hybrid-network-02>.

   [CEL]      "Common Expression Language (CEL)",
              <https://github.com/google/cel-spec>.

Appendix A.  Acknowledgments

   This work is supported by NEDO grants P23013 from the New Energy and
   Industrial Technology Development Organization.

Authors' Addresses

   Yutaka OIWA
   National Institute of Advanced Industrial Science and Technology (AIST)
   Email: y.oiwa@aist.go.jp

OIWA, et al.             Expires 7 January 2027                [Page 41]
Internet-Draft                 SHNM - PCS                      July 2026

   Satoru Kanno
   GMO CONNECT Inc.
   Email: kanno@gmo-connect.jp

   Yumi Sakemi
   GMO CONNECT Inc.
   Email: sakemi-yumi@gmo-connect.jp

OIWA, et al.             Expires 7 January 2027                [Page 42]