[NMOP] Re: AD review of draft-ietf-nmop-simap-concept-10

[Mahesh Jethanandani <[e-mail]>]

Hi Olga,

Thanks for the proposed changes. A few notes. See inline with [mj].

> On Jun 2, 2026, at 5:57 AM, Olga Havel <[e-mail]> wrote:
> 
> Hi Mahesh, Reshad,
>  
> Please let me know if the following changes address your MAJOR comments.
>  
>  
> https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/173 Reference change:
> “ … and resource views of services, at different levels of abstraction,
>                                using the SIMAP [ETSI-ZSM-019]”
>               
>  
> 8.2.  Informative References
>  
>    [ETSI-ZSM-019]
>               ETSI, "Zero-Touch Network and Service Management (ZSM);
>               ZSM Framework for NaaS", ETSI GR ZSM 019 V1.1.1, January
>               2026, <https://www.etsi.org/deliver/etsi_gr/
>               ZSM/001_099/019/01.01.01_60/gr_ZSM019v010101p.pdf>.

[mj] The proposed [ETSI-ZSM-019] entry looks good. That addresses the MAJOR concern.

>  
>  
> https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/181 REQ-SECURITY and Security Considerations.
>  
> AS-IS: 
>    REQ-SECURITY:  The conventional NACM control access rules [RFC8341]
>       should apply.  This includes module control access rules, protocol
>       operation control access rules, data node control access rules,
>       and notification control access rules.
>  
> TO-BE:
> REQ-SECURITY:
> : Any SIMAP interface MUST support strong client authentication and authorization before granting
> access to SIMAP operations and data.
> 
> : For YANG-based Netconf and RESTCONF protocols, access control SHOULD follow the Network
> Configuration Access Control Model (NACM) [RFC8341].
> 
> : For non‑YANG protocols, implementations MUST provide an access‑control
> mechanism with similar level of protection to NACM, including fine‑grained
> authorization, role‑based access, and the ability to restrict access to
> sensitive topology and service and network data.
> 
> : Because SIMAP connects highly sensitive multi‑layer topology with
> service and network data, implementations MUST ensure confidentiality,
> integrity, and replay protection for all SIMAP interactions, using
> security mechanisms appropriate to the transport protocol (e.g., TLS, SSH).
> 
> : SIMAP implementations MUST prevent unauthorized write or simulation operations
> and ensure that simulation functions cannot become unintended configuration changes.
>  
> AS-IS:
>  
> 6.  Security Considerations
>  
>    As this document covers the SIMAP concepts, requirements, and use
>    cases, there is no specific security considerations other that those
>    discussed in Section 4.3.
>  
>    Section 8 of [RFC8345] discusses security aspects that will be useful
>    when designing the SIMAP solution.
>  
>        TO-BE:
> # Security Considerations
> 
> SIMAP provides a unified access point to multi‑layer topology, and relations to services
> and resources across network domains. Although this document defines concepts and
> implementation requirements rather than a concrete implementations and
> protocols, these requirements introduce significant security considerations
> that any SIMAP implementation or protocol MUST address.
> 
> ## Data sensitivity
> SIMAP aggregates information that is highly sensitive in operational
> environments, including physical/logical/service topology, logical‑to‑physical relations,
> service relations, identifiers such as SRv6 SIDs, and references to
> configuration, inventory, assurance, and telemetry systems. Unauthorized read
> access to this information could enable targeted attacks, lateral movement, or
> large‑scale service disruption. Implementations MUST ensure that
> confidentiality protections and fine‑grained access‑control policies are
> applied to all SIMAP data.
> 
> ## Authentication
> Any SIMAP implementation, regardless of modelling language or protocol,
> MUST provide strong client authentication before granting access to SIMAP data or operations.
> Authentication mechanisms depend on the underlying protocol binding (e.g., TLS
> client certificates, SSH keys, OAuth‑based API authentication), but the
> requirement for strong authentication is universal.
> 
> ## Authorization and protocol‑binding scope
> Because SIMAP explicitly allows non‑YANG protocol bindings (REQ‑PLUGG), NACM
> applies only to YANG‑based bindings. Non‑YANG bindings MUST provide an
> access‑control mechanism that offers protections equivalent to NACM, including
> role‑based authorization, fine‑grained access restrictions, and the ability to
> limit access to sensitive topology and service‑mapping information.
> 
> ## Write and simulation operations
> SIMAP supports operations that may modify data or simulate modifications (e.g.,
> what‑if analysis). Even when write operations are limited to simulation,
> implementations MUST ensure that such operations cannot become unintended
> configuration changes, and that simulation results cannot be used to
> infer privileged or hidden information.
> 
> ## Cross‑domain aggregation
> SIMAP may expose information aggregated from multiple administrative domains.
> Implementations MUST ensure that access‑control policies are consistently
> enforced across domains and that cross‑domain data leakage does not occur.
> Policy mismatches or inconsistent authorization models across domains can
> create unintended disclosure paths.
> 
> ## Transport security
> SIMAP implementations MUST ensure confidentiality, integrity, and replay
> protection for all protocol exchanges, regardless of the underlying protocol
> binding. Transport‑layer security mechanisms such as TLS [RFC8446] or SSH
> [RFC4253] MUST be used where applicable.
> 
> These considerations are not exhaustive; protocol specifications and
> implementations of SIMAP MUST define additional security mechanisms appropriate
> to their deployment environments.
> 
> {{Section 8 of ?RFC8345}} discusses further security consideration for YANG, NECONF,
> RESTCONF and specifically for ietf-network and ietf-network-topology modules.
>  

[mj] The proposed REQ-SECURITY and expanded Section 6 are comprehensive and address all my concerns. I'm happy with this direction.

On the [draft-ietf-nmop-digital-map-concept] warning: This was an idnits tool artifact. The Discussion Venues section of the draft includes the GitHub URL https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept — idnits parsed "draft-ietf-nmop-digital-map-concept" from that URL and flagged it as a missing reference. No new reference is needed; just verify the URL is correct and disregard the warning.

I look forward to seeing the full -11 revision with all 10 issues addressed.

Thanks,

>  
> Best Regards,
> Olga
>  
>  
>  
>  
> From: Olga Havel 
> Sent: Tuesday, June 2, 2026 12:26 PM
> To: 'Mahesh Jethanandani' <[e-mail]>; '[e-mail]' <[e-mail]>
> Cc: '[e-mail]' <[e-mail]>
> Subject: RE: AD review of draft-ietf-nmop-simap-concept-10
>  
> Hi Mahesh,
>  
> Thanks again for your detailed review. I opened 10 issues in git (https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues) I will share the proposed changes on the mailing list when we address them all, with the goal to agree the final changes in the next few weeks in time for the IETF 126 submission deadline (6th July).
>  
> Could you please just clarify your comment:
>  
> No reference entries found for these items, which were mentioned in the text:
> [draft-ietf-nmop-digital-map-concept].
>  
> Does it refer to the terms mentioned in the previous text – offline and online simulation. Are you suggesting to add some references?
>  
> Best Regards,
> Olga
>  
> From: Olga Havel 
> Sent: Tuesday, May 5, 2026 10:04 AM
> To: 'Mahesh Jethanandani' <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: RE: AD review of draft-ietf-nmop-simap-concept-10
>  
> Thanks Mahesh for the review and your feedback. We will address the issues and come back with the new version.
> This week is the deadline for some modelling proposals, so I hope to be able to start addressing your comments next week.
>  
> Best regards,
> Olga
>  
> From: Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> 
> Sent: Monday, May 4, 2026 5:09 AM
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: AD review of draft-ietf-nmop-simap-concept-10
>  
> The document is well-organized and clearly motivated. The working group process was thorough — 49 issues were opened and resolved during WGLC, the shepherd review (thanks Reshad) drove a further round of useful revisions in -09/-10, and there is genuine broad WG support.
>  
> I have a couple of MAJOR comments and some MINOR comments on the document that I would like to see addressed, and believe will improve the document further.
>  
> Thanks
>  
> MAJOR:
>  
> Section 3.1.1, paragraph 0
> >    The SIMAP APIs can be invoked to retrieve all Services for selected
> >    service types.  A SIMAP client application that triggers such a
> >    request will be able to retrieve the topology for selected Services
> >    via the SIMAP APIs and, from the response, it will be able to
> >    navigate top-down to the lower layers via the supporting relationship
> >    provided by the SIMAP server.  In doing so, the SIMAP client
> >    application will be able to determine what logical resources are used
> >    by a Service.  The supporting relations to the lowest layer, provided
> >    by the SIMAP server, will help the SIMAP client application to
> >    determine what physical resources are used by the Service.  This
> >    addresses a requirement for systems to be able to provide topology
> >    and resource views of services, at different levels of abstraction,
> >    using the SIMAP [REF: ETSI ZSM 019 Clause 6].  Knowing the physical
> >    resources a service uses enables capacity planning, fault isolation,
> >    performance monitoring, and accurate billing.
>  
> [REF: ETSI ZSM 019 Clause 6] is not an IETF-formatted reference and does 
> not appear in the References section. Either:
>  
> - Add it to Section 8.2 as a properly formatted Informative reference 
> (with publisher, title, date, URL), or
> - Remove the citation.
>  
> Section 6, paragraph 0
> >    As this document covers the SIMAP concepts, requirements, and use
> >    cases, there is no specific security considerations other that those
> >    discussed in Section 4.3.
>  
> Section 4.3 contains exactly one security item — REQ-SECURITY — which 
> says NACM [RFC8341] SHOULD apply. This is insufficient for a document 
> defining a system that:
>  
> - Aggregates full multi-layer topology (physical → service) across all 
> network domains in a single queryable API;
> - Exposes write operations through SIMAP APIs (even if restricted to 
> simulation);
> - Links to inventory, configuration, assurance, and telemetry data from 
> a single entry point;
> - Explicitly considers non-YANG protocol bindings (REQ-PLUGG: "not all 
> involved components can be available using YANG”).
>  
> The following concerns are not discussed at all and should be at least 
> acknowledged, even in an Informational requirements document:
>  
> 1. Data sensitivity: Multi-layer topology data (physical locations, link 
> types, service mappings, SRv6 SIDs, BGP paths) is highly sensitive.
> An adversary with read access to SIMAP has a complete map for attack 
> planning and lateral movement. The document should acknowledge this 
> and point toward confidentiality and access-restriction requirements.
>  
> 2. Authentication: NACM is an access-control model, not an authentication 
> mechanism. The document does not mention authentication requirements for 
> the SIMAP API at all, despite the sensitivity of the data.
>  
> 3. Scope mismatch: REQ-SECURITY references only RFC 8341 (NACM), 
> which is a YANG/NETCONF-specific access control mechanism. Since SIMAP 
> explicitly encompasses non-YANG interfaces, pointing only to NACM is 
> architecturally inconsistent. The Security Considerations should either 
> clarify that NACM applies only to YANG-based SIMAP implementations, 
> or provide a more general access-control requirement.
>  
> The Security Considerations section should be expanded to address these 
> points. It need not be exhaustive (this is a concept/requirements 
> document after all) but should be commensurate with the attack surface 
> being defined.
>  
> MINOR:
>  
> Section 1, paragraph 1
> >    SIMAP is a data model that provides a topological view of the
> >    operator's networks and services, including how it is connected to
> >    other models (e.g., inventory) and external data sources (e.g.,
> >    observability data, and operational knowledge).  This model
> >    represents a multi-layered topology and offers mechanisms to navigate
> >    amongst layers and correlate between them.  This includes layers from
> >    physical topology to service topology.  This model is applicable to
> >    multiple domains (access, core, data center, etc.) and technologies
> >    (Optical, IP, etc.).
>  
> This section contains two statements that directly contradict each other.
> In this paragraph, it says:
>  
> "SIMAP is a data model that provides a topological view of the operator's 
> networks and services …" 
>  
> and then in the last but one paragraph, it says:
>  
> "This document does not specify a SIMAP implementation approach and what 
> modelling language to use.”
>  
> A data model per RFC 3444 is implementation-specific — it is a formal, 
> implementation-ready specification. This document is instead a concept 
> and a requirements document that defines what a future SIMAP data model 
> must do. During WGLC (Issues 83, 117, 124), there was substantial 
> debate about whether SIMAP should be called an "information model"
> (RFC 3444's term for an abstract, protocol-neutral representation). 
> The WG chose "data model" by consensus, but the contradiction was 
> not resolved editorially.
>  
> Suggested fix: Add a brief explanatory sentence in Section 1 
> acknowledging this, e.g.: "While this document refers to SIMAP as a 
> data model to reflect the WG's intent that it be concretely 
> implementable, the actual data model specification — including 
> modelling language and implementation approach — is out of scope 
> and will be addressed in companion documents."
>  
> Section 2, paragraph 1
> >    This document makes use of the following terms:
>  
> REQ-MULTI-DOMAIN, REQ-COMMON-API, and REQ-SUBNETWORK make extensive use 
> of "domain" (network domain, multi-domain topology, etc.), but the term 
> is not defined in this section. The shepherd review (March 9) raised 
> this for REQ-MULTI-DOMAIN specifically. The response in -09/-10 is 
> not apparent in the text. A brief definition of "domain" as used in this
> document should be added to Section 2.
>  
> Section 4.1, paragraph 47
> >    REQ-BIDIR:  SIMAP must provide a mechanism to model bidirectional
> >       links.  While data flows are unidirectional, the bidirectional
> >       links are also common in networking.  Examples are Ethernet
> >       cables, bidirectional SONET rings, socket connection to the
> >       server, etc., where a link is modeled as bidirectional, which in
> >       turn might be supported as unidirectional links at the lower
> >       layer.
>  
> As currently written, it is unclear whether "SIMAP MUST provide a 
> mechanism to model bidirectional links" is:
>  
> (a) a requirement on this document's own specification (which would 
> be inconsistent with "this document does not specify a SIMAP 
> implementation approach"), or
>  
> (b) a requirement on future SIMAP implementations/specifications 
> that use this document as their requirements base.
>  
> A suggested fix would be to add a sentence at the end of Section 2 
> (after the BCP 14 boilerplate) clarifying that the normative keywords 
> in this section, define requirements for implementations and future 
> specifications that claim to realize SIMAP, not requirements on this 
> document itself.
>  
> Section 4.3, paragraph 2
> >    REQ-PERFORMANCE:  The SIMAP APIs and SIMAP server implementations
> >       must be performant, and have acceptable response-time.  Although
> >       we are not to define the response time here.
>  
> A requirement with no measurable criterion is not a useful requirement — 
> it tells implementers nothing they don't already know (no one intends 
> to be slow). This should either be given a concrete expression 
> (e.g., "the API must support incremental/streaming retrieval to handle 
> large topologies"), be scoped to specific use-case latency characteristics, 
> or be removed. Simply stating that "we are not defining response time here"
> while using must (even if it is lowercase) is not helpful.
>  
> Section 4.3, paragraph 4
> >    REQ-SECURITY:  The conventional NACM control access rules [RFC8341]
> >       should apply.  This includes module control access rules, protocol
> >       operation control access rules, data node control access rules,
> >       and notification control access rules.
>  
> Building on my MAJOR comment on the same topic, RFC 8341 (NACM) is a 
> NETCONF/YANG-specific standard. The document explicitly acknowledges 
> in REQ-PLUGG that SIMAP must connect to non-YANG models and that 
> "not all involved components can be available using YANG." If SIMAP 
> uses REST/HTTP or graph database APIs in some implementations, 
> NACM does not apply. The requirement should either be scoped
> ("For YANG-based SIMAP implementations, NACM [RFC8341] SHOULD apply") 
> or generalized to a vendor-neutral access-control principle.
>  
> Also, Section 1 explains the online/offline simulation split well 
> (and the shepherd review discussion resolved this satisfactorily in -09/-10). 
> However, Section 4 (requirements) has no corresponding requirement 
> that enforces this separation. REQ-PROG-OPEN-MODEL mentions write 
> operations for simulations but does not include a requirement 
> that real and simulated state must be kept distinct in the SIMAP 
> server's data. Given the significance of this architectural 
> decision (and the security implications raised in my MAJOR comment), 
> a requirement along the lines of "SIMAP MUST provide unambiguous 
> separation between real network topology state and simulation state" 
> would be appropriate.
>  
> No reference entries found for these items, which were mentioned in the text:
> [draft-ietf-nmop-digital-map-concept].
>  
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
>  
>  * Term "his"; alternatives might be "they", "them", "their"
>  * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
>    "intrinsic", “original”
>  
> NITS:
>  
> Section 3.1, paragraph 1
> > odes, termination points and links. This APIs can be invoked for Service impa
> >                                     ^^^^
> The singular determiner "this" may not agree with the plural noun "apis". Did
> you mean "these"?
>  
> Section 3.6, paragraph 15
> > rk simulation is a process used to analyse the behaviour of networks via sof
> >                                    ^^^^^^^
> Do not mix variants of the same word ("analyse" and "analyze") within a single
> text.
>  
> Section 3.7, paragraph 11
> > rotocol operations and interactions among devices in the network. For exampl
> >                                     ^^^^^
> Do not mix variants of the same word ("among" and "amongst") within a single
> text.
>  
> Section 3.8.1, paragraph 5
> >  of Service Disruption Detection fine tuning as described in [I-D.ietf-nmop-n
> >                                  ^^^^^^^^^^^
> This word is normally spelled with a hyphen.
>  
> Section 4, paragraph 4
> > ndard-based SIMAP and APIs, for multi-vendor support. SIMAP must provide the
> >                                 ^^^^^^^^^^^^
> This word is normally spelled as one.
>  
> Section 4.1, paragraph 14
> > applications should be able to move among entities that belong to the same l
> >                                     ^^^^^
> Do not mix variants of the same word ("among" and "amongst") within a single
> text.
>  
> Section 4.1, paragraph 36
> > vity between different networks, sub-networks, or domains. REQ-SUBNETWORK: S
> >                                  ^^^^^^^^^^^^
> This word is normally spelled as one.
>  
> Section 4.1, paragraph 36
> > model network decomposition into sub-networks. The requirement is about model
> >                                  ^^^^^^^^^^^^
> This word is normally spelled as one.
>  
> "A", paragraph 10
> > . REQ-TEMPO-HISTO: Must support geo-spatial (geographic coordinates, region, 
> >                                 ^^^^^^^^^^^
> This word is normally spelled as one.
>  
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>

Mahesh Jethanandani
[e-mail]