Subject: [CCAMP] Fw: New Version Notification for draft-vallin-ccamp-alarm-module-00.txt

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Oct 2017 09:13:45 +0200 (CEST)

Hi,

We have submitted draft-vallin-ccamp-alarm-module-00.  The technical
content is the same as in draft-vallin-netmod-alarm-module-02, which
we posted to the CCAMP mailing list some time ago for feedback.

This draft is about generic alarm management.  We kindly ask the CCAMP
WG to review this document and provide feedback.  We especially
welcome feedback from people who are also involved in similar work in
the ITU.

/martin & stefan

Subject: New Version Notification for draft-vallin-ccamp-alarm-module-00.txt
From: [email-masked]
To: "Martin Bjorklund" <[email-masked]>, "Stefan Vallin" <[email-masked]>
Date: Wed, 11 Oct 2017 00:06:44 -0700

A new version of I-D, draft-vallin-ccamp-alarm-module-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:		draft-vallin-ccamp-alarm-module
Revision:	00
Title:		YANG Alarm Module
Document date:	2017-10-11
Group:		Individual Submission
Pages:		59
URL:            https://www.ietf.org/internet-drafts/draft-vallin-ccamp-alarm-module-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vallin-ccamp-alarm-module/
Htmlized:       https://tools.ietf.org/html/draft-vallin-ccamp-alarm-module-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vallin-ccamp-alarm-module-00

Abstract:
   This document defines a YANG module for alarm management.  It
   includes functions for alarm list management, alarm shelving and
   notifications to inform management systems.  There are also RPCs to
   manage the operator state of an alarm and administrative alarm
   procedures.  The module carefully maps to relevant alarm standards.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "t.petch" <[email-masked]>
Date: Wed, 11 Oct 2017 10:29:34 +0100

Martin

When first I read this, in its netmod designation, I scribbled in the
margin
** immenseley complicated
** 20 pages of motherhood
:-(

It is unlike any other YANG module I-D that I have read.  Most such I-D
are woefully weak on background information, leaving the reader in the
dark as to the what and why of the YANG module.

This goes off the scale in the opposite direction (IMHO).

If you want to write an essay on Alarms, adding to the mountains that
ITU-T have already produced, not to mention some smaller items of the
IETF, then that should be a separate I-D, which the YANG module I-D, or
any other I-D, can reference.

As it is, I think that those 20 pages may alienate those whom you might
like to review this, since they will know it already, perhaps better
than the authors of this I-D.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 11, 2017 8:13 AM
Subject: [CCAMP] Fw: New Version Notification for
draft-vallin-ccamp-alarm-module-00.txt

> welcome feedback from people who are also involved in similar work in

------------------------------------------------------------------------
--------

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Oct 2017 12:18:23 +0200 (CEST)

Hi,

> ** immenseley complicated

Can you be more specific; is this to be interpreted in the light of
your next comment (i.e., related to the text), or are you thinking
about the data model's structure (or something else)?

> like to review this, since they will know it already

Ok.  If the background material is not needed, we can remove it (or
move to an Appendix or possibly another document, as you suggest).

I assume you are referring to sections 3 and 4, and large parts of the
text in section 5?  Some of the text in section 5 would still be
needed, but it can certainly be rewritten so that it is shorter.

/martin

> , perhaps better

---

From: "t.petch" <[email-masked]>
Date: Wed, 11 Oct 2017 13:19:08 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 11, 2017 11:18 AM

> needed, but it can certainly be rewritten so that it is shorter.

Yes, that is what I have in mind, but I will be interested to see what
others think; they may welcome it:-).

By complicated I mean all the different aspects of Alarms.  I tend to
see the IETF as starting simple and adding complications as and when
they are needed e.g. with Netconf or YANG.  ITU-T, 3GPP and such like I
tend to see as putting everything in up front, some of which may never
get used, and I see this I-D as being more in that vein i.e.
complicated, at least as a starting point..

Likewise, the IETF has a process whereby things that are not
sufficiently widely implemented get excised from a Full Standard, a
philosophy I like, but tend not to see in other SDO.

Tom Petch

---

From: stefan vallin <[email-masked]>
Date: Wed, 11 Oct 2017 15:04:37 +0200

Hi!
Can you elaborate on what you mean with *complicated*, what is complicated in your mind?
The module provides alarm notifications and an alarm list
It also has an alarm inventory, which alarms do a system have?
Important to publish this over NETCONF/YANG rather than in a document in the side.
This is pretty basic things required for an alarm interface.

Then there are optional things like alarm shelving (filtering).

Nothing magic...

Excuse me for the initial text ;)
The problem in the alarm area is information quality versus noise.
Just putting a YANG model on noise does not help
The initial pages puts information quality *requirements* on the alarms, it is not a TM Forum book ;)

Stefan Vallin
[email-masked]
+46705233262

> On 11 Oct 2017, at 14:19, t.petch <[email-masked]> wrote:
>

---

From: "t.petch" <[email-masked]>
Date: Wed, 11 Oct 2017 17:07:33 +0100

---- Original Message -----
From: "stefan vallin" <[email-masked]>
Sent: Wednesday, October 11, 2017 2:04 PM

Hi!
Can you elaborate on what you mean with *complicated*, what is
complicated in your mind?

<tp>

Stefan

'Complicated' was my first impression on reading the original I-D (you
should not read too much into that word).  Many YANG modules are
reworking of
MIB modules and, since I was involved with the Alarm MIB (RFC3877), I
have that as my reference point for this work; the YANG module seems
more complex to me.  I was expecting something familiar looking and did
not get it; so my impression was 'complicated'.

And, as I said to Martin, IETF solutions often start simple and grow.
With the Alarm MIB module, I perceived it as being made more complex by
the influence of M.3100, X.733, X.736 (I do, in general, see the ITU-T
as producing more complex work than the IETF, for better or worse).

The initial text is fine text, I would not want you to think I am
suggesting otherwise, but having been through all the ITU-T
Recomendations in this area in the past, and seeing how little (too
little:-) prefatory text there is in most YANG I-Ds, I was querying its
place here, as opposed in a separate I-D.  Sometimes IETF work starts
with an RFC for the problem statement, separate from the RFC that is the
solution, and that could be an option here.

Tom Petch

The module provides alarm notifications and an alarm list
It also has an alarm inventory, which alarms do a system have?
Important to publish this over NETCONF/YANG rather than in a document in
the side.
This is pretty basic things required for an alarm interface.

Nothing magic...

Excuse me for the initial text ;)
The problem in the alarm area is information quality versus noise.
Just putting a YANG model on noise does not help
The initial pages puts information quality *requirements* on the alarms,
it is not a TM Forum book ;)

Stefan Vallin
[email-masked]
+46705233262

>> ---------------------------------------------------------------------
-
> --

---

From: NICK HANCOCK <[email-masked]>
Date: Wed, 11 Oct 2017 16:42:24 +0000

Dear All, 

We have been following the progress of the Internet-draft 'draft-vallin-netmod-alarm-module' with great interest and believe that the fundamental concepts behind this data model and its objectives are important for the industry and ADTRAN intends to implement support for the YANG Alarm Module within its equipment once the draft is published as an RFC. 

Therefore, we welcome the latest development to progress this draft to an RFC as the lack of a standardized YANG data model for the management of alarms may result in vendors and operators not waiting for the draft to progress to an RFC and begin implementing their own proprietary solutions in the short term. The longer this situation remains, the more difficult it would be to achieve convergence across the industry. 

In the meantime, we will begin providing our feedback on the content of the draft.

Regards, 
Nick Hancock & Joey Boyd

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, October 11, 2017 9:14 AM
To: [email-masked]
Subject: [CCAMP] Fw: New Version Notification for draft-vallin-ccamp-alarm-module-00.txt

Hi,

We have submitted draft-vallin-ccamp-alarm-module-00.  The technical content is the same as in draft-vallin-netmod-alarm-module-02, which we posted to the CCAMP mailing list some time ago for feedback.

This draft is about generic alarm management.  We kindly ask the CCAMP WG to review this document and provide feedback.  We especially welcome feedback from people who are also involved in similar work in the ITU.

/martin & stefan

---

From: stefan vallin <[email-masked]>
Date: Wed, 11 Oct 2017 22:00:38 +0200

Hi Tom!
Thanks for your comments. Forgot to comment on your RFC 3877 MIB module reference
I was very active in that discussion as well.

The 3877 module is complex in that it is a mapping mechanism to map existing notifications and states into alarms.
The reason being that there was MIB modules out there where alarm states are “hidden” in existing SNMP notifications and objects.
So, (I don’t like the word), it is kind of a meta-module. That makes 3877 complex.
But it had to be that way, since it “came too late”. There was very little chance to introduce new notifications and objects for alarms.
ifDown and ifOperState already existed ;)

In contrast our proposal is a “concrete” alarm module, directly modelling notifications and alarm states rather than mapping other existing notifications and states into alarms. This is feasible since we are in the early days of YANG module authoring, we can have devices support an alarm YANG.

Using RFC 3877 as a manager is complex, you have to interpret the mapping. You do not get direct alarm information from it.
This in contrast to our proposed alarm YANG, it provides alarm information directly.

Hope you see what I am trying to say here. Big difference in the approaches and this is why it is so early to get a YANG Alarm Module out there fast.
So our alarm YANG is simple :)

Stefan Vallin
[email-masked]
+46705233262

> On 11 Oct 2017, at 18:07, t.petch <[email-masked]> wrote:
>

---

From: "t.petch" <[email-masked]>
Date: Thu, 12 Oct 2017 17:24:16 +0100

Stefan

On a more objective(?) note, with there being extensive references from
the
YANG modules to X.733 and X.736, I think that both those documents have
to be Normative References, not Informative.

Tom Petch

----- Original Message -----
From: "stefan vallin" <[email-masked]>
Sent: Wednesday, October 11, 2017 9:00 PM

Hi Tom!
Thanks for your comments. Forgot to comment on your RFC 3877 MIB module
reference
I was very active in that discussion as well.

The 3877 module is complex in that it is a mapping mechanism to map
existing notifications and states into alarms.
The reason being that there was MIB modules out there where alarm states
are “hidden” in existing SNMP notifications and objects.
So, (I don’t like the word), it is kind of a meta-module. That makes
3877 complex.
But it had to be that way, since it “came too late”. There was very
little chance to introduce new notifications and objects for alarms.
ifDown and ifOperState already existed ;)

In contrast our proposal is a “concrete” alarm module, directly
modelling notifications and alarm states rather than mapping other
existing notifications and states into alarms. This is feasible since we
are in the early days of YANG module authoring, we can have devices
support an alarm YANG.

Using RFC 3877 as a manager is complex, you have to interpret the
mapping. You do not get direct alarm information from it.
This in contrast to our proposed alarm YANG, it provides alarm
information directly.

Hope you see what I am trying to say here. Big difference in the
approaches and this is why it is so early to get a YANG Alarm Module out
there fast.
So our alarm YANG is simple :)

Stefan Vallin
[email-masked]
+46705233262

>>>> IETF, then that should be a separate I-D, which the YANG module
I-D,
>> or

---

From: stefan vallin <[email-masked]>
Date: Fri, 13 Oct 2017 08:53:31 +0200

HI Tom!
I would rather not have X.733 as normative, it is background information for the alarm-module

“Extensive references”:
it is referenced in five places in the alarm module:

1) the module description: (one of the *input* docs)
 description
    "This module defines an interface for managing alarms.  Main
     inputs to the module design are the 3GPP Alarm IRP, ITU-T X.733
     and ANSI/ISA-18.2 alarm standards.

2) the severity typedef
      reference
        "ITU Recommendation X.733: Information Technology

3) leaf perceived-severity
      reference
        "ITU Recommendation X.733: Information Technology

4) leaf alarm-text
      reference
        "ITU Recommendation X.733: Information Technology

5) identity alarm-identity
      "Base identity for alarm types.  A unique identification of the
       alarm, not including the resource.  Different resources can
       share alarm types.  If the resource reports the same alarm
       type, it is to be considered to be the same alarm.  The alarm
       type is a simplification of the different X.733 and 3GPP alarm
       IRP alarm correlation mechanisms and it allows for
       hierarchical extensions.

Maybe we should remove the ref to X.733 for alarm-text, not relevant?
Just information for people that are looking for the additional-text field.

And X733 is mentioned in 5) to say that we are *different" from X.733.

The alarm-module differs from X.733 in several ways:
- X.733 is notification focused, the ietf-alarm-module focuses on alarms as states with notifications as a “side-effect”.
This has a major impact.
- our alarm list presents stateful alarms, not a list of notifications

- Separation of alarm severity versus clearance state

- Goodbye to the global flat name-space enum for probable-cause

- Simplified mechanism for matching which notifications/state-changes should be matched to the same alarm

Then, we have a *separate* *optional* module ietf-alarms-x733.yang.
This can be used if you want to make integration towards an X.733 based alarm manager, NETCONF client easier.
I would like to hear from others on this thread how relevant this still is. 
Alarm managers in the telecom area have been X.733 focused but that is fading.
The module augments the alarm-module with parameters like probable-cause.
But I am considering that we should remove this module (maybe put it in separate draft)
- It seems to be magnetic, draws peoples attention from the core alarm-module
- Not sure how relevant it is these days to be strictly X733 compliant, 
- Would make the RFC shorter

Also see my previous email to CCAMP where I summarised two responses in NETMOD regarding ITU-T and the sharma draft.

br Stefan

Stefan Vallin
[email-masked]
+46705233262

> On 12 Oct 2017, at 18:24, t.petch <[email-masked]> wrote:
> 
> Stefan
>

---

From: "t.petch" <[email-masked]>
Date: Sat, 14 Oct 2017 12:52:35 +0100

----- Original Message -----
From: "stefan vallin" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 13, 2017 7:53 AM

HI Tom!
I would rather not have X.733 as normative, it is background information
for the alarm-module

“Extensive references”:

<tp.

stefan

when I search, I find 45 references, not five, in the I-D as a whole,
which is what counts.  In particular, as you identify, the I-D says

"Main

"

Taken together, X.733 should be Normative IMO.

Tom Petch

2) the severity typedef
      reference

4) leaf alarm-text
      reference

Maybe we should remove the ref to X.733 for alarm-text, not relevant?
Just information for people that are looking for the additional-text
field.

The alarm-module differs from X.733 in several ways:
- X.733 is notification focused, the ietf-alarm-module focuses on alarms
as states with notifications as a “side-effect”.
This has a major impact.
- our alarm list presents stateful alarms, not a list of notifications

- Simplified mechanism for matching which notifications/state-changes
should be matched to the same alarm

Then, we have a *separate* *optional* module ietf-alarms-x733.yang.
This can be used if you want to make integration towards an X.733 based
alarm manager, NETCONF client easier.
I would like to hear from others on this thread how relevant this still
is.
Alarm managers in the telecom area have been X.733 focused but that is
fading.
The module augments the alarm-module with parameters like
probable-cause.
But I am considering that we should remove this module (maybe put it in
separate draft)
- It seems to be magnetic, draws peoples attention from the core
alarm-module
- Not sure how relevant it is these days to be strictly X733 compliant,
- Would make the RFC shorter

Also see my previous email to CCAMP where I summarised two responses in
NETMOD regarding ITU-T and the sharma draft.

br Stefan

Stefan Vallin
[email-masked]
+46705233262

>>>>> It is unlike any other YANG module I-D that I have read.  Most
such
>>> I-D
>>> they are needed e.g. with Netconf or YANG.  ITU-T, 3GPP and such
like
>> I
>>>>>> welcome feedback from people who are also involved in similar
work
>>> in
>>>>>> the ITU.
>>>>>>
>>>>>>
>>>>>> /martin & stefan
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
-