Early Review of draft-ietf-ippm-on-path-telemetry-yang-05
review-ietf-ippm-on-path-telemetry-yang-05-perfmetrdir-early-aitken-2026-08-18-00

I reviewed draft-ietf-ippm-on-path-telemetry-yang-05 and
draft-ietf-ippm-alt-mark-yang-05, especially considering their consistency with
each other and with draft-ietf-opsawg-ipfix-alt-mark-07.

draft-ietf-ippm-on-path-telemetry-yang-05 = ON-PATH-TELEMETRY-YANG
draft-ietf-ippm-alt-mark-yang-05 = ALT-MARK-YANG
draft-ietf-opsawg-ipfix-alt-mark-07 = IPFIX-ALT-MARK

(1) Loss/Delay flag: type mismatch (boolean vs bits)

IPFIX-ALT-MARK defines:
      altmarkLossFlag:  Abstract Data Type = boolean
      altmarkDelayFlag: Abstract Data Type = boolean

ON-PATH-TELEMETRY-YANG defines (loss-counters grouping):
      leaf loss-flag {
        type bits {
          bit l-flag { position 0; }
        }
      }

and (delay-timestamps grouping):
      leaf delay-flag {
        type bits {
          bit d-flag { position 0; }
        }
      }

While semantically equivalent (both represent a single binary flag per RFC
9343), these are fundamentally different representations:
    - YANG bits: encoded as space-separated bit names (e.g., "l-flag" when set,
    "" when unset) - IPFIX boolean: encoded as unsigned8 (1=true, 2=false per
    RFC 7011 Section 6.1.5)

ON-PATH-TELEMETRY-YANG should use "type boolean;" since only one flag bit is
defined.

Even so, an IPFIX collector reading the YANG operational state must perform a
type conversion. This is workable but should be documented in the IPFIX-ALT
draft (Section 4, Operational Considerations).

(2) Period Number: size mismatch (uint32 vs uint64)

IPFIX-ALT-MARK defines:
      altmarkPeriodNumber: unsigned32

ON-PATH-TELEMETRY-YANG defines (altmark-telemetry grouping):
      leaf measurement-period-number {
        type uint64;
      }

A YANG telemetry consumer reporting a period number > 2^32-1 cannot represent
that value in IPFIX without truncation. As these documents are supposed to work
together the types should match.

(3) Naming confusion: measurement-period vs measurement-period-number

ALT-MARK-YANG defines:
      measurement-period   uint64  (the marking period DURATION)

ON-PATH-TELEMETRY-YANG defines:
      measurement-period-number  uint64  (the period COUNTER)

IPFIX-ALT-MARK defines:
      altmarkPeriodNumber  (the period COUNTER)

While the cross-references are correct (IPFIX references ON-PATH-
TELEMETRY-YANG's measurement-period-number), the similar naming between
ALT-MARK-YANG's "measurement-period" (duration) and ON-PATH- TELEMETRY-YANG's
"measurement-period-number" (counter) could confuse implementers. Consider
renaming ALT-MARK-YANG's leaf to "marking-period-duration" or similar.

(4) Redundant flow-direction typedef

ALT-MARK-YANG defines:
      typedef flow-direction {
        type enumeration {
          enum "ingress" { value 1; }
          enum "transit" { value 2; }
          enum "egress"  { value 3; }
        }
      }

ON-PATH-TELEMETRY-YANG defines its own identical typedef:
      typedef flow-direction {
        type enumeration {
          enum "ingress" { value 1; }
          enum "transit" { value 2; }
          enum "egress"  { value 3; }
        }
      }

These two flow-direction types are technically different YANG types even though
they have identical enum values. Tools performing cross-module type checking
may flag this.

Since ON-PATH-TELEMETRY-YANG already imports ietf-altmark and reuses
altmark:flow-id, it should also reuse altmark:flow-direction rather than
redefining an identical type.

(5) Redundant identity hierarchies for filter and protocol

ALT-MARK-YANG defines:
      identity filter { ... }
      identity acl-filter { base filter; }
      identity protocol { ... }
      identity ipv6 { base protocol; }
      identity srh  { base protocol; }
      identity mpls { base protocol; }

ON-PATH- TELEMETRY-YANG defines its OWN parallel hierarchy:
      identity filter { ... }
      identity acl-filter { base filter; }
      identity protocol { ... }
      identity ipv6 { base protocol; }
      identity srh  { base protocol; }
      identity mpls { base protocol; }
      identity nsh  { base protocol; }  // additional

These are separate identity trees. altmark:acl-filter and
on-path-telemetry:acl-filter are different identities despite representing the
same concept. An implementation configuring a flow via ietf-altmark cannot
directly reference the same identity instance in ietf-on-path-telemetry
operational state.

Either:

    (a) ON-PATH- TELEMETRY-YANG should base its identities on the altmark
    identities:
        identity nsh { base altmark:protocol; }

    (b) Both modules use a shared identity base from a common types module.

(6) Units of measure are not specified for measurement-period [ALT-MARK-YANG,
Section 4, leaf measurement-period]

The description says: "It specifies the AltMark marking period. Its value can
be set according to RFC 9341, RFC 9342 and draft-ietf-ippm-alt-mark-deployment"

No units are stated, which violates RFC 6390 Section 2.1: "Each definition
SHOULD include the unit of measurement."

Add a "units" statement to the YANG leaf, e.g.: units "milliseconds";

(7) Units of path-delay-* metrics [ON-PATH-TELEMETRY-YANG]

The tree shows:
      path-delay-mean?  uint32
      path-delay-min?   uint32
      path-delay-max?   uint32
      path-delay-sum?   uint64

RFC 9951 defines corresponding IPFIX IEs in microseconds
(pathDelayMeanDeltaMicroseconds, etc.). Each node in the YANG model should
include explicit "units microseconds" statements to match.

(8) Measurement interval definition

The measurement interval is the AltMark "period", which is central to
interpreting all counters and timestamps. While the concept is defined in
draft-ietf-ippm-alt-mark-deployment, the YANG configuration model
(ALT-MARK-YANG) should clearly state how measurement-period relates to the
interval over which counters are accumulated. Currently the connection is
implicit.

(9) Terminology: "in-band or out-of-band" [ON-PATH-TELEMETRY-YANG, Section 1]

"IOAM is a method to produce operational and telemetry
information that may be exported using the in-band or
out-of-band method."

RFC 10014 (BCP 161, published June 2026) recommends avoiding "in-band" and
"out-of-band" when referring to OAM. Consider using "In-Data-Packet" or
"Path-Congruent" terminology per RFC 10014.

(10) in-traffic-bytes/out-traffic-bytes missing "units"
[ON-PATH-TELEMETRY-YANG, loss-counters grouping]

YANG source:
      leaf in-traffic-bytes { type uint64; ... }
      leaf out-traffic-bytes { type uint64; ... }

While "bytes" is implied by the leaf name, RFC 8407 Section 4.12 recommends
explicit units.

Either add "units bytes;" or use yang:counter64 for consistency with
in-traffic-pkts and out-traffic-pkts.

(11) Incorrect counter type for sequence numbers [ON-PATH-YANG]

YANG source (delay-timestamps grouping):
       leaf in-pkt-seq-num {
         type yang:counter32;
       }
       leaf out-pkt-seq-num {
         type yang:counter32;
       }

A sequence number is an identifier, not a monotonically increasing counter in
the YANG sense (RFC 7950 Section 4.2.3). Using yang:counter32 is semantically
incorrect; it should be "type uint32" with a description noting that this is a
packet sequence number, not a counter.

In IPFIX, existing "sequence number" IEs (tcpSequenceNumber,
selectionSequenceId, rtpSequenceNumber, gtpuSequenceNum) use unsigned16, 32,
and 64 types.

(12) YANG module issues

ippm-alt-mark-yang-05.yang

The module name should be "ippm-alt-mark-yang".

The "enabled" leaf in altmark-admin-config contains a broken description due to
an extra quotation mark:
         description
           "This object is to control the availability of configuration.
            It MUST be true before anything in the
           "/altmark/available-interfaces can be edited.
            If false, any configuration in place is not used.";

ippm-on-path-telemetry-yang-05.yang

The module name should be "ippm-on-path-telemetry-yang"

(13) Multiple YANG tree discrepancies

The yang trees in both documents are missing if-feature annotations.
Many non-optional objects are incorrectly marked with '?'
Presence containers should be marked with '!'

Both yang trees should be regenerated from the yang.