List Key Value Derivation Is Implicit and Unspecified

[ahassany]

The draft states (Section 3.1.1) that when the schema node is a YANG list, the list key leaf name (per RFC 7950 §7.8.2) is appended to the identifier, and the key value comes from the actual telemetry message content. This is a reasonable design in principle. The examples show:

• interfaces/interface/name/ethernetCsmacd.0.9.0
• hardware/component/name/board.0.9/state

However, the draft never specifies the procedure for this derivation. Open questions include:

1. Multi-key lists: RFC 7950 §7.8.2 permits lists with multiple key leaves. When a list has two or three keys (e.g., /routing/ribs/rib has name; a BGP neighbor list might have remote-address + remote-as), how are all key values concatenated in the Message Key string? No separator or ordering rule is defined.
2. Nested lists: YANG data models frequently have list-within-list structures. For example, interfaces/interface/ipv4/address involves keys at both the interface level (name) and potentially address level (ip). The draft provides no guidance on whether and how nested list keys are incorporated into the Message Key.
3. Key value sanitization: List key values in operational data can contain characters that are not valid in Kafka topic names (e.g., /, :, spaces). The draft defines topic names derived partly from absolute-schema-nodeid but does not clarify whether the list key values (which appear in the Message Key, not the topic name) require any encoding or sanitization.