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

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
stefan@wallan.se
+46705233262

> On 11 Oct 2017, at 18:07, t.petch <ietfc@btconnect.com> wrote:
> 
> ---- Original Message -----
> From: "stefan vallin" <stefan@wallan.se>
> 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
> stefan@wallan.se
> +46705233262
> 
>> On 11 Oct 2017, at 14:19, t.petch <ietfc@btconnect.com> wrote:
>> 
>> ----- Original Message -----
>> From: "Martin Bjorklund" <mbj@tail-f.com>
>> To: <ietfc@btconnect.com>
>> Cc: <ccamp@ietf.org>
>> Sent: Wednesday, October 11, 2017 11:18 AM
>> 
>>> Hi,
>>> 
>>> "t.petch" <ietfc@btconnect.com> 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" <mbj@tail-f.com>
>>>> To: <ccamp@ietf.org>
>>>> 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
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> 
>>>> 
>> 
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 