IETF Last Call Review of draft-ietf-nmop-simap-concept-12
review-ietf-nmop-simap-concept-12-opsdir-lc-linkova-2026-07-07-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-nmop-simap-concept-12

- Reviewer: Jen Linkova

- Review Date: 07-07-2026

- Intended Status: Informational

---

## Summary

Has Nits: This document is basically ready for publication but has nits that
should be considered prior to publication.

This document defines concept of Service & Infrastructure Maps (SIMAP),
discusses potential use cases and defines a set of requirements. The document
also discusses other related IETF work and explains how the SIMAP concept fits.

I found the document very well-written, easy to follow and understand, even by
someone who doesn't have any previous context.

Disclaimer: I've not been following the NMOP work (and I feel like it was a
mistake on my part..) so please excuse some newbie questions...

## Major Issues

No major issues found.

---

## Minor Issues

(again, as I know very little of the area, some of those issues might be just
me misunderstanding something)

1. Overview

1.1. "Since SIMAP is a data model and data models can generate APIs
[RFC3444][RFC7950]" - I checked both RFCs and I do not see APIs being
mentioned, so those references are a bit confusing, IMHO. Also, I'm not sure
"data models generate APIs" (I'm not a native speaker though). "Provide access
via APIs", maybe?

1.2. The text says that "the choice of modelling language and implementation
approach - is out of scope of this document". However later in the overview the
document says "potentially linking to non-YANG models". Is SIMAP limited to
YANG somehow? Do you think it should be made clear and explicit?

1.3 While reading the overview and learning about all those exciting things, I
was a bit confused how this document is related to, for example, RFC8345 and
RFC9315 - and only later I found the Appendix. I'd suggest adding a sentence
somewhere at the beginning of the Overview section, explaining that related
work is discussed in the Appendix.

1.4 "The SIMAP also provides write operations with the same set of APIs, not to
change a topology layer on the fly as a northbound interface from the
controller, but for both online and offline simulations, before applying the
changes to the network via the normal controller operations." I can imagine a
scenario, when in an intent-driven network some deployment operations (such as
deploying or decommissioning some part of the infrastructure) requires updating
the network topology intent. So is there any reason for this document not
considering such changes? Are they prohibited by some other documents? Maybe
it's worth clarifying. The same applies to the text in Section 4.1 for
REQ-PROG-OPEN-MODEL ("It also includes "write" operations, not for the ability
to directly change the live SIMAP data (e.g., changing the network or Service
parameters), but for offline simulations, also known as what-if scenarios.").

2. Section 3, Use Cases.
I have a general comment about this section, esp. Section 3.6 and 3.8.
A lot of that text seems to be generic, not specific to SIMAP. For example,
section 3.6 discusses overall aspects and benefits of the capacity planning in
general, while section 3.8 introduces a classification of network simulation
(3.8 doesn't even mention SIMAP at all). The reader might get an impression
that this document introduces a new classification, which seems to me a bit out
of scope of this document. IMHO, it would be better to rephrase it as "here are
examples of how network simulation can be used, and how SIMAP can be utilized".
Also, the section title says "Network Simulation and Network Emulation" but the
only mention of the emulation is when the authors explain how it's different
from simulation. Maybe remove "emulation" from the title and say smth
"simulation are not to be confused with emulation..."?

3. Section 4, Requirements.

3.1 Neither section 4.1 nor 4.2 using the normative language (all "should" are
lower case), while section 4.3 does use it. Is it intentional?

3.2 When this section talks about non-live topolgies (e.g. intended topology)
it's not very clear if SIMAP should support *multiple* non-live topologies of
the same type. IMHO it's worth mentioning as an explicit requirement.

4. A general comment: the document seems to refer to IP layer as a single
toplogy (or maybe I just misread it). While in practive IPv4 and IPv6
topologies might be different. So maybe adding a single sentence about it? to
ensure that Ipv4 and IPv6 can be modeled separately?

---

## Nits

Section 4.1,  REQ-STD-API-BASED says:
"SIMAP must provide the standard APIs that provide for read/write and queries. "

Maybe replace "read/write and queries" with "read-only and read/write queries"?