[{"author": "Brad Peters", "text": "

sorry I have no audio

", "time": "2025-03-17T02:32:47Z"}, {"author": "Thomas Graf", "text": "

Hello everybody, the notes will be recorded here: https://notes.ietf.org/notes-ietf-122-nmop?edit

\n

Please review and and feel free to contribute/correct.

", "time": "2025-03-17T02:33:11Z"}, {"author": "Mohamed Boucadair", "text": "

@Brad, do you still don't have audio?

", "time": "2025-03-17T02:33:39Z"}, {"author": "Brad Peters", "text": "

still no audio for myself.....i will try a mobile in a minute

", "time": "2025-03-17T02:35:48Z"}, {"author": "Brad Peters", "text": "

I have audio now

", "time": "2025-03-17T02:40:54Z"}, {"author": "Thomas Graf", "text": "

Feel free Brad to correct/update me what I just have said about the BBF Spring Meeting on WT-508.

", "time": "2025-03-17T02:42:09Z"}, {"author": "Brad Peters", "text": "

I'll go back in the recording Thomas, believe I was trying to get audio when you made the statement

", "time": "2025-03-17T03:00:10Z"}, {"author": "Nigel Davis", "text": "

Apologies, microphone issues... will try to resolve. At least I can hear and see the presentation :)

", "time": "2025-03-17T03:05:18Z"}, {"author": "Mohamed Boucadair", "text": "

You can also share your comment here. It will be mirrored in the minutes

", "time": "2025-03-17T03:05:51Z"}, {"author": "Brad Peters", "text": "

Sigh audio issues. I said I'm happy to discuss to resolve.

", "time": "2025-03-17T03:05:54Z"}, {"author": "Mohamed Boucadair", "text": "

thanks, Brad

", "time": "2025-03-17T03:06:07Z"}, {"author": "Brad Peters", "text": "

Unfortunately the IVY meetings for Au is 2am otherwise I would have some of our experts joining the discussions to build out the Use Cases to drive an understanding of value. The linkage and ability to enable automation in assurance drives a very constructive business case.

", "time": "2025-03-17T03:21:36Z"}, {"author": "Brad Peters", "text": "

Green Pint!

", "time": "2025-03-17T03:23:46Z"}, {"author": "Alex Huang Feng", "text": "

I like the idea of having a standard on this, and support the idea of having YANG-Push related in a different YANG module

", "time": "2025-03-17T03:34:47Z"}, {"author": "Brad Peters", "text": "

old X733 defined a Probably Cause field

", "time": "2025-03-17T03:48:08Z"}, {"author": "Lionel Tailhardat", "text": "

On Root Cause Analysis :

\n

causality is described in the ITU-T G.7710
\nthrough the implementation of an inductive process at the NE level, and in the ITU-T X.733 through
\na doubt removal process at the MCS level.
\nThe inductive process described in the ITU-T G.7710 is based on the distinction made between
\n\u201cprimary failures\u201d (i.e. a failure that directly indicates the fault location and initiate a repair action,
\ne.g. a broken cable or a misconnection) and \u201csecondary failures\u201d (i.e. a consequential failure, e.g.
\nan upper level service that is gone down). Following on this
\nwith an alarm diffusion process approach in mind, the root cause of a
\ntransmission impairment must be sought in the first alarming NE of a datapath. Provided that
\ndownstream NEs will alarm on this forward failure, superfluous alarms can be silenced through an confirmer
\nalarm suppression function and with help of an Alarm Indication Signal (AIS) or a Forward Defect Indication (FDI).

", "time": "2025-03-17T03:49:16Z"}, {"author": "Brad Peters", "text": "

but on a broken cable the root cause may be the person tripped over the cable because it was not cabled correctly and not compliant with the cabling standard.

", "time": "2025-03-17T03:53:09Z"}, {"author": "Tom Hill", "text": "

@Robert Wilton So thinking about your point about what happens today -- no, no-one has a problem with understanding \"root cause\" at the moment because it isn't overloaded. But if we start overloading that terminology with something that purports to be the root cause, but isn't, we run the risk of introducing confusion. If you're doing something new, it's important to think about how it's going to be interpreted by those consuming it.

", "time": "2025-03-17T03:53:32Z"}, {"author": "Tom Hill", "text": "

Important also to note that I was at least the fourth person to point this out -- it's not just my being pedantic (as is often the case).

", "time": "2025-03-17T03:55:04Z"}, {"author": "Brad Peters", "text": "

The risk of defining root cause is not a actual root cause can lead to incorrect assessment to targeted restoration times which consequently impacts customer satisfaction. It also implies to a NOC operator that no more investigation to the cause is required.

", "time": "2025-03-17T03:57:21Z"}, {"author": "Lionel Tailhardat", "text": "

@Tom Hill I liked your idea of saying that once we state it is a root cause it means that we have a definitive opinion on the case, hence ending the analysis activity.

\n

In line with @Brad, I wish we get to understand the ultimate cause (e.g. a person tripped over the cable because it was not cabled correctly and not compliant with the cabling standard) ; therefore having two different labeling for a same root cause means we need to do posterior semantic reconciliation.

\n

A nice trend on this is to differenciate the cause location and the imputation.

", "time": "2025-03-17T04:03:00Z"}, {"author": "Brad Peters", "text": "

Good example on the Root Cause the result of research and investigation

", "time": "2025-03-17T04:03:08Z"}, {"author": "Dhruv Dhody", "text": "

Is there a better term for blackhole that we should use?

", "time": "2025-03-17T04:07:10Z"}, {"author": "Lionel Tailhardat", "text": "

@Dhruv Dhody yes, \"necessary and sufficient\"

", "time": "2025-03-17T04:09:12Z"}, {"author": "Mahesh Jethanandani", "text": "

Hi Dhruv, are you asking from an inclusive language perspective?

", "time": "2025-03-17T04:09:26Z"}, {"author": "Brad Peters", "text": "

owl

", "time": "2025-03-17T04:09:27Z"}, {"author": "Dhruv Dhody", "text": "

@mahesh - yes

", "time": "2025-03-17T04:10:08Z"}, {"author": "Holger Keller", "text": "

@dhruv, sorry for that. Something like internal dropping?

", "time": "2025-03-17T04:13:00Z"}, {"author": "Mahesh Jethanandani", "text": "

See this link: https://github.com/ietf/terminology/commit/dc3ae353acaaaf451e5dd47892241822a68496b0

", "time": "2025-03-17T04:14:08Z"}, {"author": "Robert Wilton", "text": "

@Tom, but my point is that when you currently use the term root cause, do you genuinely know that it is the actual root cause of the problem, or only what the root cause if from your observation point? Are you internally going to try and explain to everyone that when they say root cause they probably don't mean root cause?

", "time": "2025-03-17T04:14:39Z"}, {"author": "Brad Peters", "text": "

from an observation aspect in the heritage FCAPS the issue becomes the context is lost because events are typically separated from fault management. So observability is different from an event, performance, or even configuration

", "time": "2025-03-17T04:16:04Z"}, {"author": "Brad Peters", "text": "

reason for the network anomaly aspect that Thomas is presenting...to bring context to operations means that the heritage veiw of FCAPS needs to evolve in reality. There is much higher correlation that can be achieved in observability where the context is maintained

", "time": "2025-03-17T04:17:13Z"}, {"author": "Lionel Tailhardat", "text": "

@Brad your last remark makes a nice opening to knowledge graphs ! => capturing the incident context is at the core of past work I have carried out :)

\n

@Robert I understand your point as \"human operator labelling of the incident\", you might be interested in complementing this labelling with \"context capture\".

", "time": "2025-03-17T04:21:02Z"}, {"author": "Brad Peters", "text": "

@lionel it is a fact that to get higher correlation means maintaining the context. ITU M.3010 moved towards M.3041/3080 for smart operations and AI bringing together context...and yes how do you get the knowledge into that for enabling automation with the enterprise specific details as well. presenting actionable outcomes rather than research requests to NOC is another way of viewing that...

", "time": "2025-03-17T04:25:45Z"}, {"author": "Nigel Davis", "text": "

Sharing incidents in some abstracted and neutralized form such that the private data is removed but the incident pattern is preserved.

", "time": "2025-03-17T04:30:43Z"}]