Summary
stripPrefixFromValue in sdcpb/path_additions.go strips module prefixes from path key values
by blindly splitting on the first ":" in each slash-separated segment. This is unsafe because
not every ":" in a value is a YANG module separator — IPv6 addresses and other colon-containing
strings are valid key values in many YANG models and must not be modified.
Why this is an issue
In RFC 7951 (JSON_IETF), module-qualified names only appear in JSON object keys and
identityref values. Generic string key values (e.g. inet:ip-address, inet:ipv6-address)
are not module-qualified — they are plain strings like 2001:db8::1. Any code that applies
: splitting unconditionally to path key values will silently corrupt those addresses.
Concrete example
A YANG list keyed by inet:ipv6-address:
/neighbor[address=2001:db8::1]/admin-state
stripPrefixFromValue("2001:db8::1") sees a : and cuts on it, producing db8::1.
The resulting path no longer matches the stored entry, silently breaking lookups.
Code occurrence
sdcpb/path_additions.go — stripPrefixFromValue (called from StripPathElemPrefixPath):
strips the first : from every slash-separated segment of a key value without checking
whether the segment is actually a module-qualified identifier.
Note on JSON object key stripping
The separate colon splitting on JSON object keys (e.g. srl_nokia-interfaces:interface → interface)
is intentional and correct: RFC 7951 object keys are always [module:]name identifiers, never
IPv6 addresses or other ambiguous strings. That code is not affected by this issue.
Expected behavior
Only strip a module prefix from a key value segment when it is unambiguously a YANG-qualified
identifier. At minimum: do not strip segments that contain more than one :.
Suggested fix direction
- Short term: guard
stripPrefixFromValue to only strip segments with exactly one :,
leaving multi-colon segments (IPv6, etc.) intact.
- Long term: make the stripping schema-aware and apply it only for
identityref-typed leaves.
Acceptance criteria
- Regression test: IPv6 key value
2001:db8::1 is preserved after StripPathElemPrefixPath.
- Regression test: mixed slash-separated value
mod:a/2001:db8::1/mod:c strips only the
unambiguous segments, yielding a/2001:db8::1/c.
- Existing behaviour for module-qualified identityref values (single
:) is unchanged.
Summary
stripPrefixFromValueinsdcpb/path_additions.gostrips module prefixes from path key valuesby blindly splitting on the first ":" in each slash-separated segment. This is unsafe because
not every ":" in a value is a YANG module separator — IPv6 addresses and other colon-containing
strings are valid key values in many YANG models and must not be modified.
Why this is an issue
In RFC 7951 (JSON_IETF), module-qualified names only appear in JSON object keys and
identityref values. Generic string key values (e.g.
inet:ip-address,inet:ipv6-address)are not module-qualified — they are plain strings like
2001:db8::1. Any code that applies:splitting unconditionally to path key values will silently corrupt those addresses.Concrete example
A YANG list keyed by
inet:ipv6-address:/neighbor[address=2001:db8::1]/admin-state
stripPrefixFromValue("2001:db8::1")sees a:and cuts on it, producingdb8::1.The resulting path no longer matches the stored entry, silently breaking lookups.
Code occurrence
sdcpb/path_additions.go—stripPrefixFromValue(called fromStripPathElemPrefixPath):strips the first
:from every slash-separated segment of a key value without checkingwhether the segment is actually a module-qualified identifier.
Note on JSON object key stripping
The separate colon splitting on JSON object keys (e.g.
srl_nokia-interfaces:interface → interface)is intentional and correct: RFC 7951 object keys are always
[module:]nameidentifiers, neverIPv6 addresses or other ambiguous strings. That code is not affected by this issue.
Expected behavior
Only strip a module prefix from a key value segment when it is unambiguously a YANG-qualified
identifier. At minimum: do not strip segments that contain more than one
:.Suggested fix direction
stripPrefixFromValueto only strip segments with exactly one:,leaving multi-colon segments (IPv6, etc.) intact.
identityref-typed leaves.Acceptance criteria
2001:db8::1is preserved afterStripPathElemPrefixPath.mod:a/2001:db8::1/mod:cstrips only theunambiguous segments, yielding
a/2001:db8::1/c.:) is unchanged.