Proposal: make OPI SZTP testable against Cisco IOS-XE (Catalyst) devices — 8 fork branches ready for review

[jeremycohoe]

Proposal: make OPI SZTP testable against Cisco IOS-XE (Catalyst) devices

Motivation

Today the docker-compose reference stack targets DPU-style clients.
Pointing it at real Cisco Catalyst hardware (9200 / 9300 / 9300X running
IOS-XE 17.x) requires a handful of workarounds that each user currently
rediscovers: building DHCPv4 option-143 per RFC 8572 §8.2, swapping the
trust-anchor bag between the ACT2 and circa-2020 Cisco SUDI CAs,
registering the device under the PID (which is what the Cisco SUDI
Subject.serialNumber returns, not the chassis SN), and validating the
voucher + owner-cert chain before reloading the switch.

I'd like to upstream the helpers and parametrization that remove those
sharp edges, while keeping the current default behavior byte-identical.

What's ready

8 self-contained topic branches on my fork, rebased on
opiproject/sztp@main. Every commit is DCO-signed, uses conventional
commit subjects, and passes the linters from
.github/workflows/linters.yml
locally (shellcheck -S warning, markdownlint --disable=MD013,
yamllint default with no-line-length).

#	Branch	What it adds	Size	Vendor-neutral?
1	feat/phase-a-dhcp-option143	RFC 8572 §8.2 DHCPv4 option-143 encoder (Python, 3 output formats) + 9 unit tests + dhcpd template + DHCP snippet examples	+330 / -19	Yes
2	feat/phase-b-iosxe-profile	Opt-in iosxe docker-compose profile (dhcp-render, dhcp-iosxe services); default up unchanged	+38	Cisco-ish
3	feat/phase-c-env-templates	Env-driven ${SZTP_TRUST_ANCHOR} / ${SZTP_DEVICE_SN} in sztpd templates; Catalyst env bundles	+91 / -5	Partially
4	feat/phase-d-validator	scripts/validate-sztp-artifacts.sh — 6 checks on voucher + owner-cert bundle	+144	Yes
5	feat/phase-e-preflight	scripts/sztp-preflight.sh — end-to-end readiness check against the running stack	+154	Yes
6	feat/phase-g-interop-matrix	tests/interop-matrix.yaml + runner; emits a Markdown result table	+188	Partially
7	feat/phase-h-safe-share	scripts/export-sanitized-bundle.sh (strips keys/vouchers) + matching .gitignore entries	+84	Yes
8	docs/phase-f-readme	README "Lab tooling" section	+24	Yes

Branch 2 stacks on branch 1; branches 3–8 are independent.

Non-breaking guarantees

• docker-compose up with no profile selected produces the same
  service set as today.
• config/sztpd.*.json.template rendered with no env overrides is
  semantically identical to the current upstream templates (defaults
  resolve to circa-2020 / first-serial-number).
• No existing file is renamed or deleted; all changes are additive
  except two template variable substitutions and two small edits to
  scripts/docker-entrypoint.sh (extended envsubst var list).

Validation status

• Linters: clean locally (matching upstream linters.yml).
• Unit tests: encoder has 9 tests covering RFC 8572 §8.2 length
  prefixing, https://-only rejection, multi-URI concatenation, and
  all three output formats.
• Real hardware: the stack as a whole has been exercised against a
  Cisco Catalyst C9300-24T (IOS-XE 17.18.01); that end-to-end work
  also involves sztpd-side CMS/voucher patches that are not
  included in these PRs (they are vendor-specific and I would submit
  them separately only if you want them). These 8 PRs are the clean,
  neutral parts.

Questions before I open PRs

1. Scope fit — willing to take any/all of these? Branches 1, 4,
   5, 7, 8 are vendor-neutral; 2, 3, 6 have a Cisco lean that I can
   rename (e.g. iosxe → network-device) if preferred.
2. Grouping — 8 small PRs, or 3 thematic ones?
   • "DHCP option-143 tooling" (1 + 2)
   • "Preflight + validator + safe-share helpers" (4 + 5 + 7)
   • "Env templates + interop matrix + docs" (3 + 6 + 8)
3. CI beyond linters I should pre-validate against?

Happy to iterate on naming, scope, or grouping here before any PR
lands in your review queue. Thanks!