Some Key Terms for Network Fault and Problem Management
draft-ietf-nmop-terminology-23

# Andy Newton, ART AD, comments for draft-ietf-nmop-terminology-19
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nmop-terminology-19.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Many thanks to Tim Bray for the ARTART review.

## Comments

To the issue of Ketan's DISCUSS, echoed by both Gunter and Éric, it might be worthwhile to reconsider the
language on lines 136 to 139.

136        When other documents make use of the terms as defined in this
137        document, it is suggested here that such uses should use
138        capitalization of the terms as in this document to help distinguish
139        them from colloquial uses, and should include an early section
140        listing the terms inherited from this document with a citation.

Perhaps:

    To avoid confusion with commonly used English words used in networking both in the IETF
    and other organizations, it is highly recommended that employment of these terms should use...

Thanks to Hilarie Orman for their multiple secdir reviews.

Section 6:  It is more than just network fault and problem management.  The collection and manipulation of all network traffic (the definition of 'network telemetry') may very well lead to the collection of end-user's privacy information.  That repository of information including the analytics generated from it needs to be protected and controlled to avoid exposure of that privacy information.  

I also support Ketan's discuss.  I certainly hope that these terms as they apply to network fault and problem management aren't now off limits to any other IETF subject areas (for example, the term 'alarms' is used in many places within the Security Area where it may or may not take on the same meaning as in this document).

Thanks for the work done in this document, it must have been a huge amount of work to reach consensus on all these terms!

Some comments though:

1) isn't "YANG data models" more appropriate than "YANG models" ?

2) why are the terms not sorted alphabetically ?

3) using SVG graphics (easy if markdown with aasvg) makes the HTML rendering much easier to read

4) like Ketan, I find the use of capitalization weird in `When other documents make use of the terms as defined in this document, it is suggested here that such uses should use capitalization of the terms as in this document to help distinguish them from colloquial uses`. Why not suggesting that other documents simply write in their terminology section that terms foo & bar are from this document (similar to the BCP 14 template).

I support the DISCUSS raised by Ketan.

From my perspective this document should clearly state that when its terminology is used, a referencing document must explicitly reference this document. Several terms defined herein, such as “state” and “error” (amongst others), are already in use in other contexts, particularly in routing protocols, where they may carry significantly different meanings. For example, “state” often refers to neighbor relationships or route computation phases, and “error” in BGP involves well-defined NOTIFICATION messages and extensive error codes (e.g., per RFC 7606).

Without such clarification, there is a risk of semantic conflicts or misinterpretation when these terms are used in non-management contexts or sometimes even in management contexts of routing technologies. I would like to see an explicitly acknowledge within this draft that its terminology is not normative across all IETF work, and that other documents remain free to define their own terminology or that it is expected to reference this document if alignment is intended.

The document is well-written and probably useful in the proper context. However, I concur with Ketan's DISCUSS about defining what that context is. It currently states that these terms are defined "for the IETF" while other bodies might use them as well; this suggests a broad application of these definitions through all future IETF publications. If that's the intent, it probably needs to come out of a broader community than nmop.

Rather, I would expect to see a BCP14-like boilerplate that future documents could use when they import these terms; something like

> The terms "Event", "State", "Fault", "Problem", "Symptom", "Cause", "Alert", and "Alarm" in this document are to be interpreted as described in [RFCthis] when, and only when, they appear capitalized as shown here.

Alternatively, a fixed boilerplate could be omitted and instead require that documents cite this document in order to use these terms. Either way, it needs to be clear that the definitions in this document do not automatically apply to all future IETF documents.

I support Ketan's discuss - it would be nice to scope this down