[Iot-directorate] Re: Iotdir last call review of draft-ietf-nmop-terminology-12

Adrian Farrel <adrian@olddog.co.uk> Tue, 25 February 2025 12:12 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: iot-directorate@mail2.ietf.org
Delivered-To: iot-directorate@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8F068F37D8; Tue, 25 Feb 2025 04:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietfa.org (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietfa.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHRBkX2YTspa; Tue, 25 Feb 2025 04:12:28 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id DD5FCF37CF; Tue, 25 Feb 2025 04:12:27 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 51PCCQ8V012946; Tue, 25 Feb 2025 12:12:26 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A835746056; Tue, 25 Feb 2025 12:12:26 +0000 (GMT)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9BC9646054; Tue, 25 Feb 2025 12:12:26 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 25 Feb 2025 12:12:26 +0000 (GMT)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 51PCCP4i009170 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Feb 2025 12:12:26 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Carsten Bormann' <cabo@tzi.org>, iot-directorate@ietf.org
References: <174048375514.514315.7611517372815752227@dt-datatracker-865df477df-9x8cj>
In-Reply-To: <174048375514.514315.7611517372815752227@dt-datatracker-865df477df-9x8cj>
Date: Tue, 25 Feb 2025 12:12:26 -0000
Organization: Old Dog Consulting
Message-ID: <00c301db877e$88d23c30$9a76b490$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFVhG5vHLQIKnI1UsmEFlA2jN22r7Rj8DXg
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=+GAwYbNKUxUXbA9Pry+9PxPy/x3Effw6tjqxbFecoqo=; b=L7Q ib2Yf6rtrPtT+koHXqmQZ5gfFqyplWkfLxFwdOOqpHN6Rp2geFdeZX9LKFpkqfUe 7maAhw9qNREGsZaAO/NRytxxkxCJdgCaWqBSH3M19WEezP66TEcxmBPBFEfBmVAW 12AHn1iLTepuK3WFpcGU/OKMQ1S/VUaUZT3ciSGHGZ2g4lwLaWHHifXZ+mBGrtEM fH6kkA3fS+Jp9/ZiP/YdTFcJ0tjgnLL3bvhHFFGqaQ/B2vONzasQQSoNZcNWgI4D l65W7BtX6g77ADRRA5czOQjyYL6zzYOSj3BXBtAyqmhzCguhijSoT38JfADelR56 hHZ0LXsOP4YlbO7S9cg==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--17.995-10.0-31-10
X-imss-scan-details: No--17.995-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--17.994500-10.000000
X-TMASE-MatchedRID: cxtZ8fwm3r/xIbpQ8BhdbI61Z+HJnvsOodQJXaDex6cvfU/riSJXkfq6 5RK/zjY1vq0sEAkmDEw8czWEGg4ankR7xl0618fERZfQN+FVqbASrxWnE1VUiUS0FpbI+14TM3Y rZzY21s+unJ7G0FIja9YBcMfOKzzWuohcuWcG2KiVUcz8XpiS9NwCa7XGp562k7MocNSj6pBqoG OwZhPjWu3QaqgYRymuyk81LzWXsmTmEVp5St5Eyu0/o+/4D7Dz9lt4BAQuIFR3de2OoBqgwtSHn JDq2yhMlRfuHzdcD7nsUWTPoh4/y79jX++auvv+KUD7foTmAvHb4QM/D7zGt1AoBBK61BhcXb3Y 2+SMHW6ZkIhQBFBMC4w7GY4c7pdLQzPxCWPcYtPece0aRiX9Wh6OXxdRGLx8os8wrPFFbA7u8zO HHa3Lj50vTLCCHDuIp6l9FCowYcWw1nLnnWhzt2ArOQGGb1wvNZEftOVQtYbwE9UIysbNohMGtP kUyFbdK2m0H5nZqT5d9dxa/QHfL5pjs55FQFHAyKTEsCRIdyXgtad6/aNzRQAheUymmndfacfF0 oh8JwwBn9KSPiWzj1+24nCsUSFN/fTpDjOELgPdB/CxWTRRuyUIayx+Skid
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: O66RCGH67ADV3LT2PFVDD2SQ2NAHHSOF
X-Message-ID-Hash: O66RCGH67ADV3LT2PFVDD2SQ2NAHHSOF
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-nmop-terminology.all@ietf.org, last-call@ietf.org, nmop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [Iot-directorate] Re: Iotdir last call review of draft-ietf-nmop-terminology-12
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/k0uQGdHFDv4f7gz4MRutlGtnIOU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Owner: <mailto:iot-directorate-owner@ietf.org>
List-Post: <mailto:iot-directorate@ietf.org>
List-Subscribe: <mailto:iot-directorate-join@ietf.org>
List-Unsubscribe: <mailto:iot-directorate-leave@ietf.org>

Thanks for this, Carsten.

I'll work on the updates.

On whilst versus while...
American (being essentially German) only has while (während).
Thereby it lacks subtlety.
"Adrian is a pedant, while Carsten tries to be helpful," means that Adrian is pedantic when (at the times that) Carsten is trying to be helpful.
"Adrian is a pedant, while Carsten tries to be helpful," means that Adrian is a pedant, but Carsten is a nice guy.

Since English speakers struggle translating when into wann or als, I feel this discussion might be better in another forum :-)

We can probably leave the RFC Editor to make correctifications.

Cheers,
Adrian

-----Original Message-----
From: Carsten Bormann via Datatracker <noreply@ietf.org> 
Sent: 25 February 2025 11:43
To: iot-directorate@ietf.org
Cc: draft-ietf-nmop-terminology.all@ietf.org; last-call@ietf.org; nmop@ietf.org
Subject: Iotdir last call review of draft-ietf-nmop-terminology-12

Reviewer: Carsten Bormann
Review result: Ready with Issues

(Insert IOTDIR review boilerplate here.)

My apologies for the tardy completion of this review assignment.

Thank you again for doing this work, and for considering my feedback
to the -07 revision of this draft.

I read this document anew (trying not to be influenced by my older
review, which I believe you have taken care of).

I believe this is almost ready to publish, limited to a few (smaller)
actual issues.  These and some more nitpicking below.

(Page numbers below are with respect to a PDF rendering that I had to
create on my own as the data tracker cannot currently create a proper
PDF form of I-Ds.  Please find it, with the markups referenced below, at:
https://tzi.org/~cabo/draft-ietf-nmop-terminology-12-marked.pdf
)

## Minor

* Box, page 4
metadata

This is the only occurrence I find for this word, and I'm not sure if
I understand why it is used here; I think it means something
different than the result of processing some data.

* Anchored Note, page 4
Observability

This term is interesting, as its name suggests a capability, not a
process.  There probably will be no confusion among the intended
consumers of this terminology, but this small dissonance may be worth
half a sentence.

* Anchored Note, page 4
data gathered

This is now saying that Network Monitoring exclusively feeds from
Telemetry, and what Monitoring mostly is concerned with is keeping a
record of that.
Naïvely, I would expect there are some additional sources of information that
go into that record, particularly events on the intent side.
E.g., you would monitor that an interface went down, but you also
would monitor (take into the record) that it was administratively shut
down -- that will certainly help with making sense of the Event.

* Anchored Note, page 6
Thus a Fault happens at a moment in time

So a Fault always goes away right after this moment in time?
I’m not sure that this is an intuitive (i.e., familiar) usage of this term.

* Anchored Note, page 7
requires

➔ may require
(except for false alarms)

* Anchored Note, page 12
Fault Management

Is this just a statement about fault management?
(There is one more place where "Fault Management" is used and maybe
"Fault and Problem Management" is meant; otherwise the document is
very careful to use the latter, so I'm wondering whether there is a
semantics difference here.)

## Editorial

* Highlight, page 4
behavior, and to identify, anomalies

Can't parse.

* Highlight, page 4
where

This fragment is not really trying to be a sentence with the bullet
items following it.

* Anchored Note, page 6
whilst a Problem is unresolved it may continue to require attention

This is not surprising.
What is the note trying to say?

I looked up “whilst” (which I'm not seeing very often), and maybe this
BE word doesn’t help my understanding.

whilst | (h)waɪlst | British English
conjunction
1 during the time that; at the same time as: Michael runs the island
co-operative whilst Mary runs the pub | the natural resources are used up
whilst the population continues to increase. 2 whereas (indicating a contrast):
some employers have a relaxed dress code, whilst others insist on formal attire.

* Anchored Note, page 7
relationship

Figure 1 misses out on the 1:n (1:1?  m:n?) nature of the relationships.

## Nits

* Highlight, page 3
help to set

(There is a "help distinguish" above -- is it to or not to?)

* Circle, page 4
ta . Th

(Spurious blank space.)

* Circle, page 5
d.

(Missing closing parenthesis.)

* Anchored Note, page 6
which

➔ that

(No comma ➔ I read this as a restricting clause, which is easier to understand
with “that”.)

* Highlight, page 6
consider a loss of light State may cause

Hard to parse.

* Anchored Note, page 7
PAs

s/PAs/As/