Subject: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

From: [email-masked]
Date: Mon, 23 Jan 2017 01:04:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : A YANG Data Model for Hardware Management
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Jie Dong
                          Dan Romascanu
	Filename        : draft-ietf-netmod-entity-02.txt
	Pages           : 40
	Date            : 2017-01-23

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 10:08:26 +0100 (CET)

Hi,

The main changes in this version of the hardware model is that
pre-provisioning is supported according to the ML discussion.  Also,
the leaf-list "contained-in" is changed to a leaf "parent", in order
to match "parent-rel-pos".

With this version, the authors believe that all known issues are
resolved, and that the document is ready for WGLC.

/martin

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 10:42:34 +0100

Hi,

I wonder when we use 'state' and when 'status' - is there a subtle
distinction or should be just consistently use lets say 'state', i.e.,
changed to alalarm-status to alarm-state and standby-status to
standby-state?

I also wonder about the mapping of the MIB object names to YANG leaf
names:

   +-------------------------------------+-----------------------------+
   | YANG data node in /hardware-        | ENTITY-SENSOR-MIB object    |
   | state/component/sensor-data         |                             |
   +-------------------------------------+-----------------------------+
   | data-type                           | entPhySensorType            |
   | data-scale                          | entPhySensorScale           |
   | precision                           | entPhySensorPrecision       |
   | value                               | entPhySensorValue           |
   | oper-status                         | entPhySensorOperStatus      |
   | sensor-units-display                | entPhySensorUnitsDisplay    |
   | value-timestamp                     | entPhySensorValueTimeStamp  |
   | value-update-rate                   | entPhySensorValueUpdateRate |
   +-------------------------------------+-----------------------------+

Is the 'data-' prefix needed? If so, why is the a prefix not used for
'precision' (scale and precision really go hand in hand). Why is it
'sensor-units-display' and not just 'units-display'? One option could
be:

  value-type
  value-scale
  value-precision
  value
  oper-status
  units-display
  value-timestamp
  value-update-rate

RFC 3433 points out that entPhySensorType and entPhySensorScale and
entPhySensorPrecision SHOULD NOT change during operation. What about
the YANG objects? I actually do not know what the SHOULD buys a client
since you can't rely on it. To be robust, you have to fetch an n-tuple
anyway and be prepared that a sensor may have changed its properties.
Should there be explicit text providing guidance that it is better to
fetch the whole n-tuple? Or alternatively, if supporting caching of
values is a goal, we may need to provide a
'sensor-data/properties-last-changed' object that allows to make
caching of value properties robust.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Jan 2017 11:58:41 +0100 (CET)

> changed to alalarm-status to alarm-state and standby-status to

The reason in this case is that we just used the MIB names.  This
said, I agree that "standby-state" and "alarm-state" are better.

BTW, RFC 4268, which defines the original objects, says:

   The terms "state" and "status" are used interchangeably in this memo.

> 'precision' (scale and precision really go hand in hand).

Unclear.  I think I'm the one to blame for this inconsistency, and it
goes back to the very first commit, but I can't remeber why.

> Why is it

Yes this is better.

> fetch the whole n-tuple?

This is certainly the simplest solution.   Any comments?

> Or alternatively, if supporting caching of

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 24 Jan 2017 09:14:55 +0000

Hi,

If I'm not mistaken, the following BBF addition was also proposed as to be
added to the IETF entity model.  Is there no consensus about this one?

1. Enabling a reset of an entity by means of an action

module bbf-entity-reset-action {
  yang-version 1.1;

  namespace "urn:broadband-forum-org:bbf-entity-reset-action";

  prefix "bbf-entity-reset-action";

  import ietf-entity {
    prefix ent;
  }
  ...

  identity reset-type {
    description
        "Type of reset requested of entity.  Examples of resets can be:
           hardware-reset, reset-with-selftest, reset-without-selftest,
           software-reset, possibly others.";
  }

  identity hardware-reset {
    base reset-type;
    description
        "Hardware reset";
  }

  augment "/ent:entity-state/ent:physical-entity" {
    description
        "Augment entity model with an action to request a reset of the
          entity";
    action reset {
      description "Request a reset of the entity";
      input {
        leaf reset-type {
          type identityref {
            base "reset-type";
          }
            description
                "Type of reset requested of entity";
        }
      }
    }
  }
}

Best regards - Vriendelijke groeten,
Bart Bogaert

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: 23 January 2017 11:59
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

> changed to alalarm-status to alarm-state and standby-status to 

The reason in this case is that we just used the MIB names.  This said, I
agree that "standby-state" and "alarm-state" are better.

> I also wonder about the mapping of the MIB object names to YANG leaf

Unclear.  I think I'm the one to blame for this inconsistency, and it goes
back to the very first commit, but I can't remeber why.

Yes this is better.

> Or alternatively, if supporting caching of values is a goal, we may 
> need to provide a 'sensor-data/properties-last-changed' object that 
> allows to make caching of value properties robust.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Jan 2017 10:28:00 +0100 (CET)

> added to the IETF entity model.  Is there no consensus about this one?

Not many spoke up.  I think there was just one comment, and that was
not in favor of adding this.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 24 Jan 2017 09:48:00 +0000

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 24 January 2017 10:28
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> Hi,
> 
> If I'm not mistaken, the following BBF addition was also proposed as 
> to be added to the IETF entity model.  Is there no consensus about this
one?

Not many spoke up.  I think there was just one comment, and that was not in
favor of adding this.
[Bart Bogaert] Ok... don't these people require the need to offer an
explicit reset capability of a HW entity to operators?  I would expect that
this is something that could be made available generically (possibly under a
feature if not everybody wants to implement this) rather than having various
own implementations to achieve the same...

Bart

/martin

> > distinction or should be just consistently use lets say 'state', 
> > i.e., changed to alalarm-status to alarm-state and standby-status to 
> > standby-state?
> 
> > Is the 'data-' prefix needed? If so, why is the a prefix not used 
> > for 'precision' (scale and precision really go hand in hand).
> 
> > the YANG objects? I actually do not know what the SHOULD buys a 
> > client since you can't rely on it. To be robust, you have to fetch 
> > an n-tuple anyway and be prepared that a sensor may have changed its
properties.
> > Should there be explicit text providing guidance that it is better 
> > to fetch the whole n-tuple?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Jan 2017 10:54:31 +0100

Assuming that not all hardware components support the same set of
reset types (or resets at all), how do I find out which reset types I
can apply to a specific hardware component? Or is the idea to let the
management system do trial and error pushing of reset buttons?

/js

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 24 Jan 2017 10:13:46 +0000

One more comment: 

The BBF proposal defines 'contained-in' as a leafref, the current version of
the hardware model has defined 'parent' as a string.  In the state container
parent is defined as a leafref.  Parent type should be the same in both
config and state container.

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: 23 January 2017 11:59
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Yes this is better.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 24 Jan 2017 10:28:52 +0000

Juergen,

I've been discussing internally here after observing that the current action
definition has no output and hence it is not possible to report whether the
reset is supported for a specific hardware instance.  Further reflection is
required on this.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 24 January 2017 10:55
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Assuming that not all hardware components support the same set of reset
types (or resets at all), how do I find out which reset types I can apply to
a specific hardware component? Or is the idea to let the management system
do trial and error pushing of reset buttons?

/js

On Tue, Jan 24, 2017 at 09:48:00AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> explicit reset capability of a HW entity to operators?  I would expect 
> that this is something that could be made available generically 
> (possibly under a feature if not everybody wants to implement this) 
> rather than having various own implementations to achieve the same...
> 
> Bart
> 
> /martin
> 
> 
> > 
> > Best regards - Vriendelijke groeten, Bart Bogaert
> > 
> > > i.e., changed to alalarm-status to alarm-state and standby-status 
> > > to standby-state?
> > 
> > Unclear.  I think I'm the one to blame for this inconsistency, and 
> > it goes back to the very first commit, but I can't remeber why.
> > 
> > > Why is it
> > > RFC 3433 points out that entPhySensorType and entPhySensorScale 
> > > and entPhySensorPrecision SHOULD NOT change during operation. What 
> > > about the YANG objects? I actually do not know what the SHOULD 
> > > buys a client since you can't rely on it. To be robust, you have 
> > > to fetch an n-tuple anyway and be prepared that a sensor may have 
> > > changed its
> properties.
> > > Or alternatively, if supporting caching of values is a goal, we 
> > > may need to provide a 'sensor-data/properties-last-changed' object 
> > > that allows to make caching of value properties robust.
> > 
> > 
> > /martin
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Jan 2017 11:37:03 +0100 (CET)

> config and state container.

The reason for the 'string' in the config tree is that when it is
pre-configured, it doesn't really refer to a component in the state
tree.  If it eventually matches a real component, the server will
instantiate an entry in the state tree, and at this point the parent
*is* a proper reference to another component.

Note that the underlying type is the same in both cases.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 24 Jan 2017 10:40:47 +0000

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 24 January 2017 11:37
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> One more comment: 
> 
> The BBF proposal defines 'contained-in' as a leafref, the current 
> version of the hardware model has defined 'parent' as a string.  In 
> the state container parent is defined as a leafref.  Parent type 
> should be the same in both config and state container.

The reason for the 'string' in the config tree is that when it is
pre-configured, it doesn't really refer to a component in the state tree.
If it eventually matches a real component, the server will instantiate an
entry in the state tree, and at this point the parent
*is* a proper reference to another component.

Note that the underlying type is the same in both cases.
[Bart Bogaert] Having it as leafref allows to verify that the parent being
configured is actually existing in the entity model (or defined in the same
transaction).  Why would we remove the modelling capability to check this
consistency?

Bart

/martin

properties.