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

From: "Fengchong (frank)" <[email-masked]>
Date: Tue, 25 Jun 2019 01:59:18 +0000

Andy,
    Can you clarify this question?

________________________________
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：[email-masked]
公司网址：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
收件人: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
抄送: yanjin (A) <[email-masked]>
主题: 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?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 24 Jun 2019 19:14:18 -0700

>     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

> ------------------------------
>
> ------------------------------
>
> *发件人:* Fengchong (frank)
> *发送时间:* 2019年6月19日 10:21
> *收件人:* [email-masked]' <[email-masked]>; [email-masked]' <
> [email-masked]>
> *抄送:* yanjin (A) <[email-masked]>
> *主题:* a question about ietf-hardware yang module
>
>
>
> Hi andy and all,
>
> It seems this description means any change (configuration change or state
> change) of list /hardware/component/ will cause the update of
> /hardware/last-change.
>
>
>
>         "RFC 6933 <https://tools.ietf.org/html/rfc6933>: Entity MIB (Version 4) - entConfigChange";
>
>     }
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jun 2019 07:51:23 +0200

> the operational value of the config=true nodes in the /hardware/component

It could be that the intention was that ietf-hardware:last-change
matches ENTITY-MIB:entLastChangeTime, which has this description (see
RFC 6933):

            "The value of sysUpTime at the time a conceptual row is
            created, modified, or deleted in any of these tables:
                    - entPhysicalTable
                    - entLogicalTable
                    - entLPMappingTable
                    - entAliasMappingTable
                    - entPhysicalContainsTable
            "

If so, ietf-hardware:last-change should change whenever the an element
in the hardware/component list changes, e.g., pluggable hardware is
added or removed.

If this interpretation is correct, then an entry in the table "YANG
Data Nodes and Related ENTITY-MIB Objects" is missing. Anyway, the
description of ietf-hardware:last-change is obviously not precise
enough and this thread should perhaps lead to an errata if we find
agreement what the intention here was.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2019 09:13:51 +0200 (CEST)

Hi,

I don't understand what is unclear about the current descriptions.  Is
it the relations to the MIB objects that are unclear or is it the
descriptions in the YANG module?  The original question was:

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

The answer is clearly "no", since /hardware/last-change says:

        "The time the '/hardware/component' list changed in the
         operational state.";

and this list has e.g.:

           When the server detects a new hardware component, it
           initializes a list entry in the operational state.

So it is clear that if a hardware component is added (not a
configuration change) this list is changed, and last-change is
updated.

/martin

Juergen Schoenwaelder <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jun 2019 09:39:51 +0200

> configuration change) this list is changed, and last-change is

I think the ambiguity is 'list changed' - does this mean that list
entries are added/removed or does it include also the case where a
property of a list entry has changed. The relationship to
entLastChangeTime is also not clear to me.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2019 09:56:09 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> property of a list entry has changed.

Ok.  Yes it is supposed to mean entry added/removed/modified.

But I can see another unclear thing - suppose I augment in an
addtional leaf from my own model into this list.  Should last-change
be updated if this new leaf is changed?

> The relationship to

Perhaps that's why it isn't listed in the table ;-)

/martin

---

From: "Fengchong (frank)" <[email-masked]>
Date: Thu, 27 Jun 2019 02:13:03 +0000

Hi all,
    Can we reach a final conclusion about this question?
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2019年6月25日 15:56
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [netmod] FW: a question about ietf-hardware yang module

Juergen Schoenwaelder <[email-masked]> wrote:
> > I don't understand what is unclear about the current descriptions.  
> > Is it the relations to the MIB objects that are unclear or is it the 

But I can see another unclear thing - suppose I augment in an addtional leaf from my own model into this list.  Should last-change be updated if this new leaf is changed?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jun 2019 07:40:59 +0200

> But I can see another unclear thing - suppose I augment in an addtional leaf from my own model into this list.  Should last-change be updated if this new leaf is changed?

A reasonable interpretation in my view is that hardware/last-change is
updated whenever

(1) a hardware component has been added
(2) a hardware component has been removed
(3) a hardware component has been replaced by a different hardware component

Here is an attempt for a new description:

         "The last time a new hardware component has been to the
          '/hardware/component' list, or a hardware component has
 	  been removed from the '/hardware/component' list, or a
          hardware component in the '/hardware/component' list has
          been replaced by a different hardware component."

The point is to define this based on the events that cause the set of
components to change instead of discussing leaf value changes.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Jun 2019 16:59:08 +0200 (CEST)

>          "The last time a new hardware component has been to the
                                                           ^^^^^
added

> components to change instead of discussing leaf value changes.

Sounds reasonable.  But what exactly does "replaced by a different
component" mean?  Presumably it has the same name, but something else
is different.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jun 2019 20:01:57 +0200

> component" mean?  Presumably it has the same name, but something else

Yes, good point, I think the phrase "by a different hardware
component" should be removed. It seems last-change should change when
I unplug a component and I plug it back shortly after, i.e., a
component is replaced by itself. So we have:

        "The last time a new hardware component has been added to the
         '/hardware/component' list, or a hardware component has been
         removed from the '/hardware/component' list, or a hardware
         component in the '/hardware/component' list has been
         replaced."

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Jun 2019 21:52:56 +0200 (CEST)

>          component in the '/hardware/component' list has been

I think that this is still not clear what it means that a component
has been replaced.  Do you mean "replaced by a different hardware
component"?

Otherwise (unplug then plug in the same component), the system either
detects the removal and thus updates last-change, or it doesn't detect
the quick removal/insertion, and then it can't do anything.  Thus, I
don't think this case needs special treatment, and the text could be
just:

         "The last time a new hardware component has been added to the
          '/hardware/component' list, or a hardware component has been
          removed from the '/hardware/component' list."

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jun 2019 22:01:18 +0200

>           removed from the '/hardware/component' list."

The question is whether every implementor will figure out that if the
component found in some slot x-y-z is different from what is expected
to be in slot x-y-z, this must be seen as a remove + add combination.
If we include 'replace', then it may be clearer that even in the case
where what is in slot x-y-z has changed, the last-change must be
updated. (That is, the list element with the same name still exists
but it is different from what was there before with the same name.)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Jun 2019 22:04:50 +0200 (CEST)

> but it is different from what was there before with the same name.)

But then we're back to where we started - what exactly does "different
from what was there before" mean?  Presumably that some leaf's value
is different...?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jun 2019 22:13:28 +0200

> from what was there before" mean?  Presumably that some leaf's value

Go back some emails, I have removed the 'different' phrase.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Jun 2019 09:52:20 +0200 (CEST)

> Go back some emails, I have removed the 'different' phrase.

Perhaps we can say:

       [...] or a hardware
       component in the '/hardware/component' list has been
       replaced with a new hardware component with the same
       name.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jun 2019 10:07:13 +0200

>        replaced with a new hardware component with the same

Do we want last-change to be updated when a component gets unplugged
and put back, i.e., a component got replaced with itself?

Can last-change be used to detect that something messed around with
the components (or a component is connected via a bad line)? Or is
last-change more strictly for the set of components has changed?

If I remove a component and I put it back slowly enough, I might get
two last-change updates (the removal and the addition). If a client
polls even more slowly, it will see that last-change has changed but
it will find the same components. Hence, it seems reasonable to not
exclude a replacement or a component with itself since it is a matter
of the time resolution with which changes are detected and reported
via the operational datastore.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Jun 2019 10:14:28 +0200 (CEST)

> via the operational datastore.

Agreed.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jun 2019 10:16:21 +0200

> > via the operational datastore.

So remove the work "new".

/js