[netmod] a question about ietf-hardware yang module

"Fengchong (frank)" <frank.fengchong@huawei.com> Wed, 19 June 2019 02:25 UTC

Return-Path: <frank.fengchong@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 36312120128 for <netmod@ietfa.amsl.com>; Tue, 18 Jun 2019 19:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CTA32ra6hvDN for <netmod@ietfa.amsl.com>; Tue, 18 Jun 2019 19:25:10 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5D112002F for <netmod@ietf.org>; Tue, 18 Jun 2019 19:25:09 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 62FE1BAB5A9F64CC7B78 for <netmod@ietf.org>; Wed, 19 Jun 2019 03:25:07 +0100 (IST)
Received: from DGGEMM403-HUB.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Jun 2019 03:25:07 +0100
Received: from DGGEMM513-MBX.china.huawei.com ([]) by DGGEMM403-HUB.china.huawei.com ([]) with mapi id 14.03.0439.000; Wed, 19 Jun 2019 10:20:58 +0800
From: "Fengchong (frank)" <frank.fengchong@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>, "andy@yumaworks.com" <andy@yumaworks.com>
CC: "yanjin (A)" <rose.yan@huawei.com>
Thread-Topic: a question about ietf-hardware yang module
Thread-Index: AdUmQwglxAO+8aYzRlOfdHT4SvZXAg==
Date: Wed, 19 Jun 2019 02:20:57 +0000
Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2@dggemm513-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2dggemm513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xRxCqFoxsxXm2J3bAafDgCkoI1E>
Subject: [netmod] a question about ietf-hardware yang module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 02:25:12 -0000

Hi andy and all,
   I'm implementing ietf-hardware.yang, and I have a question about /hardware/last-change.

   module: ietf-hardware
     +--rw hardware
        +--ro last-change?   yang:date-and-time
        +--rw component* [name]
           +--rw name              string
           +--rw class             identityref
           +--ro physical-index?   int32 {entity-mib}?
           +--ro description?      string
           +--rw parent?           -> ../../component/name
           +--rw parent-rel-pos?   int32
           +--ro contains-child*   -> ../../component/name
           +--ro hardware-rev?     string
           +--ro firmware-rev?     string
           +--ro software-rev?     string
           +--ro serial-num?       string
           +--ro mfg-name?         string
           +--ro model-name?       string
           +--rw alias?            string
           +--rw asset-id?         string
           +--ro is-fru?           boolean
           +--ro mfg-date?         yang:date-and-time

           +--rw uri*              inet:uri

           +--ro uuid?             yang:uuid

           +--rw state {hardware-state}?

           |  +--ro state-last-changed?   yang:date-and-time

           |  +--rw admin-state?          admin-state

           |  +--ro oper-state?           oper-state

           |  +--ro usage-state?          usage-state

           |  +--ro alarm-state?          alarm-state

           |  +--ro standby-state?        standby-state

           +--ro sensor-data {hardware-sensor}?

              +--ro value?               sensor-value

              +--ro value-type?          sensor-value-type

              +--ro value-scale?         sensor-value-scale

              +--ro value-precision?     sensor-value-precision

              +--ro oper-status?         sensor-status

              +--ro units-display?       string

              +--ro value-timestamp?     yang:date-and-time

              +--ro value-update-rate?   uint32

Last-change's description: "The time the '/hardware/component' list changed in the

           operational state.";
It seems this description means any change (configuration change or state change) of list /hardware/component/ will cause the update of /hardware/last-change.

But in description of  notification:hardware-state-change

    notification hardware-state-change {


        "A hardware-state-change notification is generated when the

         value of /hardware/last-change changes in the operational



        "RFC 6933<https://tools.ietf.org/html/rfc6933>: Entity MIB (Version 4) - entConfigChange";


This notification means if any change occurs in /hardware/last-change, a notification will be reported.

This notification also refers to Entity MIB's entConfigChange.

My question is whether only configuration change of hardware component will cause the update of /hardware/last-change?