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

[Olga Havel <[e-mail]>]

Hi Mahesh,

The new version with all updates is submitted  https://datatracker.ietf.org/doc/draft-ietf-nmop-simap-concept/11/

In regards to inclusivity:

  *   “his” refers to two specific individuals named in the acknowledgements, and the pronoun reflects their actual gender. Since this is not a generic usage, it is consistent with the RFC Editor’s inclusivity guidelines which says to not use his when referring to an unspecified person.
  *   “native topology” is used here in a purely technical sense and aligns with terminology used in related IETF documents. It does not refer to people or cultural identity, and therefore as purely technical term cannot be misread. Replacing it with the term ‘base topology’ or ‘built-in topology’ may bring the draft into misalignment with other IETF documents.
Let me know if these clarifications are sufficient or if we need to make some changes.

Thanks all for the help with this draft and the valuable feedback and contributions.

Best Regards,
Olga


From: Mahesh Jethanandani <[e-mail]>
Sent: Tuesday, June 2, 2026 4:50 PM
To: Olga Havel <[e-mail]>
Cc: [e-mail]; Reshad Rehman <[e-mail]>; [e-mail]
Subject: Re: AD review of draft-ietf-nmop-simap-concept-10

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.



  1.  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.





  1.  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]