idnits 2.17.1 draft-ietf-netmod-entity-07.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 (December 21, 2017) is 2311 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) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-08 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-03 Summary: 2 errors (**), 0 flaws (~~), 4 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: June 24, 2018 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 10 December 21, 2017 12 A YANG Data Model for Hardware Management 13 draft-ietf-netmod-entity-07 15 Abstract 17 This document defines a YANG data model for the management of 18 hardware on a single server. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 24, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. The Components Lists . . . . . . . . . . . . . . . . . . 5 60 4. Relationship to ENTITY-MIB . . . . . . . . . . . . . . . . . 5 61 5. Relationship to ENTITY-SENSOR-MIB . . . . . . . . . . . . . . 6 62 6. Relationship to ENTITY-STATE-MIB . . . . . . . . . . . . . . 7 63 7. Hardware YANG Module . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 65 8.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 35 66 8.2. YANG Module Registrations . . . . . . . . . . . . . . . . 35 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 71 11.2. Informative References . . . . . . . . . . . . . . . . . 38 72 Appendix A. Hardware State Data Model . . . . . . . . . . . . . 39 73 A.1. Hardware State YANG Module . . . . . . . . . . . . . . . 40 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 76 1. Introduction 78 This document defines a YANG [RFC7950] data model for the management 79 of hardware on a single server. 81 The data model includes configuration and system state (status 82 information and counters for the collection of statistics). 84 The data model in this document is designed to be compliant with the 85 Network Management Datastore Architecture (NMDA) 86 [I-D.ietf-netmod-revised-datastores]. For implementations that do 87 not yet support NMDA, a temporary module with system state data only 88 is defined in Appendix A. 90 1.1. Terminology 92 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14, [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 The following terms are defined in 99 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 101 o client 103 o server 105 o configuration 107 o system state 109 o operational state 111 o intended configuration 113 1.2. Tree Diagrams 115 Tree diagrams used in this document follow the notation defined in 116 [I-D.ietf-netmod-yang-tree-diagrams]. 118 2. Objectives 120 This section describes some of the design objectives for the hardware 121 model. 123 o There are many common properties used to identify hardware 124 components, which need to be supported in the hardware data model. 126 o There are many important information and states about the 127 components, which needs to be collected from the devices which 128 support the hardware data model. 130 o The hardware data model should be suitable for new implementations 131 to use as is. 133 o The hardware data model defined in this document can be 134 implemented on a system that also implements ENTITY-MIB, thus the 135 mapping between the hardware data model and ENTITY-MIB should be 136 clear. 138 o The data model should support pre-provisioning of hardware 139 components. 141 3. Hardware Data Model 143 This document defines the YANG module "ietf-hardware", which has the 144 following structure: 146 module: ietf-hardware 147 +--rw hardware 148 +--ro last-change? yang:date-and-time 149 +--rw component* [name] 150 +--rw name string 151 +--rw class identityref 152 +--ro physical-index? int32 {entity-mib}? 153 +--ro description? string 154 +--rw parent? -> ../../component/name 155 +--rw parent-rel-pos? int32 156 +--ro contains-child* -> ../../component/name 157 +--ro hardware-rev? string 158 +--ro firmware-rev? string 159 +--ro software-rev? string 160 +--rw serial-num? string 161 +--rw mfg-name? string 162 +--rw model-name? string 163 +--rw alias? string 164 +--rw asset-id? string 165 +--ro is-fru? boolean 166 +--ro mfg-date? yang:date-and-time 167 +--rw uri* inet:uri 168 +--ro uuid? yang:uuid 169 +--rw state {hardware-state}? 170 | +--ro state-last-changed? yang:date-and-time 171 | +--rw admin-state? admin-state 172 | +--ro oper-state? oper-state 173 | +--ro usage-state? usage-state 174 | +--ro alarm-state? alarm-state 175 | +--ro standby-state? standby-state 176 +--ro sensor-data {hardware-sensor}? 177 +--ro value? sensor-value 178 +--ro value-type? sensor-value-type 179 +--ro value-scale? sensor-value-scale 180 +--ro value-precision? sensor-value-precision 181 +--ro oper-status? sensor-status 182 +--ro units-display? string 183 +--ro value-timestamp? yang:date-and-time 184 +--ro value-update-rate? uint32 186 notifications: 187 +---n hardware-state-change 188 +---n hardware-state-oper-enabled {hardware-state}? 189 | +--ro name? -> /hardware/component/name 190 | +--ro admin-state? -> /hardware/component/state/admin-state 191 | +--ro alarm-state? -> /hardware/component/state/alarm-state 192 +---n hardware-state-oper-disabled {hardware-state}? 193 +--ro name? -> /hardware/component/name 194 +--ro admin-state? -> /hardware/component/state/admin-state 195 +--ro alarm-state? -> /hardware/component/state/alarm-state 197 3.1. The Components Lists 199 The data model for hardware presented in this document uses a flat 200 list of components. Each component in the list is identified by its 201 name. Furthermore, each component has a mandatory "class" leaf. 203 The "iana-hardware" module defines YANG identities for the hardware 204 types in the IANA-maintained "IANA-ENTITY-MIB" registry. 206 The "class" leaf is a YANG identity that describes the type of the 207 hardware. Vendors are encouraged to either directly use one of the 208 common IANA-defined identities, or derive a more specific identity 209 from one of them. 211 4. Relationship to ENTITY-MIB 213 If the device implements the ENTITY-MIB [RFC6933], each entry in the 214 "/hardware-state/component" list is mapped to one EntPhysicalEntry. 215 Objects that are writable in the MIB are mapped to nodes in the 216 "/hardware/component" list. 218 The "physical-index" leaf MUST contain the value of the corresponding 219 entPhysicalEntry's entPhysicalIndex. 221 The "class" leaf is mapped to both entPhysicalClass and 222 entPhysicalVendorType. If the value of the "class" leaf is an 223 identity that is either derived from or is one of the identities in 224 the "iana-hardware" module, then entPhysicalClass contains the 225 corresponding IANAPhysicalClass enumeration value. Otherwise, 226 entPhysicalClass contains the IANAPhysicalClass value "other(1)". 227 Vendors are encouraged to define an identity (derived from an 228 identity in "iana-hardware" if possible) for each enterprise-specific 229 registration identifier used for entPhysicalVendorType, and use that 230 identity for the "class" leaf. 232 The following tables list the YANG data nodes with corresponding 233 objects in the ENTITY-MIB. 235 +--------------------------------+----------------------------------+ 236 | YANG data node in | ENTITY-MIB object | 237 | /hardware/component | | 238 +--------------------------------+----------------------------------+ 239 | name | entPhysicalName | 240 | class | entPhysicalClass | 241 | | entPhysicalVendorType | 242 | physical-index | entPhysicalIndex | 243 | description | entPhysicalDescr | 244 | parent | entPhysicalContainedIn | 245 | parent-rel-pos | entPhysicalParentRelPos | 246 | contains-child | entPhysicalChildIndex | 247 | hardware-rev | entPhysicalHardwareRev | 248 | firmware-rev | entPhysicalFirmwareRev | 249 | software-rev | entPhysicalSoftwareRev | 250 | serial-num | entPhysicalSerialNum | 251 | mfg-name | entPhysicalMfgName | 252 | model-name | entPhysicalModelName | 253 | alias | entPhysicalAlias | 254 | asset-id | entPhysicalAssetID | 255 | is-fru | entPhysicalIsFRU | 256 | mfg-date | entPhysicalMfgDate | 257 | uri | entPhysicalUris | 258 | uuid | entPhysicalUUID | 259 +--------------------------------+----------------------------------+ 261 YANG Data Nodes and Related ENTITY-MIB Objects 263 5. Relationship to ENTITY-SENSOR-MIB 265 If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry 266 in the "/hardware/component" list where the container "sensor-data" 267 exists is mapped to one EntPhySensorEntry. 269 +-------------------------------------+-----------------------------+ 270 | YANG data node in | ENTITY-SENSOR-MIB object | 271 | /hardware/component/sensor-data | | 272 +-------------------------------------+-----------------------------+ 273 | value | entPhySensorValue | 274 | value-type | entPhySensorType | 275 | value-scale | entPhySensorScale | 276 | value-precision | entPhySensorPrecision | 277 | oper-status | entPhySensorOperStatus | 278 | units-display | entPhySensorUnitsDisplay | 279 | value-timestamp | entPhySensorValueTimeStamp | 280 | value-update-rate | entPhySensorValueUpdateRate | 281 +-------------------------------------+-----------------------------+ 283 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 285 6. Relationship to ENTITY-STATE-MIB 287 If the device implements the ENTITY-STATE-MIB [RFC4268], each entry 288 in the "/hardware/component" list where the container "state" exists 289 is mapped to one EntStateEntry. 291 +------------------------------------------+------------------------+ 292 | YANG data node in | ENTITY-STATE-MIB | 293 | /hardware/component/state | object | 294 +------------------------------------------+------------------------+ 295 | state-last-changed | entStateLastChanged | 296 | admin-state | entStateAdmin | 297 | oper-state | entStateOper | 298 | usage-state | entStateUsage | 299 | alarm-state | entStateAlarm | 300 | standby-state | entStateStandby | 301 +------------------------------------------+------------------------+ 303 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 305 7. Hardware YANG Module 307 file "ietf-hardware@2017-12-18.yang" 309 module ietf-hardware { 310 yang-version 1.1; 311 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; 312 prefix hw; 314 import ietf-inet-types { 315 prefix inet; 316 } 317 import ietf-yang-types { 318 prefix yang; 319 } 320 import iana-hardware { 321 prefix ianahw; 322 } 324 organization 325 "IETF NETMOD (Network Modeling) Working Group"; 327 contact 328 "WG Web: 329 WG List: 331 Editor: Andy Bierman 332 334 Editor: Martin Bjorklund 335 337 Editor: Jie Dong 338 340 Editor: Dan Romascanu 341 "; 343 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 344 // remove this note. 346 description 347 "This module contains a collection of YANG definitions for 348 managing hardware. 350 This data model is designed for the Network Management Datastore 351 Architecture defined in RFC YYYY. 353 Copyright (c) 2017 IETF Trust and the persons identified as 354 authors of the code. All rights reserved. 356 Redistribution and use in source and binary forms, with or 357 without modification, is permitted pursuant to, and subject 358 to the license terms contained in, the Simplified BSD License 359 set forth in Section 4.c of the IETF Trust's Legal Provisions 360 Relating to IETF Documents 361 (http://trustee.ietf.org/license-info). 363 This version of this YANG module is part of RFC XXXX; see 364 the RFC itself for full legal notices."; 366 // RFC Ed.: update the date below with the date of RFC publication 367 // and remove this note. 368 revision 2017-12-18 { 369 description 370 "Initial revision."; 371 reference 372 "RFC XXXX: A YANG Data Model for Hardware Management"; 373 } 375 /* 376 * Features 377 */ 379 feature entity-mib { 380 description 381 "This feature indicates that the device implements 382 the ENTITY-MIB."; 383 reference "RFC 6933: Entity MIB (Version 4)"; 384 } 386 feature hardware-state { 387 description 388 "Indicates the ENTITY-STATE-MIB objects are supported"; 389 reference "RFC 4268: Entity State MIB"; 390 } 392 feature hardware-sensor { 393 description 394 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 395 reference "RFC 3433: Entity Sensor MIB"; 396 } 398 /* 399 * Typedefs 400 */ 402 typedef admin-state { 403 type enumeration { 404 enum unknown { 405 value 1; 406 description 407 "The resource is unable to report administrative state."; 408 } 409 enum locked { 410 value 2; 411 description 412 "The resource is administratively prohibited from use."; 413 } 414 enum shutting-down { 415 value 3; 416 description 417 "The resource usage is administratively limited to current 418 instances of use."; 419 } 420 enum unlocked { 421 value 4; 422 description 423 "The resource is not administratively prohibited from 424 use."; 425 } 426 } 427 description 428 "Represents the various possible administrative states."; 429 reference "RFC 4268: EntityAdminState"; 430 } 432 typedef oper-state { 433 type enumeration { 434 enum unknown { 435 value 1; 436 description 437 "The resource is unable to report its operational state."; 438 } 439 enum disabled { 440 value 2; 441 description 442 "The resource is totally inoperable."; 443 } 444 enum enabled { 445 value 3; 446 description 447 "The resource is partially or fully operable."; 448 } 449 enum testing { 450 value 4; 451 description 452 "The resource is currently being tested and cannot 453 therefore report whether it is operational or not."; 454 } 455 } 456 description 457 "Represents the possible values of operational states."; 458 reference "RFC 4268: EntityOperState"; 459 } 461 typedef usage-state { 462 type enumeration { 463 enum unknown { 464 value 1; 465 description 466 "The resource is unable to report usage state."; 467 } 468 enum idle { 469 value 2; 470 description 471 "The resource is servicing no users."; 472 } 473 enum active { 474 value 3; 475 description 476 "The resource is currently in use and it has sufficient 477 spare capacity to provide for additional users."; 478 } 479 enum busy { 480 value 4; 481 description 482 "The resource is currently in use, but it currently has no 483 spare capacity to provide for additional users."; 484 } 485 } 486 description 487 "Represents the possible values of usage states."; 488 reference "RFC 4268, EntityUsageState"; 489 } 491 typedef alarm-state { 492 type bits { 493 bit unknown { 494 position 0; 495 description 496 "The resource is unable to report alarm state."; 497 } 498 bit under-repair { 499 position 1; 500 description 501 "The resource is currently being repaired, which, depending 502 on the implementation, may make the other values in this 503 bit string not meaningful."; 504 } 505 bit critical { 506 position 2; 507 description 508 "One or more critical alarms are active against the 509 resource."; 511 } 512 bit major { 513 position 3; 514 description 515 "One or more major alarms are active against the 516 resource."; 517 } 518 bit minor { 519 position 4; 520 description 521 "One or more minor alarms are active against the 522 resource."; 523 } 524 bit warning { 525 position 5; 526 description 527 "One or more warning alarms are active against the 528 resource."; 529 } 530 bit indeterminate { 531 position 6; 532 description 533 "One or more alarms of whose perceived severity cannot be 534 determined are active against this resource."; 535 } 536 } 537 description 538 "Represents the possible values of alarm states. An alarm is a 539 persistent indication of an error or warning condition. 541 When no bits of this attribute are set, then no active alarms 542 are known against this component and it is not under repair."; 543 reference "RFC 4268: EntityAlarmStatus"; 544 } 546 typedef standby-state { 547 type enumeration { 548 enum unknown { 549 value 1; 550 description 551 "The resource is unable to report standby state."; 552 } 553 enum hot-standby { 554 value 2; 555 description 556 "The resource is not providing service, but it will be 557 immediately able to take over the role of the resource to 558 be backed up, without the need for initialization 559 activity, and will contain the same information as the 560 resource to be backed up."; 561 } 562 enum cold-standby { 563 value 3; 564 description 565 "The resource is to back up another resource, but will not 566 be immediately able to take over the role of a resource to 567 be backed up, and will require some initialization 568 activity."; 569 } 570 enum providing-service { 571 value 4; 572 description 573 "The resource is providing service."; 574 } 575 } 576 description 577 "Represents the possible values of standby states."; 578 reference "RFC 4268: EntityStandbyStatus"; 579 } 581 typedef sensor-value-type { 582 type enumeration { 583 enum other { 584 value 1; 585 description 586 "A measure other than those listed below."; 587 } 588 enum unknown { 589 value 2; 590 description 591 "An unknown measurement, or arbitrary, relative numbers"; 592 } 593 enum volts-AC { 594 value 3; 595 description 596 "A measure of electric potential (alternating current)."; 597 } 598 enum volts-DC { 599 value 4; 600 description 601 "A measure of electric potential (direct current)."; 602 } 603 enum amperes { 604 value 5; 605 description 606 "A measure of electric current."; 608 } 609 enum watts { 610 value 6; 611 description 612 "A measure of power."; 613 } 614 enum hertz { 615 value 7; 616 description 617 "A measure of frequency."; 618 } 619 enum celsius { 620 value 8; 621 description 622 "A measure of temperature."; 623 } 624 enum percent-RH { 625 value 9; 626 description 627 "A measure of percent relative humidity."; 628 } 629 enum rpm { 630 value 10; 631 description 632 "A measure of shaft revolutions per minute."; 633 } 634 enum cmm { 635 value 11; 636 description 637 "A measure of cubic meters per minute (airflow)."; 638 } 639 enum truth-value { 640 value 12; 641 description 642 "Value is one of 1 (true) or 2 (false)"; 643 } 644 } 645 description 646 "A node using this data type represents the sensor measurement 647 data type associated with a physical sensor value. The actual 648 data units are determined by examining a node of this type 649 together with the associated sensor-value-scale node. 651 A node of this type SHOULD be defined together with nodes of 652 type sensor-value-scale and sensor-value-precision. These 653 three types are used to identify the semantics of a node of 654 type sensor-value."; 655 reference "RFC 3433: EntitySensorDataType"; 657 } 659 typedef sensor-value-scale { 660 type enumeration { 661 enum yocto { 662 value 1; 663 description 664 "Data scaling factor of 10^-24."; 665 } 666 enum zepto { 667 value 2; 668 description 669 "Data scaling factor of 10^-21."; 670 } 671 enum atto { 672 value 3; 673 description 674 "Data scaling factor of 10^-18."; 675 } 676 enum femto { 677 value 4; 678 description 679 "Data scaling factor of 10^-15."; 680 } 681 enum pico { 682 value 5; 683 description 684 "Data scaling factor of 10^-12."; 685 } 686 enum nano { 687 value 6; 688 description 689 "Data scaling factor of 10^-9."; 690 } 691 enum micro { 692 value 7; 693 description 694 "Data scaling factor of 10^-6."; 695 } 696 enum milli { 697 value 8; 698 description 699 "Data scaling factor of 10^-3."; 700 } 701 enum units { 702 value 9; 703 description 704 "Data scaling factor of 10^0."; 706 } 707 enum kilo { 708 value 10; 709 description 710 "Data scaling factor of 10^3."; 711 } 712 enum mega { 713 value 11; 714 description 715 "Data scaling factor of 10^6."; 716 } 717 enum giga { 718 value 12; 719 description 720 "Data scaling factor of 10^9."; 721 } 722 enum tera { 723 value 13; 724 description 725 "Data scaling factor of 10^12."; 726 } 727 enum exa { 728 value 14; 729 description 730 "Data scaling factor of 10^15."; 731 } 732 enum peta { 733 value 15; 734 description 735 "Data scaling factor of 10^18."; 736 } 737 enum zetta { 738 value 16; 739 description 740 "Data scaling factor of 10^21."; 741 } 742 enum yotta { 743 value 17; 744 description 745 "Data scaling factor of 10^24."; 746 } 747 } 748 description 749 "A node using this data type represents a data scaling factor, 750 represented with an International System of Units (SI) prefix. 751 The actual data units are determined by examining a node of 752 this type together with the associated sensor-value-type. 754 A node of this type SHOULD be defined together with nodes of 755 type sensor-value-type and sensor-value-precision. Together, 756 associated nodes of these three types are used to identify the 757 semantics of a node of type sensor-value."; 758 reference "RFC 3433: EntitySensorDataScale"; 759 } 761 typedef sensor-value-precision { 762 type int32 { 763 range "-8 .. 9"; 764 } 765 description 766 "A node using this data type represents a sensor value 767 precision range. 769 A node of this type SHOULD be defined together with nodes of 770 type sensor-value-type and sensor-value-scale. Together, 771 associated nodes of these three types are used to identify the 772 semantics of a node of type sensor-value. 774 If a node of this type contains a value in the range 1 to 9, 775 it represents the number of decimal places in the fractional 776 part of an associated sensor-value fixed- point number. 778 If a node of this type contains a value in the range -8 to -1, 779 it represents the number of accurate digits in the associated 780 sensor-value fixed-point number. 782 The value zero indicates the associated sensor-value node is 783 not a fixed-point number. 785 Server implementers must choose a value for the associated 786 sensor-value-precision node so that the precision and accuracy 787 of the associated sensor-value node is correctly indicated. 789 For example, a component representing a temperature sensor 790 that can measure 0 degrees to 100 degrees C in 0.1 degree 791 increments, +/- 0.05 degrees, would have an 792 sensor-value-precision value of '1', an sensor-value-scale 793 value of 'units', and an sensor-value ranging from '0' to 794 '1000'. The sensor-value would be interpreted as 795 'degrees C * 10'."; 796 reference "RFC 3433: EntitySensorPrecision"; 797 } 799 typedef sensor-value { 800 type int32 { 801 range "-1000000000 .. 1000000000"; 803 } 804 description 805 "A node using this data type represents an sensor value. 807 A node of this type SHOULD be defined together with nodes of 808 type sensor-value-type, sensor-value-scale, and 809 sensor-value-precision. Together, associated nodes of those 810 three types are used to identify the semantics of a node of 811 this data type. 813 The semantics of a node using this data type are determined by 814 the value of the associated sensor-value-type node. 816 If the associated sensor-value-type node is equal to 'voltsAC', 817 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 818 then a node of this type MUST contain a fixed point number 819 ranging from -999,999,999 to +999,999,999. The value 820 -1000000000 indicates an underflow error. The value +1000000000 821 indicates an overflow error. The sensor-value-precision 822 indicates how many fractional digits are represented in the 823 associated sensor-value node. 825 If the associated sensor-value-type node is equal to 826 'percentRH', then a node of this type MUST contain a number 827 ranging from 0 to 100. 829 If the associated sensor-value-type node is equal to 'rpm', 830 then a node of this type MUST contain a number ranging from 831 -999,999,999 to +999,999,999. 833 If the associated sensor-value-type node is equal to 834 'truth-value', then a node of this type MUST contain either the 835 value 1 (true) or the value 2 (false)'. 837 If the associated sensor-value-type node is equal to 'other' or 838 unknown', then a node of this type MUST contain a number 839 ranging from -1000000000 to 1000000000."; 840 reference "RFC 3433: EntitySensorValue"; 841 } 843 typedef sensor-status { 844 type enumeration { 845 enum ok { 846 value 1; 847 description 848 "Indicates that the server can obtain the sensor value."; 849 } 850 enum unavailable { 851 value 2; 852 description 853 "Indicates that the server presently cannot obtain the 854 sensor value."; 855 } 856 enum nonoperational { 857 value 3; 858 description 859 "Indicates that the server believes the sensor is broken. 860 The sensor could have a hard failure (disconnected wire), 861 or a soft failure such as out-of-range, jittery, or wildly 862 fluctuating readings."; 863 } 864 } 865 description 866 "A node using this data type represents the operational status 867 of a physical sensor."; 868 reference "RFC 3433: EntitySensorStatus"; 869 } 871 /* 872 * Data nodes 873 */ 875 container hardware { 876 description 877 "Data nodes representing components. 879 If the server supports configuration of hardware components, 880 then this data model is instantiated in the configuration 881 datastores supported by the server. The leaf-list 'datastore' 882 for the module 'ietf-hardware' in the YANG library provides 883 this information."; 885 leaf last-change { 886 type yang:date-and-time; 887 config false; 888 description 889 "The time the '/hardware/component' list changed in the 890 operational state."; 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 a list entry in the operational state. 901 If the server does not support configuration of hardware 902 components, list entries in the operational state are 903 initialized with values for all nodes as detected by the 904 implementation. 906 Otherwise, the following procedure is followed: 908 1. If there is an entry in the /hardware/component list in 909 the intended configuration with values for the nodes 910 'class', 'parent', 'parent-rel-pos' that are equal to 911 the detected values, then the list entry in operational 912 state is initialized with the configured values, 913 including the 'name'. The leafs 'serial-num', 914 'mfg-name', and 'model-name' are treated specially; see 915 their descriptions for details. 917 2. Otherwise (i.e., there is no matching configuration 918 entry), the list entry in the operational state is 919 initialized with values for all nodes as detected by 920 the implementation. 922 If the /hardware/component list in the intended 923 configuration is modified, then the system MUST behave as if 924 it re-initializes itself, and follow the procedure in (1)."; 925 reference "RFC 6933: entPhysicalEntry"; 927 leaf name { 928 type string; 929 description 930 "The name assigned to this component. 932 This name is not required to be the same as 933 entPhysicalName."; 934 } 936 leaf class { 937 type identityref { 938 base ianahw:hardware-class; 939 } 940 mandatory true; 941 description 942 "An indication of the general hardware type of the 943 component."; 944 reference "RFC 6933: entPhysicalClass"; 945 } 946 leaf physical-index { 947 if-feature entity-mib; 948 type int32 { 949 range "1..2147483647"; 950 } 951 config false; 952 description 953 "The entPhysicalIndex for the entPhysicalEntry represented 954 by this list entry."; 955 reference "RFC 6933: entPhysicalIndex"; 956 } 958 leaf description { 959 type string; 960 config false; 961 description 962 "A textual description of component. This node should 963 contain a string that identifies the manufacturer's name 964 for the component and should be set to a distinct value 965 for each version or model of the component."; 966 reference "RFC 6933: entPhysicalDescr"; 967 } 969 leaf parent { 970 type leafref { 971 path "../../component/name"; 972 require-instance false; 973 } 974 description 975 "The name of the component that physically contains this 976 component. 978 If this leaf is not instantiated, it indicates that this 979 component is not contained in any other component. 981 In the event that a physical component is contained by 982 more than one physical component (e.g., double-wide 983 modules), this node contains the name of one of these 984 components. An implementation MUST use the same name 985 every time this node is instantiated."; 986 reference "RFC 6933: entPhysicalContainedIn"; 987 } 989 leaf parent-rel-pos { 990 type int32 { 991 range "0 .. 2147483647"; 992 } 993 description 994 "An indication of the relative position of this child 995 component among all its sibling components. Sibling 996 components are defined as components that: 998 o Share the same value of the 'parent' node; and 1000 o Share a common base identity for the 'class' node. 1002 Note that the last rule gives implementations flexibility 1003 in how components are numbered. For example, some 1004 implementations might have a single number series for all 1005 components derived from 'ianahw:port', while some others 1006 might have different number series for different 1007 components with identities derived from 'ianahw:port' (for 1008 example, one for RJ45 and one for SFP)."; 1010 reference "RFC 6933: entPhysicalParentRelPos"; 1011 } 1013 leaf-list contains-child { 1014 type leafref { 1015 path "../../component/name"; 1016 } 1017 config false; 1018 description 1019 "The name of the contained component."; 1020 reference "RFC 6933: entPhysicalChildIndex"; 1021 } 1023 leaf hardware-rev { 1024 type string; 1025 config false; 1026 description 1027 "The vendor-specific hardware revision string for the 1028 component. The preferred value is the hardware revision 1029 identifier actually printed on the component itself (if 1030 present)."; 1031 reference "RFC 6933: entPhysicalHardwareRev"; 1032 } 1034 leaf firmware-rev { 1035 type string; 1036 config false; 1037 description 1038 "The vendor-specific firmware revision string for the 1039 component."; 1040 reference "RFC 6933: entPhysicalFirmwareRev"; 1041 } 1042 leaf software-rev { 1043 type string; 1044 config false; 1045 description 1046 "The vendor-specific software revision string for the 1047 component."; 1048 reference "RFC 6933: entPhysicalSoftwareRev"; 1049 } 1051 leaf serial-num { 1052 type string; 1053 description 1054 "The vendor-specific serial number string for the 1055 component. The preferred value is the serial number 1056 string actually printed on the component itself (if 1057 present). 1059 This leaf can be configured. The configured value is used 1060 only if the server cannot determine the vendor-specific 1061 serial number from the component itself."; 1062 reference "RFC 6933: entPhysicalSerialNum"; 1063 } 1065 leaf mfg-name { 1066 type string; 1067 description 1068 "The name of the manufacturer of this physical component. 1069 The preferred value is the manufacturer name string 1070 actually printed on the component itself (if present). 1072 Note that comparisons between instances of the model-name, 1073 firmware-rev, software-rev, and the serial-num nodes are 1074 only meaningful amongst component with the same value of 1075 mfg-name. 1077 If the manufacturer name string associated with the 1078 physical component is unknown to the server, then this 1079 node is not instantiated. 1081 This leaf can be configured. The configured value is used 1082 only if the server cannot determine the vendor-specific 1083 serial number from the component itself."; 1084 reference "RFC 6933: entPhysicalMfgName"; 1085 } 1087 leaf model-name { 1088 type string; 1089 description 1090 "The vendor-specific model name identifier string 1091 associated with this physical component. The preferred 1092 value is the customer-visible part number, which may be 1093 printed on the component itself. 1095 If the model name string associated with the physical 1096 component is unknown to the server, then this node is not 1097 instantiated. 1099 This leaf can be configured. The configured value is used 1100 only if the server cannot determine the vendor-specific 1101 serial number from the component itself."; 1102 reference "RFC 6933: entPhysicalModelName"; 1103 } 1105 leaf alias { 1106 type string; 1107 description 1108 "An 'alias' name for the component, as specified by a 1109 network manager, and provides a non-volatile 'handle' for 1110 the component. 1112 If no configured value exists, the server MAY set the 1113 value of this node to a locally unique value in the 1114 operational state. 1116 A server implementation MAY map this leaf to the 1117 entPhysicalAlias MIB object. Such an implementation needs 1118 to use some mechanism to handle the differences in size 1119 and characters allowed between this leaf and 1120 entPhysicalAlias. The definition of such a mechanism is 1121 outside the scope of this document."; 1122 reference "RFC 6933: entPhysicalAlias"; 1123 } 1125 leaf asset-id { 1126 type string; 1127 description 1128 "This node is a user-assigned asset tracking identifier for 1129 the component. 1131 A server implementation MAY map this leaf to the 1132 entPhysicalAssetID MIB object. Such an implementation 1133 needs to use some mechanism to handle the differences in 1134 size and characters allowed between this leaf and 1135 entPhysicalAssetID. The definition of such a mechanism is 1136 outside the scope of this document."; 1137 reference "RFC 6933: entPhysicalAssetID"; 1139 } 1141 leaf is-fru { 1142 type boolean; 1143 config false; 1144 description 1145 "This node indicates whether or not this component is 1146 considered a 'field replaceable unit' by the vendor. If 1147 this node contains the value 'true', then this component 1148 identifies a field replaceable unit. For all components 1149 that are permanently contained within a field replaceable 1150 unit, the value 'false' should be returned for this 1151 node."; 1152 reference "RFC 6933: entPhysicalIsFRU"; 1153 } 1155 leaf mfg-date { 1156 type yang:date-and-time; 1157 config false; 1158 description 1159 "The date of manufacturing of the managed component."; 1160 reference "RFC 6933: entPhysicalMfgDate"; 1161 } 1163 leaf-list uri { 1164 type inet:uri; 1165 description 1166 "This node contains identification information about the 1167 component."; 1168 reference "RFC 6933: entPhysicalUris"; 1169 } 1171 leaf uuid { 1172 type yang:uuid; 1173 config false; 1174 description 1175 "A Universally Unique Identifier of the component."; 1176 reference "RFC 6933: entPhysicalUUID"; 1177 } 1179 container state { 1180 if-feature hardware-state; 1181 description 1182 "State-related nodes"; 1183 reference "RFC 4268: Entity State MIB"; 1185 leaf state-last-changed { 1186 type yang:date-and-time; 1187 config false; 1188 description 1189 "The date and time when the value of any of the 1190 admin-state, oper-state, usage-state, alarm-state, or 1191 standby-state changed for this component. 1193 If there has been no change since the last 1194 re-initialization of the local system, this node 1195 contains the date and time of local system 1196 initialization. If there has been no change since the 1197 component was added to the local system, this node 1198 contains the date and time of the insertion."; 1199 reference "RFC 4268: entStateLastChanged"; 1200 } 1202 leaf admin-state { 1203 type admin-state; 1204 description 1205 "The administrative state for this component. 1207 This node refers to a component's administrative 1208 permission to service both other components within its 1209 containment hierarchy as well other users of its 1210 services defined by means outside the scope of this 1211 module. 1213 Some components exhibit only a subset of the remaining 1214 administrative state values. Some components cannot be 1215 locked, and hence this node exhibits only the 'unlocked' 1216 state. Other components cannot be shutdown gracefully, 1217 and hence this node does not exhibit the 'shutting-down' 1218 state."; 1219 reference "RFC 4268: entStateAdmin"; 1220 } 1222 leaf oper-state { 1223 type oper-state; 1224 config false; 1225 description 1226 "The operational state for this component. 1228 Note that this node does not follow the administrative 1229 state. An administrative state of down does not predict 1230 an operational state of disabled. 1232 Note that some implementations may not be able to 1233 accurately report oper-state while the admin-state node 1234 has a value other than 'unlocked'. In these cases, this 1235 node MUST have a value of 'unknown'."; 1236 reference "RFC 4268: entStateOper"; 1237 } 1239 leaf usage-state { 1240 type usage-state; 1241 config false; 1242 description 1243 "The usage state for this component. 1245 This node refers to a component's ability to service 1246 more components in a containment hierarchy. 1248 Some components will exhibit only a subset of the usage 1249 state values. Components that are unable to ever 1250 service any components within a containment hierarchy 1251 will always have a usage state of 'busy'. Some 1252 components will only ever be able to support one 1253 component within its containment hierarchy and will 1254 therefore only exhibit values of 'idle' and 'busy'."; 1255 reference "RFC 4268, entStateUsage"; 1256 } 1258 leaf alarm-state { 1259 type alarm-state; 1260 config false; 1261 description 1262 "The alarm state for this component. It does not 1263 include the alarms raised on child components within its 1264 containment hierarchy."; 1265 reference "RFC 4268: entStateAlarm"; 1266 } 1268 leaf standby-state { 1269 type standby-state; 1270 config false; 1271 description 1272 "The standby state for this component. 1274 Some components will exhibit only a subset of the 1275 remaining standby state values. If this component 1276 cannot operate in a standby role, the value of this node 1277 will always be 'providing-service'."; 1278 reference "RFC 4268: entStateStandby"; 1279 } 1280 } 1282 container sensor-data { 1283 when 'derived-from-or-self(../class, 1284 "ianahw:sensor")' { 1285 description 1286 "Sensor data nodes present for any component of type 1287 'sensor'"; 1288 } 1289 if-feature hardware-sensor; 1290 config false; 1292 description 1293 "Sensor-related nodes."; 1294 reference "RFC 3433: Entity Sensor MIB"; 1296 leaf value { 1297 type sensor-value; 1298 description 1299 "The most recent measurement obtained by the server 1300 for this sensor. 1302 A client that periodically fetches this node should also 1303 fetch the nodes 'value-type', 'value-scale', and 1304 'value-precision', since they may change when the value 1305 is changed."; 1306 reference "RFC 3433: entPhySensorValue"; 1307 } 1309 leaf value-type { 1310 type sensor-value-type; 1311 description 1312 "The type of data units associated with the 1313 sensor value"; 1314 reference "RFC 3433: entPhySensorType"; 1315 } 1317 leaf value-scale { 1318 type sensor-value-scale; 1319 description 1320 "The (power of 10) scaling factor associated 1321 with the sensor value"; 1322 reference "RFC 3433: entPhySensorScale"; 1323 } 1325 leaf value-precision { 1326 type sensor-value-precision; 1327 description 1328 "The number of decimal places of precision 1329 associated with the sensor value"; 1330 reference "RFC 3433: entPhySensorPrecision"; 1332 } 1334 leaf oper-status { 1335 type sensor-status; 1336 description 1337 "The operational status of the sensor."; 1338 reference "RFC 3433: entPhySensorOperStatus"; 1339 } 1341 leaf units-display { 1342 type string; 1343 description 1344 "A textual description of the data units that should be 1345 used in the display of the sensor value."; 1346 reference "RFC 3433: entPhySensorUnitsDisplay"; 1347 } 1349 leaf value-timestamp { 1350 type yang:date-and-time; 1351 description 1352 "The time the status and/or value of this sensor was last 1353 obtained by the server."; 1354 reference "RFC 3433: entPhySensorValueTimeStamp"; 1355 } 1357 leaf value-update-rate { 1358 type uint32; 1359 units "milliseconds"; 1360 description 1361 "An indication of the frequency that the server updates 1362 the associated 'value' node, representing in 1363 milliseconds. The value zero indicates: 1365 - the sensor value is updated on demand (e.g., 1366 when polled by the server for a get-request), 1367 - the sensor value is updated when the sensor 1368 value changes (event-driven), 1369 - the server does not know the update rate."; 1370 reference "RFC 3433: entPhySensorValueUpdateRate"; 1371 } 1372 } 1373 } 1374 } 1376 /* 1377 * Notifications 1378 */ 1380 notification hardware-state-change { 1381 description 1382 "A hardware-state-change notification is generated when the 1383 value of /hardware/last-change changes in the operational 1384 state."; 1385 reference "RFC 6933, entConfigChange"; 1386 } 1388 notification hardware-state-oper-enabled { 1389 if-feature hardware-state; 1390 description 1391 "A hardware-state-oper-enabled notification signifies that a 1392 component has transitioned into the 'enabled' state."; 1394 leaf name { 1395 type leafref { 1396 path "/hardware/component/name"; 1397 } 1398 description 1399 "The name of the component that has transitioned into the 1400 'enabled' state."; 1401 } 1402 leaf admin-state { 1403 type leafref { 1404 path "/hardware/component/state/admin-state"; 1405 } 1406 description 1407 "The administrative state for the component."; 1408 } 1409 leaf alarm-state { 1410 type leafref { 1411 path "/hardware/component/state/alarm-state"; 1412 } 1413 description 1414 "The alarm state for the component."; 1415 } 1416 reference "RFC 4268, entStateOperEnabled"; 1417 } 1419 notification hardware-state-oper-disabled { 1420 if-feature hardware-state; 1421 description 1422 "A hardware-state-oper-disabled notification signifies that a 1423 component has transitioned into the 'disabled' state."; 1425 leaf name { 1426 type leafref { 1427 path "/hardware/component/name"; 1429 } 1430 description 1431 "The name of the component that has transitioned into the 1432 'disabled' state."; 1433 } 1434 leaf admin-state { 1435 type leafref { 1436 path "/hardware/component/state/admin-state"; 1437 } 1438 description 1439 "The administrative state for the component."; 1440 } 1441 leaf alarm-state { 1442 type leafref { 1443 path "/hardware/component/state/alarm-state"; 1444 } 1445 description 1446 "The alarm state for the component."; 1447 } 1448 reference "RFC 4268, entStateOperDisabled"; 1449 } 1451 } 1453 1455 file "iana-hardware@2017-12-18.yang" 1457 module iana-hardware { 1458 yang-version 1.1; 1459 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1460 prefix ianahw; 1462 organization "IANA"; 1463 contact 1464 " Internet Assigned Numbers Authority 1466 Postal: ICANN 1467 4676 Admiralty Way, Suite 330 1468 Marina del Rey, CA 90292 1470 Tel: +1 310 823 9358 1471 "; 1473 description 1474 "IANA defined identities for hardware class."; 1475 reference 1476 // RFC Ed.: replace XXXX with actual path and remove this note. 1477 "https://www.iana.org/assignments/XXXX"; 1479 // RFC Ed.: replace XXXX with actual RFC number and remove this 1480 // note. 1482 // RFC Ed.: update the date below with the date of RFC publication 1483 // and remove this note. 1484 revision 2017-12-18 { 1485 description 1486 "Initial revision."; 1487 reference 1488 "RFC XXXX: A YANG Data Model for Hardware Management"; 1489 } 1491 /* 1492 * Identities 1493 */ 1495 identity hardware-class { 1496 description 1497 "This identity is the base for all hardware class 1498 identifiers."; 1499 } 1501 identity unknown { 1502 base ianahw:hardware-class; 1503 description 1504 "This identity is applicable if the hardware class is unknown 1505 to the server."; 1506 } 1508 identity chassis { 1509 base ianahw:hardware-class; 1510 description 1511 "This identity is applicable if the hardware class is an 1512 overall container for networking equipment. Any class of 1513 physical component, except a stack, may be contained within a 1514 chassis; a chassis may only be contained within a stack."; 1515 } 1517 identity backplane { 1518 base ianahw:hardware-class; 1519 description 1520 "This identity is applicable if the hardware class is some sort 1521 of device for aggregating and forwarding networking traffic, 1522 such as a shared backplane in a modular ethernet switch. Note 1523 that an implementation may model a backplane as a single 1524 physical component, which is actually implemented as multiple 1525 discrete physical components (within a chassis or stack)."; 1526 } 1528 identity container { 1529 base ianahw:hardware-class; 1530 description 1531 "This identity is applicable if the hardware class is capable 1532 of containing one or more removable physical entities, 1533 possibly of different types. For example, each (empty or 1534 full) slot in a chassis will be modeled as a container. Note 1535 that all removable physical components should be modeled 1536 within a container component, such as field-replaceable 1537 modules, fans, or power supplies. Note that all known 1538 containers should be modeled by the agent, including empty 1539 containers."; 1540 } 1542 identity power-supply { 1543 base ianahw:hardware-class; 1544 description 1545 "This identity is applicable if the hardware class is a 1546 power-supplying component."; 1547 } 1549 identity fan { 1550 base ianahw:hardware-class; 1551 description 1552 "This identity is applicable if the hardware class is a fan or 1553 other heat-reduction component."; 1554 } 1556 identity sensor { 1557 base ianahw:hardware-class; 1558 description 1559 "This identity is applicable if the hardware class is some sort 1560 of sensor, such as a temperature sensor within a router 1561 chassis."; 1562 } 1564 identity module { 1565 base ianahw:hardware-class; 1566 description 1567 "This identity is applicable if the hardware class is some sort 1568 of self-contained sub-system. If a module component is 1569 removable, then it should be modeled within a container 1570 component; otherwise, it should be modeled directly within 1571 another physical component (e.g., a chassis or another 1572 module)."; 1573 } 1575 identity port { 1576 base ianahw:hardware-class; 1577 description 1578 "This identity is applicable if the hardware class is some sort 1579 of networking port, capable of receiving and/or transmitting 1580 networking traffic."; 1581 } 1583 identity stack { 1584 base ianahw:hardware-class; 1585 description 1586 "This identity is applicable if the hardware class is some sort 1587 of super-container (possibly virtual) intended to group 1588 together multiple chassis entities. A stack may be realized 1589 by a virtual cable, a real interconnect cable attached to 1590 multiple chassis, or multiple interconnect cables. A stack 1591 should not be modeled within any other physical components, 1592 but a stack may be contained within another stack. Only 1593 chassis components should be contained within a stack."; 1594 } 1596 identity cpu { 1597 base ianahw:hardware-class; 1598 description 1599 "This identity is applicable if the hardware class is some sort 1600 of central processing unit."; 1601 } 1603 identity energy-object { 1604 base ianahw:hardware-class; 1605 description 1606 "This identity is applicable if the hardware class is some sort 1607 of energy object, i.e., a piece of equipment that is part of 1608 or attached to a communications network that is monitored, 1609 controlled, or aids in the management of another device for 1610 Energy Management."; 1611 } 1613 identity battery { 1614 base ianahw:hardware-class; 1615 description 1616 "This identity is applicable if the hardware class is some sort 1617 of battery."; 1618 } 1619 identity storage-drive { 1620 base ianahw:hardware-class; 1621 description 1622 "This identity is applicable if the hardware class is some sort 1623 of component with data storage capability as main 1624 functionality, e.g., disk drive (HDD), solid state device 1625 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1626 } 1627 } 1629 1631 8. IANA Considerations 1633 This document defines the initial version of the IANA-maintained 1634 "iana-hardware" YANG module. 1636 The "iana-hardware" YANG module is intended to reflect the 1637 "IANA-ENTITY-MIB" MIB module so that if a new enumeration is added to 1638 the "IANAPhysicalClass" TEXTUAL-CONVENTION, the same class is added 1639 as an identity derived from "ianahw:hardware-class". 1641 When the "iana-hardware" YANG module is updated, a new "revision" 1642 statement must be added in front of the existing revision statements. 1644 8.1. URI Registrations 1646 This document registers three URIs in the IETF XML registry 1647 [RFC3688]. Following the format in RFC 3688, the following 1648 registrations are requested to be made. 1650 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1651 Registrant Contact: The IESG. 1652 XML: N/A, the requested URI is an XML namespace. 1654 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1655 Registrant Contact: The IESG. 1656 XML: N/A, the requested URI is an XML namespace. 1658 URI: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1659 Registrant Contact: The IESG. 1660 XML: N/A, the requested URI is an XML namespace. 1662 8.2. YANG Module Registrations 1664 This document registers three YANG modules in the YANG Module Names 1665 registry [RFC6020]. 1667 name: iana-hardware 1668 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1669 prefix: ianahw 1670 reference: RFC XXXX 1672 name: ietf-hardware 1673 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1674 prefix: hw 1675 reference: RFC XXXX 1677 name: ietf-hardware-state 1678 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1679 prefix: hw-state 1680 reference: RFC XXXX 1682 9. Security Considerations 1684 The YANG modules specified in this document define a schema for data 1685 that is designed to be accessed via network management protocols such 1686 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1687 is the secure transport layer, and the mandatory-to-implement secure 1688 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1689 is HTTPS, and the mandatory-to-implement secure transport is TLS 1690 [RFC5246]. 1692 The NETCONF access control model [RFC6536] provides the means to 1693 restrict access for particular NETCONF or RESTCONF users to a 1694 preconfigured subset of all available NETCONF or RESTCONF protocol 1695 operations and content. 1697 There are a number of data nodes defined in the YANG module 1698 "ietf-hardware" that are writable/creatable/deletable (i.e., config 1699 true, which is the default). These data nodes may be considered 1700 sensitive or vulnerable in some network environments. Write 1701 operations (e.g., edit-config) to these data nodes without proper 1702 protection can have a negative effect on network operations. These 1703 are the subtrees and data nodes and their sensitivity/vulnerability: 1705 /hardware/component/admin-state: Setting this node to 'locked' or 1706 'shutting-down' can cause disruption of services ranging from 1707 those running on a port to those on an entire device, depending on 1708 the type of component. 1710 Some of the readable data nodes in these YANG modules may be 1711 considered sensitive or vulnerable in some network environments. It 1712 is thus important to control read access (e.g., via get, get-config, 1713 or notification) to these data nodes. These are the subtrees and 1714 data nodes and their sensitivity/vulnerability: 1716 /hardware/component: The leafs in this list expose information about 1717 the physical components in a device, which may be used to identify 1718 the vendor, model, version, and specific device-identification 1719 information of each system component. 1721 /hardware/component/sensor-data/value: This node may expose the 1722 values of particular physical sensors in a device. 1724 /hardware/component/state: Access to this node allows one to figure 1725 out what the active and standby resources in a device are. 1727 10. Acknowledgments 1729 The authors wish to thank the following individuals, who all provided 1730 helpful comments on various draft versions of this document: Bart 1731 Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder. 1733 11. References 1735 11.1. Normative References 1737 [I-D.ietf-netmod-revised-datastores] 1738 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1739 and R. Wilton, "Network Management Datastore 1740 Architecture", draft-ietf-netmod-revised-datastores-08 1741 (work in progress), December 2017. 1743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1744 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1745 RFC2119, March 1997, . 1748 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1749 Management Information Base", RFC 3433, DOI 10.17487/ 1750 RFC3433, December 2002, . 1753 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1754 DOI 10.17487/RFC3688, January 2004, . 1757 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1758 DOI 10.17487/RFC4268, November 2005, . 1761 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1762 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1763 RFC5246, August 2008, . 1766 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1767 the Network Configuration Protocol (NETCONF)", RFC 6020, 1768 DOI 10.17487/RFC6020, October 2010, . 1771 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1772 and A. Bierman, Ed., "Network Configuration Protocol 1773 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1774 . 1776 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1777 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1778 . 1780 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1781 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 1782 10.17487/RFC6536, March 2012, . 1785 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1786 Chandramouli, "Entity MIB (Version 4)", RFC 6933, DOI 1787 10.17487/RFC6933, May 2013, . 1790 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1791 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1792 . 1794 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1795 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1796 . 1798 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1799 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1800 May 2017, . 1802 11.2. Informative References 1804 [I-D.ietf-netmod-yang-tree-diagrams] 1805 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1806 ietf-netmod-yang-tree-diagrams-03 (work in progress), 1807 December 2017. 1809 Appendix A. Hardware State Data Model 1811 This non-normative appendix contains a data model designed as a 1812 temporary solution for implementations that do not yet support the 1813 Network Management Datastore Architecture (NMDA) defined in 1814 [I-D.ietf-netmod-revised-datastores]. It has the following 1815 structure: 1817 module: ietf-hardware-state 1818 x--ro hardware 1819 x--ro last-change? yang:date-and-time 1820 x--ro component* [name] 1821 x--ro name string 1822 x--ro class identityref 1823 x--ro physical-index? int32 {entity-mib}? 1824 x--ro description? string 1825 x--ro parent? -> ../../component/name 1826 x--ro parent-rel-pos? int32 1827 x--ro contains-child* -> ../../component/name 1828 x--ro hardware-rev? string 1829 x--ro firmware-rev? string 1830 x--ro software-rev? string 1831 x--ro serial-num? string 1832 x--ro mfg-name? string 1833 x--ro model-name? string 1834 x--ro alias? string 1835 x--ro asset-id? string 1836 x--ro is-fru? boolean 1837 x--ro mfg-date? yang:date-and-time 1838 x--ro uri* inet:uri 1839 x--ro uuid? yang:uuid 1840 x--ro state {hardware-state}? 1841 | x--ro state-last-changed? yang:date-and-time 1842 | x--ro admin-state? hw:admin-state 1843 | x--ro oper-state? hw:oper-state 1844 | x--ro usage-state? hw:usage-state 1845 | x--ro alarm-state? hw:alarm-state 1846 | x--ro standby-state? hw:standby-state 1847 x--ro sensor-data {hardware-sensor}? 1848 x--ro value? hw:sensor-value 1849 x--ro value-type? hw:sensor-value-type 1850 x--ro value-scale? hw:sensor-value-scale 1851 x--ro value-precision? hw:sensor-value-precision 1852 x--ro oper-status? hw:sensor-status 1853 x--ro units-display? string 1854 x--ro value-timestamp? yang:date-and-time 1855 x--ro value-update-rate? uint32 1857 notifications: 1858 x---n hardware-state-change 1859 x---n hardware-state-oper-enabled {hardware-state}? 1860 | x--ro name? -> /hardware/component/name 1861 | x--ro admin-state? -> /hardware/component/state/admin-state 1862 | x--ro alarm-state? -> /hardware/component/state/alarm-state 1863 x---n hardware-state-oper-disabled {hardware-state}? 1864 x--ro name? -> /hardware/component/name 1865 x--ro admin-state? -> /hardware/component/state/admin-state 1866 x--ro alarm-state? -> /hardware/component/state/alarm-state 1868 A.1. Hardware State YANG Module 1870 file "ietf-hardware-state@2017-12-18.yang" 1872 module ietf-hardware-state { 1873 yang-version 1.1; 1874 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware-state"; 1875 prefix hw-state; 1877 import ietf-inet-types { 1878 prefix inet; 1879 } 1880 import ietf-yang-types { 1881 prefix yang; 1882 } 1883 import iana-hardware { 1884 prefix ianahw; 1885 } 1886 import ietf-hardware { 1887 prefix hw; 1888 } 1890 organization 1891 "IETF NETMOD (Network Modeling) Working Group"; 1893 contact 1894 "WG Web: 1895 WG List: 1897 Editor: Andy Bierman 1898 1900 Editor: Martin Bjorklund 1901 1903 Editor: Jie Dong 1904 1906 Editor: Dan Romascanu 1907 "; 1909 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 1910 // remove this note. 1912 description 1913 "This module contains a collection of YANG definitions for 1914 monitoring hardware. 1916 This data model is designed as a temporary solution for 1917 implementations that do not yet support the Network Management 1918 Datastore Architecture (NMDA) defined in RFC YYYY. Such an 1919 implementation cannot implement the module 'ietf-hardware' 1920 properly, since without NMDA support, it is not possible to 1921 distinguish between instances of nodes in the running 1922 configuration and operational state. 1924 The data model in this module is the same as the data model in 1925 'ietf-hardware', except all nodes are marked as 'config false'. 1927 If a server that implements this module but doesn't support NMDA 1928 also supports configuration of hardware components, it SHOULD 1929 also implement the module 'ietf-hardware' in the configuration 1930 datastores. The corresponding state data is found in the 1931 '/hw-state:hardware' subtree. 1933 Copyright (c) 2017 IETF Trust and the persons identified as 1934 authors of the code. All rights reserved. 1936 Redistribution and use in source and binary forms, with or 1937 without modification, is permitted pursuant to, and subject 1938 to the license terms contained in, the Simplified BSD License 1939 set forth in Section 4.c of the IETF Trust's Legal Provisions 1940 Relating to IETF Documents 1941 (http://trustee.ietf.org/license-info). 1943 This version of this YANG module is part of RFC XXXX; see 1944 the RFC itself for full legal notices."; 1946 // RFC Ed.: update the date below with the date of RFC publication 1947 // and remove this note. 1948 revision 2017-12-18 { 1949 description 1950 "Initial revision."; 1951 reference 1952 "RFC XXXX: A YANG Data Model for Hardware Management"; 1953 } 1954 /* 1955 * Features 1956 */ 1958 feature entity-mib { 1959 status deprecated; 1960 description 1961 "This feature indicates that the device implements 1962 the ENTITY-MIB."; 1963 reference "RFC 6933: Entity MIB (Version 4)"; 1964 } 1966 feature hardware-state { 1967 status deprecated; 1968 description 1969 "Indicates the ENTITY-STATE-MIB objects are supported"; 1970 reference "RFC 4268: Entity State MIB"; 1971 } 1973 feature hardware-sensor { 1974 status deprecated; 1975 description 1976 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 1977 reference "RFC 3433: Entity Sensor MIB"; 1978 } 1980 /* 1981 * Data nodes 1982 */ 1984 container hardware { 1985 config false; 1986 status deprecated; 1987 description 1988 "Data nodes representing components."; 1990 leaf last-change { 1991 type yang:date-and-time; 1992 status deprecated; 1993 description 1994 "The time the '/hardware/component' list changed in the 1995 operational state."; 1996 } 1998 list component { 1999 key name; 2000 status deprecated; 2001 description 2002 "List of components. 2004 When the server detects a new hardware component, it 2005 initializes a list entry in the operational state. 2007 If the server does not support configuration of hardware 2008 components, list entries in the operational state are 2009 initialized with values for all nodes as detected by the 2010 implementation. 2012 Otherwise, the following procedure is followed: 2014 1. If there is an entry in the /hardware/component list in 2015 the intended configuration with values for the nodes 2016 'class', 'parent', 'parent-rel-pos' that are equal to 2017 the detected values, then: 2019 1a. If the configured entry has a value for 'mfg-name' 2020 that is equal to the detected value, or if the 2021 'mfg-name' value cannot be detected, then the list 2022 entry in the operational state is initialized with the 2023 configured values for all configured nodes, including 2024 the 'name'. 2026 Otherwise, the list entry in the operational state is 2027 initialized with values for all nodes as detected by 2028 the implementation. The implementation may raise an 2029 alarm that informs about the 'mfg-name' mismatch 2030 condition. How this is done is outside the scope of 2031 this document. 2033 1b. Otherwise (i.e., there is no matching configuration 2034 entry), the list entry in the operational state is 2035 initialized with values for all nodes as detected by 2036 the implementation. 2038 If the /hardware/component list in the intended 2039 configuration is modified, then the system MUST behave as if 2040 it re-initializes itself, and follow the procedure in (1)."; 2041 reference "RFC 6933: entPhysicalEntry"; 2043 leaf name { 2044 type string; 2045 status deprecated; 2046 description 2047 "The name assigned to this component. 2049 This name is not required to be the same as 2050 entPhysicalName."; 2051 } 2053 leaf class { 2054 type identityref { 2055 base ianahw:hardware-class; 2056 } 2057 mandatory true; 2058 status deprecated; 2059 description 2060 "An indication of the general hardware type of the 2061 component."; 2062 reference "RFC 6933: entPhysicalClass"; 2063 } 2065 leaf physical-index { 2066 if-feature entity-mib; 2067 type int32 { 2068 range "1..2147483647"; 2069 } 2070 status deprecated; 2071 description 2072 "The entPhysicalIndex for the entPhysicalEntry represented 2073 by this list entry."; 2074 reference "RFC 6933: entPhysicalIndex"; 2075 } 2077 leaf description { 2078 type string; 2079 status deprecated; 2080 description 2081 "A textual description of component. This node should 2082 contain a string that identifies the manufacturer's name 2083 for the component and should be set to a distinct value 2084 for each version or model of the component."; 2085 reference "RFC 6933: entPhysicalDescr"; 2086 } 2088 leaf parent { 2089 type leafref { 2090 path "../../component/name"; 2091 require-instance false; 2092 } 2093 status deprecated; 2094 description 2095 "The name of the component that physically contains this 2096 component. 2098 If this leaf is not instantiated, it indicates that this 2099 component is not contained in any other component. 2101 In the event that a physical component is contained by 2102 more than one physical component (e.g., double-wide 2103 modules), this node contains the name of one of these 2104 components. An implementation MUST use the same name 2105 every time this node is instantiated."; 2106 reference "RFC 6933: entPhysicalContainedIn"; 2107 } 2109 leaf parent-rel-pos { 2110 type int32 { 2111 range "0 .. 2147483647"; 2112 } 2113 status deprecated; 2114 description 2115 "An indication of the relative position of this child 2116 component among all its sibling components. Sibling 2117 components are defined as components that: 2119 o Share the same value of the 'parent' node; and 2121 o Share a common base identity for the 'class' node. 2123 Note that the last rule gives implementations flexibility 2124 in how components are numbered. For example, some 2125 implementations might have a single number series for all 2126 components derived from 'ianahw:port', while some others 2127 might have different number series for different 2128 components with identities derived from 'ianahw:port' (for 2129 example, one for RJ45 and one for SFP)."; 2131 reference "RFC 6933: entPhysicalParentRelPos"; 2132 } 2134 leaf-list contains-child { 2135 type leafref { 2136 path "../../component/name"; 2137 } 2138 status deprecated; 2139 description 2140 "The name of the contained component."; 2141 reference "RFC 6933: entPhysicalChildIndex"; 2142 } 2144 leaf hardware-rev { 2145 type string; 2146 status deprecated; 2147 description 2148 "The vendor-specific hardware revision string for the 2149 component. The preferred value is the hardware revision 2150 identifier actually printed on the component itself (if 2151 present)."; 2152 reference "RFC 6933: entPhysicalHardwareRev"; 2153 } 2155 leaf firmware-rev { 2156 type string; 2157 status deprecated; 2158 description 2159 "The vendor-specific firmware revision string for the 2160 component."; 2161 reference "RFC 6933: entPhysicalFirmwareRev"; 2162 } 2164 leaf software-rev { 2165 type string; 2166 status deprecated; 2167 description 2168 "The vendor-specific software revision string for the 2169 component."; 2170 reference "RFC 6933: entPhysicalSoftwareRev"; 2171 } 2173 leaf serial-num { 2174 type string; 2175 status deprecated; 2176 description 2177 "The vendor-specific serial number string for the 2178 component. The preferred value is the serial number 2179 string actually printed on the component itself (if 2180 present)."; 2181 reference "RFC 6933: entPhysicalSerialNum"; 2182 } 2184 leaf mfg-name { 2185 type string; 2186 status deprecated; 2187 description 2188 "The name of the manufacturer of this physical component. 2189 The preferred value is the manufacturer name string 2190 actually printed on the component itself (if present). 2192 Note that comparisons between instances of the model-name, 2193 firmware-rev, software-rev, and the serial-num nodes are 2194 only meaningful amongst component with the same value of 2195 mfg-name. 2197 If the manufacturer name string associated with the 2198 physical component is unknown to the server, then this 2199 node is not instantiated."; 2200 reference "RFC 6933: entPhysicalMfgName"; 2201 } 2203 leaf model-name { 2204 type string; 2205 status deprecated; 2206 description 2207 "The vendor-specific model name identifier string 2208 associated with this physical component. The preferred 2209 value is the customer-visible part number, which may be 2210 printed on the component itself. 2212 If the model name string associated with the physical 2213 component is unknown to the server, then this node is not 2214 instantiated."; 2215 reference "RFC 6933: entPhysicalModelName"; 2216 } 2218 leaf alias { 2219 type string; 2220 status deprecated; 2221 description 2222 "An 'alias' name for the component, as specified by a 2223 network manager, and provides a non-volatile 'handle' for 2224 the component. 2226 If no configured value exists, the server MAY set the 2227 value of this node to a locally unique value in the 2228 operational state. 2230 A server implementation MAY map this leaf to the 2231 entPhysicalAlias MIB object. Such an implementation needs 2232 to use some mechanism to handle the differences in size 2233 and characters allowed between this leaf and 2234 entPhysicalAlias. The definition of such a mechanism is 2235 outside the scope of this document."; 2236 reference "RFC 6933: entPhysicalAlias"; 2237 } 2239 leaf asset-id { 2240 type string; 2241 status deprecated; 2242 description 2243 "This node is a user-assigned asset tracking identifier for 2244 the component. 2246 A server implementation MAY map this leaf to the 2247 entPhysicalAssetID MIB object. Such an implementation 2248 needs to use some mechanism to handle the differences in 2249 size and characters allowed between this leaf and 2250 entPhysicalAssetID. The definition of such a mechanism is 2251 outside the scope of this document."; 2252 reference "RFC 6933: entPhysicalAssetID"; 2253 } 2255 leaf is-fru { 2256 type boolean; 2257 status deprecated; 2258 description 2259 "This node indicates whether or not this component is 2260 considered a 'field replaceable unit' by the vendor. If 2261 this node contains the value 'true', then this component 2262 identifies a field replaceable unit. For all components 2263 that are permanently contained within a field replaceable 2264 unit, the value 'false' should be returned for this 2265 node."; 2266 reference "RFC 6933: entPhysicalIsFRU"; 2267 } 2269 leaf mfg-date { 2270 type yang:date-and-time; 2271 status deprecated; 2272 description 2273 "The date of manufacturing of the managed component."; 2274 reference "RFC 6933: entPhysicalMfgDate"; 2275 } 2277 leaf-list uri { 2278 type inet:uri; 2279 status deprecated; 2280 description 2281 "This node contains identification information about the 2282 component."; 2283 reference "RFC 6933: entPhysicalUris"; 2284 } 2286 leaf uuid { 2287 type yang:uuid; 2288 status deprecated; 2289 description 2290 "A Universally Unique Identifier of the component."; 2291 reference "RFC 6933: entPhysicalUUID"; 2292 } 2294 container state { 2295 if-feature hardware-state; 2296 status deprecated; 2297 description 2298 "State-related nodes"; 2299 reference "RFC 4268: Entity State MIB"; 2301 leaf state-last-changed { 2302 type yang:date-and-time; 2303 status deprecated; 2304 description 2305 "The date and time when the value of any of the 2306 admin-state, oper-state, usage-state, alarm-state, or 2307 standby-state changed for this component. 2309 If there has been no change since the last 2310 re-initialization of the local system, this node 2311 contains the date and time of local system 2312 initialization. If there has been no change since the 2313 component was added to the local system, this node 2314 contains the date and time of the insertion."; 2315 reference "RFC 4268: entStateLastChanged"; 2316 } 2318 leaf admin-state { 2319 type hw:admin-state; 2320 status deprecated; 2321 description 2322 "The administrative state for this component. 2324 This node refers to a component's administrative 2325 permission to service both other components within its 2326 containment hierarchy as well other users of its 2327 services defined by means outside the scope of this 2328 module. 2330 Some components exhibit only a subset of the remaining 2331 administrative state values. Some components cannot be 2332 locked, and hence this node exhibits only the 'unlocked' 2333 state. Other components cannot be shutdown gracefully, 2334 and hence this node does not exhibit the 'shutting-down' 2335 state."; 2336 reference "RFC 4268: entStateAdmin"; 2337 } 2338 leaf oper-state { 2339 type hw:oper-state; 2340 status deprecated; 2341 description 2342 "The operational state for this component. 2344 Note that this node does not follow the administrative 2345 state. An administrative state of down does not predict 2346 an operational state of disabled. 2348 Note that some implementations may not be able to 2349 accurately report oper-state while the admin-state node 2350 has a value other than 'unlocked'. In these cases, this 2351 node MUST have a value of 'unknown'."; 2352 reference "RFC 4268: entStateOper"; 2353 } 2355 leaf usage-state { 2356 type hw:usage-state; 2357 status deprecated; 2358 description 2359 "The usage state for this component. 2361 This node refers to a component's ability to service 2362 more components in a containment hierarchy. 2364 Some components will exhibit only a subset of the usage 2365 state values. Components that are unable to ever 2366 service any components within a containment hierarchy 2367 will always have a usage state of 'busy'. Some 2368 components will only ever be able to support one 2369 component within its containment hierarchy and will 2370 therefore only exhibit values of 'idle' and 'busy'."; 2371 reference "RFC 4268, entStateUsage"; 2372 } 2374 leaf alarm-state { 2375 type hw:alarm-state; 2376 status deprecated; 2377 description 2378 "The alarm state for this component. It does not 2379 include the alarms raised on child components within its 2380 containment hierarchy."; 2381 reference "RFC 4268: entStateAlarm"; 2382 } 2384 leaf standby-state { 2385 type hw:standby-state; 2386 status deprecated; 2387 description 2388 "The standby state for this component. 2390 Some components will exhibit only a subset of the 2391 remaining standby state values. If this component 2392 cannot operate in a standby role, the value of this node 2393 will always be 'providing-service'."; 2394 reference "RFC 4268: entStateStandby"; 2395 } 2396 } 2398 container sensor-data { 2399 when 'derived-from-or-self(../class, 2400 "ianahw:sensor")' { 2401 description 2402 "Sensor data nodes present for any component of type 2403 'sensor'"; 2404 } 2405 if-feature hardware-sensor; 2406 status deprecated; 2408 description 2409 "Sensor-related nodes."; 2410 reference "RFC 3433: Entity Sensor MIB"; 2412 leaf value { 2413 type hw:sensor-value; 2414 status deprecated; 2415 description 2416 "The most recent measurement obtained by the server 2417 for this sensor. 2419 A client that periodically fetches this node should also 2420 fetch the nodes 'value-type', 'value-scale', and 2421 'value-precision', since they may change when the value 2422 is changed."; 2423 reference "RFC 3433: entPhySensorValue"; 2424 } 2426 leaf value-type { 2427 type hw:sensor-value-type; 2428 status deprecated; 2429 description 2430 "The type of data units associated with the 2431 sensor value"; 2432 reference "RFC 3433: entPhySensorType"; 2433 } 2434 leaf value-scale { 2435 type hw:sensor-value-scale; 2436 status deprecated; 2437 description 2438 "The (power of 10) scaling factor associated 2439 with the sensor value"; 2440 reference "RFC 3433: entPhySensorScale"; 2441 } 2443 leaf value-precision { 2444 type hw:sensor-value-precision; 2445 status deprecated; 2446 description 2447 "The number of decimal places of precision 2448 associated with the sensor value"; 2449 reference "RFC 3433: entPhySensorPrecision"; 2450 } 2452 leaf oper-status { 2453 type hw:sensor-status; 2454 status deprecated; 2455 description 2456 "The operational status of the sensor."; 2457 reference "RFC 3433: entPhySensorOperStatus"; 2458 } 2460 leaf units-display { 2461 type string; 2462 status deprecated; 2463 description 2464 "A textual description of the data units that should be 2465 used in the display of the sensor value."; 2466 reference "RFC 3433: entPhySensorUnitsDisplay"; 2467 } 2469 leaf value-timestamp { 2470 type yang:date-and-time; 2471 status deprecated; 2472 description 2473 "The time the status and/or value of this sensor was last 2474 obtained by the server."; 2475 reference "RFC 3433: entPhySensorValueTimeStamp"; 2476 } 2478 leaf value-update-rate { 2479 type uint32; 2480 units "milliseconds"; 2481 status deprecated; 2482 description 2483 "An indication of the frequency that the server updates 2484 the associated 'value' node, representing in 2485 milliseconds. The value zero indicates: 2487 - the sensor value is updated on demand (e.g., 2488 when polled by the server for a get-request), 2489 - the sensor value is updated when the sensor 2490 value changes (event-driven), 2491 - the server does not know the update rate."; 2492 reference "RFC 3433: entPhySensorValueUpdateRate"; 2493 } 2494 } 2495 } 2496 } 2498 /* 2499 * Notifications 2500 */ 2502 notification hardware-state-change { 2503 status deprecated; 2504 description 2505 "A hardware-state-change notification is generated when the 2506 value of /hardware/last-change changes in the operational 2507 state."; 2508 reference "RFC 6933, entConfigChange"; 2509 } 2511 notification hardware-state-oper-enabled { 2512 if-feature hardware-state; 2513 status deprecated; 2514 description 2515 "A hardware-state-oper-enabled notification signifies that a 2516 component has transitioned into the 'enabled' state."; 2518 leaf name { 2519 type leafref { 2520 path "/hardware/component/name"; 2521 } 2522 status deprecated; 2523 description 2524 "The name of the component that has transitioned into the 2525 'enabled' state."; 2526 } 2527 leaf admin-state { 2528 type leafref { 2529 path "/hardware/component/state/admin-state"; 2531 } 2532 status deprecated; 2533 description 2534 "The administrative state for the component."; 2535 } 2536 leaf alarm-state { 2537 type leafref { 2538 path "/hardware/component/state/alarm-state"; 2539 } 2540 status deprecated; 2541 description 2542 "The alarm state for the component."; 2543 } 2544 reference "RFC 4268, entStateOperEnabled"; 2545 } 2547 notification hardware-state-oper-disabled { 2548 if-feature hardware-state; 2549 status deprecated; 2550 description 2551 "A hardware-state-oper-disabled notification signifies that a 2552 component has transitioned into the 'disabled' state."; 2554 leaf name { 2555 type leafref { 2556 path "/hardware/component/name"; 2557 } 2558 status deprecated; 2559 description 2560 "The name of the component that has transitioned into the 2561 'disabled' state."; 2562 } 2563 leaf admin-state { 2564 type leafref { 2565 path "/hardware/component/state/admin-state"; 2566 } 2567 status deprecated; 2568 description 2569 "The administrative state for the component."; 2570 } 2571 leaf alarm-state { 2572 type leafref { 2573 path "/hardware/component/state/alarm-state"; 2574 } 2575 status deprecated; 2576 description 2577 "The alarm state for the component."; 2578 } 2579 reference "RFC 4268, entStateOperDisabled"; 2580 } 2582 } 2584 2586 Authors' Addresses 2588 Andy Bierman 2589 YumaWorks 2591 Email: andy@yumaworks.com 2593 Martin Bjorklund 2594 Tail-f Systems 2596 Email: mbj@tail-f.com 2598 Jie Dong 2599 Huawei Technologies 2601 Email: jie.dong@huawei.com 2603 Dan Romascanu 2605 Email: dromasca@gmail.com