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

[Olga Havel <[e-mail]>]

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]><mailto:olga.havel=[e-mail]>
Sent: Friday, February 13, 2026 5:23 PM
To: Sergio Belotti (Nokia) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Monday, February 2, 2026 8:43 AM
To: Olga Havel <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, January 30, 2026 6:58 PM
To: Sergio Belotti (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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