idnits 2.17.1 draft-ietf-netmod-entity-03.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 (March 13, 2017) is 2600 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: September 14, 2017 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 9 March 13, 2017 11 A YANG Data Model for Hardware Management 12 draft-ietf-netmod-entity-03 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 September 14, 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 . . . . . . . . . . . . . . . . . . . 38 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 39 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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-state? alarm-state 161 | | +--ro standby-state? standby-state 162 | +--ro sensor-data {hardware-sensor}? 163 | +--ro value? sensor-value 164 | +--ro value-type? sensor-value-type 165 | +--ro value-scale? sensor-value-scale 166 | +--ro value-precision? sensor-value-precision 167 | +--ro oper-status? sensor-status 168 | +--ro 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? -> /hardware-state/component/name 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 hardware-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-state? 191 | -> /hardware-state/component/state/alarm-state 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-state? 197 -> /hardware-state/component/state/alarm-state 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 | value | entPhySensorValue | 280 | value-type | entPhySensorType | 281 | value-scale | entPhySensorScale | 282 | value-precision | entPhySensorPrecision | 283 | oper-status | entPhySensorOperStatus | 284 | 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-state | entStateAlarm | 306 | standby-state | entStateStandby | 307 +--------------------------------------------+----------------------+ 309 YANG data nodes and related ENTITY-SENSOR-MIB objects 311 7. Hardware YANG Module 313 file "ietf-hardware@2017-03-07.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-03-07 { 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-state { 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 states. 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-state { 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 states."; 591 reference "RFC 4268: EntityStandbyStatus"; 592 } 594 typedef sensor-value-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-value-scale node. 663 A node of this type SHOULD be defined together with nodes of 664 type sensor-value-scale and sensor-value-precision. These 665 three types are used to identify the semantics of a node of 666 type sensor-value."; 667 reference "RFC 3433: EntitySensorDataType"; 668 } 670 typedef sensor-value-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-value-type. 764 A node of this type SHOULD be defined together with nodes of 765 type sensor-value-type and sensor-value-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-value-precision { 772 type int32 { 773 range "-8 .. 9"; 774 } 775 description 776 "A node using this data type represents a sensor value 777 precision range. 779 A node of this type SHOULD be defined together with nodes of 780 type sensor-value-type and sensor-value-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-value-precision node so that the precision and accuracy 797 of 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 802 sensor-value-precision value of '1', an sensor-value-scale 803 value of 'units', and an sensor-value ranging from '0' to 804 '1000'. The sensor-value would be interpreted as 805 'degrees C * 10'."; 806 reference "RFC 3433: EntitySensorPrecision"; 807 } 809 typedef sensor-value { 810 type int32 { 811 range "-1000000000 .. 1000000000"; 812 } 813 description 814 "A node using this data type represents an sensor value. 816 A node of this type SHOULD be defined together with nodes of 817 type sensor-value-type, sensor-value-scale, and 818 sensor-value-precision. Together, associated nodes of those 819 three types are used to identify the semantics of a node of 820 this data type. 822 The semantics of a node using this data type are determined by 823 the value of the associated sensor-value-type node. 825 If the associated sensor-value-type node is equal to 'voltsAC', 826 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 827 then a node of this type MUST contain a fixed point number 828 ranging from -999,999,999 to +999,999,999. The value 829 -1000000000 indicates an underflow error. The value +1000000000 830 indicates an overflow error. The sensor-value-precision 831 indicates how many fractional digits are represented in the 832 associated sensor-value node. 834 If the associated sensor-value-type node is equal to 835 'percentRH', then a node of this type MUST contain a number 836 ranging from 0 to 100. 838 If the associated sensor-value-type node is equal to 'rpm', 839 then a node of this type MUST contain a number ranging from 840 -999,999,999 to +999,999,999. 842 If the associated sensor-value-type node is equal to 843 'truth-value', then a node of this type MUST contain either the 844 value 1 (true) or the value 2 (false)'. 846 If the associated sensor-value-type node is equal to 'other' or 847 unknown', then a node of this type MUST contain a number 848 ranging from -1000000000 to 1000000000."; 849 reference "RFC 3433: EntitySensorValue"; 850 } 851 typedef sensor-status { 852 type enumeration { 853 enum ok { 854 value 1; 855 description 856 "Indicates that the server can obtain the sensor value."; 857 } 858 enum unavailable { 859 value 2; 860 description 861 "Indicates that the server presently cannot obtain the 862 sensor value."; 863 } 864 enum nonoperational { 865 value 3; 866 description 867 "Indicates that the server believes the sensor is broken. 868 The sensor could have a hard failure (disconnected wire), 869 or a soft failure such as out-of-range, jittery, or wildly 870 fluctuating readings."; 871 } 872 } 873 description 874 "A node using this data type represents the operational status 875 of a physical sensor."; 876 reference "RFC 3433: EntitySensorStatus"; 877 } 879 /* 880 * Operational state data nodes 881 */ 883 container hardware-state { 884 config false; 885 description 886 "Data nodes for the operational state of components."; 888 leaf last-change { 889 type yang:date-and-time; 890 description 891 "The time the '/hardware-state/component' list changed."; 892 } 894 list component { 895 key name; 896 description 897 "List of components. 899 When the server detects a new hardware component, it 900 initializes an entry in this list. 902 If the server does not support the feature 903 'hardware-config', the entry is initialized with values for 904 all nodes as detected by the implementation. 906 Otherwise, the following procedure is followed: 908 1. If there is an entry in the /hardware/component list 909 with values for the nodes 'class', 'parent', 910 'parent-rel-pos' that are equal to the detected values, 911 then: 913 1a. If the configured entry has a value for 'mfg-name' 914 that is equal to the detected value, or if the 915 'mfg-name' value cannot be detected, then the entry is 916 initialized with the configured values for all 917 configured leafs, including the 'name'. 919 Otherwise, the entry is initialized with values for 920 all nodes as detected by the implementation. The 921 implementation may raise an alarm that informs about 922 the 'mfg-name' mismatch condition. How this is done 923 is outside the scope of this document. 925 1b. Otherwise (i.e., there is no matching configuration 926 entry), the entry is initialized with values for all 927 nodes as detected by the implementation. 929 If the /hardware/component list is modified (i.e., someone 930 changed the configuration), then the system MUST behave as 931 if it re-initializes itself, and follow the procedure in 932 (1)."; 934 reference "RFC 6933: entPhysicalEntry"; 936 leaf name { 937 type string; 938 description 939 "The name assigned to this component. 941 This name is not required to be the same as 942 entPhysicalName."; 943 } 945 leaf class { 946 type identityref { 947 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-state, or 1165 standby-state 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-state { 1231 type alarm-state; 1232 description 1233 "The alarm state 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-state { 1240 type standby-state; 1241 description 1242 "The standby state 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 value { 1265 type sensor-value; 1266 description 1267 "The most recent measurement obtained by the server 1268 for this sensor. 1270 A client that periodically fetches this node should also 1271 fetch the nodes 'value-type', 'value-scale', and 1272 'value-precision', since they may change when the value 1273 is changed."; 1274 reference "RFC 3433: entPhySensorValue"; 1275 } 1277 leaf value-type { 1278 type sensor-value-type; 1279 description 1280 "The type of data units associated with the 1281 sensor value"; 1282 reference "RFC 3433: entPhySensorType"; 1284 } 1286 leaf value-scale { 1287 type sensor-value-scale; 1288 description 1289 "The (power of 10) scaling factor associated 1290 with the sensor value"; 1291 reference "RFC 3433: entPhySensorScale"; 1292 } 1294 leaf value-precision { 1295 type sensor-value-precision; 1296 description 1297 "The number of decimal places of precision 1298 associated with the sensor value"; 1299 reference "RFC 3433: entPhySensorPrecision"; 1300 } 1302 leaf oper-status { 1303 type sensor-status; 1304 description 1305 "The operational status of the sensor."; 1306 reference "RFC 3433: entPhySensorOperStatus"; 1307 } 1309 leaf units-display { 1310 type string; 1311 description 1312 "A textual description of the data units that should be 1313 used in the display of the sensor value."; 1314 reference "RFC 3433: entPhySensorUnitsDisplay"; 1315 } 1317 leaf value-timestamp { 1318 type yang:date-and-time; 1319 description 1320 "The time the status and/or value of this sensor was last 1321 obtained by the server."; 1322 reference "RFC 3433: entPhySensorValueTimeStamp"; 1323 } 1325 leaf value-update-rate { 1326 type uint32; 1327 units "milliseconds"; 1328 description 1329 "An indication of the frequency that the server updates 1330 the associated 'value' node, representing in 1331 milliseconds. The value zero indicates: 1333 - the sensor value is updated on demand (e.g., 1334 when polled by the server for a get-request), 1335 - the sensor value is updated when the sensor 1336 value changes (event-driven), 1337 - the server does not know the update rate."; 1338 reference "RFC 3433: entPhySensorValueUpdateRate"; 1339 } 1340 } 1341 } 1342 } 1344 /* 1345 * Configuration data nodes 1346 */ 1348 container hardware { 1349 if-feature hardware-config; 1350 description 1351 "Configuration parameters for components."; 1353 list component { 1354 key name; 1355 description 1356 "List of configuration data for components. 1358 See the description of /hardware-state/component for 1359 information on how this list is used by a server."; 1361 leaf name { 1362 type string; 1363 description 1364 "Administrative name for this component. No restrictions 1365 apply."; 1366 } 1368 leaf class { 1369 type identityref { 1370 base ianahw:hardware-class; 1371 } 1372 mandatory true; 1373 description 1374 "An indication of the general hardware type of the 1375 component."; 1376 reference "RFC 6933: entPhysicalClass"; 1377 } 1379 leaf parent { 1380 type leafref { 1381 path "/hardware-state/component/name"; 1382 require-instance false; 1383 } 1384 description 1385 "The name of the component that contains this component."; 1386 reference "RFC 6933: entPhysicalContainedIn"; 1387 } 1389 leaf parent-rel-pos { 1390 type int32 { 1391 range "0 .. 2147483647"; 1392 } 1393 description 1394 "An indication of the relative position of this child 1395 component among all its sibling components. Sibling 1396 components are defined as components that share the same 1397 instance values of each of the 'parent' and 'class' 1398 nodes."; 1399 reference "RFC 6933: entPhysicalParentRelPos"; 1400 } 1402 leaf mfg-name { 1403 type string; 1404 description 1405 "The name of the manufacturer of this physical component."; 1406 reference "RFC 6933: entPhysicalMfgName"; 1407 } 1409 leaf serial-num { 1410 type string; 1411 description 1412 "The vendor-specific serial number string for the 1413 component. The preferred value is the serial number 1414 string actually printed on the component itself (if 1415 present). 1417 This node is indented to be used for components for which 1418 the server cannot determine the serial number."; 1419 reference "RFC 6933: entPhysicalSerialNum"; 1420 } 1422 leaf alias { 1423 type string; 1424 description 1425 "This node is an 'alias' name for the component, as 1426 specified by a network manager, and provides a non- 1427 volatile 'handle' for the component. 1429 A server implementation MAY map this leaf to the 1430 entPhysicalAlias MIB object. Such an implementation needs 1431 to use some mechanism to handle the differences in size 1432 and characters allowed between this leaf and 1433 entPhysicalAlias. The definition of such a mechanism is 1434 outside the scope of this document."; 1435 reference "RFC 6933: entPhysicalAlias"; 1436 } 1438 leaf asset-id { 1439 type string; 1440 description 1441 "This node is a user-assigned asset tracking identifier (as 1442 specified by a network manager) for the component. 1444 A server implementation MAY map this leaf to the 1445 entPhysicalAssetID MIB object. Such an implementation 1446 needs to use some mechanism to handle the differences in 1447 size and characters allowed between this leaf and 1448 entPhysicalAssetID. The definition of such a mechanism is 1449 outside the scope of this document."; 1450 reference "RFC 6933: entPhysicalAssetID"; 1451 } 1453 leaf-list uri { 1454 type inet:uri; 1455 description 1456 "This node contains identification information about the 1457 component."; 1458 reference "RFC 6933: entPhysicalUris"; 1459 } 1461 leaf admin-state { 1462 if-feature hardware-state; 1463 type admin-state; 1464 description 1465 "The administrative state for this component. 1467 This node refers to a component's administrative 1468 permission to service both other components within its 1469 containment hierarchy as well other users of its services 1470 defined by means outside the scope of this module. 1472 Some components exhibit only a subset of the remaining 1473 administrative state values. Some components cannot be 1474 locked, and hence this node exhibits only the 'unlocked' 1475 state. Other components cannot be shutdown gracefully, 1476 and hence this node does not exhibit the 'shutting-down' 1477 state."; 1478 reference "RFC 4268, entStateAdmin"; 1479 } 1480 } 1481 } 1483 /* 1484 * Notifications 1485 */ 1487 notification hardware-state-change { 1488 description 1489 "A hardware-state-change notification is generated when the 1490 value of /hardware-state/last-change changes."; 1491 reference "RFC 6933, entConfigChange"; 1492 } 1494 notification hardware-state-oper-enabled { 1495 if-feature hardware-state; 1496 description 1497 "A hardware-state-oper-enabled notification signifies that a 1498 component has transitioned into the 'enabled' state."; 1500 leaf name { 1501 type leafref { 1502 path "/hardware-state/component/name"; 1503 } 1504 description 1505 "The name of the component that has transitioned into the 1506 'enabled' state."; 1507 } 1508 leaf admin-state { 1509 type leafref { 1510 path "/hardware-state/component/state/admin-state"; 1511 } 1512 description 1513 "The administrative state for the component."; 1514 } 1515 leaf alarm-state { 1516 type leafref { 1517 path "/hardware-state/component/state/alarm-state"; 1518 } 1519 description 1520 "The alarm state for the component."; 1521 } 1522 reference "RFC 4268, entStateOperEnabled"; 1523 } 1524 notification hardware-state-oper-disabled { 1525 if-feature hardware-state; 1526 description 1527 "A hardware-state-oper-disabled notification signifies that a 1528 component has transitioned into the 'disabled' state."; 1530 leaf name { 1531 type leafref { 1532 path "/hardware-state/component/name"; 1533 } 1534 description 1535 "The name of the component that has transitioned into the 1536 'disabled' state."; 1537 } 1538 leaf admin-state { 1539 type leafref { 1540 path "/hardware-state/component/state/admin-state"; 1541 } 1542 description 1543 "The administrative state for the component."; 1544 } 1545 leaf alarm-state { 1546 type leafref { 1547 path "/hardware-state/component/state/alarm-state"; 1548 } 1549 description 1550 "The alarm state for the component."; 1551 } 1552 reference "RFC 4268, entStateOperDisabled"; 1553 } 1555 } 1557 1559 file "iana-hardware@2017-03-07.yang" 1561 module iana-hardware { 1562 yang-version 1.1; 1563 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1564 prefix ianahw; 1566 organization "IANA"; 1567 contact 1568 " Internet Assigned Numbers Authority 1570 Postal: ICANN 1571 4676 Admiralty Way, Suite 330 1572 Marina del Rey, CA 90292 1574 Tel: +1 310 823 9358 1575 "; 1577 description 1578 "IANA defined identities for hardware class."; 1579 reference 1580 "https://www.iana.org/assignments/ianaentity-mib/ianaentity-mib"; 1582 // RFC Ed.: replace XXXX with actual RFC number and remove this 1583 // note. 1585 // RFC Ed.: update the date below with the date of RFC publication 1586 // and remove this note. 1587 revision 2017-03-07 { 1588 description 1589 "Initial revision."; 1590 reference 1591 "RFC XXXX: A YANG Data Model for Hardware Management"; 1592 } 1594 /* 1595 * Identities 1596 */ 1598 identity hardware-class { 1599 description 1600 "This identity is the base for all hardware class 1601 identifiers."; 1602 } 1604 identity unknown { 1605 base ianahw:hardware-class; 1606 description 1607 "This identity is applicable if the hardware class is unknown 1608 to the server."; 1609 } 1611 identity chassis { 1612 base ianahw:hardware-class; 1613 description 1614 "This identity is applicable if the hardware class is an 1615 overall container for networking equipment. Any class of 1616 physical component, except a stack, may be contained within a 1617 chassis; a chassis may only be contained within a stack."; 1618 } 1619 identity backplane { 1620 base ianahw:hardware-class; 1621 description 1622 "This identity is applicable if the hardware class is some sort 1623 of device for aggregating and forwarding networking traffic, 1624 such as a shared backplane in a modular ethernet switch. Note 1625 that an implementation may model a backplane as a single 1626 physical component, which is actually implemented as multiple 1627 discrete physical components (within a chassis or stack)."; 1628 } 1630 identity container { 1631 base ianahw:hardware-class; 1632 description 1633 "This identity is applicable if the hardware class is capable 1634 of containing one or more removable physical entities, 1635 possibly of different types. For example, each (empty or 1636 full) slot in a chassis will be modeled as a container. Note 1637 that all removable physical components should be modeled 1638 within a container component, such as field-replaceable 1639 modules, fans, or power supplies. Note that all known 1640 containers should be modeled by the agent, including empty 1641 containers."; 1642 } 1644 identity power-supply { 1645 base ianahw:hardware-class; 1646 description 1647 "This identity is applicable if the hardware class is a 1648 power-supplying component."; 1649 } 1651 identity fan { 1652 base ianahw:hardware-class; 1653 description 1654 "This identity is applicable if the hardware class is a fan or 1655 other heat-reduction component."; 1656 } 1658 identity sensor { 1659 base ianahw:hardware-class; 1660 description 1661 "This identity is applicable if the hardware class is some sort 1662 of sensor, such as a temperature sensor within a router 1663 chassis."; 1664 } 1666 identity module { 1667 base ianahw:hardware-class; 1668 description 1669 "This identity is applicable if the hardware class is some sort 1670 of self-contained sub-system. If a module component is 1671 removable, then it should be modeled within a container 1672 component; otherwise, it should be modeled directly within 1673 another physical component (e.g., a chassis or another 1674 module)."; 1675 } 1677 identity port { 1678 base ianahw:hardware-class; 1679 description 1680 "This identity is applicable if the hardware class is some sort 1681 of networking port, capable of receiving and/or transmitting 1682 networking traffic."; 1683 } 1685 identity stack { 1686 base ianahw:hardware-class; 1687 description 1688 "This identity is applicable if the hardware class is some sort 1689 of super-container (possibly virtual) intended to group 1690 together multiple chassis entities. A stack may be realized 1691 by a virtual cable, a real interconnect cable attached to 1692 multiple chassis, or multiple interconnect cables. A stack 1693 should not be modeled within any other physical components, 1694 but a stack may be contained within another stack. Only 1695 chassis components should be contained within a stack."; 1696 } 1698 identity cpu { 1699 base ianahw:hardware-class; 1700 description 1701 "This identity is applicable if the hardware class is some sort 1702 of central processing unit."; 1703 } 1705 identity energy-object { 1706 base ianahw:hardware-class; 1707 description 1708 "This identity is applicable if the hardware class is some sort 1709 of energy object, i.e., a piece of equipment that is part of 1710 or attached to a communications network that is monitored, 1711 controlled, or aids in the management of another device for 1712 Energy Management."; 1713 } 1714 identity battery { 1715 base ianahw:hardware-class; 1716 description 1717 "This identity is applicable if the hardware class is some sort 1718 of battery."; 1719 } 1721 identity storage-drive { 1722 base ianahw:hardware-class; 1723 description 1724 "This identity is applicable if the hardware class is some sort 1725 of component with data storage capability as main 1726 functionality, e.g., disk drive (HDD), solid state device 1727 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1728 } 1729 } 1731 1733 8. IANA Considerations 1735 This document registers two URIs in the IETF XML registry [RFC3688]. 1736 Following the format in RFC 3688, the following registrations are 1737 requested to be made. 1739 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1740 Registrant Contact: The IESG. 1741 XML: N/A, the requested URI is an XML namespace. 1743 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1744 Registrant Contact: The IESG. 1745 XML: N/A, the requested URI is an XML namespace. 1747 This document registers two YANG modules in the YANG Module Names 1748 registry [RFC6020]. 1750 name: iana-hardware 1751 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1752 prefix: ianahw 1753 reference: RFC XXXX 1755 name: ietf-hardware 1756 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1757 prefix: hw 1758 reference: RFC XXXX 1760 9. Security Considerations 1762 The YANG module defined in this memo is designed to be accessed via 1763 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1764 secure transport layer, and the mandatory-to-implement secure 1765 transport is Secure Shell (SSH) [RFC6242]. The NETCONF access 1766 control model [RFC6536] provides the means to restrict access for 1767 particular NETCONF users to a pre-configured subset of all available 1768 NETCONF protocol operations and content. 1770 There are a number of data nodes defined in this YANG module that are 1771 writable/creatable/deletable (i.e., config true, which is the 1772 default). These data nodes may be considered sensitive or vulnerable 1773 in some network environments. Write operations (e.g., edit-config) 1774 to these data nodes without proper protection can have a negative 1775 effect on network operations. These are the subtrees and data nodes 1776 and their sensitivity/vulnerability: 1778 /hardware/component/admin-state: Setting this node to 'locked' or 1779 'shutting-down' can cause disruption of services ranging from 1780 those running on a port to those on an entire device, depending on 1781 the type of component. 1783 Some of the readable data nodes in this YANG module may be considered 1784 sensitive or vulnerable in some network environments. It is thus 1785 important to control read access (e.g., via get, get-config, or 1786 notification) to these data nodes. These are the subtrees and data 1787 nodes and their sensitivity/vulnerability: 1789 /hardware-state/component: The leafs in this list expose information 1790 about the physical components in a device, which may be used to 1791 identify the vendor, model, version, and specific device- 1792 identification information of each system component. 1794 /hardware-state/component/sensor-data/value: This node may expose 1795 the values of particular physical sensors in a device. 1797 /hardware-state/component/state: Access to this node allows one to 1798 figure out what the active and standby resources in a device are. 1800 10. Acknowledgments 1802 The authors wish to thank the following individuals, who all provided 1803 helpful comments on various draft versions of this document: Bart 1804 Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder. 1806 11. Normative References 1808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1809 Requirement Levels", BCP 14, RFC 2119, 1810 DOI 10.17487/RFC2119, March 1997, 1811 . 1813 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1814 Management Information Base", RFC 3433, 1815 DOI 10.17487/RFC3433, December 2002, 1816 . 1818 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1819 DOI 10.17487/RFC3688, January 2004, 1820 . 1822 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1823 DOI 10.17487/RFC4268, November 2005, 1824 . 1826 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1827 the Network Configuration Protocol (NETCONF)", RFC 6020, 1828 DOI 10.17487/RFC6020, October 2010, 1829 . 1831 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1832 and A. Bierman, Ed., "Network Configuration Protocol 1833 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1834 . 1836 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1837 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1838 . 1840 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1841 Protocol (NETCONF) Access Control Model", RFC 6536, 1842 DOI 10.17487/RFC6536, March 2012, 1843 . 1845 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1846 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1847 DOI 10.17487/RFC6933, May 2013, 1848 . 1850 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1851 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1852 . 1854 Authors' Addresses 1856 Andy Bierman 1857 YumaWorks 1859 Email: andy@yumaworks.com 1861 Martin Bjorklund 1862 Tail-f Systems 1864 Email: mbj@tail-f.com 1866 Jie Dong 1867 Huawei Technologies 1869 Email: jie.dong@huawei.com 1871 Dan Romascanu 1873 Email: dromasca@gmail.com