idnits 2.17.1 draft-ietf-netmod-entity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 23, 2017) is 2650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft YumaWorks 4 Intended status: Standards Track M. Bjorklund 5 Expires: July 27, 2017 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 9 January 23, 2017 11 A YANG Data Model for Hardware Management 12 draft-ietf-netmod-entity-02 14 Abstract 16 This document defines a YANG data model for the management of 17 hardware on a single server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 27, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 2 56 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. The Components Lists . . . . . . . . . . . . . . . . . . 5 59 4. Relationship to ENTITY-MIB . . . . . . . . . . . . . . . . . 5 60 5. Relationship to ENTITY-SENSOR-MIB . . . . . . . . . . . . . . 6 61 6. Relationship to ENTITY-STATE-MIB . . . . . . . . . . . . . . 7 62 7. Hardware YANG Module . . . . . . . . . . . . . . . . . . . . 7 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 38 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 69 1. Introduction 71 This document defines a YANG [RFC7950] data model for the management 72 of hardware on a single server. 74 The data model includes configuration data and state data (status 75 information and counters for the collection of statistics). 77 1.1. Terminology 79 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14, [RFC2119]. 84 1.1.1. Tree Diagrams 86 A simplified graphical representation of the data model is used in 87 this document. The meaning of the symbols in these diagrams is as 88 follows: 90 o Brackets "[" and "]" enclose list keys. 92 o Abbreviations before data node names: "rw" means configuration 93 data (read-write) and "ro" state data (read-only). 95 o Symbols after data node names: "?" means an optional node, "!" 96 means a presence container, and "*" denotes a list and leaf-list. 98 o Parentheses enclose choice and case nodes, and case nodes are also 99 marked with a colon (":"). 101 o Ellipsis ("...") stands for contents of subtrees that are not 102 shown. 104 2. Objectives 106 This section describes some of the design objectives for the hardware 107 model. 109 o There are many common properties used to identify hardware 110 components, which need to be supported in the hardware data model. 112 o There are many important information and states about the 113 components, which needs to be collected from the devices which 114 support the hardware data model. 116 o The hardware data model SHOULD be suitable for new implementations 117 to use as is. 119 o The hardware data model defined in this document can be 120 implemented on a system that also implements ENTITY-MIB, thus the 121 mapping between the hardware data model and ENTITY-MIB SHOULD be 122 clear. 124 o The data model should support pre-provisioning of hardware 125 components. 127 3. Hardware Data Model 129 This document defines the YANG module "ietf-hardware", which has the 130 following structure: 132 module: ietf-hardware 133 +--ro hardware-state 134 | +--ro last-change? yang:date-and-time 135 | +--ro component* [name] 136 | +--ro name string 137 | +--ro class identityref 138 | +--ro physical-index? int32 {entity-mib}? 139 | +--ro description? string 140 | +--ro parent? -> ../../component/name 141 | +--ro parent-rel-pos? int32 142 | +--ro contains-child* -> ../../component/name 143 | +--ro hardware-rev? string 144 | +--ro firmware-rev? string 145 | +--ro software-rev? string 146 | +--ro serial-num? string 147 | +--ro mfg-name? string 148 | +--ro model-name? string 149 | +--ro alias? string 150 | +--ro asset-id? string 151 | +--ro is-fru? boolean 152 | +--ro mfg-date? yang:date-and-time 153 | +--ro uri* inet:uri 154 | +--ro uuid? yang:uuid 155 | +--ro state {hardware-state}? 156 | | +--ro state-last-changed? yang:date-and-time 157 | | +--ro admin-state? admin-state 158 | | +--ro oper-state? oper-state 159 | | +--ro usage-state? usage-state 160 | | +--ro alarm-status? alarm-status 161 | | +--ro standby-status? standby-status 162 | +--ro sensor-data {hardware-sensor}? 163 | +--ro data-type? sensor-data-type 164 | +--ro data-scale? sensor-data-scale 165 | +--ro precision? sensor-precision 166 | +--ro value? sensor-value 167 | +--ro oper-status? sensor-status 168 | +--ro sensor-units-display? string 169 | +--ro value-timestamp? yang:date-and-time 170 | +--ro value-update-rate? uint32 171 +--rw hardware {hardware-config}? 172 +--rw component* [name] 173 +--rw name string 174 +--rw class identityref 175 +--rw parent? string 176 +--rw parent-rel-pos? int32 177 +--rw mfg-name? string 178 +--rw serial-num? string 179 +--rw alias? string 180 +--rw asset-id? string 181 +--rw uri* inet:uri 182 +--rw admin-state? admin-state {hardware-state}? 184 notifications: 185 +---n harwdare-state-change 186 +---n hardware-state-oper-enabled {hardware-state}? 187 | +--ro name? -> /hardware-state/component/name 188 | +--ro admin-state? 189 | | -> /hardware-state/component/state/admin-state 190 | +--ro alarm-status? 191 | -> /hardware-state/component/state/alarm-status 192 +---n hardware-state-oper-disabled {hardware-state}? 193 +--ro name? -> /hardware-state/component/name 194 +--ro admin-state? 195 | -> /hardware-state/component/state/admin-state 196 +--ro alarm-status? 197 -> /hardware-state/component/state/alarm-status 199 3.1. The Components Lists 201 The data model for hardware presented in this document uses a flat 202 list of components. Each component in the list is identified by its 203 name. Furthermore, each component has a mandatory "class" leaf. 205 The "iana-hardware" module defines YANG identities for the hardware 206 types in the IANA-maintained "IANA-ENTITY-MIB" registry. 208 The "class" leaf is a YANG identity that describes the type of the 209 hardware. Vendors are encouraged to either directly use one of the 210 common IANA-defined identities, or derive a more specific identity 211 from one of them. 213 There is one optional list of configured components ("/hardware/ 214 component"), and a separate list for the operational state of all 215 components ("/hardware-state/component"). 217 4. Relationship to ENTITY-MIB 219 If the device implements the ENTITY-MIB [RFC6933], each entry in the 220 "/hardware-state/component" list is mapped to one EntPhysicalEntry. 221 Objects that are writable in the MIB are mapped to nodes in the 222 "/hardware/component" list. 224 The "physical-index" leaf MUST contain the value of the corresponding 225 entPhysicalEntry's entPhysicalIndex. 227 The "class" leaf is mapped to both entPhysicalClass and 228 entPhysicalVendorType. If the value of the "class" leaf is an 229 identity that is either derived from or is one of the identities in 230 the "iana-hardware" module, then entPhysicalClass contains the 231 corresponding IANAPhysicalClass enumeration value. Otherwise, 232 entPhysicalClass contains the IANAPhysicalClass value "other(1)". 233 Vendors are encouraged to define an identity (derived from an 234 identity in "iana-hardware" if possible) for each enterprise-specific 235 registration identifier used for entPhysicalVendorType, and use that 236 identity for the "class" leaf. 238 The following tables list the YANG data nodes with corresponding 239 objects in the ENTITY-MIB. 241 +----------------------------------+--------------------------------+ 242 | YANG data node in /hardware- | ENTITY-MIB object | 243 | state/component | | 244 +----------------------------------+--------------------------------+ 245 | name | entPhysicalName | 246 | class | entPhysicalClass | 247 | | entPhysicalVendorType | 248 | physical-index | entPhysicalIndex | 249 | description | entPhysicalDescr | 250 | parent | entPhysicalContainedIn | 251 | parent-rel-pos | entPhysicalParentRelPos | 252 | contains-child | entPhysicalChildIndex | 253 | hardware-rev | entPhysicalHardwareRev | 254 | firmware-rev | entPhysicalFirmwareRev | 255 | software-rev | entPhysicalSoftwareRev | 256 | serial-num | entPhysicalSerialNum | 257 | mfg-name | entPhysicalMfgName | 258 | model-name | entPhysicalModelName | 259 | alias | entPhysicalAlias | 260 | asset-id | entPhysicalAssetID | 261 | is-fru | entPhysicalIsFRU | 262 | mfg-date | entPhysicalMfgDate | 263 | uri | entPhysicalUris | 264 | uuid | entPhysicalUUID | 265 +----------------------------------+--------------------------------+ 267 YANG data nodes and related ENTITY-MIB objects 269 5. Relationship to ENTITY-SENSOR-MIB 271 If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry 272 the in "/hardware-state/component" list where the container 273 "sensor-data" exists is mapped to one EntPhySensorEntry. 275 +-------------------------------------+-----------------------------+ 276 | YANG data node in /hardware- | ENTITY-SENSOR-MIB object | 277 | state/component/sensor-data | | 278 +-------------------------------------+-----------------------------+ 279 | data-type | entPhySensorType | 280 | data-scale | entPhySensorScale | 281 | precision | entPhySensorPrecision | 282 | value | entPhySensorValue | 283 | oper-status | entPhySensorOperStatus | 284 | sensor-units-display | entPhySensorUnitsDisplay | 285 | value-timestamp | entPhySensorValueTimeStamp | 286 | value-update-rate | entPhySensorValueUpdateRate | 287 +-------------------------------------+-----------------------------+ 289 YANG data nodes and related ENTITY-SENSOR-MIB objects 291 6. Relationship to ENTITY-STATE-MIB 293 If the device implements the ENTITY-STATE-MIB [RFC4268], each entry 294 the in "/hardware-state/component" list where the container "state" 295 exists is mapped to one EntStateEntry. 297 +--------------------------------------------+----------------------+ 298 | YANG data node in /hardware- | ENTITY-STATE-MIB | 299 | state/component/state | object | 300 +--------------------------------------------+----------------------+ 301 | state-last-changed | entStateLastChanged | 302 | admin-state | entStateAdmin | 303 | oper-state | entStateOper | 304 | usage-state | entStateUsage | 305 | alarm-status | entStateAlarm | 306 | standby-status | entStateStandby | 307 +--------------------------------------------+----------------------+ 309 YANG data nodes and related ENTITY-SENSOR-MIB objects 311 7. Hardware YANG Module 313 file "ietf-hardware@2017-01-18.yang" 315 module ietf-hardware { 316 yang-version 1.1; 317 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; 318 prefix hw; 320 import ietf-inet-types { 321 prefix inet; 322 } 323 import ietf-yang-types { 324 prefix yang; 325 } 326 import iana-hardware { 327 prefix ianahw; 328 } 330 organization 331 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 333 contact 334 "WG Web: 335 WG List: 337 WG Chair: Lou Berger 338 340 WG Chair: Kent Watsen 341 343 Editor: Andy Bierman 344 346 Editor: Martin Bjorklund 347 349 Editor: Jie Dong 350 352 Editor: Dan Romascanu 353 "; 355 // RFC Ed.: replace XXXX with actual RFC number and remove this 356 // note. 358 description 359 "This module contains a collection of YANG definitions for 360 managing hardware. 362 Copyright (c) 2017 IETF Trust and the persons identified as 363 authors of the code. All rights reserved. 365 Redistribution and use in source and binary forms, with or 366 without modification, is permitted pursuant to, and subject 367 to the license terms contained in, the Simplified BSD License 368 set forth in Section 4.c of the IETF Trust's Legal Provisions 369 Relating to IETF Documents 370 (http://trustee.ietf.org/license-info). 371 This version of this YANG module is part of RFC XXXX; see 372 the RFC itself for full legal notices."; 374 // RFC Ed.: update the date below with the date of RFC publication 375 // and remove this note. 376 revision 2017-01-18 { 377 description 378 "Initial revision."; 379 reference 380 "RFC XXXX: A YANG Data Model for Hardware Management"; 381 } 383 /* 384 * Features 385 */ 387 feature entity-mib { 388 description 389 "This feature indicates that the device implements 390 the ENTITY-MIB."; 391 reference "RFC 6933: Entity MIB (Version 4)"; 392 } 394 feature hardware-config { 395 description 396 "Indicates that the server supports configuration of 397 hardware components."; 398 } 400 feature hardware-state { 401 description 402 "Indicates the ENTITY-STATE-MIB objects are supported"; 403 reference "RFC 4268: Entity State MIB"; 404 } 406 feature hardware-sensor { 407 description 408 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 409 reference "RFC 3433: Entity Sensor MIB"; 410 } 412 /* 413 * Typedefs 414 */ 416 typedef admin-state { 417 type enumeration { 418 enum unknown { 419 value 1; 420 description 421 "The resource is unable to report administrative state."; 422 } 423 enum locked { 424 value 2; 425 description 426 "The resource is administratively prohibited from use."; 427 } 428 enum shutting-down { 429 value 3; 430 description 431 "The resource usage is administratively limited to current 432 instances of use."; 433 } 434 enum unlocked { 435 value 4; 436 description 437 "The resource is not administratively prohibited from 438 use."; 439 } 440 } 441 description 442 "Represents the various possible administrative states."; 443 reference "RFC 4268: EntityAdminState"; 444 } 446 typedef oper-state { 447 type enumeration { 448 enum unknown { 449 value 1; 450 description 451 "The resource is unable to report operational state."; 452 } 453 enum disabled { 454 value 2; 455 description 456 "The resource is totally inoperable."; 457 } 458 enum enabled { 459 value 3; 460 description 461 "The resource is partially or fully operable."; 462 } 463 enum testing { 464 value 4; 465 description 466 "The resource is currently being tested and cannot 467 therefore report whether it is operational or not."; 468 } 469 } 470 description 471 "Represents the possible values of operational states."; 472 reference "RFC 4268: EntityOperState"; 473 } 475 typedef usage-state { 476 type enumeration { 477 enum unknown { 478 value 1; 479 description 480 "The resource is unable to report usage state."; 481 } 482 enum idle { 483 value 2; 484 description 485 "The resource is servicing no users."; 486 } 487 enum active { 488 value 3; 489 description 490 "The resource is currently in use and it has sufficient 491 spare capacity to provide for additional users."; 492 } 493 enum busy { 494 value 4; 495 description 496 "The resource is currently in use, but it currently has no 497 spare capacity to provide for additional users."; 498 } 499 } 500 description 501 "Represents the possible values of usage states."; 502 reference "RFC 4268, EntityUsageState"; 503 } 505 typedef alarm-status { 506 type bits { 507 bit unknown { 508 position 0; 509 description 510 "The resource is unable to report alarm state."; 511 } 512 bit under-repair { 513 position 1; 514 description 515 "The resource is currently being repaired, which, depending 516 on the implementation, may make the other values in this 517 bit string not meaningful."; 518 } 519 bit critical { 520 position 2; 521 description 522 "One or more critical alarms are active against the 523 resource."; 524 } 525 bit major { 526 position 3; 527 description 528 "One or more major alarms are active against the 529 resource."; 530 } 531 bit minor { 532 position 4; 533 description 534 "One or more minor alarms are active against the 535 resource."; 536 } 537 bit warning { 538 position 5; 539 description 540 "One or more warning alarms are active against the 541 resource."; 542 } 543 bit indeterminate { 544 position 6; 545 description 546 "One or more alarms of whose perceived severity cannot be 547 determined are active against this resource."; 548 } 549 } 550 description 551 "Represents the possible values of alarm status. An alarm is a 552 persistent indication of an error or warning condition. 554 When no bits of this attribute are set, then no active alarms 555 are known against this component and it is not under repair."; 556 reference "RFC 4268: EntityAlarmStatus"; 557 } 559 typedef standby-status { 560 type enumeration { 561 enum unknown { 562 value 1; 563 description 564 "The resource is unable to report standby state."; 565 } 566 enum hot-standby { 567 value 2; 568 description 569 "The resource is not providing service, but it will be 570 immediately able to take over the role of the resource to 571 be backed up, without the need for initialization 572 activity, and will contain the same information as the 573 resource to be backed up."; 574 } 575 enum cold-standby { 576 value 3; 577 description 578 "The resource is to back up another resource, but will not 579 be immediately able to take over the role of a resource to 580 be backed up, and will require some initialization 581 activity."; 582 } 583 enum providing-service { 584 value 4; 585 description 586 "The resource is providing service."; 587 } 588 } 589 description 590 "Represents the possible values of standby status."; 591 reference "RFC 4268: EntityStandbyStatus"; 592 } 594 typedef sensor-data-type { 595 type enumeration { 596 enum other { 597 value 1; 598 description 599 "A measure other than those listed below."; 600 } 601 enum unknown { 602 value 2; 603 description 604 "An unknown measurement, or arbitrary, relative numbers"; 605 } 606 enum volts-AC { 607 value 3; 608 description 609 "A measure of electric potential (alternating current)."; 610 } 611 enum volts-DC { 612 value 4; 613 description 614 "A measure of electric potential (direct current)."; 615 } 616 enum amperes { 617 value 5; 618 description 619 "A measure of electric current."; 620 } 621 enum watts { 622 value 6; 623 description 624 "A measure of power."; 625 } 626 enum hertz { 627 value 7; 628 description 629 "A measure of frequency."; 630 } 631 enum celsius { 632 value 8; 633 description 634 "A measure of temperature."; 635 } 636 enum percent-RH { 637 value 9; 638 description 639 "A measure of percent relative humidity."; 640 } 641 enum rpm { 642 value 10; 643 description 644 "A measure of shaft revolutions per minute."; 645 } 646 enum cmm { 647 value 11; 648 description 649 "A measure of cubic meters per minute (airflow)."; 650 } 651 enum truth-value { 652 value 12; 653 description 654 "Value is one of 1 (true) or 2 (false)"; 655 } 656 } 657 description 658 "A node using this data type represents the sensor measurement 659 data type associated with a physical sensor value. The actual 660 data units are determined by examining a node of this type 661 together with the associated sensor-data-scale node. 663 A node of this type SHOULD be defined together with nodes of 664 type sensor-data-scale and sensor-precision. These three types 665 are used to identify the semantics of a node of type 666 sensor-value."; 667 reference "RFC 3433: EntitySensorDataType"; 668 } 670 typedef sensor-data-scale { 671 type enumeration { 672 enum yocto { 673 value 1; 674 description 675 "Data scaling factor of 10^-24."; 676 } 677 enum zepto { 678 value 2; 679 description 680 "Data scaling factor of 10^-21."; 681 } 682 enum atto { 683 value 3; 684 description 685 "Data scaling factor of 10^-18."; 686 } 687 enum femto { 688 value 4; 689 description 690 "Data scaling factor of 10^-15."; 691 } 692 enum pico { 693 value 5; 694 description 695 "Data scaling factor of 10^-12."; 696 } 697 enum nano { 698 value 6; 699 description 700 "Data scaling factor of 10^-9."; 701 } 702 enum micro { 703 value 7; 704 description 705 "Data scaling factor of 10^-6."; 706 } 707 enum milli { 708 value 8; 709 description 710 "Data scaling factor of 10^-3."; 711 } 712 enum units { 713 value 9; 714 description 715 "Data scaling factor of 10^0."; 716 } 717 enum kilo { 718 value 10; 719 description 720 "Data scaling factor of 10^3."; 721 } 722 enum mega { 723 value 11; 724 description 725 "Data scaling factor of 10^6."; 726 } 727 enum giga { 728 value 12; 729 description 730 "Data scaling factor of 10^9."; 731 } 732 enum tera { 733 value 13; 734 description 735 "Data scaling factor of 10^12."; 736 } 737 enum exa { 738 value 14; 739 description 740 "Data scaling factor of 10^15."; 741 } 742 enum peta { 743 value 15; 744 description 745 "Data scaling factor of 10^18."; 746 } 747 enum zetta { 748 value 16; 749 description 750 "Data scaling factor of 10^21."; 751 } 752 enum yotta { 753 value 17; 754 description 755 "Data scaling factor of 10^24."; 756 } 757 } 758 description 759 "A node using this data type represents a data scaling factor, 760 represented with an International System of Units (SI) prefix. 761 The actual data units are determined by examining a node of 762 this type together with the associated sensor-data-type. 764 A node of this type SHOULD be defined together with nodes of 765 type sensor-data-type and sensor-precision. Together, 766 associated nodes of these three types are used to identify the 767 semantics of a node of type sensor-value."; 768 reference "RFC 3433: EntitySensorDataScale"; 769 } 771 typedef sensor-precision { 772 type int32 { 773 range "-8 .. 9"; 774 } 775 description 776 "A node using this data type represents a sensor precision 777 range. 779 A node of this type SHOULD be defined together with nodes of 780 type sensor-data-type and sensor-data-scale. Together, 781 associated nodes of these three types are used to identify the 782 semantics of a node of type sensor-value. 784 If a node of this type contains a value in the range 1 to 9, 785 it represents the number of decimal places in the fractional 786 part of an associated sensor-value fixed- point number. 788 If a node of this type contains a value in the range -8 to -1, 789 it represents the number of accurate digits in the associated 790 sensor-value fixed-point number. 792 The value zero indicates the associated sensor-value node is 793 not a fixed-point number. 795 Server implementers must choose a value for the associated 796 sensor-precision node so that the precision and accuracy of 797 the associated sensor-value node is correctly indicated. 799 For example, a component representing a temperature sensor 800 that can measure 0 degrees to 100 degrees C in 0.1 degree 801 increments, +/- 0.05 degrees, would have an sensor-precision 802 value of '1', an sensor-data-scale value of 'units', and an 803 sensor-value ranging from '0' to '1000'. The sensor-value 804 would be interpreted as 'degrees C * 10'."; 805 reference "RFC 3433: EntitySensorPrecision"; 806 } 808 typedef sensor-value { 809 type int32 { 810 range "-1000000000 .. 1000000000"; 811 } 812 description 813 "A node using this data type represents an sensor value. 815 A node of this type SHOULD be defined together with nodes of 816 type sensor-data-type, sensor-data-scale, and sensor-precision. 817 Together, associated nodes of those three types are used to 818 identify the semantics of a node of this data type. 820 The semantics of a node using this data type are determined by 821 the value of the associated sensor-data-type node. 823 If the associated sensor-data-type node is equal to 'voltsAC', 824 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 825 then a node of this type MUST contain a fixed point number 826 ranging from -999,999,999 to +999,999,999. The value 827 -1000000000 indicates an underflow error. The value +1000000000 828 indicates an overflow error. The sensor-precision indicates 829 how many fractional digits are represented in the associated 830 sensor-value node. 832 If the associated sensor-data-type node is equal to 833 'percentRH', then a node of this type MUST contain a number 834 ranging from 0 to 100. 836 If the associated sensor-data-type node is equal to 'rpm', then 837 a node of this type MUST contain a number ranging from 838 -999,999,999 to +999,999,999. 840 If the associated sensor-data-type node is equal to 841 'truth-value', then a node of this type MUST contain either the 842 value 1 (true) or the value 2 (false)'. 844 If the associated sensor-data-type node is equal to 'other' or 845 unknown', then a node of this type MUST contain a number 846 ranging from -1000000000 to 1000000000."; 847 reference "RFC 3433: EntitySensorValue"; 848 } 850 typedef sensor-status { 851 type enumeration { 852 enum ok { 853 value 1; 854 description 855 "Indicates that the server can obtain the sensor value."; 856 } 857 enum unavailable { 858 value 2; 859 description 860 "Indicates that the server presently cannot obtain the 861 sensor value."; 862 } 863 enum nonoperational { 864 value 3; 865 description 866 "Indicates that the server believes the sensor is broken. 867 The sensor could have a hard failure (disconnected wire), 868 or a soft failure such as out-of-range, jittery, or wildly 869 fluctuating readings."; 870 } 871 } 872 description 873 "A node using this data type represents the operational status 874 of a physical sensor."; 875 reference "RFC 3433: EntitySensorStatus"; 876 } 878 /* 879 * Operational state data nodes 880 */ 882 container hardware-state { 883 config false; 884 description 885 "Data nodes for the operational state of components."; 887 leaf last-change { 888 type yang:date-and-time; 889 description 890 "The time the '/hardware-state/component' list changed."; 891 } 893 list component { 894 key name; 895 description 896 "List of components. 898 When the server detects a new hardware component, it 899 initializes an entry in this list. 901 If the server does not support the feature 902 'hardware-config', the entry is initialized with values for 903 all nodes as detected by the implementation. 905 Otherwise, the following procedure is followed: 907 1. If there is an entry in the /hardware/component list 908 with values for the nodes 'class', 'parent', 909 'parent-rel-pos' that are equal to the detected values, 910 then: 912 1a. If the configured entry has a value for 'mfg-name' 913 that is equal to the detected value, or if the 914 'mfg-name' value cannot be detected, then the entry is 915 initialized with the configured values for all 916 configured leafs, including the 'name'. 918 Otherwise, the entry is initialized with values for 919 all nodes as detected by the implementation. The 920 implementation may raise an alarm that informs about 921 the 'mfg-name' mismatch condition. How this is done 922 is outside the scope of this document. 924 1b. Otherwise (i.e., there is no matching configuration 925 entry), the entry is initialized with values for all 926 nodes as detected by the implementation. 928 If the /hardware/component list is modified (i.e., someone 929 changed the configuration), then the system MUST behave as 930 if it re-initializes itself, and follow the procedure in 931 (1)."; 933 reference "RFC 6933: entPhysicalEntry"; 935 leaf name { 936 type string; 937 description 938 "The name assigned to this component. 940 This name is not required to be the same as 941 entPhysicalName."; 942 } 944 leaf class { 945 type identityref { 946 base ianahw:hardware-class; 948 } 949 mandatory true; 950 description 951 "An indication of the general hardware type of the 952 component."; 953 reference "RFC 6933: entPhysicalClass"; 954 } 956 leaf physical-index { 957 if-feature entity-mib; 958 type int32 { 959 range "1..2147483647"; 960 } 961 description 962 "The entPhysicalIndex for the entPhysicalEntry represented 963 by this list entry."; 964 reference "RFC 6933: entPhysicalIndex"; 965 } 967 leaf description { 968 type string; 969 description 970 "A textual description of component. This node should 971 contain a string that identifies the manufacturer's name 972 for the component and should be set to a distinct value 973 for each version or model of the component."; 974 reference "RFC 6933: entPhysicalDescr"; 975 } 977 leaf parent { 978 type leafref { 979 path "../../component/name"; 980 } 981 description 982 "The name of the component that physically contains this 983 component. 985 If this leaf is not instantiated, it indicates that this 986 component is not contained in any other component. 988 In the event that a physical component is contained by 989 more than one physical component (e.g., double-wide 990 modules), this node contains the name of one of these 991 components. An implementation MUST use the same name 992 every time this node is instantiated."; 993 reference "RFC 6933: entPhysicalContainedIn"; 994 } 995 leaf parent-rel-pos { 996 type int32 { 997 range "0 .. 2147483647"; 998 } 999 description 1000 "An indication of the relative position of this child 1001 component among all its sibling components. Sibling 1002 components are defined as components that share the same 1003 instance values of each of the 'parent' and 'class' 1004 nodes."; 1005 reference "RFC 6933: entPhysicalParentRelPos"; 1006 } 1008 leaf-list contains-child { 1009 type leafref { 1010 path "../../component/name"; 1011 } 1012 description 1013 "The name of the contained component."; 1014 reference "RFC 6933: entPhysicalChildIndex"; 1015 } 1017 leaf hardware-rev { 1018 type string; 1019 description 1020 "The vendor-specific hardware revision string for the 1021 component. The preferred value is the hardware revision 1022 identifier actually printed on the component itself (if 1023 present)."; 1024 reference "RFC 6933: entPhysicalHardwareRev"; 1025 } 1027 leaf firmware-rev { 1028 type string; 1029 description 1030 "The vendor-specific firmware revision string for the 1031 component."; 1032 reference "RFC 6933: entPhysicalFirmwareRev"; 1033 } 1035 leaf software-rev { 1036 type string; 1037 description 1038 "The vendor-specific software revision string for the 1039 component."; 1040 reference "RFC 6933: entPhysicalSoftwareRev"; 1041 } 1042 leaf serial-num { 1043 type string; 1044 description 1045 "The vendor-specific serial number string for the 1046 component. The preferred value is the serial number 1047 string actually printed on the component itself (if 1048 present). 1050 If a serial number has been configured for this component 1051 in /hardware/component/serial-num, this node contains the 1052 configured value."; 1053 reference "RFC 6933: entPhysicalSerialNum"; 1054 } 1056 leaf mfg-name { 1057 type string; 1058 description 1059 "The name of the manufacturer of this physical component. 1060 The preferred value is the manufacturer name string 1061 actually printed on the component itself (if present). 1063 Note that comparisons between instances of the model-name, 1064 firmware-rev, software-rev, and the serial-num nodes are 1065 only meaningful amongst component with the same value of 1066 mfg-name. 1068 If the manufacturer name string associated with the 1069 physical component is unknown to the server, then this 1070 node is not instantiated."; 1071 reference "RFC 6933: entPhysicalMfgName"; 1072 } 1074 leaf model-name { 1075 type string; 1076 description 1077 "The vendor-specific model name identifier string 1078 associated with this physical component. The preferred 1079 value is the customer-visible part number, which may be 1080 printed on the component itself. 1082 If the model name string associated with the physical 1083 component is unknown to the server, then this node is not 1084 instantiated."; 1085 reference "RFC 6933: entPhysicalModelName"; 1086 } 1088 leaf alias { 1089 type string; 1090 description 1091 "An 'alias' name for the component, as specified by a 1092 network manager, and provides a non-volatile 'handle' for 1093 the component. 1095 If an alias has been configured for this component in 1096 /hardware/component/alias, this node contains the 1097 configured value. If no such alias has been configured, 1098 the server may set the value of this node to a locally 1099 unique value."; 1100 reference "RFC 6933: entPhysicalAlias"; 1101 } 1103 leaf asset-id { 1104 type string; 1105 description 1106 "This node is a user-assigned asset tracking identifier for 1107 the component. 1109 If an asset tracking identifier has been configured for 1110 this component in /hardware/component/asset-id, this node 1111 contains the configured value."; 1112 reference "RFC 6933: entPhysicalAssetID"; 1113 } 1115 leaf is-fru { 1116 type boolean; 1117 description 1118 "This node indicates whether or not this component is 1119 considered a 'field replaceable unit' by the vendor. If 1120 this node contains the value 'true', then this component 1121 identifies a field replaceable unit. For all components 1122 that are permanently contained within a field replaceable 1123 unit, the value 'false' should be returned for this 1124 node."; 1125 reference "RFC 6933: entPhysicalIsFRU"; 1126 } 1128 leaf mfg-date { 1129 type yang:date-and-time; 1130 description 1131 "The date of manufacturing of the managed component."; 1132 reference "RFC 6933: entPhysicalMfgDate"; 1133 } 1135 leaf-list uri { 1136 type inet:uri; 1137 description 1138 "This node contains identification information about the 1139 component. 1141 If uris have been configured for this component in 1142 /hardware/component/uri, this node contains the configured 1143 values."; 1144 reference "RFC 6933: entPhysicalUris"; 1145 } 1147 leaf uuid { 1148 type yang:uuid; 1149 description 1150 "A Universally Unique Identifier of the component."; 1151 reference "RFC 6933: entPhysicalUUID"; 1152 } 1154 container state { 1155 if-feature hardware-state; 1156 description 1157 "State-related nodes"; 1158 reference "RFC 4268: Entity State MIB"; 1160 leaf state-last-changed { 1161 type yang:date-and-time; 1162 description 1163 "The date and time when the value of any of the 1164 admin-state, oper-state, usage-state, alarm-status, or 1165 standby-status changed for this component. 1167 If there has been no change since the last 1168 re-initialization of the local system, this node 1169 contains the date and time of local system 1170 initialization. If there has been no change since the 1171 component was added to the local system, this node 1172 contains the date and time of the insertion."; 1173 reference "RFC 4268: entStateLastChanged"; 1174 } 1176 leaf admin-state { 1177 type admin-state; 1178 description 1179 "The administrative state for this component. 1181 This node refers to a component's administrative 1182 permission to service both other components within its 1183 containment hierarchy as well other users of its 1184 services defined by means outside the scope of this 1185 module. 1187 Some components exhibit only a subset of the remaining 1188 administrative state values. Some components cannot be 1189 locked, and hence this node exhibits only the 'unlocked' 1190 state. Other components cannot be shutdown gracefully, 1191 and hence this node does not exhibit the 'shutting-down' 1192 state."; 1193 reference "RFC 4268: entStateAdmin"; 1194 } 1196 leaf oper-state { 1197 type oper-state; 1198 description 1199 "The operational state for this component. 1201 Note that this node does not follow the administrative 1202 state. An administrative state of down does not predict 1203 an operational state of disabled. 1205 Note that some implementations may not be able to 1206 accurately report oper-state while the admin-state node 1207 has a value other than 'unlocked'. In these cases, this 1208 node MUST have a value of 'unknown'."; 1209 reference "RFC 4268: entStateOper"; 1210 } 1212 leaf usage-state { 1213 type usage-state; 1214 description 1215 "The usage state for this component. 1217 This node refers to a component's ability to service 1218 more components in a containment hierarchy. 1220 Some components will exhibit only a subset of the usage 1221 state values. Components that are unable to ever 1222 service any components within a containment hierarchy 1223 will always have a usage state of 'busy'. Some 1224 components will only ever be able to support one 1225 component within its containment hierarchy and will 1226 therefore only exhibit values of 'idle' and 'busy'."; 1227 reference "RFC 4268, entStateUsage"; 1228 } 1230 leaf alarm-status { 1231 type alarm-status; 1232 description 1233 "The alarm status for this component. It does not 1234 include the alarms raised on child components within its 1235 containment hierarchy."; 1236 reference "RFC 4268: entStateAlarm"; 1237 } 1239 leaf standby-status { 1240 type standby-status; 1241 description 1242 "The standby status for this component. 1244 Some components will exhibit only a subset of the 1245 remaining standby state values. If this component 1246 cannot operate in a standby role, the value of this node 1247 will always be 'providing-service'."; 1248 reference "RFC 4268: entStateStandby"; 1249 } 1250 } 1252 container sensor-data { 1253 when 'derived-from-or-self(../class, 1254 "ianahw:sensor")' { 1255 description 1256 "Sensor data nodes present for any component of type 1257 'sensor'"; 1258 } 1259 if-feature hardware-sensor; 1260 description 1261 "Sensor-related nodes."; 1262 reference "RFC 3433: Entity Sensor MIB"; 1264 leaf data-type { 1265 type sensor-data-type; 1266 description 1267 "The type of data units associated with the 1268 sensor value"; 1269 reference "RFC 3433: entPhySensorType"; 1270 } 1272 leaf data-scale { 1273 type sensor-data-scale; 1274 description 1275 "The (power of 10) scaling factor associated 1276 with the sensor value"; 1277 reference "RFC 3433: entPhySensorScale"; 1278 } 1280 leaf precision { 1281 type sensor-precision; 1282 description 1283 "The number of decimal places of precision 1284 associated with the sensor value"; 1285 reference "RFC 3433: entPhySensorPrecision"; 1286 } 1288 leaf value { 1289 type sensor-value; 1290 description 1291 "The most recent measurement obtained by the server 1292 for this sensor."; 1293 reference "RFC 3433: entPhySensorValue"; 1294 } 1296 leaf oper-status { 1297 type sensor-status; 1298 description 1299 "The operational status of the sensor."; 1300 reference "RFC 3433: entPhySensorOperStatus"; 1301 } 1303 leaf sensor-units-display { 1304 type string; 1305 description 1306 "A textual description of the data units that should be 1307 used in the display of the sensor value."; 1308 reference "RFC 3433: entPhySensorUnitsDisplay"; 1309 } 1311 leaf value-timestamp { 1312 type yang:date-and-time; 1313 description 1314 "The time the status and/or value of this sensor was last 1315 obtained by the server."; 1316 reference "RFC 3433: entPhySensorValueTimeStamp"; 1317 } 1319 leaf value-update-rate { 1320 type uint32; 1321 units "milliseconds"; 1322 description 1323 "An indication of the frequency that the server updates 1324 the associated 'value' node, representing in 1325 milliseconds. The value zero indicates: 1327 - the sensor value is updated on demand (e.g., 1328 when polled by the server for a get-request), 1329 - the sensor value is updated when the sensor 1330 value changes (event-driven), 1332 - the server does not know the update rate."; 1333 reference "RFC 3433: entPhySensorValueUpdateRate"; 1334 } 1335 } 1336 } 1337 } 1339 /* 1340 * Configuration data nodes 1341 */ 1343 container hardware { 1344 if-feature hardware-config; 1345 description 1346 "Configuration parameters for components."; 1348 list component { 1349 key name; 1350 description 1351 "List of configuration data for components. 1353 See the description of /hardware-state/component for 1354 information on how this list is used by a server."; 1356 leaf name { 1357 type string; 1358 description 1359 "Administrative name for this component. No restrictions 1360 apply."; 1361 } 1363 leaf class { 1364 type identityref { 1365 base ianahw:hardware-class; 1366 } 1367 mandatory true; 1368 description 1369 "An indication of the general hardware type of the 1370 component."; 1371 reference "RFC 6933: entPhysicalClass"; 1372 } 1374 leaf parent { 1375 type string; 1376 description 1377 "The name of the component that contains this component."; 1378 reference "RFC 6933: entPhysicalContainedIn"; 1379 } 1380 leaf parent-rel-pos { 1381 type int32 { 1382 range "0 .. 2147483647"; 1383 } 1384 description 1385 "An indication of the relative position of this child 1386 component among all its sibling components. Sibling 1387 components are defined as components that share the same 1388 instance values of each of the 'parent' and 'class' 1389 nodes."; 1390 reference "RFC 6933: entPhysicalParentRelPos"; 1391 } 1393 leaf mfg-name { 1394 type string; 1395 description 1396 "The name of the manufacturer of this physical component."; 1397 reference "RFC 6933: entPhysicalMfgName"; 1398 } 1400 leaf serial-num { 1401 type string; 1402 description 1403 "The vendor-specific serial number string for the 1404 component. The preferred value is the serial number 1405 string actually printed on the component itself (if 1406 present). 1408 This node is indented to be used for components for which 1409 the server cannot determine the serial number."; 1410 reference "RFC 6933: entPhysicalSerialNum"; 1411 } 1413 leaf alias { 1414 type string; 1415 description 1416 "This node is an 'alias' name for the component, as 1417 specified by a network manager, and provides a non- 1418 volatile 'handle' for the component. 1420 A server implementation MAY map this leaf to the 1421 entPhysicalAlias MIB object. Such an implementation needs 1422 to use some mechanism to handle the differences in size 1423 and characters allowed between this leaf and 1424 entPhysicalAlias. The definition of such a mechanism is 1425 outside the scope of this document."; 1426 reference "RFC 6933: entPhysicalAlias"; 1427 } 1428 leaf asset-id { 1429 type string; 1430 description 1431 "This node is a user-assigned asset tracking identifier (as 1432 specified by a network manager) for the component. 1434 A server implementation MAY map this leaf to the 1435 entPhysicalAssetID MIB object. Such an implementation 1436 needs to use some mechanism to handle the differences in 1437 size and characters allowed between this leaf and 1438 entPhysicalAssetID. The definition of such a mechanism is 1439 outside the scope of this document."; 1440 reference "RFC 6933: entPhysicalAssetID"; 1441 } 1443 leaf-list uri { 1444 type inet:uri; 1445 description 1446 "This node contains identification information about the 1447 component."; 1448 reference "RFC 6933: entPhysicalUris"; 1449 } 1451 leaf admin-state { 1452 if-feature hardware-state; 1453 type admin-state; 1454 description 1455 "The administrative state for this component. 1457 This node refers to a component's administrative 1458 permission to service both other components within its 1459 containment hierarchy as well other users of its services 1460 defined by means outside the scope of this module. 1462 Some components exhibit only a subset of the remaining 1463 administrative state values. Some components cannot be 1464 locked, and hence this node exhibits only the 'unlocked' 1465 state. Other components cannot be shutdown gracefully, 1466 and hence this node does not exhibit the 'shutting-down' 1467 state."; 1468 reference "RFC 4268, entStateAdmin"; 1469 } 1470 } 1471 } 1473 /* 1474 * Notifications 1475 */ 1477 notification harwdare-state-change { 1478 description 1479 "A hardware-state-change notification is generated when the 1480 value of /hardware-state/last-change changes."; 1481 reference "RFC 6933, entConfigChange"; 1482 } 1484 notification hardware-state-oper-enabled { 1485 if-feature hardware-state; 1486 description 1487 "A hardware-state-oper-enabled notification signifies that a 1488 component has transitioned into the 'enabled' state."; 1490 leaf name { 1491 type leafref { 1492 path "/hardware-state/component/name"; 1493 } 1494 description 1495 "The name of the component that has transitioned into the 1496 'enabled' state."; 1497 } 1498 leaf admin-state { 1499 type leafref { 1500 path "/hardware-state/component/state/admin-state"; 1501 } 1502 description 1503 "The administrative state for the component."; 1504 } 1505 leaf alarm-status { 1506 type leafref { 1507 path "/hardware-state/component/state/alarm-status"; 1508 } 1509 description 1510 "The alarm status for the component."; 1511 } 1512 reference "RFC 4268, entStateOperEnabled"; 1513 } 1515 notification hardware-state-oper-disabled { 1516 if-feature hardware-state; 1517 description 1518 "A hardware-state-oper-disabled notification signifies that a 1519 component has transitioned into the 'disabled' state."; 1521 leaf name { 1522 type leafref { 1523 path "/hardware-state/component/name"; 1524 } 1525 description 1526 "The name of the component that has transitioned into the 1527 'disabled' state."; 1528 } 1529 leaf admin-state { 1530 type leafref { 1531 path "/hardware-state/component/state/admin-state"; 1532 } 1533 description 1534 "The administrative state for the component."; 1535 } 1536 leaf alarm-status { 1537 type leafref { 1538 path "/hardware-state/component/state/alarm-status"; 1539 } 1540 description 1541 "The alarm status for the component."; 1542 } 1543 reference "RFC 4268, entStateOperDisabled"; 1544 } 1546 } 1548 1550 file "iana-hardware@2017-01-18.yang" 1552 module iana-hardware { 1553 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1554 prefix ianahw; 1556 organization "IANA"; 1557 contact 1558 " Internet Assigned Numbers Authority 1560 Postal: ICANN 1561 4676 Admiralty Way, Suite 330 1562 Marina del Rey, CA 90292 1564 Tel: +1 310 823 9358 1565 "; 1567 description 1568 "IANA defined identities for hardware class."; 1569 reference 1570 "https://www.iana.org/assignments/ianaentity-mib/ianaentity-mib"; 1572 // RFC Ed.: replace XXXX with actual RFC number and remove this 1573 // note. 1575 // RFC Ed.: update the date below with the date of RFC publication 1576 // and remove this note. 1577 revision 2017-01-18 { 1578 description 1579 "Initial revision."; 1580 reference 1581 "RFC XXXX: A YANG Data Model for Hardware Management"; 1582 } 1584 /* 1585 * Identities 1586 */ 1588 identity hardware-class { 1589 description 1590 "This identity is the base for all hardware class 1591 identifiers."; 1592 } 1594 identity unknown { 1595 base ianahw:hardware-class; 1596 description 1597 "This identity is applicable if the hardware class is unknown 1598 to the server."; 1599 } 1601 identity chassis { 1602 base ianahw:hardware-class; 1603 description 1604 "This identity is applicable if the hardware class is an 1605 overall container for networking equipment. Any class of 1606 physical component, except a stack, may be contained within a 1607 chassis; a chassis may only be contained within a stack."; 1608 } 1610 identity backplane { 1611 base ianahw:hardware-class; 1612 description 1613 "This identity is applicable if the hardware class is some sort 1614 of device for aggregating and forwarding networking traffic, 1615 such as a shared backplane in a modular ethernet switch. Note 1616 that an implementation may model a backplane as a single 1617 physical component, which is actually implemented as multiple 1618 discrete physical components (within a chassis or stack)."; 1620 } 1622 identity container { 1623 base ianahw:hardware-class; 1624 description 1625 "This identity is applicable if the hardware class is capable 1626 of containing one or more removable physical entities, 1627 possibly of different types. For example, each (empty or 1628 full) slot in a chassis will be modeled as a container. Note 1629 that all removable physical components should be modeled 1630 within a container component, such as field-replaceable 1631 modules, fans, or power supplies. Note that all known 1632 containers should be modeled by the agent, including empty 1633 containers."; 1634 } 1636 identity power-supply { 1637 base ianahw:hardware-class; 1638 description 1639 "This identity is applicable if the hardware class is a 1640 power-supplying component."; 1641 } 1643 identity fan { 1644 base ianahw:hardware-class; 1645 description 1646 "This identity is applicable if the hardware class is a fan or 1647 other heat-reduction component."; 1648 } 1650 identity sensor { 1651 base ianahw:hardware-class; 1652 description 1653 "This identity is applicable if the hardware class is some sort 1654 of sensor, such as a temperature sensor within a router 1655 chassis."; 1656 } 1658 identity module { 1659 base ianahw:hardware-class; 1660 description 1661 "This identity is applicable if the hardware class is some sort 1662 of self-contained sub-system. If a module component is 1663 removable, then it should be modeled within a container 1664 component; otherwise, it should be modeled directly within 1665 another physical component (e.g., a chassis or another 1666 module)."; 1667 } 1668 identity port { 1669 base ianahw:hardware-class; 1670 description 1671 "This identity is applicable if the hardware class is some sort 1672 of networking port, capable of receiving and/or transmitting 1673 networking traffic."; 1674 } 1676 identity stack { 1677 base ianahw:hardware-class; 1678 description 1679 "This identity is applicable if the hardware class is some sort 1680 of super-container (possibly virtual) intended to group 1681 together multiple chassis entities. A stack may be realized 1682 by a virtual cable, a real interconnect cable attached to 1683 multiple chassis, or multiple interconnect cables. A stack 1684 should not be modeled within any other physical components, 1685 but a stack may be contained within another stack. Only 1686 chassis components should be contained within a stack."; 1687 } 1689 identity cpu { 1690 base ianahw:hardware-class; 1691 description 1692 "This identity is applicable if the hardware class is some sort 1693 of central processing unit."; 1694 } 1696 identity energy-object { 1697 base ianahw:hardware-class; 1698 description 1699 "This identity is applicable if the hardware class is some sort 1700 of energy object, i.e., a piece of equipment that is part of 1701 or attached to a communications network that is monitored, 1702 controlled, or aids in the management of another device for 1703 Energy Management."; 1704 } 1706 identity battery { 1707 base ianahw:hardware-class; 1708 description 1709 "This identity is applicable if the hardware class is some sort 1710 of battery."; 1711 } 1713 identity storage-drive { 1714 base ianahw:hardware-class; 1715 description 1716 "This identity is applicable if the hardware class is some sort 1717 of component with data storage capability as main 1718 functionality, e.g., disk drive (HDD), solid state device 1719 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1720 } 1721 } 1723 1725 8. IANA Considerations 1727 This document registers two URIs in the IETF XML registry [RFC3688]. 1728 Following the format in RFC 3688, the following registrations are 1729 requested to be made. 1731 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1732 Registrant Contact: The IESG. 1733 XML: N/A, the requested URI is an XML namespace. 1735 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1736 Registrant Contact: The IESG. 1737 XML: N/A, the requested URI is an XML namespace. 1739 This document registers two YANG modules in the YANG Module Names 1740 registry [RFC6020]. 1742 name: iana-hardware 1743 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1744 prefix: ianahw 1745 reference: RFC XXXX 1747 name: ietf-hardware 1748 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1749 prefix: hw 1750 reference: RFC XXXX 1752 9. Security Considerations 1754 The YANG module defined in this memo is designed to be accessed via 1755 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1756 secure transport layer, and the mandatory-to-implement secure 1757 transport is Secure Shell (SSH) [RFC6242]. The NETCONF access 1758 control model [RFC6536] provides the means to restrict access for 1759 particular NETCONF users to a pre-configured subset of all available 1760 NETCONF protocol operations and content. 1762 There are a number of data nodes defined in this YANG module that are 1763 writable/creatable/deletable (i.e., config true, which is the 1764 default). These data nodes may be considered sensitive or vulnerable 1765 in some network environments. Write operations (e.g., edit-config) 1766 to these data nodes without proper protection can have a negative 1767 effect on network operations. These are the subtrees and data nodes 1768 and their sensitivity/vulnerability: 1770 /hardware/component/admin-state: Setting this node to 'locked' or 1771 'shutting-down' can cause disruption of services ranging from 1772 those running on a port to those on an entire device, depending on 1773 the type of component. 1775 Some of the readable data nodes in this YANG module may be considered 1776 sensitive or vulnerable in some network environments. It is thus 1777 important to control read access (e.g., via get, get-config, or 1778 notification) to these data nodes. These are the subtrees and data 1779 nodes and their sensitivity/vulnerability: 1781 /hardware-state/component: The leafs in this list expose information 1782 about the physical components in a device, which may be used to 1783 identify the vendor, model, version, and specific device- 1784 identification information of each system component. 1786 /hardware-state/component/sensor-data/value: This node may expose 1787 the values of particular physical sensors in a device. 1789 /hardware-state/component/state: Access to this node allows one to 1790 figure out what the active and standby resources in a device are. 1792 10. Acknowledgments 1794 The authors wish to thank the following individuals, who all provided 1795 helpful comments on various draft versions of this document: Bart 1796 Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder. 1798 11. Normative References 1800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1801 Requirement Levels", BCP 14, RFC 2119, 1802 DOI 10.17487/RFC2119, March 1997, 1803 . 1805 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1806 Management Information Base", RFC 3433, 1807 DOI 10.17487/RFC3433, December 2002, 1808 . 1810 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1811 DOI 10.17487/RFC3688, January 2004, 1812 . 1814 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1815 DOI 10.17487/RFC4268, November 2005, 1816 . 1818 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1819 the Network Configuration Protocol (NETCONF)", RFC 6020, 1820 DOI 10.17487/RFC6020, October 2010, 1821 . 1823 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1824 and A. Bierman, Ed., "Network Configuration Protocol 1825 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1826 . 1828 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1829 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1830 . 1832 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1833 Protocol (NETCONF) Access Control Model", RFC 6536, 1834 DOI 10.17487/RFC6536, March 2012, 1835 . 1837 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1838 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1839 DOI 10.17487/RFC6933, May 2013, 1840 . 1842 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1843 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1844 . 1846 Authors' Addresses 1848 Andy Bierman 1849 YumaWorks 1851 Email: andy@yumaworks.com 1853 Martin Bjorklund 1854 Tail-f Systems 1856 Email: mbj@tail-f.com 1857 Jie Dong 1858 Huawei Technologies 1860 Email: jie.dong@huawei.com 1862 Dan Romascanu 1864 Email: dromasca@gmail.com