A YANG Data Model for Hardware Management
draft-ietf-netmod-entity-05

Internet-Draft          YANG Hardware Management            October 2017

         }
         description
           "The name of the component that has transitioned into the
            'disabled' state.";
       }
       leaf admin-state {
         type leafref {
           path "/hardware/component/state/admin-state";
         }
         description
           "The administrative state for the component.";
       }
       leaf alarm-state {
         type leafref {
           path "/hardware/component/state/alarm-state";
         }
         description
           "The alarm state for the component.";
       }
       reference "RFC 4268, entStateOperDisabled";
     }

   }

   <CODE ENDS>

   <CODE BEGINS> file "iana-hardware@2017-10-16.yang"

   module iana-hardware {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:iana-hardware";
     prefix ianahw;

     organization "IANA";
     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                4676 Admiralty Way, Suite 330
                Marina del Rey, CA 90292

        Tel:    +1 310 823 9358
        <mailto:iana@iana.org>";

     description
       "IANA defined identities for hardware class.";
     reference

Bierman, et al.          Expires April 19, 2018                [Page 31]
Internet-Draft          YANG Hardware Management            October 2017

       // RFC Ed.: replace XXXX with actual path and remove this note.
       "https://www.iana.org/assignments/XXXX";

     // RFC Ed.: replace XXXX with actual RFC number and remove this
     // note.

     // RFC Ed.: update the date below with the date of RFC publication
     // and remove this note.
     revision 2017-10-16 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: A YANG Data Model for Hardware Management";
     }

     /*
      * Identities
      */

     identity hardware-class {
       description
         "This identity is the base for all hardware class
          identifiers.";
     }

     identity unknown {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is unknown
          to the server.";
     }

     identity chassis {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is an
          overall container for networking equipment.  Any class of
          physical component, except a stack, may be contained within a
          chassis; a chassis may only be contained within a stack.";
     }

     identity backplane {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of device for aggregating and forwarding networking traffic,
          such as a shared backplane in a modular ethernet switch.  Note
          that an implementation may model a backplane as a single

Bierman, et al.          Expires April 19, 2018                [Page 32]
Internet-Draft          YANG Hardware Management            October 2017

          physical component, which is actually implemented as multiple
          discrete physical components (within a chassis or stack).";
     }

     identity container {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is capable
          of containing one or more removable physical entities,
          possibly of different types.  For example, each (empty or
          full) slot in a chassis will be modeled as a container.  Note
          that all removable physical components should be modeled
          within a container component, such as field-replaceable
          modules, fans, or power supplies.  Note that all known
          containers should be modeled by the agent, including empty
          containers.";
     }

     identity power-supply {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is a
          power-supplying component.";
     }

     identity fan {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is a fan or
          other heat-reduction component.";
     }

     identity sensor {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of sensor, such as a temperature sensor within a router
          chassis.";
     }

     identity module {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of self-contained sub-system.  If a module component is
          removable, then it should be modeled within a container
          component; otherwise, it should be modeled directly within
          another physical component (e.g., a chassis or another

Bierman, et al.          Expires April 19, 2018                [Page 33]
Internet-Draft          YANG Hardware Management            October 2017

          module).";
     }

     identity port {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of networking port, capable of receiving and/or transmitting
          networking traffic.";
     }

     identity stack {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of super-container (possibly virtual) intended to group
          together multiple chassis entities.  A stack may be realized
          by a virtual cable, a real interconnect cable attached to
          multiple chassis, or multiple interconnect cables.  A stack
          should not be modeled within any other physical components,
          but a stack may be contained within another stack.  Only
          chassis components should be contained within a stack.";
     }

     identity cpu {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of central processing unit.";
     }

     identity energy-object {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of energy object, i.e., a piece of equipment that is part of
          or attached to a communications network that is monitored,
          controlled, or aids in the management of another device for
          Energy Management.";
     }

     identity battery {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of battery.";
     }

Bierman, et al.          Expires April 19, 2018                [Page 34]
Internet-Draft          YANG Hardware Management            October 2017

     identity storage-drive {
       base ianahw:hardware-class;
       description
         "This identity is applicable if the hardware class is some sort
          of component with data storage capability as main
          functionality, e.g., disk drive (HDD), solid state device
          (SSD), hybrid (SSHD), object storage (OSD) or other.";
     }
   }

   <CODE ENDS>

8.  IANA Considerations

   This document defines the initial version of the IANA-maintained
   "iana-hardware" YANG module.

   The "iana-hardware" YANG module is intended to reflect the
   "IANA-ENTITY-MIB" MIB module so that if a new enumeration is added to
   the "IANAPhysicalClass" TEXTUAL-CONVENTION, the same class is added
   as an identity derived from "ianahw:hardware-class".

   When the "iana-hardware" YANG module is updated, a new "revision"
   statement must be added in front of the existing revision statements.

8.1.  URI Registrations

   This document registers two URIs in the IETF XML registry [RFC3688].
   Following the format in RFC 3688, the following registrations are
   requested to be made.

        URI: urn:ietf:params:xml:ns:yang:iana-hardware
        Registrant Contact: The IESG.
        XML: N/A, the requested URI is an XML namespace.

        URI: urn:ietf:params:xml:ns:yang:ietf-hardware
        Registrant Contact: The IESG.
        XML: N/A, the requested URI is an XML namespace.

8.2.  YANG Module Registrations

   This document registers two YANG modules in the YANG Module Names
   registry [RFC6020].

Bierman, et al.          Expires April 19, 2018                [Page 35]
Internet-Draft          YANG Hardware Management            October 2017

     name:         iana-hardware
     namespace:    urn:ietf:params:xml:ns:yang:iana-hardware
     prefix:       ianahw
     reference:    RFC XXXX

     name:         ietf-hardware
     namespace:    urn:ietf:params:xml:ns:yang:ietf-hardware
     prefix:       hw
     reference:    RFC XXXX

9.  Security Considerations

   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The NETCONF access
   control model [RFC6536] provides the means to restrict access for
   particular NETCONF users to a pre-configured subset of all available
   NETCONF protocol operations and content.

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   /hardware/component/admin-state:  Setting this node to 'locked' or
      'shutting-down' can cause disruption of services ranging from
      those running on a port to those on an entire device, depending on
      the type of component.

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   /hardware/component:  The leafs in this list expose information about
      the physical components in a device, which may be used to identify
      the vendor, model, version, and specific device-identification
      information of each system component.

   /hardware/component/sensor-data/value:  This node may expose the
      values of particular physical sensors in a device.

Bierman, et al.          Expires April 19, 2018                [Page 36]
Internet-Draft          YANG Hardware Management            October 2017

   /hardware/component/state:  Access to this node allows one to figure
      out what the active and standby resources in a device are.

10.  Acknowledgments

   The authors wish to thank the following individuals, who all provided
   helpful comments on various draft versions of this document: Bart
   Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder.

11.  Normative References

   [I-D.ietf-netmod-revised-datastores]
              Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore
              Architecture", draft-ietf-netmod-revised-datastores-03
              (work in progress), July 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
              Management Information Base", RFC 3433,
              DOI 10.17487/RFC3433, December 2002, <https://www.rfc-
              editor.org/info/rfc3433>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
              editor.org/info/rfc3688>.

   [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
              DOI 10.17487/RFC4268, November 2005, <https://www.rfc-
              editor.org/info/rfc4268>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
              editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

Bierman, et al.          Expires April 19, 2018                [Page 37]
Internet-Draft          YANG Hardware Management            October 2017

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
              editor.org/info/rfc6536>.

   [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
              Chandramouli, "Entity MIB (Version 4)", RFC 6933,
              DOI 10.17487/RFC6933, May 2013, <https://www.rfc-
              editor.org/info/rfc6933>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

Authors' Addresses

   Andy Bierman
   YumaWorks

   Email: andy@yumaworks.com

   Martin Bjorklund
   Tail-f Systems

   Email: mbj@tail-f.com

   Jie Dong
   Huawei Technologies

   Email: jie.dong@huawei.com

   Dan Romascanu

   Email: dromasca@gmail.com

Bierman, et al.          Expires April 19, 2018                [Page 38]