Re: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04

["Davis, Nigel" <[e-mail]>]

Hi all,

As Joe points out, there is work by other bodies in this area that must be accounted for, and that was certainly the intention. One of the challenges of course, as Joe also notes, is gaining access to some of this work. In addition, in many cases one bodies work can only be used in the context of the other models from that body. We did discuss in TM Forum (~15 years ago), the construction of a federation of models from various bodies, but this did not develop. Since then we have had several attempts to reduce unnecessary variety in the industry with some success (that has usually occurred where there are individuals active across several bodies). Perhaps it is time to approach that federation again.

Considering federation, we have a similar work item in TAPI (related to problem reporting). The intention now is to not develop the model in the TAPI community and instead to leverage the IETF work. Hence, my aim is to ensure that the IETF work is also applicable for TAPI so that we have one YANG model, developed in IETF, that supports both needs. I aim to coordinate this as we proceed. The work in IETF will provide an open YANG model that is aligned with other IETF models and the intention is that this be consistent with the TAPI model.

As noted in the email chain below, there is a terminology challenge. We have taken an action to clean up the terminology usage and will aim to, where possible, align with terms used in the industry (although, as is often the case, the terms are used ambiguously and will need local definitions).

I hope the above helps…

Regards,

Nigel


From: OPSAWG <[e-mail]> On Behalf Of Italo Busi
Sent: Monday, February 19, 2024 2:59 PM
To: Qin Wu <[e-mail]>; Joe Clarke (jclarke) <jclarke=[e-mail]>; Henk Birkholz <[e-mail]>; OPSAWG <[e-mail]>; [e-mail]
Subject: [**EXTERNAL**] Re: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04

Qin, Joe,

A couple of comments of mine in line

Thanks, Italo

From: Qin Wu <[e-mail]<mailto:[e-mail]>>
Sent: domenica 18 febbraio 2024 03:13
To: Joe Clarke (jclarke) <jclarke=[e-mail]<mailto:jclarke=[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; OPSAWG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04

Hi, Joe:
发件人: OPSAWG [mailto:[e-mail]] 代表 Joe Clarke (jclarke)
发送时间: 2024年2月16日 21:15
收件人: Henk Birkholz <[e-mail]<mailto:[e-mail]>>; OPSAWG <[e-mail]<mailto:[e-mail]>>
主题: Re: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04

=== As a contributor ===

I struggle to see why the IETF should be working on this.  Clearly there are other SDOs that work in the area of incident management.  This draft refers to a [IMHO tenuous] reference to a TM Forum API spec (which I cannot read as I am not a member), but ITIL has similar definitions of incidents and problems.  There does not seem to be any liaison or indication of a close relationship with these other SDOs to help drive consistent use of terminology and help their members achieve desired goals.

[Qin Wu]
Thanks Joe for valuable input and comments, see my clarification in the presentation in IETF 116 (https://datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-incident-management-for-network-service-00.pdf [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-incident-management-for-network-service-00.pdf__;!!OSsGDw!L-hmq5U2QKNjd6Feub_s3qYT6UFm_01xmxRDrAjPkxhvBP9oi6kLaAw7zLKKaQsRS5Ri4WzYcVRlRqXfCwH8Y2Rk0gA$>), which I clarify the relationship
with TMF API spec, as you can see what draft-feng proposes to do is to define YANG model for incident lifecycle management, complementary to TMF API profile which focus on requirements, function, component capability. Talking with TMF API profile authors in TMF, they are happy to have this work land on IETF since IETF has more YANG model work expertise.

Secondly, the definition of network incidents and problems in TMF API spec is sourced from ITIL. ITIL is an internationally recognized and widespread de-facto standard for IT services management, not **developed by any other SDOs**, the idea of the definition of network incident and problem in TMF API spec is to introduce incident concept originally applied to IT field to **operator's network field**, which require support not only from domain controllers but also OSS. The typical scenario not only applied to optical scenario but also applied to IP network scenario.
Therefore in my opinion, alignment with TMF specification by quoting TMF network incident definition is sufficient, note that TMF specification has already been published by TMF. if you think necessary, I can consult with TMF specification authors for clarification.

[Italo Busi] IMHO, after this document is adopted as WG item, we can send a LS to TMF to get their feedbacks to make it sure the work is fully complementary to their work

Even in this first pass, I see what I feel is a mix of terminology.  You have an enumeration on leaf type where “fault” reads as the type of incident being a fault.  To me, this is the type of problem (i.e., the cause of the incident).  The incident type might be an SLA violation.

[Qin Wu] I believe this is naming confusion issue, according to network incident definition, the incident type can be unexpected interruption of the network service, or degradation of the network service, in the current design, we use fault and potential risk, if this is not clear, we can use better term as you suggested. Thanks.
Also as you can see, Nigel and Adrian have started a new draft on incident management terminology based on action point taken in IETF 118 side meeting on incident management, which can also help produce better terminology for this work.

[Italo Busi] This looks like an issue which can be addressed through normal WG process after adoption.

I do not feel this work should be adopted by the IETF in its current form.

[Qin Wu] I am thinking change the title into "A YANG Data Model for Network Incident management", which will focus on network level model, in the same level as L3NM, L2NM and Attachment Circuit.
[Italo Busi] Sounds reasonable to me
Joe

From: OPSAWG <[e-mail]<mailto:[e-mail]>> on behalf of Henk Birkholz <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 8, 2024 at 10:44
To: OPSAWG <[e-mail]<mailto:[e-mail]>>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04
Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-04.html [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-feng-opsawg-incident-management-04.html__;!!OSsGDw!L-hmq5U2QKNjd6Feub_s3qYT6UFm_01xmxRDrAjPkxhvBP9oi6kLaAw7zLKKaQsRS5Ri4WzYcVRlRqXfCwH8uU0Hg2w$>

ending on Thursday, February 22nd.

As a reminder, this I-D specifies a YANG Module for Incident Management.
Incidents in this context are scoped to unexpected yet quantifiable
adverse effects detected in a network service. The majority of the
document provides background and motivation for the structure of the
YANG Module that is in support of reporting, diagnosing, and mitigating
the detected adverse effects.

The chairs acknowledge some positive feedback on the list and a positive
poll result at IETF118. We would like to gather feedback from the WG if
there is interest to further contribute and review.

Please reply with your support and especially any substantive comments
you may have.


For the OPSAWG co-chairs,

Henk

_______________________________________________
OPSAWG mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsawg [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/opsawg__;!!OSsGDw!L-hmq5U2QKNjd6Feub_s3qYT6UFm_01xmxRDrAjPkxhvBP9oi6kLaAw7zLKKaQsRS5Ri4WzYcVRlRqXfCwH8HC9eJzk$>