Hi, Joe: ๅไปถไบบ: OPSAWG [mailto:opsawg-boun...@ietf.org] ไปฃ่กจ Joe Clarke (jclarke) ๅ้ๆถ้ด: 2024ๅนด2ๆ16ๆฅ 21:15 ๆถไปถไบบ: Henk Birkholz <henk.birkholz@ietf.contact>; OPSAWG <opsawg@ietf.org> ไธป้ข: 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), 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. 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. 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. Joe From: OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> on behalf of Henk Birkholz <henk.birkholz@ietf.contact<mailto:henk.birkholz@ietf.contact>> Date: Thursday, February 8, 2024 at 10:44 To: OPSAWG <opsawg@ietf.org<mailto:opsawg@ietf.org>> 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 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 OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
