Re: [netmod] FW: a question about ietf-hardware yang module

Andy Bierman <andy@yumaworks.com> Tue, 25 June 2019 02:14 UTC

Return-Path: <andy@yumaworks.com>
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 8CA3312022A for <netmod@ietfa.amsl.com>; Mon, 24 Jun 2019 19:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 bX2R1C4Qu86e for <netmod@ietfa.amsl.com>; Mon, 24 Jun 2019 19:14:32 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD9F12001A for <netmod@ietf.org>; Mon, 24 Jun 2019 19:14:31 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id p17so14588950ljg.1 for <netmod@ietf.org>; Mon, 24 Jun 2019 19:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sO6EW4IUyrrDkWP0+gKYMriuz9G643YleYE5ZlH0Jro=; b=l9iBTpr7mfkevrloiuouDVyUyBpWFpd3MbRO1sLzxIQVMjm79PUYY9pwweLgdojjWz 29jJ0/C4E1Dcz4S6IH+vegSKU7Pe1zk/+mGoparvvcu4zsCIawTNa1KQMUQPUtnDUpW5 9x4+cyqoxmReijtaMBEWuwyC9hqaNepoRz6bzC6Dgk2s0eLyOtnsTeF3HQU+YqPjwhBe ovikyt6eA0pQ1PdJj/pjWBikQfz+i4F4ep1UNAoIFusHgcBxMnPx5Gw3yHyGTWZFVQ/9 LusxDSLwmQhSbFzq+7EscNuRChkRctDWk5FwfI8Md1r9bzY7KRcjNHa3XhI0N/3GUNIS hggQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sO6EW4IUyrrDkWP0+gKYMriuz9G643YleYE5ZlH0Jro=; b=U7RRn4XC0Jovv2iTJqBXnon2/4ocXAV9gkvO8fb6ncsnJsPkNvwolVSHVVgoIXAp0B xW6ixv76tiLdXz+U67iLudEkNXvFk1UzLnquW3f63NkSu33vCPJMFh+3qG8dhPWgclDx MWcSeLOLXsxEcOM+LxEGiBSspjfMacNh8xd+1oyqqic2oyaclw4SCtBVgyaUoLGkt+xp D38V8LZxFeRGmU4hFEoyKwlBXKtGVix4e+vsM5A9pbFo/cYvVCgvtHluEXiSnl+iu+ro i9ivwD72nS5cApTiQ2e3xTzMCVtfX5VbXmnUXF5DkYRsxaAjLDKfjpPL7oRMkJ2VfP+0 1yog==
X-Gm-Message-State: APjAAAX39Xt8FI9KJr5EJhdnmz9j5qu4fdBYy6nVRFjmWPUoJ5sEsOQP b9mnN31TBfuo5NeO779nt1tJbyUgk35UiJkqNa9PDQ==
X-Google-Smtp-Source: APXvYqwxHBfjsUFso8kV+dwVM2hVzNSk2Vu9VT58oHcOO2nooPTxdljB6rafZUorhFAt/5vk/phBOTvinpEI2A0nYmo=
X-Received: by 2002:a2e:86cc:: with SMTP id n12mr5191458ljj.146.1561428869784; Mon, 24 Jun 2019 19:14:29 -0700 (PDT)
MIME-Version: 1.0
References: <5756FB984666AD4BB8E1D63E2E3AA3D001ED25CD@dggemm513-mbx.china.huawei.com>
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001ED25CD@dggemm513-mbx.china.huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 24 Jun 2019 19:14:18 -0700
Message-ID: <CABCOCHTZzGycEYDnaWk0aUgGQwnD-joRcGjGoESrg-iCJ_9r0w@mail.gmail.com>
To: "Fengchong (frank)" <frank.fengchong@huawei.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/related; boundary="000000000000208b61058c1c7dec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GVauxG6yZETFTx_T6HLzja5lWeg>
Subject: Re: [netmod] FW: 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: Tue, 25 Jun 2019 02:14:36 -0000

On Mon, Jun 24, 2019 at 6:59 PM Fengchong (frank) <
frank.fengchong@huawei.com> wrote:

> Andy,
>
>     Can you clarify this question?
>
>
>

Since state-last-changed seems to cover state data changing, last-change
seems to apply to
the operational value of the config=true nodes in the /hardware/component
subtree

Andy




> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
> 个人签名:冯冲
> 手 机:13776612983
> 电子邮件:frank.fengchong@huawei.com
> 公司网址:www.huawei.com
> ------------------------------
>
>  本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人:* Fengchong (frank)
> *发送时间:* 2019年6月19日 10:21
> *收件人:* 'netmod@ietf.org' <netmod@ietf.org>rg>; 'andy@yumaworks.com' <
> andy@yumaworks.com>
> *抄送:* yanjin (A) <rose.yan@huawei.com>
> *主题:* a question about ietf-hardware yang module
>
>
>
> 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 {
>
>       description
>
>         "A hardware-state-change notification is generated when the
>
>          value of /hardware/last-change changes in the operational
>
>          state.";
>
>       reference
>
>         "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?
>
>
>