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

"BRUNGARD, DEBORAH A" <> Fri, 10 August 2018 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 379F2130F82 for <>; Fri, 10 Aug 2018 12:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 820WAmJLlnww for <>; Fri, 10 Aug 2018 12:18:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B91A2130F81 for <>; Fri, 10 Aug 2018 12:18:07 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w7AJ6L0R035777; Fri, 10 Aug 2018 15:18:01 -0400
Received: from ( []) by with ESMTP id 2ksg379b97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Aug 2018 15:18:01 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id w7AJHxAe000937; Fri, 10 Aug 2018 15:18:00 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w7AJHoVm000661; Fri, 10 Aug 2018 15:17:51 -0400
Received: from ( []) by (Service) with ESMTP id E5DEE4048B4D; Fri, 10 Aug 2018 19:17:50 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id CFCD44048B59; Fri, 10 Aug 2018 19:17:50 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0408.000; Fri, 10 Aug 2018 15:17:50 -0400
To: tom petch <>, stefan vallin <>
CC: "" <>
Thread-Topic: [CCAMP] review of draft-ietf-ccamp-alarm-module-01
Thread-Index: AQHUMKC9sMM0l+INs0eaTNYFL4owK6S5TAvg
Date: Fri, 10 Aug 2018 19:17:49 +0000
Message-ID: <>
References: <> <> <04c501d430a0$3c5cc3c0$>
In-Reply-To: <04c501d430a0$3c5cc3c0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-10_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808100205
Archived-At: <>
Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Aug 2018 19:18:10 -0000

Stefan, Authors,

I've been reviewing the SG15 liaison and your draft, as we'll need to respond in about a month to SG15. Similar to Tom, SG15 is confused on terms of reference/prior standards relationship. While the abstract says "carefully maps to relevant alarm standards", there's no direct references. In the document, it also has a sentence "based on experience from using and implementing available alarm standards". So it is not clear if this work is based on standards or "experience implementing".

During the microwave yang review, a similar concern was raised, and it was decided to clearly identify which standard is being referenced. Recommend the same should be done here. It's ok you have included "vendor implementations of alarm standards". But you need to clearly identify.

There's a sentence in the abstract of draft-ietf-netmod-intf-ext-yang which may help here:
"These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard."
" Several of the augmentations defined here are not backed by any formal standard specification.  Instead, they are for features that are commonly implemented in equivalent ways by multiple independent network equipment vendors.  The aim of this draft is to define common paths and leaves for the configuration of these equivalent features in a uniform way, making it easier for users of the YANG model to access these features in a vendor independent way.  Where necessary, a description of the expected behavior is also provided with the aim of ensuring vendors implementations are consistent with the specified behaviour."

Similar to the intf-ext, it will be important to allow implementors the flexibility to choose which specific parts of the model they support, and to allow in the future supporting other standards (G.7710). It would help to include a few sentences in the draft on how this can be done.

Once we have a cleaner document, I'm recommending to liaison with the SDOs which you reference, ITU-T, 3GPP (and BBF in response to their earlier liaison). Hopefully with these clarifications, it will be an easier read by these other groups.

Thanks Tom and Qin for reviewing -

Thanks Authors for continuing the dialogue- as with any solution document, the solution stabilizes, then need to clean up the description text😊  

(AD hat on)

-----Original Message-----
From: CCAMP <> On Behalf Of tom petch
Sent: Friday, August 10, 2018 7:53 AM
To: stefan vallin <>
Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01


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
actual state of the alarms
 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.
 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" <>
To: "Qin Wu" <>
Cc: <>
Sent: Sunday, July 22, 2018 7:17 PM

CCAMP mailing list