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

[Adrian Farrel <[e-mail]>]

Hey Carsten,

Well, I'm a little behind with all this, but...

> ## 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.

Gone.

> * 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.

Yeah, the purist in me would like "Network Observation" but the words "observability" seems to have currency.

I changed the first words to be "The Network Observability process is"

> * 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.

Not sure, to be honest.
The definition of network monitoring says to distinguish it from resource or device monitoring.

Any suggestions for wording?

> * 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.

We are being very careful with "familiar usage" because, we find, everyone's familiar usage is different.

Anyway, a fault does not go away or stay. For that to happen it would need to be a state. A fault is an occurrence, that is, an event.

> * Anchored Note, page 7
> requires
>
> ➔ may require
> (except for false alarms)

Ah, the fallacy fallacy :-)
We have "an Alarm signifies an undesirable State"
So, prima facie, 	an alarm requires corrective action.
But, in fact, it’s a bit tighter than that because the definition does not say that an alarm indicates that corrective action is needed, it says that an alarm indicates a state that requires corrective action.
Now, if we are to handle everything as "but it might not really be true" then our world (and definitions) break down!
In this case, a false alarm would be one of:
- here is an alarm reporting a state, but actually, the resource is not in that state
- here is an alarm reporting an undesirable state, but really, the state is not undesirable
- here is an alarm reporting an undesirable state that requires corrective action, but in truth, you don't need to correct it.
In all of those "false alarms" there is actually no alarm, just a bit of bogus information.

> * 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.)

Yes, no reason to capitalise when we don't have a defined term.
Yes, better to stick to "network fault and problem management"

> ## Editorial
>
> * Highlight, page 4
> behavior, and to identify, anomalies
>
> Can't parse.

Thanks. Superfluous comma.

> * Highlight, page 4
> where
>
> This fragment is not really trying to be a sentence with the bullet
> items following it.

Correct. That is not the only use of colons.
But I will change it to "where the following relationships apply."

> * 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 hope it isn't a requirement that we surprise you :-)
In conjunction with the previous note, this is observing that the state that we care about from an operational point of view is resolved, but the problem persists ("we don't know why that happened") and attention may be required.

> 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.

Yeah, I have been told. I will change to "while" which is more sympathetic to the American ear.

> * Anchored Note, page 7
> relationship
>
> Figure 1 misses out on the 1:n (1:1?  m:n?) nature of the relationships.

I'll add a note.

> ## Nits
>
> * Highlight, page 3
> help to set
>
> (There is a "help distinguish" above -- is it to or not to?)

US/UK issue.
Leaving it to the RFC Editor as I react badly to the Germanification of my language via the US.

> * Circle, page 4
> ta . Th
>
> (Spurious blank space.)

Ack

> * Circle, page 5
> d.
>
> (Missing closing parenthesis.)

Ack

> * Anchored Note, page 6
> which
>
> ➔ that
>
> (No comma ➔ I read this as a restricting clause, which is easier to understand
> with “that”.)

Correct.

> * Highlight, page 6
> consider a loss of light State may cause
>
> Hard to parse.

Fixed

> * Anchored Note, page 7
> PAs
>
> s/PAs/As/

Ack

Cheers,
Adrian