Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01

[tom petch <[e-mail]>]

Stefan

I find this I-D (too) hard to understand.  The problem I have is with
terminology which seems elastic.

Thus 'alarm state' is not defined as a term; it is in other alarm work
where the definition would fit with usage such as

   The operator state for an alarm can be: "none", "ack", "shelved", and
   "closed".
or
actual state of the alarms
or
 The alarm list (/alarms/alarm-list) is a function from (resource,
   alarm type, alarm type qualifier) to the current alarm state.

But this meaning makes no sense to me when the term appears in
o  Alarm Instance: The alarm state for a specific resource and alarm
type.
or
 o  Alarm Type: An alarm type identifies a possible unique alarm state
for a resource.

and since I cannot understand what you mean by these two terms, I think
I cannot understand the document.

Another example would be the use of 'event' which appears as

1.  the definition focuses on leaving out events and logging information
in general.

This I-D does not define event; previous IETF work, e.g. RFC3877 does,
and makes it clear that an alarm (class) is a subset of an event which
would make no sense here.

There is a lot of prior art in this field but this I-D seems to go
against it rather than build on it.

Tom Petch

----- Original Message -----
From: "stefan vallin" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, July 22, 2018 7:17 PM