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

["t.petch" <[e-mail]>]

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