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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Adrian,

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

Aren’t we all…

Loose ends:

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

I didn’t really want to change the terminology, just to point out that it seems a bit unnatural to this reader.
In my mind, changes to the intent that, e.g., ultimately cause an interface to be administratively shut down need to be kept close to the observations on the network, but it may make sense to have terms that clearly distinguish the two.

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

Good.  Maybe I was missing some reinforcement of this because in my personal version of the English language “fault" is indeed a state.

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

Maybe "whilst a Problem remains unresolved it may continue to require attention”?

Thank you for diligently addressing my feedback.

Grüße, Carsten

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux