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

[Qin Wu <[e-mail]>]

Hi, Nigel, Joe, and Italo
Thanks for valuable input to this draft, see my reply inline below.
发件人: Davis, Nigel [mailto:[e-mail]]
发送时间: 2024年2月20日 21:06
收件人: Italo Busi <Italo.Busi=[e-mail]>; Qin Wu <[e-mail]>; Joe Clarke (jclarke) <jclarke=[e-mail]>; Henk Birkholz <[e-mail]>; OPSAWG <[e-mail]>; [e-mail]
主题: RE: [OPSAWG] 🔔 WG Adoption Call for draft-feng-opsawg-incident-management-04

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.

[Qin Wu] Thanks for sharing your experience to work with other SDOs or organizations,  I am optimistic with coordinations between IETF and many other various different SDOs. First IETF have liaison coordinators and liaison manager to facilitate such coordination, secondly even there is no formal liaison relation between IETF and other organization or body, it doesn’t prevent
Liaison statement exchanged between any two organization. Note that IVY WG was created  based on ITU-T SG15, ONF, IETF, Openconfig have common interests in some common building block. TMF in the past has sent many liaison statement to IETF, IRTF for feedback, it works well, you can check liaison pages(https://datatracker.ietf.org/liaison/). Many successful story depends on whether we have some delegate who in both organizations.
I think access to some work in SDOs who require membership is not big issues, e.g., for some SDOs, when standard work get published, it will be available to the public.

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.

[Qin Wu] Great to see TAPI community is willing to leverage the IETF work and thanks for help coordinate between TAPI community and IETF community, which help build a good eco-system.
One thing I want to clarify, TMF is not aimed at developing any YANG data model, they publish many API profile, but they are not targeted to develop YANG model work.
Note than I have reached out TMF experts who publish related work, he will chime in probably soon to clarify such collaboration.

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).

[Qin Wu] Thanks, one input from my side is we may use various different term at device level, network level, service level, I hope this alignment take place at each level. It is not good conflate everything together without level categorization.

I hope the above helps…

Regards,

Nigel


From: OPSAWG <[e-mail]<mailto:[e-mail]>> On Behalf Of Italo Busi
Sent: Monday, February 19, 2024 2:59 PM
To: Qin Wu <[e-mail]<mailto:[e-mail]>>; 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: [**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$>