=== Again, as contributor === Thanks, Nigel. Italo, and Qin for further comments.
Nigel, you hit on my overall heartburn with this document. I ultimately feel that without strong collaboration with other bodies (de facto or otherwise) the IETF will end up with yet another set of terminology and approach to incident/problem management. If this document is adopted โ regardless of WG โ that collaboration and cooperation needs to be clearly spelled out IMHO. Qin and Italo, comments below. 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 [JMC] Iโd go as far as to spell out that tight cooperation is needed to make sure we donโt end up with our own flavor of incident management. 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. [JMC] Yes and no. If there is de facto or standardized language to which this document refers, then that should be incorporated. To Nigelโs point, maybe there is some additional language that can be local, but this should track with what those other bodies are doing. This would include liaison reviews to ensure consistency. 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 [JMC] Agreed this title would be clearer. Joe
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
