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

Hi, Joe:
发件人: OPSAWG [mailto:opsawg-bounces@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-bounces@ietf.org<mailto:opsawg-bounces@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