[NMOP] Re: SIMAP Issue #110: SIMAP definition - Observability sources and operational knowledge

[Dan Voyer IETF <[e-mail]>]

Hi Olga, Benoit, and Sergio,

I understand where Sergio is coming from, but I have a strong preference to
keep the *definition* short and avoid expanding it into a long list of
low-level details (as Benoit also noted). I’d suggest a small tweak to the
existing sentence to make it a bit clearer while keeping it simple.

AS IS:

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/data
(e.g., inventory, observability sources, and operational knowledge).


Dan's tweak:
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).

If we still feel we need examples, I’d rather add a brief clarifying
sentence outside the definition, but I don’t think we should keep iterating
on the definition text itself. This thread has already taken longer than it
should — let’s keep it simple/clear and move on.

Best,

Dan


On Mon, Feb 23, 2026 at 6:00 AM Olga Havel <olga.havel=
[e-mail]> wrote:

> Thanks for the feedback Benoit, I agree with you completely.
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Sunday, February 22, 2026 9:55 PM
> *To:* Olga Havel <[e-mail]>; Olga Havel <olga.havel=
> [e-mail]>; Sergio Belotti (Nokia) <
> [e-mail]>; [e-mail]; [e-mail];
> OSCAR GONZALEZ DE DIOS <[e-mail]>;
> [e-mail]; 'reshad@yahoo. com' <[e-mail]>
> *Subject:* Re: SIMAP Issue #110: SIMAP definition - Observability sources
> and operational knowledge
>
>
>
> Hi Olga,
>
> Since you are asking directly, here is my feedback.
>
> I actually disagree with the initial comment "Observability sources, and
> operational knowledge need to be better described . It is important since
> they are part of SIMAP definition." (
> https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/110
> )
>
> When I look at the TO BE below, it seems to me that we now have a too long
> list of low level details for a definition.
> Do we really want to have a term (specified in the terminology, so
> hopefully reused in different documents) that troubleshooting playbooks,
> policy documents, even change-management logs. If a specific SIMAP
> implementation has all of those, fine, but it's a different story to
> include them in definition.
>
> The outcome of the concept draft is a YANG module. I can picture people
> asking : how does your SIMAP YANG module link to metrics, logs, traces and
> alerts, policy documents, troubleshooting playbooks, change-management
> logs, just to name a few.
>
>
>
> I have a strong preference for the initial definition, kept generic on
> purpose.
>
> Regards, Benoit
>
> Hi Med, Oscar, Thomas, Benoit, Reshad, others,
>
>
>
> We agreed the SIMAP definition some time ago and there was consensus about
> it. Sergio is now asking us to add clarification about what observability
> sources and operational knowledge  are inside this definition.
>
>
>
> Therefore, the following change is a candidate, please let me know if you
> agree that it improves the definition. I am happy to leave it as it is,
> based on the consensus we had some time ago, but want to get more feedback
> before closing the issue either way. I feel that we spent some time
> agreeing the definition and reaching consensus, do not feel comfortable
> changing it based on late comments without getting more feedback.
>
>
>
> AS IS (both in Terminology and in Introduction):
>
>
>
> 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/data
> (e.g., inventory, observability sources, and operational knowledge)
>
>
>
> TO BE (in Terminology, in Introduction, or in both ?. If we agree to
> change it, I would recommend in Terminology only):
>
>
>
> 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/data
> (e.g., inventory, observability sources *like metrics, logs, traces and
> alerts*, and operational knowledge *like configuration files, policy
> documents, troubleshooting playbooks, change-management logs*)
>
>
>
> Best Regards,
>
> Olga
>
>
>
> *From:* Olga Havel <olga.havel=[e-mail]>
> <olga.havel=[e-mail]>
> *Sent:* Friday, February 13, 2026 5:23 PM
> *To:* Sergio Belotti (Nokia) <[e-mail]>
> <[e-mail]>; [e-mail]
> *Subject:* [NMOP] Re: SIMAP Issue #110: SIMAP definition - Observability
> sources and operational knowledge
>
>
>
> Hi Sergio,
>
>
>
> I am not sure if we can separate model and data as you suggested, as we
> may need to connect at both model level (A->B) and instance/data level
> (A:a1->B:b1) for inventory, observability sources, and operational
> knowledge.
>
>
>
> Best regards,
>
> Olga
>
>
>
>
>
>
>
> *From:* Sergio Belotti (Nokia) <[e-mail]>
> *Sent:* Monday, February 2, 2026 8:43 AM
> *To:* Olga Havel <[e-mail]>; [e-mail]
> *Subject:* RE: SIMAP Issue #110: SIMAP definition - Observability sources
> and operational knowledge
>
>
>
> Hi Olga,
>
> I disagree with you about the need of better description and your proposal
> under “to be” would help.
>
> I think the best would be to separate the connection to other models from
> data , in this way :
>
>
>
> “……..,  including how it is connected to other models (e.g., inventory)
>  and data (e.g. observability sources like metrics, logs, traces and
> alerts, and operational knowledge like configuration files, policy
> documents, troubleshooting playbooks, change-management logs)
>
>
>
> This would fix my comment.
>
>
>
> BR, Sergio
>
>
>
> *From:* Olga Havel <[e-mail]>
> *Sent:* Friday, January 30, 2026 6:58 PM
> *To:* Sergio Belotti (Nokia) <[e-mail]>; [e-mail]
> *Subject:* SIMAP Issue #110: SIMAP definition - Observability sources and
> operational knowledge
>
>
>
> Hi Sergio,
>
>
>
> In relation to your comment about SIMAP definition: Observability sources,
> and operational knowledge need to be better described . It is important
> since they are part of SIMAP definition.
>
>
>
> The text that includes ‘observability sources and operational knowledge’
> was proposed by an operator and they are just mentioned as examples (e.g.
> of external data). I don’t personally find these terms ambiguous and needed
> any definitions or clarification in terminology. My concern would be that
> any clarification would expand the definition because of something that is
> an example of external entities outside of SIMAP, and move the focus from
> SIMAP itself.
>
>
>
>
>
> Nevertheless, if others agree with you I can easily add the following
> sentence that clarifies it further:
>
>
>
> AS IS:
>
>
>
> 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/data
> (e.g., inventory, observability sources, and operational knowledge)
>
>
>
> TO BE:
>
>
>
> 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/data
> (e.g., inventory, observability sources like metrics, logs, traces and
> alerts, and operational knowledge like configuration files, policy
> documents, troubleshooting playbooks, change-management logs)
>
>
>
>
>
> Best regards,
>
> Olga
>
>
> --
> Nmop mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>