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

["Bogaert, Bart (Nokia - BE)" <[e-mail]>]

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:[e-mail]] On Behalf Of Martin Bjorklund
Sent: 23 January 2017 11:59
To: [e-mail]
Cc: [e-mail]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

Juergen Schoenwaelder <[e-mail]> wrote:
> 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?

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.


> 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).

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
> '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

Yes this is better.

> 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?

This is certainly the simplest solution.   Any comments?

> 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

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod