Skip to content

Implement YANG unique list constraint at instance validation #445

@steiler

Description

@steiler

Summary

YANG unique (RFC 7950 § 7.8.3) constrains list entries so that no two rows share the same combination of values for the leaf instances named in the constraint. Today the README YANG compatibility matrix marks unique as Partial for compiled schema and No for default-on value validation, with footnote 5 noting that there is no dedicated unique row validator in the active validation dispatcher—partners should not assume list uniqueness is re-checked at instance validation.

This issue tracks runtime enforcement of unique in data-server (aligned with other validators under pkg/tree/ops/validation and validation-defaults in config), unless product explicitly decides uniqueness is compile-only / elsewhere.

Note: The unique argument is not XPath (unlike must / when). It is a space-separated list of descendant schema node identifiers (descendant-schema-nodeid, RFC 7950 § 14). Implementation complexity is about path resolution, defaults, and participation rules—not an XPath VM.

Context

  • Test / fixture module with a unique example: tests/schema/sdcio_model_list_unique.yang (e.g. unique "ip port";).
  • Generated test types reference list-unique in tests/sdcioygot/sdcio_schema.go.

Acceptance criteria (draft)

  • Validate list instance data against compiled unique metadata from the bound schema (SDCPB / schema contract as emitted by the compile pipeline).
  • Failed transactions / writes surface a clear validation error when a proposed state would violate unique (same semantics as YANG for the supported subset).
  • Optional: YAML validation-defaults.disabled-validators key (e.g. unique) for parity with other validators, if we add a dedicated check.
  • Update README matrix footnote / cells when behaviour ships.

Open questions

  • Exact shape of unique in SDCPB (field paths, defaults, interaction with keys / ordered-by).
  • RFC scope for v1 vs explicitly unsupported: multi-segment descendant paths through nested data, interaction with default values, and when a list entry is excluded from the constraint because not all referenced leaves exist or have defaults (see § 7.8.3 and enforcement in § 8)—document any deliberate subset for partners.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions