Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36312120128 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTA32ra6hvDN for ; Tue, 18 Jun 2019 19:25:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 ; Tue, 18 Jun 2019 19:25:09 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 62FE1BAB5A9F64CC7B78 for ; Wed, 19 Jun 2019 03:25:07 +0100 (IST) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml704-cah.china.huawei.com (10.201.108.45) 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 ([169.254.1.175]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Wed, 19 Jun 2019 10:20:58 +0800 From: "Fengchong (frank)" To: "netmod@ietf.org" , "andy@yumaworks.com" CC: "yanjin (A)" 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-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2dggemm513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 02:25:12 -0000 --_000_5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2dggemm513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi andy and all, I'm implementing ietf-hardware.yang, and I have a question about /hardwa= re/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 c= hange) of list /hardware/component/ will cause the update of /hardware/last= -change. But in description of notification:hardware-state-change notification hardware-state-change { description "A hardware-state-change notification is generated when the value of /hardware/last-change changes in the operational state."; reference "RFC 6933: Entity MIB (Version= 4) - entConfigChange"; } This notification means if any change occurs in /hardware/last-change, a no= tification 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? --_000_5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2dggemm513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi andy and all,

   I’m implemen= ting ietf-hardware.yang, and I have a question about /hardware/last-change.=

 

 =   module: ietf-hardware

 =     +--rw hardware

 =        +--ro last-change?   yan= g:date-and-time

 =        +--rw component* [name]=

 =           +--rw name =              st= ring

 =           +--rw class = ;            identit= yref

 =           +--ro physical-i= ndex?   int32 {entity-mib}?

 =           +--ro descriptio= n?      string

 =           +--rw parent?&nb= sp;          -> ../../compo= nent/name

 =           +--rw parent-rel= -pos?   int32

 =           +--ro contains-c= hild*   -> ../../component/name

 =           +--ro hardware-r= ev?     string

 =           +--ro firmware-r= ev?     string

 =           +--ro software-r= ev?     string

 =           +--ro serial-num= ?       string

 =           +--ro mfg-name?&= nbsp;        string

 =           +--ro model-name= ?       string

 =           +--rw alias?&nbs= p;           string<= /o:p>

 =           +--rw asset-id?&= nbsp;        string

 =           +--ro is-fru?&nb= sp;          boolean

 =           +--ro mfg-date?&= nbsp;        yang:date-and-time

 &nbs=
p;         +--rw uri* &nbs=
p;            inet:u=
ri
 &nbs=
p;         +--ro uuid? &nb=
sp;           yang:uuid
 &nbs=
p;         +--rw state {hardwar=
e-state}?
 &nbs=
p;         |  +--ro state-=
last-changed?   yang:date-and-time
 &nbs=
p;         |  +--rw admin-=
state?          admin-state
 &nbs=
p;         |  +--ro oper-s=
tate?           oper-stat=
e
 &nbs=
p;         |  +--ro usage-=
state?          usage-state
 &nbs=
p;         |  +--ro alarm-=
state?          alarm-state
 &nbs=
p;         |  +--ro standb=
y-state?        standby-state=

 &nbs=
p;         +--ro sensor-data {h=
ardware-sensor}?
 &nbs=
p;            +-=
-ro value?           =
;    sensor-value
 &nbs=
p;            +-=
-ro value-type?          senso=
r-value-type
 &nbs=
p;            +-=
-ro value-scale?         sensor-val=
ue-scale
 &nbs=
p;            +-=
-ro value-precision?     sensor-value-precision
 &nbs=
p;            +-=
-ro oper-status?         sensor-sta=
tus
 &nbs=
p;            +-=
-ro units-display?       string
 &nbs=
p;            +-=
-ro value-timestamp?     yang:date-and-time<=
/span>
 &nbs=
p;            +-=
-ro value-update-rate?   uint32

 

Last-cha=
nge’s description: "The time the '/hardware/component' list changed in=
 the
 &n=
bsp;         operational state.&quo=
t;;

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

 

But in d=
escription of  notification:hardware-state-change
 &n=
bsp;  notification hardware-state-change {
 &n=
bsp;    description
 &n=
bsp;      "A hardware-state-change notificati=
on is generated when the
 &n=
bsp;       value of /hardware/last-change cha=
nges in the operational
 &n=
bsp;       state.";

 &n=
bsp;    reference


 &n=
bsp;      "RFC 6933: Entity MIB=
 (Version 4) - entConfigChange";


 &n=
bsp;  }


&nb=
sp;


This not=
ification means if any change occurs in /hardware/last-change, a notificati=
on will be reported.


This not=
ification also refers to Entity MIB’s entConfigChange.


&nb=
sp;


My quest=
ion is whether only configuration change of hardware component will cause t=
he update of /hardware/last-change? 


 
--_000_5756FB984666AD4BB8E1D63E2E3AA3D001ED0EA2dggemm513mbxchi_--