NAM API Review Response: Alpha Release Strategy and Technical Roadmap Discussion

[clundie-CL]

Problem description
The Network Access Management (NAM) API has undergone a comprehensive review for potential inclusion in the Fall25 meta-release. The review identified significant compliance and design issues that would block approval for a formal meta-release. While an alpha release remains possible, it requires addressing critical technical compliance issues. Additionally, the team is simultaneously planning major architectural changes that could impact the API's structure and design approach.

See meta-release PR #73 contains original feedback and AI-generated review documents listed below for convenience:

• nam-camara-compliance-review.md

• nam-camara-design-review.md

Expected action

Discuss these agenda items:

• Release Strategy Decision:

  • Release-first: Do we prioritize the alpha release compliance of the current NAM spec?
  • Architecture-first: Do we prioritize the planned refactoring (e.g., Trust Domains replacement of Isolated Networks)?

  Proposal: Architecture-first focus in preparation for alpha release
  Rationale:

    - Spring26 meta-release target appears ambitious given current team capacity
    - Alpha release still requires addressing critical compliance issues
    - Refactored API could introduce changes that need considered in view of existing review feedback
  

• Sub-API Architecture Validation

  Proposal: Before going too far down this path, we should define and create a MVP branch that captures the intent of this design and submit for review.

• Critical Issue Resolution

  • Minor
    • Incorrect versioning and changelog references #74
    • BaseDevice schema duplication #80
    • See PR Prepare r1.1 #73 and review markdown attachments for context:
      • remove forbidden contact field
      • add missing externalDocs
      • correct server URL format
      • correct commonalities version format
      • correct service site path parameter reference
  • Major
    • Inconsistent Resource Hierarchy #75
    • PATCH for Bulk Operations #76
    • Overly complex scope hierarchy #78
    • Complex Discriminator Patterns #79
    • Remove Conditional Responses (or document necessity)
  • Meta-release compliance
    • Create gherkin feature file #52

Additional context

501 Usage

Herbert's comment:

        One additional question from my side: it is intentional that only the
endpoints for /isolated-networks are mandatory to be implemented while all
other features (service sites, devices, reboot requests) are optional
extensions (as they have 501 as possible response)?

Resolution: Sub-api design seeks to address this by mitigating the "fat interface" of a single monolithic OpenAPI spec providing user flexibility to decide which APIs need implemented in their context without excessive 501's related to irrelevant endpoints.

---

Misc:

• Multiple unclear/incomplete YAMLs (capabilities.yaml, domain folders)
  • Part of Sub-API structure. Will yank out into own branch
• Redocly config included but disallowed
  • Part of Sub-API structure. Will yank out into own branch

[caubut-charter]

All this has been triaged into other issues to be groomed further for which releases.