Return-Path: X-Original-To: nmop@mail2.ietf.org Delivered-To: nmop@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2AE00E884DCE for ; Sun, 3 May 2026 21:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777867773; bh=ynuALMEOpDNhzZiSp/MezFwYiH/ZJ997oxQZ3DogmhQ=; h=From:Subject:Date:Cc:To; b=FcI8abNLF7ORIhCELvtt3zNglal0QzCZCqV5GPOy4X2YkD3HJ3KOqKpdF5Y2P3tj5 gO8R/NncUXtjb/8ONMUX8WA+RhgAFrdmeUtFEWhXnWqfL5DNJnSsnC+NWotB5MOgti o/wpYlxE9IRuiWiKKpG6x9DhQzYYAAtopni9fkZs= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa5lBvxFYCqv for ; Sun, 3 May 2026 21:09:32 -0700 (PDT) Received: from mail-dy1-x1332.google.com (mail-dy1-x1332.google.com [IPv6:2607:f8b0:4864:20::1332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2E0C8E884DC7 for ; Sun, 3 May 2026 21:09:32 -0700 (PDT) Received: by mail-dy1-x1332.google.com with SMTP id 5a478bee46e88-2f00a567cfaso590673eec.0 for ; Sun, 03 May 2026 21:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777867765; x=1778472565; darn=ietf.org; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=yDO07L5RYmzmxcSFjAYK4Z0EDng4RK8rVOpfhrG//zA=; b=BfanN1O5rqBEOWEg3vzJMob0LxZeKzXE4W7ILvmDAFhS6RS4zOekkAqFYte3ANmAs5 vmHw1bA8xruq7QIswZJ9eC4G2lPW7/DYcgF65p1m5bt4euwqB3WAR0/4VAk0uCt+Ep+l iG0YHG3MEDT7fhv/c6FHcWFocedz7TxdT+HPYqQGTjhvSRhM1OJLVSOUg6Xc1CFeS9we DdYr9bQxWhHW6DEWuQ308RDkiqmUApF1CIOObAqEjrzG+yLgOpMWHlAvbyAQI4U1s0hV 7KH/Orz87NEAeCruMF3/aRKjp8YFG3RPGKxat7dCIfVtDuF05XaqTOXMkhz9atQhhlxT CXvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777867765; x=1778472565; h=to:cc:date:message-id:subject:mime-version:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yDO07L5RYmzmxcSFjAYK4Z0EDng4RK8rVOpfhrG//zA=; b=TfNdRBdcjfsEx1EqNknzuke65qIluYgZfyee0FC/6lkXE5M9CQt9SvXqFdTF5xOE8h V7B3u8iFhkMGc2tusk8EEMchqCHmHWmlxLaKJLHUOwiL9EWFJLpi14JiMP+1CPruJfR4 0II2YslfKwIv7NyQF8Ne646z3+jCb0RuvDQ49/MyJXQB6HP1Cx7X7iaTpi88AI3h9fZK DVyamislWbJWj4ByUeYqIgDH96ygfx0aQLVWMdBW9flNeJLJlISnv4RSP7bJlt7+QPNZ 63HrsnGueB4EVbVcOgoHtu90/Bm8z909ZdoqEszJ2MXSMAohRc9a6R3jjZb8B7rSW9SW cgHQ== X-Gm-Message-State: AOJu0YzneGO+tDkdVevYT6+4GCUlAkzqg9YjyZ87DYH/ceyaXmsres2A f4AbeRsZPLm4f75XWZqZc+6IEaoSzrIjxc2i+6ikYo1uOHMA6noaJiY0 X-Gm-Gg: AeBDieu3rDuICrR/PPoGt8DUY9uV4D3Gu7M7M29pXBq1UpiJS/qKRh0Tn1y1gAR0iDl cosd6kFH9bmrATndQIxfqOMwTqulraRXN9nfZzg9dc9nBMxn/ic3BZDUkJLNMDZUISgsjPSrgHq IUPa6uo8J6RMViftG9u0RS5GGzXntc8n8S7gGscIJUaoZ+1l9begMt2C6mjfPhrLk/WIaK+oOY+ NNz+tD96F+7z7TKKqCxU1LyE9OW4lq8EqoH0mT37aGt4Lh8h4P3UA/ga0nZcldAjjoYOZ9g8mqo VtNEFx0DFB/vd0E+qAKK0KF8ZfKg4VwldgOMziDq0N0HpbGmhmGh+wKpeHRseVe7MYyEcU+YoQZ QsKNQb2mGvJYK4bzXUfyrQ9oJX+b2T+aLswN8wlPKpA1365cMHdk7WUQZSNG5h9ClEuRNSqryXL jurpQ9GptP5vRkTVG6agUNZCjVlEPzf57LqZObudtmjNuEUy2qYf8218m0j8njgdWxI3VKHRYHb QEU3UY+nyboiHXHsw== X-Received: by 2002:a05:7301:d19:b0:2c1:67e1:61a9 with SMTP id 5a478bee46e88-2efb23861d5mr2717800eec.13.1777867764483; Sun, 03 May 2026 21:09:24 -0700 (PDT) Received: from smtpclient.apple (c-67-180-189-3.hsd1.ca.comcast.net. [67.180.189.3]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2ee38d78391sm19502344eec.7.2026.05.03.21.09.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2026 21:09:24 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_A6E12D79-CFE3-413E-870B-3AAB7C7BE879" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\)) Message-Id: <87882296-752E-4C87-BF46-4CCC304FF95B@gmail.com> Date: Sun, 3 May 2026 21:09:12 -0700 To: draft-ietf-nmop-simap-concept.all@ietf.org X-Mailer: Apple Mail (2.3731.700.6.1.21) Message-ID-Hash: FMDFMRSZAJP7WNZU4I35T5QV76456SDH X-Message-ID-Hash: FMDFMRSZAJP7WNZU4I35T5QV76456SDH X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: nmop@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BNMOP=5D_AD_review_of_draft-ietf-nmop-simap-concept-10?= List-Id: "Network Management Operations (NMOP) Working Group" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_A6E12D79-CFE3-413E-870B-3AAB7C7BE879 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The document is well-organized and clearly motivated. The working group = process was thorough =E2=80=94 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=20= not appear in the References section. Either: - Add it to Section 8.2 as a properly formatted Informative reference=20 (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 =E2=80=94 REQ-SECURITY = =E2=80=94 which=20 says NACM [RFC8341] SHOULD apply. This is insufficient for a document=20 defining a system that: - Aggregates full multi-layer topology (physical =E2=86=92 service) = across all=20 network domains in a single queryable API; - Exposes write operations through SIMAP APIs (even if restricted to=20 simulation); - Links to inventory, configuration, assurance, and telemetry data from=20= a single entry point; - Explicitly considers non-YANG protocol bindings (REQ-PLUGG: "not all=20= involved components can be available using YANG=E2=80=9D). The following concerns are not discussed at all and should be at least=20= acknowledged, even in an Informational requirements document: 1. Data sensitivity: Multi-layer topology data (physical locations, link=20= types, service mappings, SRv6 SIDs, BGP paths) is highly sensitive. An adversary with read access to SIMAP has a complete map for attack=20 planning and lateral movement. The document should acknowledge this=20 and point toward confidentiality and access-restriction requirements. 2. Authentication: NACM is an access-control model, not an = authentication=20 mechanism. The document does not mention authentication requirements for=20= the SIMAP API at all, despite the sensitivity of the data. 3. Scope mismatch: REQ-SECURITY references only RFC 8341 (NACM),=20 which is a YANG/NETCONF-specific access control mechanism. Since SIMAP=20= explicitly encompasses non-YANG interfaces, pointing only to NACM is=20 architecturally inconsistent. The Security Considerations should either=20= clarify that NACM applies only to YANG-based SIMAP implementations,=20 or provide a more general access-control requirement. The Security Considerations section should be expanded to address these=20= points. It need not be exhaustive (this is a concept/requirements=20 document after all) but should be commensurate with the attack surface=20= 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=20 networks and services =E2=80=A6"=20 and then in the last but one paragraph, it says: "This document does not specify a SIMAP implementation approach and what=20= modelling language to use.=E2=80=9D A data model per RFC 3444 is implementation-specific =E2=80=94 it is a = formal,=20 implementation-ready specification. This document is instead a concept=20= and a requirements document that defines what a future SIMAP data model=20= must do. During WGLC (Issues 83, 117, 124), there was substantial=20 debate about whether SIMAP should be called an "information model" (RFC 3444's term for an abstract, protocol-neutral representation).=20 The WG chose "data model" by consensus, but the contradiction was=20 not resolved editorially. Suggested fix: Add a brief explanatory sentence in Section 1=20 acknowledging this, e.g.: "While this document refers to SIMAP as a=20 data model to reflect the WG's intent that it be concretely=20 implementable, the actual data model specification =E2=80=94 including=20= modelling language and implementation approach =E2=80=94 is out of scope=20= 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=20= of "domain" (network domain, multi-domain topology, etc.), but the term=20= is not defined in this section. The shepherd review (March 9) raised=20 this for REQ-MULTI-DOMAIN specifically. The response in -09/-10 is=20 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=20 mechanism to model bidirectional links" is: (a) a requirement on this document's own specification (which would=20 be inconsistent with "this document does not specify a SIMAP=20 implementation approach"), or (b) a requirement on future SIMAP implementations/specifications=20 that use this document as their requirements base. A suggested fix would be to add a sentence at the end of Section 2=20 (after the BCP 14 boilerplate) clarifying that the normative keywords=20 in this section, define requirements for implementations and future=20 specifications that claim to realize SIMAP, not requirements on this=20 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 = =E2=80=94=20 it tells implementers nothing they don't already know (no one intends=20 to be slow). This should either be given a concrete expression=20 (e.g., "the API must support incremental/streaming retrieval to handle=20= large topologies"), be scoped to specific use-case latency = characteristics,=20 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=20 NETCONF/YANG-specific standard. The document explicitly acknowledges=20 in REQ-PLUGG that SIMAP must connect to non-YANG models and that=20 "not all involved components can be available using YANG." If SIMAP=20 uses REST/HTTP or graph database APIs in some implementations,=20 NACM does not apply. The requirement should either be scoped ("For YANG-based SIMAP implementations, NACM [RFC8341] SHOULD apply")=20 or generalized to a vendor-neutral access-control principle. Also, Section 1 explains the online/offline simulation split well=20 (and the shepherd review discussion resolved this satisfactorily in = -09/-10).=20 However, Section 4 (requirements) has no corresponding requirement=20 that enforces this separation. REQ-PROG-OPEN-MODEL mentions write=20 operations for simulations but does not include a requirement=20 that real and simulated state must be kept distinct in the SIMAP=20 server's data. Given the significance of this architectural=20 decision (and the security implications raised in my MAJOR comment),=20 a requirement along the lines of "SIMAP MUST provide unambiguous=20 separation between real network topology state and simulation state"=20 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", =E2=80=9Coriginal=E2=80=9D 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,=20 > ^^^^^^^^^^^ This word is normally spelled as one. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A6E12D79-CFE3-413E-870B-3AAB7C7BE879 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The document = is well-organized and clearly motivated. The working group process was = thorough =E2=80=94 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 =E2=80=94 REQ-SECURITY =E2=80=94 which 
says NACM = [RFC8341] SHOULD apply. This is insufficient for a = document 
defining a system = that:

- Aggregates full multi-layer topology = (physical =E2=86=92 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=E2=80=9D).

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:

Sec= tion 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 = =E2=80=A6" 

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.=E2=80=9D

A data model per RFC 3444 is = implementation-specific =E2=80=94 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 =E2=80=94 including 
modelling language and = implementation approach =E2=80=94 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 =E2=80=94 
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", = =E2=80=9Coriginal=E2=80=9D

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
mjethanandani@gmail.com

<= br class=3D"Apple-interchange-newline">




= --Apple-Mail=_A6E12D79-CFE3-413E-870B-3AAB7C7BE879--