From dee56a68466c3128407e474930f8366b80a0f13c Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Fri, 17 Apr 2026 11:58:54 -0400 Subject: [PATCH] =?UTF-8?q?Mark=20corrections-doc=20B1=20(data-path=20ACLs?= =?UTF-8?q?)=20and=20C5=20(consumer=20cutover=20scope)=20as=20RESOLVED.=20?= =?UTF-8?q?B1:=20OtOpcUa=20team=20has=20designed=20and=20committed=20the?= =?UTF-8?q?=20OPC=20UA=20client=20data-path=20authorization=20model=20in?= =?UTF-8?q?=20lmxopcua/docs/v2/acl-design.md=20(decisions=20#129=E2=80=931?= =?UTF-8?q?32)=20covering=20NodePermissions=20bitmask=20flags=20for=20Brow?= =?UTF-8?q?se/Read/Subscribe/HistoryRead/WriteOperate/WriteTune/WriteConfi?= =?UTF-8?q?gure/AlarmRead/AlarmAck/AlarmConfirm/AlarmShelve/MethodCall=20p?= =?UTF-8?q?lus=20common=20bundles,=206-level=20scope=20hierarchy=20with=20?= =?UTF-8?q?default-deny=20+=20additive=20grants,=20NodeAcl=20table=20gener?= =?UTF-8?q?ation-versioned=20alongside=20the=20rest=20of=20the=20content,?= =?UTF-8?q?=20cluster-create=20workflow=20seeding=20the=20v1=20LDAP-role-t?= =?UTF-8?q?o-permission=20map=20for=20v1=20=E2=86=92=20v2=20consumer=20mig?= =?UTF-8?q?ration=20parity,=20Admin=20UI=20ACL=20tab=20with=20bulk=20grant?= =?UTF-8?q?=20+=20permission=20simulator,=20denied-only=20audit=20logging;?= =?UTF-8?q?=20the=20"must=20work=20from=20day=20one=20of=20Tier=201=20cuto?= =?UTF-8?q?ver"=20timing=20constraint=20is=20satisfied=20because=20Phase?= =?UTF-8?q?=201=20(Configuration=20+=20Admin=20scaffold)=20completes=20bef?= =?UTF-8?q?ore=20any=20driver=20phase.=20C5:=20consumer=20cutover=20(Scada?= =?UTF-8?q?Bridge=20/=20Ignition=20/=20System=20Platform=20IO)=20is=20OUT?= =?UTF-8?q?=20of=20v2=20scope=20per=20lmxopcua=20decision=20#136=20?= =?UTF-8?q?=E2=80=94=20OtOpcUa=20team's=20scope=20ends=20at=20Phase=205=20?= =?UTF-8?q?(all=20drivers=20built,=20all=20stability=20protections=20in=20?= =?UTF-8?q?place,=20full=20Admin=20UI=20shipped=20including=20ACL=20editor?= =?UTF-8?q?);=20cutover=20sequencing=20per=20site,=20validation=20methodol?= =?UTF-8?q?ogy,=20rollback=20procedures,=20and=20Aveva-pattern=20validatio?= =?UTF-8?q?n=20for=20tier=203=20are=20deliverables=20of=20a=20separate=20i?= =?UTF-8?q?ntegration=20/=20operations=20team=20that=20has=20yet=20to=20be?= =?UTF-8?q?=20named.=20Plan=20should=20explicitly=20assign=20ownership=20o?= =?UTF-8?q?f=20the=20cutover=20plan=20to=20that=20team=20and=20link=20to?= =?UTF-8?q?=20their=20forthcoming=20doc.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.7 (1M context) --- handoffs/otopcua-corrections-2026-04-17.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/handoffs/otopcua-corrections-2026-04-17.md b/handoffs/otopcua-corrections-2026-04-17.md index 0c6ad6b..5c495b7 100644 --- a/handoffs/otopcua-corrections-2026-04-17.md +++ b/handoffs/otopcua-corrections-2026-04-17.md @@ -71,6 +71,17 @@ The v1 LmxOpcUa LDAP layer (`Security.md`) maps LDAP groups to OPC UA permission This is a substantial missing surface area in both the handoff and the v2 design. Suggest the plan add this as an explicit Year 1 deliverable alongside driver work, since Tier 1 (ScadaBridge) cutover will need authorization enforcement working from day one to satisfy "access control / authorization chokepoint" responsibility. +**Resolution** (lmxopcua decisions #129–132, 2026-04-17): the OtOpcUa team has designed and committed the data-path ACL model in `lmxopcua/docs/v2/acl-design.md`. Highlights: +- `NodePermissions` bitmask enum covering Browse / Read / Subscribe / HistoryRead / WriteOperate / WriteTune / WriteConfigure / AlarmRead / AlarmAcknowledge / AlarmConfirm / AlarmShelve / MethodCall, plus common bundles (`ReadOnly` / `Operator` / `Engineer` / `Admin`) +- 6-level scope hierarchy (Cluster / Namespace / UnsArea / UnsLine / Equipment / Tag) with default-deny + additive grants and Browse-implication on ancestors +- `NodeAcl` table is generation-versioned (decision #130) — ACL changes go through draft → diff → publish → rollback like every other content table +- Cluster-create workflow seeds default ACL set matching the v1 LmxOpcUa LDAP-role-to-permission map (decision #131), preserving behavioral parity for v1 → v2 consumer migration +- Per-session permission-trie evaluator with O(depth × group-count) cost; cache invalidated on generation-apply or LDAP group cache expiry +- Admin UI ACL tab + bulk grant + permission simulator +- Phase 1 ships the schema + Admin UI + evaluator unit tests; per-driver enforcement lands in each driver's phase (Phase 2+) per `acl-design.md` §"Implementation Plan" + +The "must be working from day one of Tier 1 cutover" timing constraint is satisfied — Phase 1 (Configuration + Admin scaffold) is completed before any driver phase, so the ACL model exists in the central config DB before any driver consumes it. + --- ### B2. Equipment-class templates dependency on the not-yet-created `schemas` repo blocks more than canonical-model integration @@ -209,6 +220,10 @@ Or alternatively, the cutover plan lives outside the OtOpcUa v2 design and is ow **Recommendation:** the cutover plan needs an owner and a doc. Either OtOpcUa team owns it (add Phases 6–8 to v2 plan) or another team owns it (handoff should name them and link the doc). +**Resolution** (lmxopcua decision #136, 2026-04-17): consumer cutover is **OUT of v2 scope** for the OtOpcUa team. The OtOpcUa team's responsibility ends at Phase 5 — all drivers built, all stability protections in place, full Admin UI shipped including the data-path ACL editor (per the §B1 resolution). Cutover sequencing per site, validation methodology, rollback procedures, and Aveva-pattern validation for tier 3 (System Platform IO) are deliverables of a separate **integration / operations team** that has yet to be named. + +The plan should explicitly assign ownership of the cutover plan to that team and link to their (forthcoming) doc, replacing any wording that implies the OtOpcUa team owns end-to-end through tier 3. The handoff §"Rollout Posture" tier 1/2/3 sequencing remains the authoritative high-level roadmap; the implementation-level plan for it lives outside OtOpcUa's docs. + --- ### C6. Per-building cluster pattern (Warsaw) — UNS path interaction needs clarification