<?xml version='1.0' encoding='UTF-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" version="3" category="std" docName="draft-li-detnet-preof-loss-matrix-yang-00" ipr="trust200902" submissionType="IETF" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true">
  <front>
    <title abbrev="DetNet PREOF Loss Matrix YANG">A YANG Data Model for Pre-Elimination Correlated Loss Matrix and Fate-Sharing OAM in Deterministic Networking (DetNet) PREOF</title>
    <seriesInfo name="Internet-Draft" value="draft-li-detnet-preof-loss-matrix-yang-00"/>
    <author fullname="Zhiqiang Li" initials="Z." surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>lizhiqiangyjy@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>duzongpeng@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Junjie Wang" initials="J." surname="Wang">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Shanghai</city>
          <country>China</country>
        </postal>
        <email>wangjj@centec.com</email>
      </address>
    </author>
    <author fullname="Wei Cheng" initials="W." surname="Cheng">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Shanghai</city>
          <country>China</country>
        </postal>
        <email>chengw@centec.com</email>
      </address>
    </author>
    <author fullname="Ying Zhao" initials="Y." surname="Zhao">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Shanghai</city>
          <country>China</country>
        </postal>
        <email>zhaoying@centec.com</email>
      </address>
    </author>
    <author fullname="Chunhao Zhao" initials="C." surname="Zhao">
      <organization>SAIA</organization>
      <address>
        <postal>
          <city>Shanghai</city>
          <country>China</country>
        </postal>
        <email>chunhao.zhao@sh-aia.com</email>
      </address>
    </author>
    <author fullname="Xun Sun" initials="X." surname="Sun">
      <organization>Inesa</organization>
      <address>
        <postal>
          <city>Shanghai</city>
          <country>China</country>
        </postal>
        <email>sunxun@inesa.com</email>
      </address>
    </author>
    <date year="2026" month="October" day="30"/>
    <area>RTG</area>
    <workgroup>Deterministic Networking</workgroup>
    <keyword>DetNet</keyword><keyword>PREOF</keyword><keyword>correlated loss matrix</keyword><keyword>fate-sharing OAM</keyword><keyword>dual-branch telemetry</keyword><keyword>YANG</keyword><keyword>NMDA</keyword><abstract>
      <t>This document specifies a Standards Track YANG 1.1 data model (ietf-detnet-preof-loss-matrix) for reporting pre-elimination correlated packet delivery and co-failure outcomes across Deterministic Networking (DetNet) Packet Replication, Ordering, and Elimination Functions (PREOF). Against a closed source-declared packet population, the model classifies each original sequence number across paired replication branches into a 16-cell joint outcome matrix ({on-time, late, missing, indeterminate} x {Branch A, Branch B}) and four fate-sharing summary buckets (delivered-both, delivered-a-only, delivered-b-only, lost-both), enabling operators to distinguish masked single-branch drops from correlated dual-branch failures.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>Replication can improve delivery reliability when the branches do not fail together. Two marginal loss ratios cannot reveal how often both branches fail for the same original packet. Multiplying those ratios assumes independence, which can fail under shared congestion, interference, power, or software faults. A joint outcome measurement therefore needs packet-level correlation and a population that includes packets absent from both receivers.</t>
      <t>DetNet <xref target="RFC8655"/> provides replication and elimination concepts. Reliable and Available Wireless <xref target="RFC9912"/> discusses reliability over wireless segments. One-way packet loss <xref target="RFC7680"/>, loss-pattern metrics <xref target="RFC3357"/>, and loss episode measurements <xref target="RFC6534"/> already define important single-path and temporal properties. This document specifies a Standards Track YANG data model that reports correlated per-packet outcomes across paired DetNet PREOF replication branches against a closed source-declared packet population.</t>
      <t>The report is intended for a managed measurement domain. It can support transport for a RAN cloud but does not prescribe radio resource allocation. Pairwise observations characterize two selected branches only; they <bcp14>MUST NOT</bcp14> be presented as the full joint distribution of a system with three or more branches.</t>
      <t>In particular, the bi-packet loss pair in <xref target="RFC6534"/> observes two distinct source packets at different sending times. Here, an outcome pair concerns copies of the same original packet on two branches. The existing binary pair encoding is not reinterpreted, and no new IPPM metric registry allocation is requested by this YANG reporting specification.</t>
    </section>
    <section anchor="requirements">
      <name>Requirements Language</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/>
        <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="population">
      <name>Population and Measurement Contract</name>
      <t>Before measurement, the producer and consumer <bcp14>MUST</bcp14> share a measurement contract identifying the original-packet population, replication scope, branch identities, observation points, deadline budget, correlation method, and closure rules. contract-id identifies the immutable, version-specific measurement contract; population-id identifies the exact closed population in that contract namespace. It <bcp14>MUST</bcp14> distinguish correlation generations across restart or sequence reuse.</t>
      <t>The population <bcp14>MUST</bcp14> be established from authoritative source or replication-function evidence, not the union of packets received on the two branches. For every original packet it identifies which copies are expected on the two branches and the reference emission event used for the deadline. Packets that never reach either receiver still belong to the denominator. If the producer cannot establish the closed original-packet set, it <bcp14>MUST</bcp14> use unavailable-reason and <bcp14>MUST NOT</bcp14> report a complete denominator or zero joint loss.</t>
      <t>The accounting concerns the replication service from the declared source event to the selected merge observer. Missing includes failure anywhere in that declared scope; it does not by itself attribute a failure to a radio, forwarding hop, or sender. A narrower claim about packets actually emitted on both branches requires corresponding source-emission evidence. The same two branch identifiers <bcp14>MUST</bcp14> have a stable meaning throughout a reported window.</t>
      <t>A single report contains at most 4294967295 original packets, and a positive population is required for counts. Larger populations <bcp14>MUST</bcp14> be divided into distinct, non-overlapping windows. A producer <bcp14>MUST NOT</bcp14> report a zero denominator as a successful reliability measurement. The data model uses uint32 counts so that its bounded 16-cell sum is exact in the arithmetic domain used by YANG XPath constraints.</t>
      <t>A contract <bcp14>MUST</bcp14> specify source identity and emission event, flow and direction, the identities and pre-elimination placement of both observers, original/copy correlation and restart handling, expected-copy eligibility, timestamp scales and error treatment, capture-completeness rules, and population membership/disjointness. These are required deployment inputs; the opaque identifier does not transport them. Changing any interpretation requires a new contract-id. A producer <bcp14>MUST</bcp14> split a window at a contract change. An unknown contract prevents semantic aggregation even if the matrix is syntactically valid.</t>
      <t>Every original in a counts population <bcp14>MUST</bcp14> be eligible for an intended copy on both selected branches. Known ineligible originals <bcp14>MUST</bcp14> be excluded when forming the source-declared common population, not removed from only one branch after classification. A change in this eligibility policy requires a new contract and a split window. Eligibility does not require successful creation or emission of both copies: failure to produce an expected copy remains within the population and is classified using the observation and closure rules. Unknown eligibility prevents a complete qualifying counts population; it <bcp14>MUST NOT</bcp14> be guessed from the union of received copies.</t>
    </section>
    <section anchor="correlation">
      <name>Correlation, Observation, and Closure</name>
      <t>An original packet is correlated with observations on each branch using the replication mechanism and the measurement contract. This specification introduces no new packet sequence header, reset flag, or per-packet epoch. A sequence number is insufficient without its flow, direction, and generation context. Sequence wrap, restart, or reuse <bcp14>MUST NOT</bcp14> merge unrelated originals. If correlation cannot be resolved, affected outcomes become indeterminate, or the population is unavailable if its membership is no longer known.</t>
      <t>The preferred observer is at the merge function with branch-specific observations before elimination. An observer after elimination alone normally cannot determine branch outcomes and <bcp14>MUST NOT</bcp14> infer them from the surviving packet. A producer relying on distributed observation reports <bcp14>MUST</bcp14> establish the completeness and identity of those reports before classifying an absence as missing.</t>
      <t>For each original packet, the producer determines a conservative interval enclosing the true elapsed time from the declared source event to an observed copy. The interval includes clock error, timestamp quantization, domain conversion, and observation uncertainty. An arrival is certainly on time when its upper endpoint is at most the deadline budget. It is certainly late when its lower endpoint is greater than that budget. A boundary-straddling interval is indeterminate.</t>
      <t>A packet may have duplicate observations within one branch. The producer <bcp14>MUST</bcp14> account for the original at most once per branch. If any valid observation proves an on-time delivery, the branch outcome is on-time. Otherwise, if an observation might have been on time, the outcome is indeterminate even if another copy is certainly late. If all valid observed copies are certainly late, and the observer evidence is complete, the outcome is late.</t>
      <t>Each packet has a closure instant after its deadline, including the configured closure-wait and any necessary observation-report completeness allowance. The observer <bcp14>MUST</bcp14> have continuous, valid instrumentation through closure before classifying a never-observed copy as missing. An instrumentation gap, unknown source time, corrupt observation, or uncertain closure produces indeterminate rather than missing for the affected original and branch.</t>
      <t>Closure-wait does not extend the delivery deadline. It permits distinguishing an observed late delivery from a copy not observed by closure. A missing classification is a timeout-bounded observation, not proof that a packet will never arrive. The report <bcp14>MUST NOT</bcp14> be finalized until every original in the population has reached a valid closure or been classified indeterminate. An event discovered after finalization does not rewrite the final report silently; it is a measurement exception requiring a distinct report or diagnostic under the deployment contract.</t>
      <t>The classification precedence is: a valid proof of an on-time copy gives O; otherwise any observation that could have been on time, or any relevant unresolved capture gap, gives I; otherwise one or more certainly late observations with complete evidence gives L; otherwise complete evidence through valid closure gives M; otherwise the result is I. A certainly late copy does not cancel a prior instrumentation gap in which an on-time copy might have passed. Copies arriving after closure are outside the finalized measurement; identifying an error in the earlier evidence is a report conflict, not permission to count a new disjoint population.</t>
    </section>
    <section anchor="accounting">
      <name>Joint Accounting and Interpretation</name>
      <t>The four outcomes are on-time (O), late (L), missing (M), and indeterminate (I). Every original belongs to exactly one of the 16 ordered outcome pairs. All cells, including zero cells, <bcp14>MUST</bcp14> be present in a counts report. Their sum <bcp14>MUST</bcp14> equal expected. A consumer <bcp14>MUST</bcp14> reject a counts report with absent or duplicate cells, a negative or out-of-range count, unequal total, or identical branch identities.</t>
      <t>Let C[a,b] be a cell count and N the expected population. The number of originals certainly failing the deadline on both branches is the sum over a and b in {L,M}. A conservative upper bound on that number also includes all pairs with no on-time outcome and at least one indeterminate outcome. A known on-time copy on either branch proves that the original did not fail this paired delivery test, even if the other branch is indeterminate.</t>
      <sourcecode type="text">
F = {late, missing}
J_lower = sum(C[a,b] for a in F for b in F)
J_upper = sum(C[a,b] for a != on-time for b != on-time)

Observed joint-failure fraction is in [J_lower/N, J_upper/N].
If there are no indeterminate outcomes: J_lower = J_upper.</sourcecode>
      <t>These bounds describe only the observed window and its declared evidence. They are not statistical confidence intervals or deterministic future-service guarantees. A producer or consumer <bcp14>MUST NOT</bcp14> label them as a probability of future failure without a separate justified predictive model. Correlation within a time series also prevents applying independent-trial confidence formulas without checking their assumptions.</t>
      <t>Marginal branch failure fractions can be derived from the same matrix, retaining uncertainty from I cells. A consumer <bcp14>MUST NOT</bcp14> replace the joint counts with a product of marginals unless an independent analysis justifies that model, and even then <bcp14>MUST</bcp14> identify the result as a model estimate rather than the observed joint fraction. A joint failure is not proof of a common physical cause; causal diagnosis requires additional evidence.</t>
    </section>
    <section anchor="reporting">
      <name>Report Identity, Retrieval, and Retention</name>
      <t>Each finalized window has an opaque 128-bit identifier unique across the reporting producer and its restarts. A producer <bcp14>MUST NOT</bcp14> reuse an identifier for a different population or changed counts. A report is immutable after finalization. A repeated retrieval of the same report does not constitute another measurement. Consumers <bcp14>MUST</bcp14> deduplicate by authenticated producer identity and window id before aggregating non-overlapping populations.</t>
      <t>The producer <bcp14>MUST</bcp14> retain a complete window as one coherent operational-data entry. It <bcp14>MUST NOT</bcp14> expose a partially populated matrix as finalized data. A filtered retrieval that omits cells is not a complete report even if the server retains all of them. A client requiring joint results <bcp14>MUST</bcp14> retrieve and validate the complete counts subtree.</t>
      <t>Retention limits are implementation and deployment policy. The producer <bcp14>MAY</bcp14> evict old complete windows. Disappearance of a window is not evidence of zero loss or a negative count. If clients require exhaustive time coverage, the measurement contract must provide a source-side window manifest or another existing reliable inventory mechanism; this model does not define an event stream with exactly-once delivery.</t>
      <t>The report does not contain raw user payload. population-id and branch labels are opaque references in the managed measurement domain. Their lifecycle, namespace mapping, and authorized interpretation <bcp14>MUST</bcp14> be provisioned. A consumer unable to resolve them <bcp14>MAY</bcp14> retain the raw report but <bcp14>MUST NOT</bcp14> combine it with unrelated measurement scopes.</t>
    </section>
    <section anchor="aggregation">
      <name>Aggregation and Existing OAM Boundaries</name>
      <t>Before adding matrices, the consumer <bcp14>MUST</bcp14> establish equal contract interpretation, equal ordered branch roles, equal deadline and closure rules, and disjoint source populations. Window identifiers distinguish reports; distinct identifiers do not prove disjoint populations. A changed report for the same population <bcp14>MUST NOT</bcp14> be added to the old one. If two immutable reports conflict, the consumer <bcp14>MUST</bcp14> withhold their combined result and obtain an explicit reconciliation outside this reporting model.</t>
      <t>When branch roles are exchanged under a verified mapping, the consumer <bcp14>MUST</bcp14> transpose the matrix before comparison. A shared path name is not sufficient to map two observers. Aggregate arithmetic <bcp14>MUST</bcp14> use a width large enough for all summed windows and compute the lower and upper fractions from summed counts and summed populations, not an unweighted average of ratios. Raw sums exceeding uint32 can remain local analytic results; they <bcp14>MUST NOT</bcp14> be serialized into a single counts window that exceeds this module range.</t>
      <t>The DetNet OAM framework <xref target="RFC9551"/> already covers service monitoring and PREOF observability. This document specifies a management report for a particular paired population, not an OAM packet format or a replacement failure-detection protocol. Measurement interpretation guidance <xref target="MEAS-INTERPRET"/> also separates measurement scope and evidence from root-cause attribution. The report follows that boundary: it cannot infer a common cause, future reliability, or application experience from a joint matrix alone.</t>
      <t>The DetNet YANG model in <xref target="RFC9633"/> already describes flows, service protection, and sequence configuration. This report does not replace that configuration model. A deployment <bcp14>MUST</bcp14> explicitly map its report contract and ordered branch roles to the relevant configured flow and observation identities; a shared display name does not establish the mapping. The individual PREOF OAM proposal <xref target="PREOF-OAM"/> describes replication, elimination, timeout, gap, and late-event observability. Such events can supply evidence, but they do not by themselves establish this report's complete source population and 16-cell joint matrix. Referencing that proposal does not imply working-group adoption.</t>
    </section>
    <section anchor="model">
      <name>YANG Data Model</name>
      <t>This module uses YANG 1.1 <xref target="RFC7950"/> and the Network Management Datastore Architecture <xref target="RFC8342"/>. Read-only nodes are operational data. A server advertises support using YANG Library <xref target="RFC8525"/>; successful transport establishment alone does not establish support. JSON encoding follows <xref target="RFC7951"/>.</t>
      <t>The following tree follows <xref target="RFC8340"/>. The module definition, including its feature, choice, when, must, and reference constraints, is authoritative.</t>
      <artwork type="ascii-art">
module: ietf-detnet-preof-loss-matrix
  +--ro replication-outcomes
     +--ro window* [id]
        +--ro id                          binary
        +--ro population-id               string
        +--ro contract-id                 string
        +--ro branch-a                    string
        +--ro branch-b                    string
        +--ro deadline-budget             uint64
        +--ro closure-wait                uint64
        +--ro (evidence)
           +--:(unavailable)
           |  +--ro unavailable-reason?   string
           +--:(accounted)
              +--ro counts!
                 +--ro expected    uint32
                 +--ro cell* [a b]
                    +--ro a          outcome
                    +--ro b          outcome
                    +--ro packets    uint32</artwork>
      <sourcecode type="yang" name="ietf-detnet-preof-loss-matrix@2026-10-30.yang" markers="true">
module ietf-detnet-preof-loss-matrix {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix";
  prefix rpo;

  organization
    "IETF Deterministic Networking (DetNet) Working Group";
  contact
    "Zhiqiang Li &lt;lizhiqiangyjy@chinamobile.com&gt;";
  description
    "ietf-detnet-preof-loss-matrix data model.
     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code. All rights reserved.
     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).
     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";
  revision 2026-10-30 {
    description "Initial revision.";
    reference "draft-li-detnet-preof-correlated-outcomes-yang-00";
  }

  typedef outcome {
    type enumeration {
      enum on-time {
        description "Certainly at or before deadline.";
      }
      enum late {
        description "Certainly late, observed by closure.";
      }
      enum missing { description "Not observed by valid closure."; }
      enum indeterminate {
        description "Evidence is insufficient.";
      }
    }
    description "Mutually exclusive outcome for one branch.";
  }
  container replication-outcomes {
    config false;
    description "Retained, finalized paired observation windows.";
    list window {
      must "branch-a != branch-b" {
        error-message "Two distinct branches are required.";
      }
      key "id";
      description "An immutable final report, never a partial
         update.";
      leaf id {
        type binary { length "16"; }
        description "Unique identifier, including across restarts.";
      }
      leaf population-id {
        type string { length "1..256"; }
        mandatory true;
        description
          "Reference to the exact original-packet manifest and its
           correlation generation within the measurement domain.";
      }
      leaf contract-id {
        type string { length "1..256"; }
        mandatory true;
        description
          "Immutable, version-specific measurement contract
             identifier
           in a provisioned namespace. Equality alone does not prove
           two populations are disjoint.";
      }
      leaf branch-a {
        type string { length "1..128"; }
        mandatory true;
        description "First replication branch at the merge
           observer.";
      }
      leaf branch-b {
        type string { length "1..128"; }
        mandatory true;
        description "Second, distinct branch at the merge
           observer.";
      }
      leaf deadline-budget {
        type uint64;
        units "nanoseconds";
        mandatory true;
        description "Budget from source emission to merge
           observation.";
      }
      leaf closure-wait {
        type uint64;
        units "nanoseconds";
        mandatory true;
        description
          "Wait after the latest deadline before final
             classification.
           This is not permission to extend the deadline.";
      }
      choice evidence {
        mandatory true;
        description "Complete accounting or unavailable
           population.";
        case unavailable {
          leaf unavailable-reason {
            type string { length "1..512"; }
            description "Why a closed original-packet set is
               unknown.";
          }
        }
        case accounted {
          container counts {
            must "sum(cell/packets) = expected" {
              error-message "Outcome counts must sum to
                 population.";
            }
            presence "The original-packet population is known.";
            description "Exactly one pair outcome per original
               packet.";
            leaf expected {
              type uint32 { range "1..max"; }
              mandatory true;
              description "Size of the source-declared population.";
            }
            list cell {
              key "a b";
              min-elements 16;
              max-elements 16;
              description "All 16 outcome pairs, including zero
                 cells.";
              leaf a {
                type outcome;
                description "Outcome on branch A.";
              }
              leaf b {
                type outcome;
                description "Outcome on branch B.";
              }
              leaf packets {
                type uint32;
                mandatory true;
                description "Original packets with this outcome
                   pair.";
              }
            }
          }
        }
      }
    }
  }
}</sourcecode>
    </section>
    <section anchor="example">
      <name>Worked Example</name>
      <table anchor="matrix-example">
        <name>Example finalized population of 1000 originals</name>
        <thead>
          <tr>
            <th>A / B</th>
            <th>O</th>
            <th>L</th>
            <th>M</th>
            <th>I</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>O</td>
            <td>950</td>
            <td>10</td>
            <td>5</td>
            <td>5</td>
          </tr>
          <tr>
            <td>L</td>
            <td>10</td>
            <td>4</td>
            <td>3</td>
            <td>2</td>
          </tr>
          <tr>
            <td>M</td>
            <td>5</td>
            <td>2</td>
            <td>2</td>
            <td>1</td>
          </tr>
          <tr>
            <td>I</td>
            <td>0</td>
            <td>0</td>
            <td>0</td>
            <td>1</td>
          </tr>
        </tbody>
      </table>
      <t>The matrix totals 1000. The four certainly failed cells contain 4 + 3 + 2 + 2 = 11 originals. Including L/I, M/I and I/I adds 4 potentially failed originals, giving an observed joint-failure fraction between 11/1000 and 15/1000. The 5 O/I entries do not increase the upper bound because branch A proves timely delivery.</t>
      <t>If only received-packet unions were used as the denominator, the M/M originals would be invisible and the resulting joint measurement would be biased. If a capture failure affected branch B, it would be wrong to move every unobserved B packet to M; the affected cells must use I unless complete evidence can be recovered.</t>
      <t>This constructed example illustrates the 16-cell joint outcome matrix and the conservative interval bounds [J_lower/N, J_upper/N]. It is not an implementation or decoding test result.</t>
    </section>
    <section anchor="tests">
      <name>Conformance and Failure Cases</name>
      <table anchor="joint-tests">
        <name>Required behavior</name>
        <thead>
          <tr>
            <th>Test</th>
            <th>Expected outcome</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>Both copies absent; source manifest known; observers complete</td>
            <td>M/M cell</td>
          </tr>
          <tr>
            <td>Only receive union known</td>
            <td>Population unavailable</td>
          </tr>
          <tr>
            <td>A proves on-time; B capture lost</td>
            <td>O/I cell; no joint failure</td>
          </tr>
          <tr>
            <td>Arrival uncertainty straddles deadline</td>
            <td>Indeterminate unless another copy proves on-time</td>
          </tr>
          <tr>
            <td>Duplicate before elimination</td>
            <td>Count one original on that branch</td>
          </tr>
          <tr>
            <td>Sequence reset without generation context</td>
            <td>Do not correlate across reset</td>
          </tr>
          <tr>
            <td>16 cells do not sum to N</td>
            <td>Reject complete counts interpretation</td>
          </tr>
          <tr>
            <td>Repeated window id with changed counts</td>
            <td>Conflicting report; do not aggregate</td>
          </tr>
          <tr>
            <td>Window omitted by retention</td>
            <td>Missing coverage, never zero failures</td>
          </tr>
          <tr>
            <td>Third branch present in system</td>
            <td>Do not generalize pairwise result</td>
          </tr>
        </tbody>
      </table>
    <t>A conforming report producer MUST preserve the source-declared eligible packet denominator even when both branch copies are missing, and a consumer MUST validate all 16 matrix cells before computing any joint loss or delivery ratio. Required negative test cases include: (1) rejecting a received-union denominator that omits lost-both packets, (2) rejecting omitted zero cells or duplicate cell coordinates, (3) detecting swapped branch roles without matrix transposition, (4) rejecting packets with unknown dual-branch eligibility, and (5) distinguishing unavailable observation evidence from a measured zero joint-failure count.</t></section>
    <section anchor="deployment-and-instrumentation">
      <name>Deployment and Instrumentation Boundaries</name>
      <t>The deployment requires an active DetNet replication and elimination service with identifiable original sequence numbers and pre-elimination branch observation points as defined in <xref target="RFC8655"/> and <xref target="RFC9551"/>. Standard equal-cost multi-path (ECMP) forwarding or upper-layer application retries without per-packet DetNet sequence correlation do not instantiate a valid paired observation population.</t>
      <t>This YANG data model operates strictly at the DetNet service and forwarding sub-layers <xref target="RFC9633"/>. It requires no modification to DetNet data-plane encapsulation headers, sequence number fields, or upper-layer application protocols.</t>
      <t>A useful validation separates the original-packet generator, the two branch observers, and the report consumer. The source population includes packets missing on both branches. Loss injection and observer-capture failure must yield different outcomes. This document does not establish joint failure probabilities for future traffic or prove physical failure independence.</t>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>The YANG data defined here is designed to be accessed using NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. NETCONF implementations use the secure transport requirements of <xref target="RFC6242"/>. RESTCONF uses HTTPS; implementations of this specification that expose RESTCONF <bcp14>MUST</bcp14> support TLS 1.3 <xref target="RFC9846"/>. Servers <bcp14>MUST</bcp14> authenticate peers, authorize each read or operation, and protect message integrity and confidentiality. The NETCONF Access Control Model <xref target="RFC8341"/> provides access control. Deployments <bcp14>MUST NOT</bcp14> permit unauthenticated fallback when the protected channel fails.</t>
      <t>The module is read-only but exposes service quality, branch relationships, and potentially sensitive population references. Those nodes require role-scoped read authorization. A false population manifest can hide joint failures, and a compromised observer can falsely assert complete capture. Consumers <bcp14>MUST</bcp14> bind both to their measurement contract and trusted source identities. Input sequence identifiers are untrusted unless validated in the replication scope; attackers can otherwise create false correlations. Implementations <bcp14>MUST</bcp14> limit the number of retained windows and the work used to match originals and copies. Authentication of a report does not establish the independence of two branches or the correctness of a claimed physical cause.</t>
      <t>Servers <bcp14>MUST</bcp14> bound retained records, request rate, response size, and processing work per authorized principal. Failure of an observation or management channel <bcp14>MUST NOT</bcp14> be converted into a favorable quality or reliability result. Protected transport authenticates the reporting peer; it does not prove that a sensor, estimator, or device is truthful. Consumers <bcp14>MUST</bcp14> use only authorized sources for the relevant device and measurement scope.</t>
      <t>This module defines no writable nodes or RPCs. Sensitive readable nodes under replication-outcomes/window are contract-id, population-id, branch-a, branch-b, deadline-budget, closure-wait, unavailable-reason, and counts. They reveal service selection, topology, and service performance. Window id also permits linkage across queries. Read authorization and retention limits <bcp14>SHOULD</bcp14> apply to the whole window so that partial disclosure does not create a misleading complete report. A contract identifier <bcp14>MUST NOT</bcp14> cause automatic retrieval of an arbitrary URL supplied by an untrusted source.</t>
      <t>A deliberately filtered view can depart from whole-window disclosure when required by access policy or an authorized query. The consumer <bcp14>MUST NOT</bcp14> treat that partial view as a complete joint matrix or infer omitted counts as zero. The server's retained complete window and its resource bounds remain unchanged.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>IANA is requested to register the following URI in the IETF XML Registry defined by <xref target="RFC3688"/>. This request does not assign the namespace before publication.</t>
      <t>URI: urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix. Registrant Contact: the IESG. XML: N/A; the requested URI is an XML namespace.</t>
      <t>IANA is requested to register the module ietf-detnet-preof-loss-matrix in the YANG Module Names registry under the guidelines of <xref target="RFC6020"/> and <xref target="RFC9907"/>. Namespace: urn:ietf:params:xml:ns:yang:ietf-detnet-preof-loss-matrix. Prefix: rpo. Maintained by IANA: N. Reference: this document. No new transport port, data-plane flag, or packet code point is requested.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6242"/>
          <seriesInfo name="DOI" value="10.17487/RFC6242"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7951"/>
          <seriesInfo name="DOI" value="10.17487/RFC7951"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8342">
          <front>
            <title>Network Management Datastore Architecture (NMDA)</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
            <author fullname="P. Shafer" initials="P." surname="Shafer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="R. Wilton" initials="R." surname="Wilton"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8342"/>
          <seriesInfo name="DOI" value="10.17487/RFC8342"/>
        </reference>
        <reference anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="July" year="2026"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9846"/>
          <seriesInfo name="DOI" value="10.17487/RFC9846"/>
        </reference>
        <reference anchor="RFC8525" target="https://www.rfc-editor.org/info/rfc8525">
          <front>
            <title>YANG Library</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="R. Wilton" initials="R." surname="Wilton"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8525"/>
          <seriesInfo name="DOI" value="10.17487/RFC8525"/>
        </reference>
        <reference anchor="RFC9633" target="https://www.rfc-editor.org/info/rfc9633">
          <front>
            <title>Deterministic Networking (DetNet) YANG Data Model</title>
            <author fullname="X. Geng" initials="X." surname="Geng"/>
            <author fullname="Y. Ryoo" initials="Y." surname="Ryoo"/>
            <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
            <author fullname="R. Rahman" initials="R." surname="Rahman"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="October" year="2024"/>
            <abstract>
              <t>This document contains the specification for the Deterministic Networking (DetNet) YANG data model for configuration and operational data for DetNet flows. The model allows the provisioning of an end-to-end DetNet service on devices along the path without depending on any signaling protocol. It also specifies operational status for flows.</t>
              <t>The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9633"/>
          <seriesInfo name="DOI" value="10.17487/RFC9633"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="PREOF-OAM" target="https://datatracker.ietf.org/doc/html/draft-contreras-detnet-preof-oam-00">
          <front>
            <title>PREOF Observability and OAM Requirements</title>
            <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras"/>
            <date year="2026" month="July" day="6"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-contreras-detnet-preof-oam-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="MEAS-INTERPRET" target="https://datatracker.ietf.org/doc/html/draft-liu-ippm-measurement-interpretation-00">
          <front>
            <title>Considerations for Interpreting IP Performance Measurement Results</title>
            <author fullname="Liu, L."/>
            <date year="2026" month="10"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-liu-ippm-measurement-interpretation-00"/>
        </reference>
        <reference anchor="RFC3357" target="https://www.rfc-editor.org/info/rfc3357">
          <front>
            <title>One-way Loss Pattern Sample Metrics</title>
            <author fullname="R. Koodli" initials="R." surname="Koodli"/>
            <author fullname="R. Ravikanth" initials="R." surname="Ravikanth"/>
            <date month="August" year="2002"/>
            <abstract>
              <t>The Internet exhibits certain specific types of behavior (e.g.,
bursty packet loss) that can affect the performance seen by the users
as well as the operators. The loss pattern or loss distribution is a
key parameter that determines the performance observed by the users
for certain real-time applications such as packet voice and video.
For the same loss rate, two different loss distributions could
potentially produce widely different perceptions of performance.
Using the base loss metric defined in RFC 2680, this document defines 
two derived metrics 'loss distance' and 'loss period', and the 
associated statistics that together capture loss patterns experienced
by packet streams on the Internet.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3357"/>
          <seriesInfo name="DOI" value="10.17487/RFC3357"/>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC6534" target="https://www.rfc-editor.org/info/rfc6534">
          <front>
            <title>Loss Episode Metrics for IP Performance Metrics (IPPM)</title>
            <author fullname="N. Duffield" initials="N." surname="Duffield"/>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <author fullname="J. Sommers" initials="J." surname="Sommers"/>
            <date month="May" year="2012"/>
            <abstract>
              <t>The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6534"/>
          <seriesInfo name="DOI" value="10.17487/RFC6534"/>
        </reference>
        <reference anchor="RFC7680" target="https://www.rfc-editor.org/info/rfc7680">
          <front>
            <title>A One-Way Loss Metric for IP Performance Metrics (IPPM)</title>
            <author fullname="G. Almes" initials="G." surname="Almes"/>
            <author fullname="S. Kalidindi" initials="S." surname="Kalidindi"/>
            <author fullname="M. Zekauskas" initials="M." surname="Zekauskas"/>
            <author fullname="A. Morton" initials="A." role="editor" surname="Morton"/>
            <date month="January" year="2016"/>
            <abstract>
              <t>This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="82"/>
          <seriesInfo name="RFC" value="7680"/>
          <seriesInfo name="DOI" value="10.17487/RFC7680"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655">
          <front>
            <title>Deterministic Networking Architecture</title>
            <author fullname="N. Finn" initials="N." surname="Finn"/>
            <author fullname="P. Thubert" initials="P." surname="Thubert"/>
            <author fullname="B. Varga" initials="B." surname="Varga"/>
            <author fullname="J. Farkas" initials="J." surname="Farkas"/>
            <date month="October" year="2019"/>
            <abstract>
              <t>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8655"/>
          <seriesInfo name="DOI" value="10.17487/RFC8655"/>
        </reference>
        <reference anchor="RFC9551" target="https://www.rfc-editor.org/info/rfc9551">
          <front>
            <title>Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet)</title>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="F. Theoleyre" initials="F." surname="Theoleyre"/>
            <author fullname="G. Papadopoulos" initials="G." surname="Papadopoulos"/>
            <author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/>
            <author fullname="B. Varga" initials="B." surname="Varga"/>
            <author fullname="J. Farkas" initials="J." surname="Farkas"/>
            <date month="March" year="2024"/>
            <abstract>
              <t>Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9551"/>
          <seriesInfo name="DOI" value="10.17487/RFC9551"/>
        </reference>
        <reference anchor="RFC9907" target="https://www.rfc-editor.org/info/rfc9907">
          <front>
            <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="March" year="2026"/>
            <abstract>
              <t>This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules.</t>
              <t>This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="216"/>
          <seriesInfo name="RFC" value="9907"/>
          <seriesInfo name="DOI" value="10.17487/RFC9907"/>
        </reference>
        <reference anchor="RFC9912" target="https://www.rfc-editor.org/info/rfc9912">
          <front>
            <title>Reliable and Available Wireless (RAW) Architecture</title>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
            <date month="April" year="2026"/>
            <abstract>
              <t>Reliable and Available Wireless (RAW) extends the reliability and availability of Deterministic Networking (DetNet) to networks composed of any combination of wired and wireless segments. The RAW architecture leverages and extends RFC 8655 ("Deterministic Networking Architecture") to adapt to challenges that prominently affect the wireless medium, notably intermittent transmission loss. This document defines a network control loop that optimizes the use of constrained bandwidth and energy while ensuring the expected DetNet services. The loop involves a new Point of Local Repair (PLR) function in the DetNet Service sub-layer that dynamically selects the DetNet path(s) for packets to route around local connectivity degradation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9912"/>
          <seriesInfo name="DOI" value="10.17487/RFC9912"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
