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

[Mahesh Jethanandani <[e-mail]>]

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]