CARVIEW |
Select Language
HTTP/2 200
date: Mon, 14 Jul 2025 07:32:59 GMT
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self' 'unsafe-inline' data: https://datatracker.ietf.org/ https://www.ietf.org/ https://ietf.org/ https://analytics.ietf.org https://static.ietf.org; frame-ancestors 'self' ietf.org *.ietf.org meetecho.com *.meetecho.com
cross-origin-opener-policy: unsafe-none
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=3600; includeSubDomains
vary: Cookie, Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
cf-cache-status: REVALIDATED
expires: Mon, 14 Jul 2025 11:32:58 GMT
cache-control: public, max-age=14400
server: cloudflare
cf-ray: 95ef5448ddb1c1b8-BLR
content-encoding: gzip
alt-svc: h3=":443"; ma=86400
Early Review of draft-ietf-nmop-terminology-07
Skip to main content
Early Review of draft-ietf-nmop-terminology-07
Early Review of draft-ietf-nmop-terminology-07
review-ietf-nmop-terminology-07-secdir-early-orman-2024-11-13-00
Request | Review of | draft-ietf-nmop-terminology |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2024-11-22 | |
Requested | 2024-10-17 | |
Requested by | Mohamed Boucadair | |
Authors | Nigel Davis , Adrian Farrel , Thomas Graf , Qin Wu , Chaode Yu | |
I-D last updated | 2025-06-26 (Latest revision 2025-06-18) | |
Completed reviews |
Secdir Early review of -07
by Hilarie Orman
(diff)
Genart Early review of -07 by Paul Kyzivat (diff) Opsdir Early review of -07 by Jouni Korhonen (diff) Rtgdir Early review of -07 by Stewart Bryant (diff) Iotdir Early review of -07 by Carsten Bormann (diff) Intdir Early review of -07 by Dirk Von Hugo (diff) Iotdir IETF Last Call review of -12 by Carsten Bormann (diff) Genart IETF Last Call review of -10 by Paul Kyzivat (diff) Secdir IETF Last Call review of -10 by Hilarie Orman (diff) Artart IETF Last Call review of -17 by Tim Bray (diff) Artart Telechat review of -19 by Tim Bray |
|
Comments |
The document establishes foundational terms and concepts for anomaly, incident, and fault management. Coining carefully these terms is thus important for adoption within the IETF at large (but also in discussion with other SDOs). Some of these terms may have more contextualized meaning in areas such as "incident" in security. We do appreciate your review on the scope, clarity, articulation of various concepts in the document. Of course, the WG and the authors welcome other comments. Thank you. |
|
Assignment | Reviewer | Hilarie Orman |
State | Completed | |
Request | Early review on draft-ietf-nmop-terminology by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/XskV_1SqS-ENeDyPxE4Q7OllU58 | |
Reviewed revision | 07 (document currently at 19) | |
Result | Has issues | |
Completed | 2024-11-13 |
review-ietf-nmop-terminology-07-secdir-early-orman-2024-11-13-00
To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-nmop-terminology.all@ietf.org Subject: Security directorate review of draft-ietf-nmop-terminology-06 --text follows this line-- Security review of Some Key Terms for Network Fault and Problem Management draft-ietf-nmop-terminology-06 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other early review comments. The selection of the "key terms" for definition was mysterious to me as I read the draft. Reading over the mailing list, I've come to see that it is conceived as a companion document for all the NMOP documents, and the terms were derived from that collection. The definitions help ensure that the document collection has consistent terminology. That, however, is undermined by the awkwardness of the definitions. This is a laudable effort to facilitate communication by acting on the adage "define your terms". Those definitions have to shine with clarity if they are to be useful. But if instead, the definitions are per se confusing, then there is no advantage, and it would be better to proceed on the assumption that the words have their ordinary dictionary meanings. Much of this document lacks clarity, as illustrated by the following samples. "A characteristic may be considered with respect to the concept of dimensional that is built on facts (see 'value', below) and dimensions (the contexts and descriptors that identify and give meaning to the facts)." I cannot interpret that sentence. "Dimensional analysis", perhaps? Still, it is opaque, and I recommend deleting it. The next sentence says that "metric" is a synonym for "characteristic". Amend the preceding sentence "Characteristic: Observable or measurable aspect or behavior associated with a resource." to "Characteristic: Observable or measurable aspect or behavior associated with a resource. I.e., a metric." "Value: A measurable amount which may be in the form of an integer (e.g., a count) or on a continuous variable (e.g., an analogue measurement) associated with a characteristic." Awkward phrasing. A value is a measured amount that can be integer or rational. A value is the measurement of a resource. That resource might be associated with a characteristic, or it might not, or it might be associated with many characteristics. Must a value be a number? Could it be one of "{low, medium, high}", for example? That might happen if a vendor supplies a "measurement" with those values. "Resource: A component, commodity, service, or capability that can be used to support the delivery of some function." What does the "delivery of some function" mean? "Function" is not a defined term. I suspect that a "resource" is more succinctly defined as a "component of a system". Further definitions suggest that a resource must have at least one "characteristic" (i.e., metric), so a resource is a system component with one or more metrics. Are there system components without metrics? Are they resources? I'm not sure. "Change: In the context of monitoring network resources, the variation in values associated with a characteristic of a resource at a specific time or over time. * Most changes are not noteworthy (i.e., are not relevant). * Perception of change depends upon detection, the sampling rate/accuracy/detail, and perspective." First, it's not a good idea to redefine an ordinary, simple word ("change") to have a particular meaning. It results in people having to say "I mean 'change' in the sense of terminology document, not in the sense of ordinary English" or vice versa. Beyond that, the definition is awkward. You can just say "a variation in a value or a history of those variations." A value is associated with a time, so there's no need to use "time" as part of the definition of "change". Why is the statement that "most changes are not noteworthy" part of the *definition*?? "Perception of change" sounds like "if a tree falls in the forest" conundrum. The text is redundant and unhelpful. "Event: The change in value (of a characteristic of a resource)" "Compared with a change, which is over a period of time, an event happens at a measurable instant." But an event is here *defined* as a "change". It's a change but not a change? What is a "measurable instant"? It's not the instant that's being measured, it's the value at a time. Etc.