idnits 2.17.1 draft-ietf-netmod-entity-06.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 18, 2017) is 2320 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-07 ** 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-02 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 21, 2018 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 9 December 18, 2017 11 A YANG Data Model for Hardware Management 12 draft-ietf-netmod-entity-06 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 June 21, 2018. 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.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 35 64 8.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 35 65 8.2. YANG Module Registrations . . . . . . . . . . . . . . . . 35 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 70 11.2. Informative References . . . . . . . . . . . . . . . . . 38 71 Appendix A. Hardware State Data Model . . . . . . . . . . . . . 39 72 A.1. Hardware State YANG Module . . . . . . . . . . . . . . . 40 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 75 1. Introduction 77 This document defines a YANG [RFC7950] data model for the management 78 of hardware on a single server. 80 The data model includes configuration and system state (status 81 information and counters for the collection of statistics). 83 The data model in this document is designed to be compliant with the 84 Network Management Datastore Architecture (NMDA) 85 [I-D.ietf-netmod-revised-datastores]. For implementations that do 86 not yet support NMDA, a temporary module with system state data only 87 is defined in Appendix A. 89 1.1. Terminology 91 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14, [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 The following terms are defined in 98 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 100 o client 102 o server 104 o configuration 106 o system state 108 o operational state 110 o intended configuration 112 1.2. Tree Diagrams 114 Tree diagrams used in this document follow the notation defined in 115 [I-D.ietf-netmod-yang-tree-diagrams]. 117 2. Objectives 119 This section describes some of the design objectives for the hardware 120 model. 122 o There are many common properties used to identify hardware 123 components, which need to be supported in the hardware data model. 125 o There are many important information and states about the 126 components, which needs to be collected from the devices which 127 support the hardware data model. 129 o The hardware data model SHOULD be suitable for new implementations 130 to use as is. 132 o The hardware data model defined in this document can be 133 implemented on a system that also implements ENTITY-MIB, thus the 134 mapping between the hardware data model and ENTITY-MIB SHOULD be 135 clear. 137 o The data model should support pre-provisioning of hardware 138 components. 140 3. Hardware Data Model 142 This document defines the YANG module "ietf-hardware", which has the 143 following structure: 145 module: ietf-hardware 146 +--rw hardware 147 +--ro last-change? yang:date-and-time 148 +--rw component* [name] 149 +--rw name string 150 +--rw class identityref 151 +--ro physical-index? int32 {entity-mib}? 152 +--ro description? string 153 +--rw parent? -> ../../component/name 154 +--rw parent-rel-pos? int32 155 +--ro contains-child* -> ../../component/name 156 +--ro hardware-rev? string 157 +--ro firmware-rev? string 158 +--ro software-rev? string 159 +--ro serial-num? string 160 +--rw mfg-name? string 161 +--ro model-name? string 162 +--rw alias? string 163 +--rw asset-id? string 164 +--ro is-fru? boolean 165 +--ro mfg-date? yang:date-and-time 166 +--rw uri* inet:uri 167 +--ro uuid? yang:uuid 168 +--rw state {hardware-state}? 169 | +--ro state-last-changed? yang:date-and-time 170 | +--rw admin-state? admin-state 171 | +--ro oper-state? oper-state 172 | +--ro usage-state? usage-state 173 | +--ro alarm-state? alarm-state 174 | +--ro standby-state? standby-state 175 +--ro sensor-data {hardware-sensor}? 176 +--ro value? sensor-value 177 +--ro value-type? sensor-value-type 178 +--ro value-scale? sensor-value-scale 179 +--ro value-precision? sensor-value-precision 180 +--ro oper-status? sensor-status 181 +--ro units-display? string 182 +--ro value-timestamp? yang:date-and-time 183 +--ro value-update-rate? uint32 185 notifications: 186 +---n hardware-state-change 187 +---n hardware-state-oper-enabled {hardware-state}? 188 | +--ro name? -> /hardware/component/name 189 | +--ro admin-state? -> /hardware/component/state/admin-state 190 | +--ro alarm-state? -> /hardware/component/state/alarm-state 191 +---n hardware-state-oper-disabled {hardware-state}? 192 +--ro name? -> /hardware/component/name 193 +--ro admin-state? -> /hardware/component/state/admin-state 194 +--ro alarm-state? -> /hardware/component/state/alarm-state 196 3.1. The Components Lists 198 The data model for hardware presented in this document uses a flat 199 list of components. Each component in the list is identified by its 200 name. Furthermore, each component has a mandatory "class" leaf. 202 The "iana-hardware" module defines YANG identities for the hardware 203 types in the IANA-maintained "IANA-ENTITY-MIB" registry. 205 The "class" leaf is a YANG identity that describes the type of the 206 hardware. Vendors are encouraged to either directly use one of the 207 common IANA-defined identities, or derive a more specific identity 208 from one of them. 210 4. Relationship to ENTITY-MIB 212 If the device implements the ENTITY-MIB [RFC6933], each entry in the 213 "/hardware-state/component" list is mapped to one EntPhysicalEntry. 214 Objects that are writable in the MIB are mapped to nodes in the 215 "/hardware/component" list. 217 The "physical-index" leaf MUST contain the value of the corresponding 218 entPhysicalEntry's entPhysicalIndex. 220 The "class" leaf is mapped to both entPhysicalClass and 221 entPhysicalVendorType. If the value of the "class" leaf is an 222 identity that is either derived from or is one of the identities in 223 the "iana-hardware" module, then entPhysicalClass contains the 224 corresponding IANAPhysicalClass enumeration value. Otherwise, 225 entPhysicalClass contains the IANAPhysicalClass value "other(1)". 226 Vendors are encouraged to define an identity (derived from an 227 identity in "iana-hardware" if possible) for each enterprise-specific 228 registration identifier used for entPhysicalVendorType, and use that 229 identity for the "class" leaf. 231 The following tables list the YANG data nodes with corresponding 232 objects in the ENTITY-MIB. 234 +--------------------------------+----------------------------------+ 235 | YANG data node in | ENTITY-MIB object | 236 | /hardware/component | | 237 +--------------------------------+----------------------------------+ 238 | name | entPhysicalName | 239 | class | entPhysicalClass | 240 | | entPhysicalVendorType | 241 | physical-index | entPhysicalIndex | 242 | description | entPhysicalDescr | 243 | parent | entPhysicalContainedIn | 244 | parent-rel-pos | entPhysicalParentRelPos | 245 | contains-child | entPhysicalChildIndex | 246 | hardware-rev | entPhysicalHardwareRev | 247 | firmware-rev | entPhysicalFirmwareRev | 248 | software-rev | entPhysicalSoftwareRev | 249 | serial-num | entPhysicalSerialNum | 250 | mfg-name | entPhysicalMfgName | 251 | model-name | entPhysicalModelName | 252 | alias | entPhysicalAlias | 253 | asset-id | entPhysicalAssetID | 254 | is-fru | entPhysicalIsFRU | 255 | mfg-date | entPhysicalMfgDate | 256 | uri | entPhysicalUris | 257 | uuid | entPhysicalUUID | 258 +--------------------------------+----------------------------------+ 260 YANG Data Nodes and Related ENTITY-MIB Objects 262 5. Relationship to ENTITY-SENSOR-MIB 264 If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry 265 in the "/hardware/component" list where the container "sensor-data" 266 exists is mapped to one EntPhySensorEntry. 268 +-------------------------------------+-----------------------------+ 269 | YANG data node in | ENTITY-SENSOR-MIB object | 270 | /hardware/component/sensor-data | | 271 +-------------------------------------+-----------------------------+ 272 | value | entPhySensorValue | 273 | value-type | entPhySensorType | 274 | value-scale | entPhySensorScale | 275 | value-precision | entPhySensorPrecision | 276 | oper-status | entPhySensorOperStatus | 277 | units-display | entPhySensorUnitsDisplay | 278 | value-timestamp | entPhySensorValueTimeStamp | 279 | value-update-rate | entPhySensorValueUpdateRate | 280 +-------------------------------------+-----------------------------+ 282 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 284 6. Relationship to ENTITY-STATE-MIB 286 If the device implements the ENTITY-STATE-MIB [RFC4268], each entry 287 in the "/hardware/component" list where the container "state" exists 288 is mapped to one EntStateEntry. 290 +------------------------------------------+------------------------+ 291 | YANG data node in | ENTITY-STATE-MIB | 292 | /hardware/component/state | object | 293 +------------------------------------------+------------------------+ 294 | state-last-changed | entStateLastChanged | 295 | admin-state | entStateAdmin | 296 | oper-state | entStateOper | 297 | usage-state | entStateUsage | 298 | alarm-state | entStateAlarm | 299 | standby-state | entStateStandby | 300 +------------------------------------------+------------------------+ 302 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 304 7. Hardware YANG Module 306 file "ietf-hardware@2017-12-18.yang" 308 module ietf-hardware { 309 yang-version 1.1; 310 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; 311 prefix hw; 313 import ietf-inet-types { 314 prefix inet; 315 } 316 import ietf-yang-types { 317 prefix yang; 318 } 319 import iana-hardware { 320 prefix ianahw; 321 } 323 organization 324 "IETF NETMOD (Network Modeling) Working Group"; 326 contact 327 "WG Web: 328 WG List: 330 Editor: Andy Bierman 331 333 Editor: Martin Bjorklund 334 336 Editor: Jie Dong 337 339 Editor: Dan Romascanu 340 "; 342 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 343 // remove this note. 345 description 346 "This module contains a collection of YANG definitions for 347 managing hardware. 349 This data model is designed for the Network Management Datastore 350 Architecture defined in RFC YYYY. 352 Copyright (c) 2017 IETF Trust and the persons identified as 353 authors of the code. All rights reserved. 355 Redistribution and use in source and binary forms, with or 356 without modification, is permitted pursuant to, and subject 357 to the license terms contained in, the Simplified BSD License 358 set forth in Section 4.c of the IETF Trust's Legal Provisions 359 Relating to IETF Documents 360 (http://trustee.ietf.org/license-info). 362 This version of this YANG module is part of RFC XXXX; see 363 the RFC itself for full legal notices."; 365 // RFC Ed.: update the date below with the date of RFC publication 366 // and remove this note. 367 revision 2017-12-18 { 368 description 369 "Initial revision."; 370 reference 371 "RFC XXXX: A YANG Data Model for Hardware Management"; 372 } 374 /* 375 * Features 376 */ 378 feature entity-mib { 379 description 380 "This feature indicates that the device implements 381 the ENTITY-MIB."; 382 reference "RFC 6933: Entity MIB (Version 4)"; 383 } 385 feature hardware-state { 386 description 387 "Indicates the ENTITY-STATE-MIB objects are supported"; 388 reference "RFC 4268: Entity State MIB"; 389 } 391 feature hardware-sensor { 392 description 393 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 394 reference "RFC 3433: Entity Sensor MIB"; 395 } 397 /* 398 * Typedefs 399 */ 401 typedef admin-state { 402 type enumeration { 403 enum unknown { 404 value 1; 405 description 406 "The resource is unable to report administrative state."; 407 } 408 enum locked { 409 value 2; 410 description 411 "The resource is administratively prohibited from use."; 412 } 413 enum shutting-down { 414 value 3; 415 description 416 "The resource usage is administratively limited to current 417 instances of use."; 418 } 419 enum unlocked { 420 value 4; 421 description 422 "The resource is not administratively prohibited from 423 use."; 424 } 425 } 426 description 427 "Represents the various possible administrative states."; 428 reference "RFC 4268: EntityAdminState"; 429 } 431 typedef oper-state { 432 type enumeration { 433 enum unknown { 434 value 1; 435 description 436 "The resource is unable to report its operational state."; 437 } 438 enum disabled { 439 value 2; 440 description 441 "The resource is totally inoperable."; 442 } 443 enum enabled { 444 value 3; 445 description 446 "The resource is partially or fully operable."; 447 } 448 enum testing { 449 value 4; 450 description 451 "The resource is currently being tested and cannot 452 therefore report whether it is operational or not."; 453 } 454 } 455 description 456 "Represents the possible values of operational states."; 457 reference "RFC 4268: EntityOperState"; 458 } 460 typedef usage-state { 461 type enumeration { 462 enum unknown { 463 value 1; 464 description 465 "The resource is unable to report usage state."; 466 } 467 enum idle { 468 value 2; 469 description 470 "The resource is servicing no users."; 471 } 472 enum active { 473 value 3; 474 description 475 "The resource is currently in use and it has sufficient 476 spare capacity to provide for additional users."; 477 } 478 enum busy { 479 value 4; 480 description 481 "The resource is currently in use, but it currently has no 482 spare capacity to provide for additional users."; 483 } 484 } 485 description 486 "Represents the possible values of usage states."; 487 reference "RFC 4268, EntityUsageState"; 488 } 490 typedef alarm-state { 491 type bits { 492 bit unknown { 493 position 0; 494 description 495 "The resource is unable to report alarm state."; 496 } 497 bit under-repair { 498 position 1; 499 description 500 "The resource is currently being repaired, which, depending 501 on the implementation, may make the other values in this 502 bit string not meaningful."; 503 } 504 bit critical { 505 position 2; 506 description 507 "One or more critical alarms are active against the 508 resource."; 510 } 511 bit major { 512 position 3; 513 description 514 "One or more major alarms are active against the 515 resource."; 516 } 517 bit minor { 518 position 4; 519 description 520 "One or more minor alarms are active against the 521 resource."; 522 } 523 bit warning { 524 position 5; 525 description 526 "One or more warning alarms are active against the 527 resource."; 528 } 529 bit indeterminate { 530 position 6; 531 description 532 "One or more alarms of whose perceived severity cannot be 533 determined are active against this resource."; 534 } 535 } 536 description 537 "Represents the possible values of alarm states. An alarm is a 538 persistent indication of an error or warning condition. 540 When no bits of this attribute are set, then no active alarms 541 are known against this component and it is not under repair."; 542 reference "RFC 4268: EntityAlarmStatus"; 543 } 545 typedef standby-state { 546 type enumeration { 547 enum unknown { 548 value 1; 549 description 550 "The resource is unable to report standby state."; 551 } 552 enum hot-standby { 553 value 2; 554 description 555 "The resource is not providing service, but it will be 556 immediately able to take over the role of the resource to 557 be backed up, without the need for initialization 558 activity, and will contain the same information as the 559 resource to be backed up."; 560 } 561 enum cold-standby { 562 value 3; 563 description 564 "The resource is to back up another resource, but will not 565 be immediately able to take over the role of a resource to 566 be backed up, and will require some initialization 567 activity."; 568 } 569 enum providing-service { 570 value 4; 571 description 572 "The resource is providing service."; 573 } 574 } 575 description 576 "Represents the possible values of standby states."; 577 reference "RFC 4268: EntityStandbyStatus"; 578 } 580 typedef sensor-value-type { 581 type enumeration { 582 enum other { 583 value 1; 584 description 585 "A measure other than those listed below."; 586 } 587 enum unknown { 588 value 2; 589 description 590 "An unknown measurement, or arbitrary, relative numbers"; 591 } 592 enum volts-AC { 593 value 3; 594 description 595 "A measure of electric potential (alternating current)."; 596 } 597 enum volts-DC { 598 value 4; 599 description 600 "A measure of electric potential (direct current)."; 601 } 602 enum amperes { 603 value 5; 604 description 605 "A measure of electric current."; 607 } 608 enum watts { 609 value 6; 610 description 611 "A measure of power."; 612 } 613 enum hertz { 614 value 7; 615 description 616 "A measure of frequency."; 617 } 618 enum celsius { 619 value 8; 620 description 621 "A measure of temperature."; 622 } 623 enum percent-RH { 624 value 9; 625 description 626 "A measure of percent relative humidity."; 627 } 628 enum rpm { 629 value 10; 630 description 631 "A measure of shaft revolutions per minute."; 632 } 633 enum cmm { 634 value 11; 635 description 636 "A measure of cubic meters per minute (airflow)."; 637 } 638 enum truth-value { 639 value 12; 640 description 641 "Value is one of 1 (true) or 2 (false)"; 642 } 643 } 644 description 645 "A node using this data type represents the sensor measurement 646 data type associated with a physical sensor value. The actual 647 data units are determined by examining a node of this type 648 together with the associated sensor-value-scale node. 650 A node of this type SHOULD be defined together with nodes of 651 type sensor-value-scale and sensor-value-precision. These 652 three types are used to identify the semantics of a node of 653 type sensor-value."; 654 reference "RFC 3433: EntitySensorDataType"; 656 } 658 typedef sensor-value-scale { 659 type enumeration { 660 enum yocto { 661 value 1; 662 description 663 "Data scaling factor of 10^-24."; 664 } 665 enum zepto { 666 value 2; 667 description 668 "Data scaling factor of 10^-21."; 669 } 670 enum atto { 671 value 3; 672 description 673 "Data scaling factor of 10^-18."; 674 } 675 enum femto { 676 value 4; 677 description 678 "Data scaling factor of 10^-15."; 679 } 680 enum pico { 681 value 5; 682 description 683 "Data scaling factor of 10^-12."; 684 } 685 enum nano { 686 value 6; 687 description 688 "Data scaling factor of 10^-9."; 689 } 690 enum micro { 691 value 7; 692 description 693 "Data scaling factor of 10^-6."; 694 } 695 enum milli { 696 value 8; 697 description 698 "Data scaling factor of 10^-3."; 699 } 700 enum units { 701 value 9; 702 description 703 "Data scaling factor of 10^0."; 705 } 706 enum kilo { 707 value 10; 708 description 709 "Data scaling factor of 10^3."; 710 } 711 enum mega { 712 value 11; 713 description 714 "Data scaling factor of 10^6."; 715 } 716 enum giga { 717 value 12; 718 description 719 "Data scaling factor of 10^9."; 720 } 721 enum tera { 722 value 13; 723 description 724 "Data scaling factor of 10^12."; 725 } 726 enum exa { 727 value 14; 728 description 729 "Data scaling factor of 10^15."; 730 } 731 enum peta { 732 value 15; 733 description 734 "Data scaling factor of 10^18."; 735 } 736 enum zetta { 737 value 16; 738 description 739 "Data scaling factor of 10^21."; 740 } 741 enum yotta { 742 value 17; 743 description 744 "Data scaling factor of 10^24."; 745 } 746 } 747 description 748 "A node using this data type represents a data scaling factor, 749 represented with an International System of Units (SI) prefix. 750 The actual data units are determined by examining a node of 751 this type together with the associated sensor-value-type. 753 A node of this type SHOULD be defined together with nodes of 754 type sensor-value-type and sensor-value-precision. Together, 755 associated nodes of these three types are used to identify the 756 semantics of a node of type sensor-value."; 757 reference "RFC 3433: EntitySensorDataScale"; 758 } 760 typedef sensor-value-precision { 761 type int32 { 762 range "-8 .. 9"; 763 } 764 description 765 "A node using this data type represents a sensor value 766 precision range. 768 A node of this type SHOULD be defined together with nodes of 769 type sensor-value-type and sensor-value-scale. Together, 770 associated nodes of these three types are used to identify the 771 semantics of a node of type sensor-value. 773 If a node of this type contains a value in the range 1 to 9, 774 it represents the number of decimal places in the fractional 775 part of an associated sensor-value fixed- point number. 777 If a node of this type contains a value in the range -8 to -1, 778 it represents the number of accurate digits in the associated 779 sensor-value fixed-point number. 781 The value zero indicates the associated sensor-value node is 782 not a fixed-point number. 784 Server implementers must choose a value for the associated 785 sensor-value-precision node so that the precision and accuracy 786 of the associated sensor-value node is correctly indicated. 788 For example, a component representing a temperature sensor 789 that can measure 0 degrees to 100 degrees C in 0.1 degree 790 increments, +/- 0.05 degrees, would have an 791 sensor-value-precision value of '1', an sensor-value-scale 792 value of 'units', and an sensor-value ranging from '0' to 793 '1000'. The sensor-value would be interpreted as 794 'degrees C * 10'."; 795 reference "RFC 3433: EntitySensorPrecision"; 796 } 798 typedef sensor-value { 799 type int32 { 800 range "-1000000000 .. 1000000000"; 802 } 803 description 804 "A node using this data type represents an sensor value. 806 A node of this type SHOULD be defined together with nodes of 807 type sensor-value-type, sensor-value-scale, and 808 sensor-value-precision. Together, associated nodes of those 809 three types are used to identify the semantics of a node of 810 this data type. 812 The semantics of a node using this data type are determined by 813 the value of the associated sensor-value-type node. 815 If the associated sensor-value-type node is equal to 'voltsAC', 816 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 817 then a node of this type MUST contain a fixed point number 818 ranging from -999,999,999 to +999,999,999. The value 819 -1000000000 indicates an underflow error. The value +1000000000 820 indicates an overflow error. The sensor-value-precision 821 indicates how many fractional digits are represented in the 822 associated sensor-value node. 824 If the associated sensor-value-type node is equal to 825 'percentRH', then a node of this type MUST contain a number 826 ranging from 0 to 100. 828 If the associated sensor-value-type node is equal to 'rpm', 829 then a node of this type MUST contain a number ranging from 830 -999,999,999 to +999,999,999. 832 If the associated sensor-value-type node is equal to 833 'truth-value', then a node of this type MUST contain either the 834 value 1 (true) or the value 2 (false)'. 836 If the associated sensor-value-type node is equal to 'other' or 837 unknown', then a node of this type MUST contain a number 838 ranging from -1000000000 to 1000000000."; 839 reference "RFC 3433: EntitySensorValue"; 840 } 842 typedef sensor-status { 843 type enumeration { 844 enum ok { 845 value 1; 846 description 847 "Indicates that the server can obtain the sensor value."; 848 } 849 enum unavailable { 850 value 2; 851 description 852 "Indicates that the server presently cannot obtain the 853 sensor value."; 854 } 855 enum nonoperational { 856 value 3; 857 description 858 "Indicates that the server believes the sensor is broken. 859 The sensor could have a hard failure (disconnected wire), 860 or a soft failure such as out-of-range, jittery, or wildly 861 fluctuating readings."; 862 } 863 } 864 description 865 "A node using this data type represents the operational status 866 of a physical sensor."; 867 reference "RFC 3433: EntitySensorStatus"; 868 } 870 /* 871 * Data nodes 872 */ 874 container hardware { 875 description 876 "Data nodes representing components. 878 If the server supports configuration of hardware components, 879 then this data model is instantiated in the configuration 880 datastores supported by the server. The leaf-list 'datastore' 881 for the module 'ietf-hardware' in the YANG library provides 882 this information."; 884 leaf last-change { 885 type yang:date-and-time; 886 config false; 887 description 888 "The time the '/hardware/component' list changed in the 889 operational state."; 890 } 892 list component { 893 key name; 894 description 895 "List of components. 897 When the server detects a new hardware component, it 898 initializes a list entry in the operational state. 900 If the server does not support configuration of hardware 901 components, list entries in the operational state are 902 initialized with values for all nodes as detected by the 903 implementation. 905 Otherwise, the following procedure is followed: 907 1. If there is an entry in the /hardware/component list in 908 the intended configuration with values for the nodes 909 'class', 'parent', 'parent-rel-pos' that are equal to 910 the detected values, then: 912 1a. If the configured entry has a value for 'mfg-name' 913 that is equal to the detected value, or if the 914 'mfg-name' value cannot be detected, then the list 915 entry in the operational state is initialized with the 916 configured values for all configured nodes, including 917 the 'name'. 919 Otherwise, the list entry in the operational state is 920 initialized with values for all nodes as detected by 921 the implementation. The implementation may raise an 922 alarm that informs about the 'mfg-name' mismatch 923 condition. How this is done is outside the scope of 924 this document. 926 1b. Otherwise (i.e., there is no matching configuration 927 entry), the list entry in the operational state is 928 initialized with values for all nodes as detected by 929 the implementation. 931 If the /hardware/component list in the intended 932 configuration is modified, then the system MUST behave as if 933 it re-initializes itself, and follow the procedure in (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 config false; 962 description 963 "The entPhysicalIndex for the entPhysicalEntry represented 964 by this list entry."; 965 reference "RFC 6933: entPhysicalIndex"; 966 } 968 leaf description { 969 type string; 970 config false; 971 description 972 "A textual description of component. This node should 973 contain a string that identifies the manufacturer's name 974 for the component and should be set to a distinct value 975 for each version or model of the component."; 976 reference "RFC 6933: entPhysicalDescr"; 977 } 979 leaf parent { 980 type leafref { 981 path "../../component/name"; 982 require-instance false; 983 } 984 description 985 "The name of the component that physically contains this 986 component. 988 If this leaf is not instantiated, it indicates that this 989 component is not contained in any other component. 991 In the event that a physical component is contained by 992 more than one physical component (e.g., double-wide 993 modules), this node contains the name of one of these 994 components. An implementation MUST use the same name 995 every time this node is instantiated."; 996 reference "RFC 6933: entPhysicalContainedIn"; 997 } 999 leaf parent-rel-pos { 1000 type int32 { 1001 range "0 .. 2147483647"; 1002 } 1003 description 1004 "An indication of the relative position of this child 1005 component among all its sibling components. Sibling 1006 components are defined as components that: 1008 o Share the same value of the 'parent' node; and 1010 o Share a common base identity for the 'class' node. 1012 Note that the last rule gives implementations flexibility 1013 in how components are numbered. For example, some 1014 implementations might have a single number series for all 1015 components derived from 'ianahw:port', while some others 1016 might have different number series for different 1017 components with identities derived from 'ianahw:port' (for 1018 example, one for RJ45 and one for SFP)."; 1020 reference "RFC 6933: entPhysicalParentRelPos"; 1021 } 1023 leaf-list contains-child { 1024 type leafref { 1025 path "../../component/name"; 1026 } 1027 config false; 1028 description 1029 "The name of the contained component."; 1030 reference "RFC 6933: entPhysicalChildIndex"; 1031 } 1033 leaf hardware-rev { 1034 type string; 1035 config false; 1036 description 1037 "The vendor-specific hardware revision string for the 1038 component. The preferred value is the hardware revision 1039 identifier actually printed on the component itself (if 1040 present)."; 1041 reference "RFC 6933: entPhysicalHardwareRev"; 1043 } 1045 leaf firmware-rev { 1046 type string; 1047 config false; 1048 description 1049 "The vendor-specific firmware revision string for the 1050 component."; 1051 reference "RFC 6933: entPhysicalFirmwareRev"; 1052 } 1054 leaf software-rev { 1055 type string; 1056 config false; 1057 description 1058 "The vendor-specific software revision string for the 1059 component."; 1060 reference "RFC 6933: entPhysicalSoftwareRev"; 1061 } 1063 leaf serial-num { 1064 type string; 1065 config false; 1066 description 1067 "The vendor-specific serial number string for the 1068 component. The preferred value is the serial number 1069 string actually printed on the component itself (if 1070 present)."; 1071 reference "RFC 6933: entPhysicalSerialNum"; 1072 } 1074 leaf mfg-name { 1075 type string; 1076 description 1077 "The name of the manufacturer of this physical component. 1078 The preferred value is the manufacturer name string 1079 actually printed on the component itself (if present). 1081 Note that comparisons between instances of the model-name, 1082 firmware-rev, software-rev, and the serial-num nodes are 1083 only meaningful amongst component with the same value of 1084 mfg-name. 1086 If the manufacturer name string associated with the 1087 physical component is unknown to the server, then this 1088 node is not instantiated."; 1089 reference "RFC 6933: entPhysicalMfgName"; 1090 } 1091 leaf model-name { 1092 type string; 1093 config false; 1094 description 1095 "The vendor-specific model name identifier string 1096 associated with this physical component. The preferred 1097 value is the customer-visible part number, which may be 1098 printed on the component itself. 1100 If the model name string associated with the physical 1101 component is unknown to the server, then this node is not 1102 instantiated."; 1103 reference "RFC 6933: entPhysicalModelName"; 1104 } 1106 leaf alias { 1107 type string; 1108 description 1109 "An 'alias' name for the component, as specified by a 1110 network manager, and provides a non-volatile 'handle' for 1111 the component. 1113 If no configured value exists, the server MAY set the 1114 value of this node to a locally unique value in the 1115 operational state. 1117 A server implementation MAY map this leaf to the 1118 entPhysicalAlias MIB object. Such an implementation needs 1119 to use some mechanism to handle the differences in size 1120 and characters allowed between this leaf and 1121 entPhysicalAlias. The definition of such a mechanism is 1122 outside the scope of this document."; 1123 reference "RFC 6933: entPhysicalAlias"; 1124 } 1126 leaf asset-id { 1127 type string; 1128 description 1129 "This node is a user-assigned asset tracking identifier for 1130 the component. 1132 A server implementation MAY map this leaf to the 1133 entPhysicalAssetID MIB object. Such an implementation 1134 needs to use some mechanism to handle the differences in 1135 size and characters allowed between this leaf and 1136 entPhysicalAssetID. The definition of such a mechanism is 1137 outside the scope of this document."; 1138 reference "RFC 6933: entPhysicalAssetID"; 1140 } 1142 leaf is-fru { 1143 type boolean; 1144 config false; 1145 description 1146 "This node indicates whether or not this component is 1147 considered a 'field replaceable unit' by the vendor. If 1148 this node contains the value 'true', then this component 1149 identifies a field replaceable unit. For all components 1150 that are permanently contained within a field replaceable 1151 unit, the value 'false' should be returned for this 1152 node."; 1153 reference "RFC 6933: entPhysicalIsFRU"; 1154 } 1156 leaf mfg-date { 1157 type yang:date-and-time; 1158 config false; 1159 description 1160 "The date of manufacturing of the managed component."; 1161 reference "RFC 6933: entPhysicalMfgDate"; 1162 } 1164 leaf-list uri { 1165 type inet:uri; 1166 description 1167 "This node contains identification information about the 1168 component."; 1169 reference "RFC 6933: entPhysicalUris"; 1170 } 1172 leaf uuid { 1173 type yang:uuid; 1174 config false; 1175 description 1176 "A Universally Unique Identifier of the component."; 1177 reference "RFC 6933: entPhysicalUUID"; 1178 } 1180 container state { 1181 if-feature hardware-state; 1182 description 1183 "State-related nodes"; 1184 reference "RFC 4268: Entity State MIB"; 1186 leaf state-last-changed { 1187 type yang:date-and-time; 1188 config false; 1189 description 1190 "The date and time when the value of any of the 1191 admin-state, oper-state, usage-state, alarm-state, or 1192 standby-state changed for this component. 1194 If there has been no change since the last 1195 re-initialization of the local system, this node 1196 contains the date and time of local system 1197 initialization. If there has been no change since the 1198 component was added to the local system, this node 1199 contains the date and time of the insertion."; 1200 reference "RFC 4268: entStateLastChanged"; 1201 } 1203 leaf admin-state { 1204 type admin-state; 1205 description 1206 "The administrative state for this component. 1208 This node refers to a component's administrative 1209 permission to service both other components within its 1210 containment hierarchy as well other users of its 1211 services defined by means outside the scope of this 1212 module. 1214 Some components exhibit only a subset of the remaining 1215 administrative state values. Some components cannot be 1216 locked, and hence this node exhibits only the 'unlocked' 1217 state. Other components cannot be shutdown gracefully, 1218 and hence this node does not exhibit the 'shutting-down' 1219 state."; 1220 reference "RFC 4268: entStateAdmin"; 1221 } 1223 leaf oper-state { 1224 type oper-state; 1225 config false; 1226 description 1227 "The operational state for this component. 1229 Note that this node does not follow the administrative 1230 state. An administrative state of down does not predict 1231 an operational state of disabled. 1233 Note that some implementations may not be able to 1234 accurately report oper-state while the admin-state node 1235 has a value other than 'unlocked'. In these cases, this 1236 node MUST have a value of 'unknown'."; 1237 reference "RFC 4268: entStateOper"; 1238 } 1240 leaf usage-state { 1241 type usage-state; 1242 config false; 1243 description 1244 "The usage state for this component. 1246 This node refers to a component's ability to service 1247 more components in a containment hierarchy. 1249 Some components will exhibit only a subset of the usage 1250 state values. Components that are unable to ever 1251 service any components within a containment hierarchy 1252 will always have a usage state of 'busy'. Some 1253 components will only ever be able to support one 1254 component within its containment hierarchy and will 1255 therefore only exhibit values of 'idle' and 'busy'."; 1256 reference "RFC 4268, entStateUsage"; 1257 } 1259 leaf alarm-state { 1260 type alarm-state; 1261 config false; 1262 description 1263 "The alarm state for this component. It does not 1264 include the alarms raised on child components within its 1265 containment hierarchy."; 1266 reference "RFC 4268: entStateAlarm"; 1267 } 1269 leaf standby-state { 1270 type standby-state; 1271 config false; 1272 description 1273 "The standby state for this component. 1275 Some components will exhibit only a subset of the 1276 remaining standby state values. If this component 1277 cannot operate in a standby role, the value of this node 1278 will always be 'providing-service'."; 1279 reference "RFC 4268: entStateStandby"; 1280 } 1281 } 1283 container sensor-data { 1284 when 'derived-from-or-self(../class, 1285 "ianahw:sensor")' { 1286 description 1287 "Sensor data nodes present for any component of type 1288 'sensor'"; 1289 } 1290 if-feature hardware-sensor; 1291 config false; 1293 description 1294 "Sensor-related nodes."; 1295 reference "RFC 3433: Entity Sensor MIB"; 1297 leaf value { 1298 type sensor-value; 1299 description 1300 "The most recent measurement obtained by the server 1301 for this sensor. 1303 A client that periodically fetches this node should also 1304 fetch the nodes 'value-type', 'value-scale', and 1305 'value-precision', since they may change when the value 1306 is changed."; 1307 reference "RFC 3433: entPhySensorValue"; 1308 } 1310 leaf value-type { 1311 type sensor-value-type; 1312 description 1313 "The type of data units associated with the 1314 sensor value"; 1315 reference "RFC 3433: entPhySensorType"; 1316 } 1318 leaf value-scale { 1319 type sensor-value-scale; 1320 description 1321 "The (power of 10) scaling factor associated 1322 with the sensor value"; 1323 reference "RFC 3433: entPhySensorScale"; 1324 } 1326 leaf value-precision { 1327 type sensor-value-precision; 1328 description 1329 "The number of decimal places of precision 1330 associated with the sensor value"; 1331 reference "RFC 3433: entPhySensorPrecision"; 1333 } 1335 leaf oper-status { 1336 type sensor-status; 1337 description 1338 "The operational status of the sensor."; 1339 reference "RFC 3433: entPhySensorOperStatus"; 1340 } 1342 leaf units-display { 1343 type string; 1344 description 1345 "A textual description of the data units that should be 1346 used in the display of the sensor value."; 1347 reference "RFC 3433: entPhySensorUnitsDisplay"; 1348 } 1350 leaf value-timestamp { 1351 type yang:date-and-time; 1352 description 1353 "The time the status and/or value of this sensor was last 1354 obtained by the server."; 1355 reference "RFC 3433: entPhySensorValueTimeStamp"; 1356 } 1358 leaf value-update-rate { 1359 type uint32; 1360 units "milliseconds"; 1361 description 1362 "An indication of the frequency that the server updates 1363 the associated 'value' node, representing in 1364 milliseconds. The value zero indicates: 1366 - the sensor value is updated on demand (e.g., 1367 when polled by the server for a get-request), 1368 - the sensor value is updated when the sensor 1369 value changes (event-driven), 1370 - the server does not know the update rate."; 1371 reference "RFC 3433: entPhySensorValueUpdateRate"; 1372 } 1373 } 1374 } 1375 } 1377 /* 1378 * Notifications 1379 */ 1381 notification hardware-state-change { 1382 description 1383 "A hardware-state-change notification is generated when the 1384 value of /hardware/last-change changes in the operational 1385 state."; 1386 reference "RFC 6933, entConfigChange"; 1387 } 1389 notification hardware-state-oper-enabled { 1390 if-feature hardware-state; 1391 description 1392 "A hardware-state-oper-enabled notification signifies that a 1393 component has transitioned into the 'enabled' state."; 1395 leaf name { 1396 type leafref { 1397 path "/hardware/component/name"; 1398 } 1399 description 1400 "The name of the component that has transitioned into the 1401 'enabled' state."; 1402 } 1403 leaf admin-state { 1404 type leafref { 1405 path "/hardware/component/state/admin-state"; 1406 } 1407 description 1408 "The administrative state for the component."; 1409 } 1410 leaf alarm-state { 1411 type leafref { 1412 path "/hardware/component/state/alarm-state"; 1413 } 1414 description 1415 "The alarm state for the component."; 1416 } 1417 reference "RFC 4268, entStateOperEnabled"; 1418 } 1420 notification hardware-state-oper-disabled { 1421 if-feature hardware-state; 1422 description 1423 "A hardware-state-oper-disabled notification signifies that a 1424 component has transitioned into the 'disabled' state."; 1426 leaf name { 1427 type leafref { 1428 path "/hardware/component/name"; 1430 } 1431 description 1432 "The name of the component that has transitioned into the 1433 'disabled' state."; 1434 } 1435 leaf admin-state { 1436 type leafref { 1437 path "/hardware/component/state/admin-state"; 1438 } 1439 description 1440 "The administrative state for the component."; 1441 } 1442 leaf alarm-state { 1443 type leafref { 1444 path "/hardware/component/state/alarm-state"; 1445 } 1446 description 1447 "The alarm state for the component."; 1448 } 1449 reference "RFC 4268, entStateOperDisabled"; 1450 } 1452 } 1454 1456 file "iana-hardware@2017-12-18.yang" 1458 module iana-hardware { 1459 yang-version 1.1; 1460 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1461 prefix ianahw; 1463 organization "IANA"; 1464 contact 1465 " Internet Assigned Numbers Authority 1467 Postal: ICANN 1468 4676 Admiralty Way, Suite 330 1469 Marina del Rey, CA 90292 1471 Tel: +1 310 823 9358 1472 "; 1474 description 1475 "IANA defined identities for hardware class."; 1476 reference 1477 // RFC Ed.: replace XXXX with actual path and remove this note. 1478 "https://www.iana.org/assignments/XXXX"; 1480 // RFC Ed.: replace XXXX with actual RFC number and remove this 1481 // note. 1483 // RFC Ed.: update the date below with the date of RFC publication 1484 // and remove this note. 1485 revision 2017-12-18 { 1486 description 1487 "Initial revision."; 1488 reference 1489 "RFC XXXX: A YANG Data Model for Hardware Management"; 1490 } 1492 /* 1493 * Identities 1494 */ 1496 identity hardware-class { 1497 description 1498 "This identity is the base for all hardware class 1499 identifiers."; 1500 } 1502 identity unknown { 1503 base ianahw:hardware-class; 1504 description 1505 "This identity is applicable if the hardware class is unknown 1506 to the server."; 1507 } 1509 identity chassis { 1510 base ianahw:hardware-class; 1511 description 1512 "This identity is applicable if the hardware class is an 1513 overall container for networking equipment. Any class of 1514 physical component, except a stack, may be contained within a 1515 chassis; a chassis may only be contained within a stack."; 1516 } 1518 identity backplane { 1519 base ianahw:hardware-class; 1520 description 1521 "This identity is applicable if the hardware class is some sort 1522 of device for aggregating and forwarding networking traffic, 1523 such as a shared backplane in a modular ethernet switch. Note 1524 that an implementation may model a backplane as a single 1525 physical component, which is actually implemented as multiple 1526 discrete physical components (within a chassis or stack)."; 1527 } 1529 identity container { 1530 base ianahw:hardware-class; 1531 description 1532 "This identity is applicable if the hardware class is capable 1533 of containing one or more removable physical entities, 1534 possibly of different types. For example, each (empty or 1535 full) slot in a chassis will be modeled as a container. Note 1536 that all removable physical components should be modeled 1537 within a container component, such as field-replaceable 1538 modules, fans, or power supplies. Note that all known 1539 containers should be modeled by the agent, including empty 1540 containers."; 1541 } 1543 identity power-supply { 1544 base ianahw:hardware-class; 1545 description 1546 "This identity is applicable if the hardware class is a 1547 power-supplying component."; 1548 } 1550 identity fan { 1551 base ianahw:hardware-class; 1552 description 1553 "This identity is applicable if the hardware class is a fan or 1554 other heat-reduction component."; 1555 } 1557 identity sensor { 1558 base ianahw:hardware-class; 1559 description 1560 "This identity is applicable if the hardware class is some sort 1561 of sensor, such as a temperature sensor within a router 1562 chassis."; 1563 } 1565 identity module { 1566 base ianahw:hardware-class; 1567 description 1568 "This identity is applicable if the hardware class is some sort 1569 of self-contained sub-system. If a module component is 1570 removable, then it should be modeled within a container 1571 component; otherwise, it should be modeled directly within 1572 another physical component (e.g., a chassis or another 1573 module)."; 1574 } 1576 identity port { 1577 base ianahw:hardware-class; 1578 description 1579 "This identity is applicable if the hardware class is some sort 1580 of networking port, capable of receiving and/or transmitting 1581 networking traffic."; 1582 } 1584 identity stack { 1585 base ianahw:hardware-class; 1586 description 1587 "This identity is applicable if the hardware class is some sort 1588 of super-container (possibly virtual) intended to group 1589 together multiple chassis entities. A stack may be realized 1590 by a virtual cable, a real interconnect cable attached to 1591 multiple chassis, or multiple interconnect cables. A stack 1592 should not be modeled within any other physical components, 1593 but a stack may be contained within another stack. Only 1594 chassis components should be contained within a stack."; 1595 } 1597 identity cpu { 1598 base ianahw:hardware-class; 1599 description 1600 "This identity is applicable if the hardware class is some sort 1601 of central processing unit."; 1602 } 1604 identity energy-object { 1605 base ianahw:hardware-class; 1606 description 1607 "This identity is applicable if the hardware class is some sort 1608 of energy object, i.e., a piece of equipment that is part of 1609 or attached to a communications network that is monitored, 1610 controlled, or aids in the management of another device for 1611 Energy Management."; 1612 } 1614 identity battery { 1615 base ianahw:hardware-class; 1616 description 1617 "This identity is applicable if the hardware class is some sort 1618 of battery."; 1619 } 1620 identity storage-drive { 1621 base ianahw:hardware-class; 1622 description 1623 "This identity is applicable if the hardware class is some sort 1624 of component with data storage capability as main 1625 functionality, e.g., disk drive (HDD), solid state device 1626 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1627 } 1628 } 1630 1632 8. IANA Considerations 1634 This document defines the initial version of the IANA-maintained 1635 "iana-hardware" YANG module. 1637 The "iana-hardware" YANG module is intended to reflect the 1638 "IANA-ENTITY-MIB" MIB module so that if a new enumeration is added to 1639 the "IANAPhysicalClass" TEXTUAL-CONVENTION, the same class is added 1640 as an identity derived from "ianahw:hardware-class". 1642 When the "iana-hardware" YANG module is updated, a new "revision" 1643 statement must be added in front of the existing revision statements. 1645 8.1. URI Registrations 1647 This document registers three URIs in the IETF XML registry 1648 [RFC3688]. Following the format in RFC 3688, the following 1649 registrations are requested to be made. 1651 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1652 Registrant Contact: The IESG. 1653 XML: N/A, the requested URI is an XML namespace. 1655 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1656 Registrant Contact: The IESG. 1657 XML: N/A, the requested URI is an XML namespace. 1659 URI: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1660 Registrant Contact: The IESG. 1661 XML: N/A, the requested URI is an XML namespace. 1663 8.2. YANG Module Registrations 1665 This document registers three YANG modules in the YANG Module Names 1666 registry [RFC6020]. 1668 name: iana-hardware 1669 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1670 prefix: ianahw 1671 reference: RFC XXXX 1673 name: ietf-hardware 1674 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1675 prefix: hw 1676 reference: RFC XXXX 1678 name: ietf-hardware-state 1679 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1680 prefix: hw-state 1681 reference: RFC XXXX 1683 9. Security Considerations 1685 The YANG modules defined in this document are designed to be accessed 1686 via network management protocols such as NETCONF [RFC6241] or 1687 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1688 layer, and the mandatory-to-implement secure transport is Secure 1689 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1690 mandatory-to-implement secure transport is TLS [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-07 1741 (work in progress), November 2017. 1743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1744 Requirement Levels", BCP 14, RFC 2119, 1745 DOI 10.17487/RFC2119, March 1997, . 1748 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1749 Management Information Base", RFC 3433, 1750 DOI 10.17487/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, 1763 DOI 10.17487/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, 1782 DOI 10.17487/RFC6536, March 2012, . 1785 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1786 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1787 DOI 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-02 (work in progress), 1807 October 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 +--ro hardware 1819 +--ro last-change? yang:date-and-time 1820 +--ro component* [name] 1821 +--ro name string 1822 +--ro class identityref 1823 +--ro physical-index? int32 {entity-mib}? 1824 +--ro description? string 1825 +--ro parent? -> ../../component/name 1826 +--ro parent-rel-pos? int32 1827 +--ro contains-child* -> ../../component/name 1828 +--ro hardware-rev? string 1829 +--ro firmware-rev? string 1830 +--ro software-rev? string 1831 +--ro serial-num? string 1832 +--ro mfg-name? string 1833 +--ro model-name? string 1834 +--ro alias? string 1835 +--ro asset-id? string 1836 +--ro is-fru? boolean 1837 +--ro mfg-date? yang:date-and-time 1838 +--ro uri* inet:uri 1839 +--ro uuid? yang:uuid 1840 +--ro state {hardware-state}? 1841 | +--ro state-last-changed? yang:date-and-time 1842 | +--ro admin-state? hw:admin-state 1843 | +--ro oper-state? hw:oper-state 1844 | +--ro usage-state? hw:usage-state 1845 | +--ro alarm-state? hw:alarm-state 1846 | +--ro standby-state? hw:standby-state 1847 +--ro sensor-data {hardware-sensor}? 1848 +--ro value? hw:sensor-value 1849 +--ro value-type? hw:sensor-value-type 1850 +--ro value-scale? hw:sensor-value-scale 1851 +--ro value-precision? hw:sensor-value-precision 1852 +--ro oper-status? hw:sensor-status 1853 +--ro units-display? string 1854 +--ro value-timestamp? yang:date-and-time 1855 +--ro value-update-rate? uint32 1857 notifications: 1858 +---n hardware-state-change 1859 +---n hardware-state-oper-enabled {hardware-state}? 1860 | +--ro name? -> /hardware/component/name 1861 | +--ro admin-state? -> /hardware/component/state/admin-state 1862 | +--ro alarm-state? -> /hardware/component/state/alarm-state 1863 +---n hardware-state-oper-disabled {hardware-state}? 1864 +--ro name? -> /hardware/component/name 1865 +--ro admin-state? -> /hardware/component/state/admin-state 1866 +--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 description 1960 "This feature indicates that the device implements 1961 the ENTITY-MIB."; 1962 reference "RFC 6933: Entity MIB (Version 4)"; 1963 } 1965 feature hardware-state { 1966 description 1967 "Indicates the ENTITY-STATE-MIB objects are supported"; 1968 reference "RFC 4268: Entity State MIB"; 1969 } 1971 feature hardware-sensor { 1972 description 1973 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 1974 reference "RFC 3433: Entity Sensor MIB"; 1975 } 1977 /* 1978 * Data nodes 1979 */ 1981 container hardware { 1982 config false; 1983 description 1984 "Data nodes representing components."; 1986 leaf last-change { 1987 type yang:date-and-time; 1988 description 1989 "The time the '/hardware/component' list changed in the 1990 operational state."; 1991 } 1993 list component { 1994 key name; 1995 description 1996 "List of components. 1998 When the server detects a new hardware component, it 1999 initializes a list entry in the operational state. 2001 If the server does not support configuration of hardware 2002 components, list entries in the operational state are 2003 initialized with values for all nodes as detected by the 2004 implementation. 2006 Otherwise, the following procedure is followed: 2008 1. If there is an entry in the /hardware/component list in 2009 the intended configuration with values for the nodes 2010 'class', 'parent', 'parent-rel-pos' that are equal to 2011 the detected values, then: 2013 1a. If the configured entry has a value for 'mfg-name' 2014 that is equal to the detected value, or if the 2015 'mfg-name' value cannot be detected, then the list 2016 entry in the operational state is initialized with the 2017 configured values for all configured nodes, including 2018 the 'name'. 2020 Otherwise, the list entry in the operational state is 2021 initialized with values for all nodes as detected by 2022 the implementation. The implementation may raise an 2023 alarm that informs about the 'mfg-name' mismatch 2024 condition. How this is done is outside the scope of 2025 this document. 2027 1b. Otherwise (i.e., there is no matching configuration 2028 entry), the list entry in the operational state is 2029 initialized with values for all nodes as detected by 2030 the implementation. 2032 If the /hardware/component list in the intended 2033 configuration is modified, then the system MUST behave as if 2034 it re-initializes itself, and follow the procedure in (1)."; 2035 reference "RFC 6933: entPhysicalEntry"; 2037 leaf name { 2038 type string; 2039 description 2040 "The name assigned to this component. 2042 This name is not required to be the same as 2043 entPhysicalName."; 2044 } 2046 leaf class { 2047 type identityref { 2048 base ianahw:hardware-class; 2049 } 2050 mandatory true; 2051 description 2052 "An indication of the general hardware type of the 2053 component."; 2054 reference "RFC 6933: entPhysicalClass"; 2055 } 2057 leaf physical-index { 2058 if-feature entity-mib; 2059 type int32 { 2060 range "1..2147483647"; 2061 } 2062 description 2063 "The entPhysicalIndex for the entPhysicalEntry represented 2064 by this list entry."; 2065 reference "RFC 6933: entPhysicalIndex"; 2066 } 2068 leaf description { 2069 type string; 2070 description 2071 "A textual description of component. This node should 2072 contain a string that identifies the manufacturer's name 2073 for the component and should be set to a distinct value 2074 for each version or model of the component."; 2075 reference "RFC 6933: entPhysicalDescr"; 2076 } 2078 leaf parent { 2079 type leafref { 2080 path "../../component/name"; 2081 require-instance false; 2082 } 2083 description 2084 "The name of the component that physically contains this 2085 component. 2087 If this leaf is not instantiated, it indicates that this 2088 component is not contained in any other component. 2090 In the event that a physical component is contained by 2091 more than one physical component (e.g., double-wide 2092 modules), this node contains the name of one of these 2093 components. An implementation MUST use the same name 2094 every time this node is instantiated."; 2095 reference "RFC 6933: entPhysicalContainedIn"; 2096 } 2097 leaf parent-rel-pos { 2098 type int32 { 2099 range "0 .. 2147483647"; 2100 } 2101 description 2102 "An indication of the relative position of this child 2103 component among all its sibling components. Sibling 2104 components are defined as components that: 2106 o Share the same value of the 'parent' node; and 2108 o Share a common base identity for the 'class' node. 2110 Note that the last rule gives implementations flexibility 2111 in how components are numbered. For example, some 2112 implementations might have a single number series for all 2113 components derived from 'ianahw:port', while some others 2114 might have different number series for different 2115 components with identities derived from 'ianahw:port' (for 2116 example, one for RJ45 and one for SFP)."; 2118 reference "RFC 6933: entPhysicalParentRelPos"; 2119 } 2121 leaf-list contains-child { 2122 type leafref { 2123 path "../../component/name"; 2124 } 2125 description 2126 "The name of the contained component."; 2127 reference "RFC 6933: entPhysicalChildIndex"; 2128 } 2130 leaf hardware-rev { 2131 type string; 2132 description 2133 "The vendor-specific hardware revision string for the 2134 component. The preferred value is the hardware revision 2135 identifier actually printed on the component itself (if 2136 present)."; 2137 reference "RFC 6933: entPhysicalHardwareRev"; 2138 } 2140 leaf firmware-rev { 2141 type string; 2142 description 2143 "The vendor-specific firmware revision string for the 2144 component."; 2146 reference "RFC 6933: entPhysicalFirmwareRev"; 2147 } 2149 leaf software-rev { 2150 type string; 2151 description 2152 "The vendor-specific software revision string for the 2153 component."; 2154 reference "RFC 6933: entPhysicalSoftwareRev"; 2155 } 2157 leaf serial-num { 2158 type string; 2159 description 2160 "The vendor-specific serial number string for the 2161 component. The preferred value is the serial number 2162 string actually printed on the component itself (if 2163 present)."; 2164 reference "RFC 6933: entPhysicalSerialNum"; 2165 } 2167 leaf mfg-name { 2168 type string; 2169 description 2170 "The name of the manufacturer of this physical component. 2171 The preferred value is the manufacturer name string 2172 actually printed on the component itself (if present). 2174 Note that comparisons between instances of the model-name, 2175 firmware-rev, software-rev, and the serial-num nodes are 2176 only meaningful amongst component with the same value of 2177 mfg-name. 2179 If the manufacturer name string associated with the 2180 physical component is unknown to the server, then this 2181 node is not instantiated."; 2182 reference "RFC 6933: entPhysicalMfgName"; 2183 } 2185 leaf model-name { 2186 type string; 2187 description 2188 "The vendor-specific model name identifier string 2189 associated with this physical component. The preferred 2190 value is the customer-visible part number, which may be 2191 printed on the component itself. 2193 If the model name string associated with the physical 2194 component is unknown to the server, then this node is not 2195 instantiated."; 2196 reference "RFC 6933: entPhysicalModelName"; 2197 } 2199 leaf alias { 2200 type string; 2201 description 2202 "An 'alias' name for the component, as specified by a 2203 network manager, and provides a non-volatile 'handle' for 2204 the component. 2206 If no configured value exists, the server MAY set the 2207 value of this node to a locally unique value in the 2208 operational state. 2210 A server implementation MAY map this leaf to the 2211 entPhysicalAlias MIB object. Such an implementation needs 2212 to use some mechanism to handle the differences in size 2213 and characters allowed between this leaf and 2214 entPhysicalAlias. The definition of such a mechanism is 2215 outside the scope of this document."; 2216 reference "RFC 6933: entPhysicalAlias"; 2217 } 2219 leaf asset-id { 2220 type string; 2221 description 2222 "This node is a user-assigned asset tracking identifier for 2223 the component. 2225 A server implementation MAY map this leaf to the 2226 entPhysicalAssetID MIB object. Such an implementation 2227 needs to use some mechanism to handle the differences in 2228 size and characters allowed between this leaf and 2229 entPhysicalAssetID. The definition of such a mechanism is 2230 outside the scope of this document."; 2231 reference "RFC 6933: entPhysicalAssetID"; 2232 } 2234 leaf is-fru { 2235 type boolean; 2236 description 2237 "This node indicates whether or not this component is 2238 considered a 'field replaceable unit' by the vendor. If 2239 this node contains the value 'true', then this component 2240 identifies a field replaceable unit. For all components 2241 that are permanently contained within a field replaceable 2242 unit, the value 'false' should be returned for this 2243 node."; 2244 reference "RFC 6933: entPhysicalIsFRU"; 2245 } 2247 leaf mfg-date { 2248 type yang:date-and-time; 2249 description 2250 "The date of manufacturing of the managed component."; 2251 reference "RFC 6933: entPhysicalMfgDate"; 2252 } 2254 leaf-list uri { 2255 type inet:uri; 2256 description 2257 "This node contains identification information about the 2258 component."; 2259 reference "RFC 6933: entPhysicalUris"; 2260 } 2262 leaf uuid { 2263 type yang:uuid; 2264 description 2265 "A Universally Unique Identifier of the component."; 2266 reference "RFC 6933: entPhysicalUUID"; 2267 } 2269 container state { 2270 if-feature hardware-state; 2271 description 2272 "State-related nodes"; 2273 reference "RFC 4268: Entity State MIB"; 2275 leaf state-last-changed { 2276 type yang:date-and-time; 2277 description 2278 "The date and time when the value of any of the 2279 admin-state, oper-state, usage-state, alarm-state, or 2280 standby-state changed for this component. 2282 If there has been no change since the last 2283 re-initialization of the local system, this node 2284 contains the date and time of local system 2285 initialization. If there has been no change since the 2286 component was added to the local system, this node 2287 contains the date and time of the insertion."; 2288 reference "RFC 4268: entStateLastChanged"; 2289 } 2290 leaf admin-state { 2291 type hw:admin-state; 2292 description 2293 "The administrative state for this component. 2295 This node refers to a component's administrative 2296 permission to service both other components within its 2297 containment hierarchy as well other users of its 2298 services defined by means outside the scope of this 2299 module. 2301 Some components exhibit only a subset of the remaining 2302 administrative state values. Some components cannot be 2303 locked, and hence this node exhibits only the 'unlocked' 2304 state. Other components cannot be shutdown gracefully, 2305 and hence this node does not exhibit the 'shutting-down' 2306 state."; 2307 reference "RFC 4268: entStateAdmin"; 2308 } 2310 leaf oper-state { 2311 type hw:oper-state; 2312 description 2313 "The operational state for this component. 2315 Note that this node does not follow the administrative 2316 state. An administrative state of down does not predict 2317 an operational state of disabled. 2319 Note that some implementations may not be able to 2320 accurately report oper-state while the admin-state node 2321 has a value other than 'unlocked'. In these cases, this 2322 node MUST have a value of 'unknown'."; 2323 reference "RFC 4268: entStateOper"; 2324 } 2326 leaf usage-state { 2327 type hw:usage-state; 2328 description 2329 "The usage state for this component. 2331 This node refers to a component's ability to service 2332 more components in a containment hierarchy. 2334 Some components will exhibit only a subset of the usage 2335 state values. Components that are unable to ever 2336 service any components within a containment hierarchy 2337 will always have a usage state of 'busy'. Some 2338 components will only ever be able to support one 2339 component within its containment hierarchy and will 2340 therefore only exhibit values of 'idle' and 'busy'."; 2341 reference "RFC 4268, entStateUsage"; 2342 } 2344 leaf alarm-state { 2345 type hw:alarm-state; 2346 description 2347 "The alarm state for this component. It does not 2348 include the alarms raised on child components within its 2349 containment hierarchy."; 2350 reference "RFC 4268: entStateAlarm"; 2351 } 2353 leaf standby-state { 2354 type hw:standby-state; 2355 description 2356 "The standby state for this component. 2358 Some components will exhibit only a subset of the 2359 remaining standby state values. If this component 2360 cannot operate in a standby role, the value of this node 2361 will always be 'providing-service'."; 2362 reference "RFC 4268: entStateStandby"; 2363 } 2364 } 2366 container sensor-data { 2367 when 'derived-from-or-self(../class, 2368 "ianahw:sensor")' { 2369 description 2370 "Sensor data nodes present for any component of type 2371 'sensor'"; 2372 } 2373 if-feature hardware-sensor; 2375 description 2376 "Sensor-related nodes."; 2377 reference "RFC 3433: Entity Sensor MIB"; 2379 leaf value { 2380 type hw:sensor-value; 2381 description 2382 "The most recent measurement obtained by the server 2383 for this sensor. 2385 A client that periodically fetches this node should also 2386 fetch the nodes 'value-type', 'value-scale', and 2387 'value-precision', since they may change when the value 2388 is changed."; 2389 reference "RFC 3433: entPhySensorValue"; 2390 } 2392 leaf value-type { 2393 type hw:sensor-value-type; 2394 description 2395 "The type of data units associated with the 2396 sensor value"; 2397 reference "RFC 3433: entPhySensorType"; 2398 } 2400 leaf value-scale { 2401 type hw:sensor-value-scale; 2402 description 2403 "The (power of 10) scaling factor associated 2404 with the sensor value"; 2405 reference "RFC 3433: entPhySensorScale"; 2406 } 2408 leaf value-precision { 2409 type hw:sensor-value-precision; 2410 description 2411 "The number of decimal places of precision 2412 associated with the sensor value"; 2413 reference "RFC 3433: entPhySensorPrecision"; 2414 } 2416 leaf oper-status { 2417 type hw:sensor-status; 2418 description 2419 "The operational status of the sensor."; 2420 reference "RFC 3433: entPhySensorOperStatus"; 2421 } 2423 leaf units-display { 2424 type string; 2425 description 2426 "A textual description of the data units that should be 2427 used in the display of the sensor value."; 2428 reference "RFC 3433: entPhySensorUnitsDisplay"; 2429 } 2431 leaf value-timestamp { 2432 type yang:date-and-time; 2433 description 2434 "The time the status and/or value of this sensor was last 2435 obtained by the server."; 2436 reference "RFC 3433: entPhySensorValueTimeStamp"; 2437 } 2439 leaf value-update-rate { 2440 type uint32; 2441 units "milliseconds"; 2442 description 2443 "An indication of the frequency that the server updates 2444 the associated 'value' node, representing in 2445 milliseconds. The value zero indicates: 2447 - the sensor value is updated on demand (e.g., 2448 when polled by the server for a get-request), 2449 - the sensor value is updated when the sensor 2450 value changes (event-driven), 2451 - the server does not know the update rate."; 2452 reference "RFC 3433: entPhySensorValueUpdateRate"; 2453 } 2454 } 2455 } 2456 } 2458 /* 2459 * Notifications 2460 */ 2462 notification hardware-state-change { 2463 description 2464 "A hardware-state-change notification is generated when the 2465 value of /hardware/last-change changes in the operational 2466 state."; 2467 reference "RFC 6933, entConfigChange"; 2468 } 2470 notification hardware-state-oper-enabled { 2471 if-feature hardware-state; 2472 description 2473 "A hardware-state-oper-enabled notification signifies that a 2474 component has transitioned into the 'enabled' state."; 2476 leaf name { 2477 type leafref { 2478 path "/hardware/component/name"; 2479 } 2480 description 2481 "The name of the component that has transitioned into the 2482 'enabled' state."; 2483 } 2484 leaf admin-state { 2485 type leafref { 2486 path "/hardware/component/state/admin-state"; 2487 } 2488 description 2489 "The administrative state for the component."; 2490 } 2491 leaf alarm-state { 2492 type leafref { 2493 path "/hardware/component/state/alarm-state"; 2494 } 2495 description 2496 "The alarm state for the component."; 2497 } 2498 reference "RFC 4268, entStateOperEnabled"; 2499 } 2501 notification hardware-state-oper-disabled { 2502 if-feature hardware-state; 2503 description 2504 "A hardware-state-oper-disabled notification signifies that a 2505 component has transitioned into the 'disabled' state."; 2507 leaf name { 2508 type leafref { 2509 path "/hardware/component/name"; 2510 } 2511 description 2512 "The name of the component that has transitioned into the 2513 'disabled' state."; 2514 } 2515 leaf admin-state { 2516 type leafref { 2517 path "/hardware/component/state/admin-state"; 2518 } 2519 description 2520 "The administrative state for the component."; 2521 } 2522 leaf alarm-state { 2523 type leafref { 2524 path "/hardware/component/state/alarm-state"; 2525 } 2526 description 2527 "The alarm state for the component."; 2528 } 2529 reference "RFC 4268, entStateOperDisabled"; 2531 } 2533 } 2535 2537 Authors' Addresses 2539 Andy Bierman 2540 YumaWorks 2542 Email: andy@yumaworks.com 2544 Martin Bjorklund 2545 Tail-f Systems 2547 Email: mbj@tail-f.com 2549 Jie Dong 2550 Huawei Technologies 2552 Email: jie.dong@huawei.com 2554 Dan Romascanu 2556 Email: dromasca@gmail.com