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

[stefan vallin <[e-mail]>]

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
[e-mail]
[phone]

> On 12 Oct 2017, at 18:24, t.petch <[e-mail]> wrote:
> 
> 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" <[e-mail]>
> 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
> [e-mail]
> [phone]
> 
>> On 11 Oct 2017, at 18:07, t.petch <[e-mail]> wrote:
>> 
>> ---- Original Message -----
>> From: "stefan vallin" <[e-mail]>
>> 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.
>> 
>> 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
>> [e-mail]
>> [phone]
>> 
>>> On 11 Oct 2017, at 14:19, t.petch <[e-mail]> wrote:
>>> 
>>> ----- Original Message -----
>>> From: "Martin Bjorklund" <[e-mail]>
>>> To: <[e-mail]>
>>> Cc: <[e-mail]>
>>> Sent: Wednesday, October 11, 2017 11:18 AM
>>> 
>>>> Hi,
>>>> 
>>>> "t.petch" <[e-mail]> wrote:
>>>>> Martin
>>>>> 
>>>>> When first I read this, in its netmod designation, I scribbled in
>>> the
>>>>> margin
>>>>> ** 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)?
>>>> 
>>>>> ** 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
>>>> 
>>>> 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.
>>> 
>>> 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
>>> 
>>>> /martin
>>>> 
>>>>> , perhaps better
>>>>> than the authors of this I-D.
>>>> 
>>>> 
>>>>> 
>>>>> Tom Petch
>>>>> 
>>>>> ----- Original Message -----
>>>>> From: "Martin Bjorklund" <[e-mail]>
>>>>> To: <[e-mail]>
>>>>> Sent: Wednesday, October 11, 2017 8:13 AM
>>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --------------------------------------------------------------------
> -
>> -
>>> --
>>>>> --------
>>>>> 
>>>>> 
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>> 
>>>>> 
>>> 
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>> 
>> 
> 
>