idnits 2.17.1 draft-ietf-netmod-entity-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 22, 2018) is 2279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 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-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bierman 3 Internet-Draft YumaWorks 4 Intended status: Standards Track M. Bjorklund 5 Expires: July 26, 2018 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 9 January 22, 2018 11 A YANG Data Model for Hardware Management 12 draft-ietf-netmod-entity-08 14 Abstract 16 This document defines a YANG data model for the management of 17 hardware on a single server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 26, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . 36 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 70 11.2. Informative References . . . . . . . . . . . . . . . . . 39 71 Appendix A. Hardware State Data Model . . . . . . . . . . . . . 39 72 A.1. Hardware State YANG Module . . . . . . . . . . . . . . . 40 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 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 +--ro 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/component" list in the operational state is mapped to one 214 EntPhysicalEntry. Objects that are writable in the MIB are mapped to 215 "config true" nodes in the "/hardware/component" list, except 216 "entPhysicalSerialNum" which is writable in the MIB, but "config 217 false" in the YANG module. 219 The "physical-index" leaf MUST contain the value of the corresponding 220 entPhysicalEntry's entPhysicalIndex. 222 The "class" leaf is mapped to both entPhysicalClass and 223 entPhysicalVendorType. If the value of the "class" leaf is an 224 identity that is either derived from or is one of the identities in 225 the "iana-hardware" module, then entPhysicalClass contains the 226 corresponding IANAPhysicalClass enumeration value. Otherwise, 227 entPhysicalClass contains the IANAPhysicalClass value "other(1)". 228 Vendors are encouraged to define an identity (derived from an 229 identity in "iana-hardware" if possible) for each enterprise-specific 230 registration identifier used for entPhysicalVendorType, and use that 231 identity for the "class" leaf. 233 The following tables list the YANG data nodes with corresponding 234 objects in the ENTITY-MIB. 236 +--------------------------------+----------------------------------+ 237 | YANG data node in | ENTITY-MIB object | 238 | /hardware/component | | 239 +--------------------------------+----------------------------------+ 240 | name | entPhysicalName | 241 | class | entPhysicalClass | 242 | | entPhysicalVendorType | 243 | physical-index | entPhysicalIndex | 244 | description | entPhysicalDescr | 245 | parent | entPhysicalContainedIn | 246 | parent-rel-pos | entPhysicalParentRelPos | 247 | contains-child | entPhysicalChildIndex | 248 | hardware-rev | entPhysicalHardwareRev | 249 | firmware-rev | entPhysicalFirmwareRev | 250 | software-rev | entPhysicalSoftwareRev | 251 | serial-num | entPhysicalSerialNum | 252 | mfg-name | entPhysicalMfgName | 253 | model-name | entPhysicalModelName | 254 | alias | entPhysicalAlias | 255 | asset-id | entPhysicalAssetID | 256 | is-fru | entPhysicalIsFRU | 257 | mfg-date | entPhysicalMfgDate | 258 | uri | entPhysicalUris | 259 | uuid | entPhysicalUUID | 260 +--------------------------------+----------------------------------+ 262 YANG Data Nodes and Related ENTITY-MIB Objects 264 5. Relationship to ENTITY-SENSOR-MIB 266 If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry 267 in the "/hardware/component" list where the container "sensor-data" 268 exists is mapped to one EntPhySensorEntry. 270 +-------------------------------------+-----------------------------+ 271 | YANG data node in | ENTITY-SENSOR-MIB object | 272 | /hardware/component/sensor-data | | 273 +-------------------------------------+-----------------------------+ 274 | value | entPhySensorValue | 275 | value-type | entPhySensorType | 276 | value-scale | entPhySensorScale | 277 | value-precision | entPhySensorPrecision | 278 | oper-status | entPhySensorOperStatus | 279 | units-display | entPhySensorUnitsDisplay | 280 | value-timestamp | entPhySensorValueTimeStamp | 281 | value-update-rate | entPhySensorValueUpdateRate | 282 +-------------------------------------+-----------------------------+ 284 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 286 6. Relationship to ENTITY-STATE-MIB 288 If the device implements the ENTITY-STATE-MIB [RFC4268], each entry 289 in the "/hardware/component" list where the container "state" exists 290 is mapped to one EntStateEntry. 292 +------------------------------------------+------------------------+ 293 | YANG data node in | ENTITY-STATE-MIB | 294 | /hardware/component/state | object | 295 +------------------------------------------+------------------------+ 296 | state-last-changed | entStateLastChanged | 297 | admin-state | entStateAdmin | 298 | oper-state | entStateOper | 299 | usage-state | entStateUsage | 300 | alarm-state | entStateAlarm | 301 | standby-state | entStateStandby | 302 +------------------------------------------+------------------------+ 304 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 306 7. Hardware YANG Module 308 file "ietf-hardware@2018-01-15.yang" 310 module ietf-hardware { 311 yang-version 1.1; 312 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; 313 prefix hw; 315 import ietf-inet-types { 316 prefix inet; 317 } 318 import ietf-yang-types { 319 prefix yang; 320 } 321 import iana-hardware { 322 prefix ianahw; 323 } 325 organization 326 "IETF NETMOD (Network Modeling) Working Group"; 328 contact 329 "WG Web: 330 WG List: 332 Editor: Andy Bierman 333 335 Editor: Martin Bjorklund 336 338 Editor: Jie Dong 339 341 Editor: Dan Romascanu 342 "; 344 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 345 // remove this note. 347 description 348 "This module contains a collection of YANG definitions for 349 managing hardware. 351 This data model is designed for the Network Management Datastore 352 Architecture defined in RFC YYYY. 354 Copyright (c) 2018 IETF Trust and the persons identified as 355 authors of the code. All rights reserved. 357 Redistribution and use in source and binary forms, with or 358 without modification, is permitted pursuant to, and subject 359 to the license terms contained in, the Simplified BSD License 360 set forth in Section 4.c of the IETF Trust's Legal Provisions 361 Relating to IETF Documents 362 (http://trustee.ietf.org/license-info). 364 This version of this YANG module is part of RFC XXXX; see 365 the RFC itself for full legal notices."; 367 // RFC Ed.: update the date below with the date of RFC publication 368 // and remove this note. 369 revision 2018-01-15 { 370 description 371 "Initial revision."; 372 reference 373 "RFC XXXX: A YANG Data Model for Hardware Management"; 374 } 376 /* 377 * Features 378 */ 380 feature entity-mib { 381 description 382 "This feature indicates that the device implements 383 the ENTITY-MIB."; 384 reference "RFC 6933: Entity MIB (Version 4)"; 385 } 387 feature hardware-state { 388 description 389 "Indicates the ENTITY-STATE-MIB objects are supported"; 390 reference "RFC 4268: Entity State MIB"; 391 } 393 feature hardware-sensor { 394 description 395 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 396 reference "RFC 3433: Entity Sensor MIB"; 397 } 399 /* 400 * Typedefs 401 */ 403 typedef admin-state { 404 type enumeration { 405 enum unknown { 406 value 1; 407 description 408 "The resource is unable to report administrative state."; 409 } 410 enum locked { 411 value 2; 412 description 413 "The resource is administratively prohibited from use."; 414 } 415 enum shutting-down { 416 value 3; 417 description 418 "The resource usage is administratively limited to current 419 instances of use."; 420 } 421 enum unlocked { 422 value 4; 423 description 424 "The resource is not administratively prohibited from 425 use."; 426 } 427 } 428 description 429 "Represents the various possible administrative states."; 430 reference "RFC 4268: EntityAdminState"; 431 } 433 typedef oper-state { 434 type enumeration { 435 enum unknown { 436 value 1; 437 description 438 "The resource is unable to report its operational state."; 439 } 440 enum disabled { 441 value 2; 442 description 443 "The resource is totally inoperable."; 444 } 445 enum enabled { 446 value 3; 447 description 448 "The resource is partially or fully operable."; 449 } 450 enum testing { 451 value 4; 452 description 453 "The resource is currently being tested and cannot 454 therefore report whether it is operational or not."; 455 } 456 } 457 description 458 "Represents the possible values of operational states."; 459 reference "RFC 4268: EntityOperState"; 460 } 462 typedef usage-state { 463 type enumeration { 464 enum unknown { 465 value 1; 466 description 467 "The resource is unable to report usage state."; 468 } 469 enum idle { 470 value 2; 471 description 472 "The resource is servicing no users."; 473 } 474 enum active { 475 value 3; 476 description 477 "The resource is currently in use and it has sufficient 478 spare capacity to provide for additional users."; 479 } 480 enum busy { 481 value 4; 482 description 483 "The resource is currently in use, but it currently has no 484 spare capacity to provide for additional users."; 485 } 486 } 487 description 488 "Represents the possible values of usage states."; 489 reference "RFC 4268, EntityUsageState"; 490 } 492 typedef alarm-state { 493 type bits { 494 bit unknown { 495 position 0; 496 description 497 "The resource is unable to report alarm state."; 498 } 499 bit under-repair { 500 position 1; 501 description 502 "The resource is currently being repaired, which, depending 503 on the implementation, may make the other values in this 504 bit string not meaningful."; 505 } 506 bit critical { 507 position 2; 508 description 509 "One or more critical alarms are active against the 510 resource."; 512 } 513 bit major { 514 position 3; 515 description 516 "One or more major alarms are active against the 517 resource."; 518 } 519 bit minor { 520 position 4; 521 description 522 "One or more minor alarms are active against the 523 resource."; 524 } 525 bit warning { 526 position 5; 527 description 528 "One or more warning alarms are active against the 529 resource."; 530 } 531 bit indeterminate { 532 position 6; 533 description 534 "One or more alarms of whose perceived severity cannot be 535 determined are active against this resource."; 536 } 537 } 538 description 539 "Represents the possible values of alarm states. An alarm is a 540 persistent indication of an error or warning condition. 542 When no bits of this attribute are set, then no active alarms 543 are known against this component and it is not under repair."; 544 reference "RFC 4268: EntityAlarmStatus"; 545 } 547 typedef standby-state { 548 type enumeration { 549 enum unknown { 550 value 1; 551 description 552 "The resource is unable to report standby state."; 553 } 554 enum hot-standby { 555 value 2; 556 description 557 "The resource is not providing service, but it will be 558 immediately able to take over the role of the resource to 559 be backed up, without the need for initialization 560 activity, and will contain the same information as the 561 resource to be backed up."; 562 } 563 enum cold-standby { 564 value 3; 565 description 566 "The resource is to back up another resource, but will not 567 be immediately able to take over the role of a resource to 568 be backed up, and will require some initialization 569 activity."; 570 } 571 enum providing-service { 572 value 4; 573 description 574 "The resource is providing service."; 575 } 576 } 577 description 578 "Represents the possible values of standby states."; 579 reference "RFC 4268: EntityStandbyStatus"; 580 } 582 typedef sensor-value-type { 583 type enumeration { 584 enum other { 585 value 1; 586 description 587 "A measure other than those listed below."; 588 } 589 enum unknown { 590 value 2; 591 description 592 "An unknown measurement, or arbitrary, relative numbers"; 593 } 594 enum volts-AC { 595 value 3; 596 description 597 "A measure of electric potential (alternating current)."; 598 } 599 enum volts-DC { 600 value 4; 601 description 602 "A measure of electric potential (direct current)."; 603 } 604 enum amperes { 605 value 5; 606 description 607 "A measure of electric current."; 609 } 610 enum watts { 611 value 6; 612 description 613 "A measure of power."; 614 } 615 enum hertz { 616 value 7; 617 description 618 "A measure of frequency."; 619 } 620 enum celsius { 621 value 8; 622 description 623 "A measure of temperature."; 624 } 625 enum percent-RH { 626 value 9; 627 description 628 "A measure of percent relative humidity."; 629 } 630 enum rpm { 631 value 10; 632 description 633 "A measure of shaft revolutions per minute."; 634 } 635 enum cmm { 636 value 11; 637 description 638 "A measure of cubic meters per minute (airflow)."; 639 } 640 enum truth-value { 641 value 12; 642 description 643 "Value is one of 1 (true) or 2 (false)"; 644 } 645 } 646 description 647 "A node using this data type represents the sensor measurement 648 data type associated with a physical sensor value. The actual 649 data units are determined by examining a node of this type 650 together with the associated sensor-value-scale node. 652 A node of this type SHOULD be defined together with nodes of 653 type sensor-value-scale and sensor-value-precision. These 654 three types are used to identify the semantics of a node of 655 type sensor-value."; 656 reference "RFC 3433: EntitySensorDataType"; 658 } 660 typedef sensor-value-scale { 661 type enumeration { 662 enum yocto { 663 value 1; 664 description 665 "Data scaling factor of 10^-24."; 666 } 667 enum zepto { 668 value 2; 669 description 670 "Data scaling factor of 10^-21."; 671 } 672 enum atto { 673 value 3; 674 description 675 "Data scaling factor of 10^-18."; 676 } 677 enum femto { 678 value 4; 679 description 680 "Data scaling factor of 10^-15."; 681 } 682 enum pico { 683 value 5; 684 description 685 "Data scaling factor of 10^-12."; 686 } 687 enum nano { 688 value 6; 689 description 690 "Data scaling factor of 10^-9."; 691 } 692 enum micro { 693 value 7; 694 description 695 "Data scaling factor of 10^-6."; 696 } 697 enum milli { 698 value 8; 699 description 700 "Data scaling factor of 10^-3."; 701 } 702 enum units { 703 value 9; 704 description 705 "Data scaling factor of 10^0."; 707 } 708 enum kilo { 709 value 10; 710 description 711 "Data scaling factor of 10^3."; 712 } 713 enum mega { 714 value 11; 715 description 716 "Data scaling factor of 10^6."; 717 } 718 enum giga { 719 value 12; 720 description 721 "Data scaling factor of 10^9."; 722 } 723 enum tera { 724 value 13; 725 description 726 "Data scaling factor of 10^12."; 727 } 728 enum peta { 729 value 14; 730 description 731 "Data scaling factor of 10^15."; 732 } 733 enum exa { 734 value 15; 735 description 736 "Data scaling factor of 10^18."; 737 } 738 enum zetta { 739 value 16; 740 description 741 "Data scaling factor of 10^21."; 742 } 743 enum yotta { 744 value 17; 745 description 746 "Data scaling factor of 10^24."; 747 } 748 } 749 description 750 "A node using this data type represents a data scaling factor, 751 represented with an International System of Units (SI) prefix. 752 The actual data units are determined by examining a node of 753 this type together with the associated sensor-value-type. 755 A node of this type SHOULD be defined together with nodes of 756 type sensor-value-type and sensor-value-precision. Together, 757 associated nodes of these three types are used to identify the 758 semantics of a node of type sensor-value."; 759 reference "RFC 3433: EntitySensorDataScale"; 760 } 762 typedef sensor-value-precision { 763 type int8 { 764 range "-8 .. 9"; 765 } 766 description 767 "A node using this data type represents a sensor value 768 precision range. 770 A node of this type SHOULD be defined together with nodes of 771 type sensor-value-type and sensor-value-scale. Together, 772 associated nodes of these three types are used to identify the 773 semantics of a node of type sensor-value. 775 If a node of this type contains a value in the range 1 to 9, 776 it represents the number of decimal places in the fractional 777 part of an associated sensor-value fixed- point number. 779 If a node of this type contains a value in the range -8 to -1, 780 it represents the number of accurate digits in the associated 781 sensor-value fixed-point number. 783 The value zero indicates the associated sensor-value node is 784 not a fixed-point number. 786 Server implementers must choose a value for the associated 787 sensor-value-precision node so that the precision and accuracy 788 of the associated sensor-value node is correctly indicated. 790 For example, a component representing a temperature sensor 791 that can measure 0 degrees to 100 degrees C in 0.1 degree 792 increments, +/- 0.05 degrees, would have a 793 sensor-value-precision value of '1', a sensor-value-scale 794 value of 'units', and a sensor-value ranging from '0' to 795 '1000'. The sensor-value would be interpreted as 796 'degrees C * 10'."; 797 reference "RFC 3433: EntitySensorPrecision"; 798 } 800 typedef sensor-value { 801 type int32 { 802 range "-1000000000 .. 1000000000"; 804 } 805 description 806 "A node using this data type represents a sensor value. 808 A node of this type SHOULD be defined together with nodes of 809 type sensor-value-type, sensor-value-scale, and 810 sensor-value-precision. Together, associated nodes of those 811 three types are used to identify the semantics of a node of 812 this data type. 814 The semantics of a node using this data type are determined by 815 the value of the associated sensor-value-type node. 817 If the associated sensor-value-type node is equal to 'voltsAC', 818 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 819 then a node of this type MUST contain a fixed point number 820 ranging from -999,999,999 to +999,999,999. The value 821 -1000000000 indicates an underflow error. The value +1000000000 822 indicates an overflow error. The sensor-value-precision 823 indicates how many fractional digits are represented in the 824 associated sensor-value node. 826 If the associated sensor-value-type node is equal to 827 'percentRH', then a node of this type MUST contain a number 828 ranging from 0 to 100. 830 If the associated sensor-value-type node is equal to 'rpm', 831 then a node of this type MUST contain a number ranging from 832 -999,999,999 to +999,999,999. 834 If the associated sensor-value-type node is equal to 835 'truth-value', then a node of this type MUST contain either the 836 value 1 (true) or the value 2 (false)'. 838 If the associated sensor-value-type node is equal to 'other' or 839 unknown', then a node of this type MUST contain a number 840 ranging from -1000000000 to 1000000000."; 841 reference "RFC 3433: EntitySensorValue"; 842 } 844 typedef sensor-status { 845 type enumeration { 846 enum ok { 847 value 1; 848 description 849 "Indicates that the server can obtain the sensor value."; 850 } 851 enum unavailable { 852 value 2; 853 description 854 "Indicates that the server presently cannot obtain the 855 sensor value."; 856 } 857 enum nonoperational { 858 value 3; 859 description 860 "Indicates that the server believes the sensor is broken. 861 The sensor could have a hard failure (disconnected wire), 862 or a soft failure such as out-of-range, jittery, or wildly 863 fluctuating readings."; 864 } 865 } 866 description 867 "A node using this data type represents the operational status 868 of a physical sensor."; 869 reference "RFC 3433: EntitySensorStatus"; 870 } 872 /* 873 * Data nodes 874 */ 876 container hardware { 877 description 878 "Data nodes representing components. 880 If the server supports configuration of hardware components, 881 then this data model is instantiated in the configuration 882 datastores supported by the server. The leaf-list 'datastore' 883 for the module 'ietf-hardware' in the YANG library provides 884 this information."; 886 leaf last-change { 887 type yang:date-and-time; 888 config false; 889 description 890 "The time the '/hardware/component' list changed in the 891 operational state."; 892 } 894 list component { 895 key name; 896 description 897 "List of components. 899 When the server detects a new hardware component, it 900 initializes a list entry in the operational state. 902 If the server does not support configuration of hardware 903 components, list entries in the operational state are 904 initialized with values for all nodes as detected by the 905 implementation. 907 Otherwise, the following procedure is followed: 909 1. If there is an entry in the /hardware/component list in 910 the intended configuration with values for the nodes 911 'class', 'parent', 'parent-rel-pos' that are equal to 912 the detected values, then the list entry in operational 913 state is initialized with the configured values, 914 including the 'name'. 916 2. Otherwise (i.e., there is no matching configuration 917 entry), the list entry in the operational state is 918 initialized with values for all nodes as detected by 919 the implementation. 921 If the /hardware/component list in the intended 922 configuration is modified, then the system MUST behave as if 923 it re-initializes itself, and follow the procedure in (1)."; 924 reference "RFC 6933: entPhysicalEntry"; 926 leaf name { 927 type string; 928 description 929 "The name assigned to this component. 931 This name is not required to be the same as 932 entPhysicalName."; 933 } 935 leaf class { 936 type identityref { 937 base ianahw:hardware-class; 938 } 939 mandatory true; 940 description 941 "An indication of the general hardware type of the 942 component."; 943 reference "RFC 6933: entPhysicalClass"; 944 } 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 } 1043 leaf software-rev { 1044 type string; 1045 config false; 1046 description 1047 "The vendor-specific software revision string for the 1048 component."; 1049 reference "RFC 6933: entPhysicalSoftwareRev"; 1050 } 1052 leaf serial-num { 1053 type string; 1054 config false; 1055 description 1056 "The vendor-specific serial number string for the 1057 component. The preferred value is the serial number 1058 string actually printed on the component itself (if 1059 present)."; 1060 reference "RFC 6933: entPhysicalSerialNum"; 1061 } 1063 leaf mfg-name { 1064 type string; 1065 config false; 1066 description 1067 "The name of the manufacturer of this physical component. 1068 The preferred value is the manufacturer name string 1069 actually printed on the component itself (if present). 1071 Note that comparisons between instances of the model-name, 1072 firmware-rev, software-rev, and the serial-num nodes are 1073 only meaningful amongst component with the same value of 1074 mfg-name. 1076 If the manufacturer name string associated with the 1077 physical component is unknown to the server, then this 1078 node is not instantiated."; 1079 reference "RFC 6933: entPhysicalMfgName"; 1080 } 1082 leaf model-name { 1083 type string; 1084 config false; 1085 description 1086 "The vendor-specific model name identifier string 1087 associated with this physical component. The preferred 1088 value is the customer-visible part number, which may be 1089 printed on the component itself. 1091 If the model name string associated with the physical 1092 component is unknown to the server, then this node is not 1093 instantiated."; 1094 reference "RFC 6933: entPhysicalModelName"; 1095 } 1097 leaf alias { 1098 type string; 1099 description 1100 "An 'alias' name for the component, as specified by a 1101 network manager, and provides a non-volatile 'handle' for 1102 the component. 1104 If no configured value exists, the server MAY set the 1105 value of this node to a locally unique value in the 1106 operational state. 1108 A server implementation MAY map this leaf to the 1109 entPhysicalAlias MIB object. Such an implementation needs 1110 to use some mechanism to handle the differences in size 1111 and characters allowed between this leaf and 1112 entPhysicalAlias. The definition of such a mechanism is 1113 outside the scope of this document."; 1114 reference "RFC 6933: entPhysicalAlias"; 1115 } 1117 leaf asset-id { 1118 type string; 1119 description 1120 "This node is a user-assigned asset tracking identifier for 1121 the component. 1123 A server implementation MAY map this leaf to the 1124 entPhysicalAssetID MIB object. Such an implementation 1125 needs to use some mechanism to handle the differences in 1126 size and characters allowed between this leaf and 1127 entPhysicalAssetID. The definition of such a mechanism is 1128 outside the scope of this document."; 1129 reference "RFC 6933: entPhysicalAssetID"; 1130 } 1132 leaf is-fru { 1133 type boolean; 1134 config false; 1135 description 1136 "This node indicates whether or not this component is 1137 considered a 'field replaceable unit' by the vendor. If 1138 this node contains the value 'true', then this component 1139 identifies a field replaceable unit. For all components 1140 that are permanently contained within a field replaceable 1141 unit, the value 'false' should be returned for this 1142 node."; 1143 reference "RFC 6933: entPhysicalIsFRU"; 1144 } 1146 leaf mfg-date { 1147 type yang:date-and-time; 1148 config false; 1149 description 1150 "The date of manufacturing of the managed component."; 1151 reference "RFC 6933: entPhysicalMfgDate"; 1152 } 1154 leaf-list uri { 1155 type inet:uri; 1156 description 1157 "This node contains identification information about the 1158 component."; 1159 reference "RFC 6933: entPhysicalUris"; 1160 } 1162 leaf uuid { 1163 type yang:uuid; 1164 config false; 1165 description 1166 "A Universally Unique Identifier of the component."; 1167 reference "RFC 6933: entPhysicalUUID"; 1168 } 1170 container state { 1171 if-feature hardware-state; 1172 description 1173 "State-related nodes"; 1174 reference "RFC 4268: Entity State MIB"; 1176 leaf state-last-changed { 1177 type yang:date-and-time; 1178 config false; 1179 description 1180 "The date and time when the value of any of the 1181 admin-state, oper-state, usage-state, alarm-state, or 1182 standby-state changed for this component. 1184 If there has been no change since the last 1185 re-initialization of the local system, this node 1186 contains the date and time of local system 1187 initialization. If there has been no change since the 1188 component was added to the local system, this node 1189 contains the date and time of the insertion."; 1190 reference "RFC 4268: entStateLastChanged"; 1191 } 1193 leaf admin-state { 1194 type admin-state; 1195 description 1196 "The administrative state for this component. 1198 This node refers to a component's administrative 1199 permission to service both other components within its 1200 containment hierarchy as well other users of its 1201 services defined by means outside the scope of this 1202 module. 1204 Some components exhibit only a subset of the remaining 1205 administrative state values. Some components cannot be 1206 locked, and hence this node exhibits only the 'unlocked' 1207 state. Other components cannot be shutdown gracefully, 1208 and hence this node does not exhibit the 'shutting-down' 1209 state."; 1210 reference "RFC 4268: entStateAdmin"; 1211 } 1213 leaf oper-state { 1214 type oper-state; 1215 config false; 1216 description 1217 "The operational state for this component. 1219 Note that this node does not follow the administrative 1220 state. An administrative state of down does not predict 1221 an operational state of disabled. 1223 Note that some implementations may not be able to 1224 accurately report oper-state while the admin-state node 1225 has a value other than 'unlocked'. In these cases, this 1226 node MUST have a value of 'unknown'."; 1227 reference "RFC 4268: entStateOper"; 1228 } 1230 leaf usage-state { 1231 type usage-state; 1232 config false; 1233 description 1234 "The usage state for this component. 1236 This node refers to a component's ability to service 1237 more components in a containment hierarchy. 1239 Some components will exhibit only a subset of the usage 1240 state values. Components that are unable to ever 1241 service any components within a containment hierarchy 1242 will always have a usage state of 'busy'. Some 1243 components will only ever be able to support one 1244 component within its containment hierarchy and will 1245 therefore only exhibit values of 'idle' and 'busy'."; 1246 reference "RFC 4268, entStateUsage"; 1247 } 1249 leaf alarm-state { 1250 type alarm-state; 1251 config false; 1252 description 1253 "The alarm state for this component. It does not 1254 include the alarms raised on child components within its 1255 containment hierarchy."; 1256 reference "RFC 4268: entStateAlarm"; 1257 } 1259 leaf standby-state { 1260 type standby-state; 1261 config false; 1262 description 1263 "The standby state for this component. 1265 Some components will exhibit only a subset of the 1266 remaining standby state values. If this component 1267 cannot operate in a standby role, the value of this node 1268 will always be 'providing-service'."; 1269 reference "RFC 4268: entStateStandby"; 1270 } 1271 } 1273 container sensor-data { 1274 when 'derived-from-or-self(../class, 1275 "ianahw:sensor")' { 1276 description 1277 "Sensor data nodes present for any component of type 1278 'sensor'"; 1279 } 1280 if-feature hardware-sensor; 1281 config false; 1283 description 1284 "Sensor-related nodes."; 1285 reference "RFC 3433: Entity Sensor MIB"; 1287 leaf value { 1288 type sensor-value; 1289 description 1290 "The most recent measurement obtained by the server 1291 for this sensor. 1293 A client that periodically fetches this node should also 1294 fetch the nodes 'value-type', 'value-scale', and 1295 'value-precision', since they may change when the value 1296 is changed."; 1297 reference "RFC 3433: entPhySensorValue"; 1298 } 1300 leaf value-type { 1301 type sensor-value-type; 1302 description 1303 "The type of data units associated with the 1304 sensor value"; 1305 reference "RFC 3433: entPhySensorType"; 1306 } 1308 leaf value-scale { 1309 type sensor-value-scale; 1310 description 1311 "The (power of 10) scaling factor associated 1312 with the sensor value"; 1313 reference "RFC 3433: entPhySensorScale"; 1314 } 1316 leaf value-precision { 1317 type sensor-value-precision; 1318 description 1319 "The number of decimal places of precision 1320 associated with the sensor value"; 1321 reference "RFC 3433: entPhySensorPrecision"; 1322 } 1324 leaf oper-status { 1325 type sensor-status; 1326 description 1327 "The operational status of the sensor."; 1328 reference "RFC 3433: entPhySensorOperStatus"; 1329 } 1331 leaf units-display { 1332 type string; 1333 description 1334 "A textual description of the data units that should be 1335 used in the display of the sensor value."; 1336 reference "RFC 3433: entPhySensorUnitsDisplay"; 1337 } 1339 leaf value-timestamp { 1340 type yang:date-and-time; 1341 description 1342 "The time the status and/or value of this sensor was last 1343 obtained by the server."; 1344 reference "RFC 3433: entPhySensorValueTimeStamp"; 1345 } 1347 leaf value-update-rate { 1348 type uint32; 1349 units "milliseconds"; 1350 description 1351 "An indication of the frequency that the server updates 1352 the associated 'value' node, representing in 1353 milliseconds. The value zero indicates: 1355 - the sensor value is updated on demand (e.g., 1356 when polled by the server for a get-request), 1357 - the sensor value is updated when the sensor 1358 value changes (event-driven), 1359 - the server does not know the update rate."; 1360 reference "RFC 3433: entPhySensorValueUpdateRate"; 1361 } 1362 } 1363 } 1364 } 1366 /* 1367 * Notifications 1368 */ 1370 notification hardware-state-change { 1371 description 1372 "A hardware-state-change notification is generated when the 1373 value of /hardware/last-change changes in the operational 1374 state."; 1375 reference "RFC 6933, entConfigChange"; 1376 } 1378 notification hardware-state-oper-enabled { 1379 if-feature hardware-state; 1380 description 1381 "A hardware-state-oper-enabled notification signifies that a 1382 component has transitioned into the 'enabled' state."; 1384 leaf name { 1385 type leafref { 1386 path "/hardware/component/name"; 1387 } 1388 description 1389 "The name of the component that has transitioned into the 1390 'enabled' state."; 1391 } 1392 leaf admin-state { 1393 type leafref { 1394 path "/hardware/component/state/admin-state"; 1395 } 1396 description 1397 "The administrative state for the component."; 1398 } 1399 leaf alarm-state { 1400 type leafref { 1401 path "/hardware/component/state/alarm-state"; 1402 } 1403 description 1404 "The alarm state for the component."; 1405 } 1406 reference "RFC 4268, entStateOperEnabled"; 1407 } 1409 notification hardware-state-oper-disabled { 1410 if-feature hardware-state; 1411 description 1412 "A hardware-state-oper-disabled notification signifies that a 1413 component has transitioned into the 'disabled' state."; 1415 leaf name { 1416 type leafref { 1417 path "/hardware/component/name"; 1418 } 1419 description 1420 "The name of the component that has transitioned into the 1421 'disabled' state."; 1422 } 1423 leaf admin-state { 1424 type leafref { 1425 path "/hardware/component/state/admin-state"; 1426 } 1427 description 1428 "The administrative state for the component."; 1429 } 1430 leaf alarm-state { 1431 type leafref { 1432 path "/hardware/component/state/alarm-state"; 1433 } 1434 description 1435 "The alarm state for the component."; 1436 } 1437 reference "RFC 4268, entStateOperDisabled"; 1438 } 1440 } 1442 1444 file "iana-hardware@2018-01-15.yang" 1446 module iana-hardware { 1447 yang-version 1.1; 1448 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1449 prefix ianahw; 1451 organization "IANA"; 1452 contact 1453 " Internet Assigned Numbers Authority 1455 Postal: ICANN 1456 12025 Waterfront Drive, Suite 300 1457 Los Angeles, CA 90094-2536 1458 United States 1460 Tel: +1 310 301 5800 1461 E-Mail: iana@iana.org>"; 1462 // RFC Ed.: replace XXXX with actual RFC number and remove this 1463 // note. 1464 description 1465 "IANA defined identities for hardware class. 1467 The latest revision of this YANG module can be obtained from 1468 the IANA web site. 1470 Requests for new values should be made to IANA via 1471 email (iana@iana.org). 1473 Copyright (c) 2018 IETF Trust and the persons identified as 1474 authors of the code. All rights reserved. 1476 Redistribution and use in source and binary forms, with or 1477 without modification, is permitted pursuant to, and subject 1478 to the license terms contained in, the Simplified BSD License 1479 set forth in Section 4.c of the IETF Trust's Legal Provisions 1480 Relating to IETF Documents 1481 (http://trustee.ietf.org/license-info). 1483 The initial version of this YANG module is part of RFC XXXX; 1484 see the RFC itself for full legal notices."; 1485 reference 1486 // RFC Ed.: replace PPPP with actual path and remove this note. 1487 "https://www.iana.org/assignments/PPPP"; 1489 // RFC Ed.: update the date below with the date of RFC publication 1490 // and remove this note. 1491 revision 2018-01-15 { 1492 description 1493 "Initial revision."; 1494 reference 1495 "RFC XXXX: A YANG Data Model for Hardware Management"; 1496 } 1498 /* 1499 * Identities 1500 */ 1502 identity hardware-class { 1503 description 1504 "This identity is the base for all hardware class 1505 identifiers."; 1506 } 1508 identity unknown { 1509 base ianahw:hardware-class; 1510 description 1511 "This identity is applicable if the hardware class is unknown 1512 to the server."; 1513 } 1515 identity chassis { 1516 base ianahw:hardware-class; 1517 description 1518 "This identity is applicable if the hardware class is an 1519 overall container for networking equipment. Any class of 1520 physical component, except a stack, may be contained within a 1521 chassis; a chassis may only be contained within a stack."; 1522 } 1523 identity backplane { 1524 base ianahw:hardware-class; 1525 description 1526 "This identity is applicable if the hardware class is some sort 1527 of device for aggregating and forwarding networking traffic, 1528 such as a shared backplane in a modular ethernet switch. Note 1529 that an implementation may model a backplane as a single 1530 physical component, which is actually implemented as multiple 1531 discrete physical components (within a chassis or stack)."; 1532 } 1534 identity container { 1535 base ianahw:hardware-class; 1536 description 1537 "This identity is applicable if the hardware class is capable 1538 of containing one or more removable physical entities, 1539 possibly of different types. For example, each (empty or 1540 full) slot in a chassis will be modeled as a container. Note 1541 that all removable physical components should be modeled 1542 within a container component, such as field-replaceable 1543 modules, fans, or power supplies. Note that all known 1544 containers should be modeled by the agent, including empty 1545 containers."; 1546 } 1548 identity power-supply { 1549 base ianahw:hardware-class; 1550 description 1551 "This identity is applicable if the hardware class is a 1552 power-supplying component."; 1553 } 1555 identity fan { 1556 base ianahw:hardware-class; 1557 description 1558 "This identity is applicable if the hardware class is a fan or 1559 other heat-reduction component."; 1560 } 1562 identity sensor { 1563 base ianahw:hardware-class; 1564 description 1565 "This identity is applicable if the hardware class is some sort 1566 of sensor, such as a temperature sensor within a router 1567 chassis."; 1568 } 1570 identity module { 1571 base ianahw:hardware-class; 1572 description 1573 "This identity is applicable if the hardware class is some sort 1574 of self-contained sub-system. If a module component is 1575 removable, then it should be modeled within a container 1576 component; otherwise, it should be modeled directly within 1577 another physical component (e.g., a chassis or another 1578 module)."; 1579 } 1581 identity port { 1582 base ianahw:hardware-class; 1583 description 1584 "This identity is applicable if the hardware class is some sort 1585 of networking port, capable of receiving and/or transmitting 1586 networking traffic."; 1587 } 1589 identity stack { 1590 base ianahw:hardware-class; 1591 description 1592 "This identity is applicable if the hardware class is some sort 1593 of super-container (possibly virtual) intended to group 1594 together multiple chassis entities. A stack may be realized 1595 by a virtual cable, a real interconnect cable attached to 1596 multiple chassis, or multiple interconnect cables. A stack 1597 should not be modeled within any other physical components, 1598 but a stack may be contained within another stack. Only 1599 chassis components should be contained within a stack."; 1600 } 1602 identity cpu { 1603 base ianahw:hardware-class; 1604 description 1605 "This identity is applicable if the hardware class is some sort 1606 of central processing unit."; 1607 } 1609 identity energy-object { 1610 base ianahw:hardware-class; 1611 description 1612 "This identity is applicable if the hardware class is some sort 1613 of energy object, i.e., a piece of equipment that is part of 1614 or attached to a communications network that is monitored, 1615 controlled, or aids in the management of another device for 1616 Energy Management."; 1617 } 1618 identity battery { 1619 base ianahw:hardware-class; 1620 description 1621 "This identity is applicable if the hardware class is some sort 1622 of battery."; 1623 } 1625 identity storage-drive { 1626 base ianahw:hardware-class; 1627 description 1628 "This identity is applicable if the hardware class is some sort 1629 of component with data storage capability as main 1630 functionality, e.g., disk drive (HDD), solid state device 1631 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1632 } 1633 } 1635 1637 8. IANA Considerations 1639 This document defines the initial version of the IANA-maintained 1640 "iana-hardware" YANG module. 1642 The "iana-hardware" YANG module is intended to reflect the 1643 "IANA-ENTITY-MIB" MIB module so that if a new enumeration is added to 1644 the "IANAPhysicalClass" TEXTUAL-CONVENTION, the same class is added 1645 as an identity derived from "ianahw:hardware-class". 1647 When the "iana-hardware" YANG module is updated, a new "revision" 1648 statement must be added in front of the existing revision statements. 1650 8.1. URI Registrations 1652 This document registers three URIs in the IETF XML registry 1653 [RFC3688]. Following the format in RFC 3688, the following 1654 registrations are requested to be made. 1656 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1657 Registrant Contact: The IESG. 1658 XML: N/A, the requested URI is an XML namespace. 1660 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1661 Registrant Contact: The IESG. 1662 XML: N/A, the requested URI is an XML namespace. 1664 URI: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1665 Registrant Contact: The IESG. 1666 XML: N/A, the requested URI is an XML namespace. 1668 8.2. YANG Module Registrations 1670 This document registers three YANG modules in the YANG Module Names 1671 registry [RFC6020]. 1673 name: iana-hardware 1674 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1675 prefix: ianahw 1676 reference: RFC XXXX 1678 name: ietf-hardware 1679 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1680 prefix: hw 1681 reference: RFC XXXX 1683 name: ietf-hardware-state 1684 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware-state 1685 prefix: hw-state 1686 reference: RFC XXXX 1688 9. Security Considerations 1690 The YANG modules specified in this document define a schema for data 1691 that is designed to be accessed via network management protocols such 1692 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1693 is the secure transport layer, and the mandatory-to-implement secure 1694 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1695 is HTTPS, and the mandatory-to-implement secure transport is TLS 1696 [RFC5246]. 1698 The NETCONF access control model [RFC6536] provides the means to 1699 restrict access for particular NETCONF or RESTCONF users to a 1700 preconfigured subset of all available NETCONF or RESTCONF protocol 1701 operations and content. 1703 There are a number of data nodes defined in the YANG module 1704 "ietf-hardware" that are writable/creatable/deletable (i.e., config 1705 true, which is the default). These data nodes may be considered 1706 sensitive or vulnerable in some network environments. Write 1707 operations (e.g., edit-config) to these data nodes without proper 1708 protection can have a negative effect on network operations. These 1709 are the subtrees and data nodes and their sensitivity/vulnerability: 1711 /hardware/component/admin-state: Setting this node to 'locked' or 1712 'shutting-down' can cause disruption of services ranging from 1713 those running on a port to those on an entire device, depending on 1714 the type of component. 1716 Some of the readable data nodes in these YANG modules may be 1717 considered sensitive or vulnerable in some network environments. It 1718 is thus important to control read access (e.g., via get, get-config, 1719 or notification) to these data nodes. These are the subtrees and 1720 data nodes and their sensitivity/vulnerability: 1722 /hardware/component: The leafs in this list expose information about 1723 the physical components in a device, which may be used to identify 1724 the vendor, model, version, and specific device-identification 1725 information of each system component. 1727 /hardware/component/sensor-data/value: This node may expose the 1728 values of particular physical sensors in a device. 1730 /hardware/component/state: Access to this node allows one to figure 1731 out what the active and standby resources in a device are. 1733 10. Acknowledgments 1735 The authors wish to thank the following individuals, who all provided 1736 helpful comments on various draft versions of this document: Bart 1737 Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder. 1739 11. References 1741 11.1. Normative References 1743 [I-D.ietf-netmod-revised-datastores] 1744 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1745 and R. Wilton, "Network Management Datastore 1746 Architecture", draft-ietf-netmod-revised-datastores-10 1747 (work in progress), January 2018. 1749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1750 Requirement Levels", BCP 14, RFC 2119, 1751 DOI 10.17487/RFC2119, March 1997, . 1754 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1755 Management Information Base", RFC 3433, 1756 DOI 10.17487/RFC3433, December 2002, . 1759 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1760 DOI 10.17487/RFC3688, January 2004, . 1763 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1764 DOI 10.17487/RFC4268, November 2005, . 1767 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1768 (TLS) Protocol Version 1.2", RFC 5246, 1769 DOI 10.17487/RFC5246, August 2008, . 1772 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1773 the Network Configuration Protocol (NETCONF)", RFC 6020, 1774 DOI 10.17487/RFC6020, October 2010, . 1777 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1778 and A. Bierman, Ed., "Network Configuration Protocol 1779 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1780 . 1782 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1783 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1784 . 1786 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1787 Protocol (NETCONF) Access Control Model", RFC 6536, 1788 DOI 10.17487/RFC6536, March 2012, . 1791 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1792 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1793 DOI 10.17487/RFC6933, May 2013, . 1796 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1797 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1798 . 1800 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1801 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1802 . 1804 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1805 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1806 May 2017, . 1808 11.2. Informative References 1810 [I-D.ietf-netmod-yang-tree-diagrams] 1811 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1812 ietf-netmod-yang-tree-diagrams-04 (work in progress), 1813 December 2017. 1815 Appendix A. Hardware State Data Model 1817 This non-normative appendix contains a data model designed as a 1818 temporary solution for implementations that do not yet support the 1819 Network Management Datastore Architecture (NMDA) defined in 1820 [I-D.ietf-netmod-revised-datastores]. It has the following 1821 structure: 1823 module: ietf-hardware-state 1824 x--ro hardware 1825 x--ro last-change? yang:date-and-time 1826 x--ro component* [name] 1827 x--ro name string 1828 x--ro class identityref 1829 x--ro physical-index? int32 {entity-mib}? 1830 x--ro description? string 1831 x--ro parent? -> ../../component/name 1832 x--ro parent-rel-pos? int32 1833 x--ro contains-child* -> ../../component/name 1834 x--ro hardware-rev? string 1835 x--ro firmware-rev? string 1836 x--ro software-rev? string 1837 x--ro serial-num? string 1838 x--ro mfg-name? string 1839 x--ro model-name? string 1840 x--ro alias? string 1841 x--ro asset-id? string 1842 x--ro is-fru? boolean 1843 x--ro mfg-date? yang:date-and-time 1844 x--ro uri* inet:uri 1845 x--ro uuid? yang:uuid 1846 x--ro state {hardware-state}? 1847 | x--ro state-last-changed? yang:date-and-time 1848 | x--ro admin-state? hw:admin-state 1849 | x--ro oper-state? hw:oper-state 1850 | x--ro usage-state? hw:usage-state 1851 | x--ro alarm-state? hw:alarm-state 1852 | x--ro standby-state? hw:standby-state 1853 x--ro sensor-data {hardware-sensor}? 1854 x--ro value? hw:sensor-value 1855 x--ro value-type? hw:sensor-value-type 1856 x--ro value-scale? hw:sensor-value-scale 1857 x--ro value-precision? hw:sensor-value-precision 1858 x--ro oper-status? hw:sensor-status 1859 x--ro units-display? string 1860 x--ro value-timestamp? yang:date-and-time 1861 x--ro value-update-rate? uint32 1863 notifications: 1864 x---n hardware-state-change 1865 x---n hardware-state-oper-enabled {hardware-state}? 1866 | x--ro name? -> /hardware/component/name 1867 | x--ro admin-state? -> /hardware/component/state/admin-state 1868 | x--ro alarm-state? -> /hardware/component/state/alarm-state 1869 x---n hardware-state-oper-disabled {hardware-state}? 1870 x--ro name? -> /hardware/component/name 1871 x--ro admin-state? -> /hardware/component/state/admin-state 1872 x--ro alarm-state? -> /hardware/component/state/alarm-state 1874 A.1. Hardware State YANG Module 1876 file "ietf-hardware-state@2017-12-18.yang" 1878 module ietf-hardware-state { 1879 yang-version 1.1; 1880 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware-state"; 1881 prefix hw-state; 1883 import ietf-inet-types { 1884 prefix inet; 1885 } 1886 import ietf-yang-types { 1887 prefix yang; 1888 } 1889 import iana-hardware { 1890 prefix ianahw; 1891 } 1892 import ietf-hardware { 1893 prefix hw; 1894 } 1896 organization 1897 "IETF NETMOD (Network Modeling) Working Group"; 1899 contact 1900 "WG Web: 1901 WG List: 1903 Editor: Andy Bierman 1904 1906 Editor: Martin Bjorklund 1907 1909 Editor: Jie Dong 1910 1912 Editor: Dan Romascanu 1913 "; 1915 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 1916 // remove this note. 1918 description 1919 "This module contains a collection of YANG definitions for 1920 monitoring hardware. 1922 This data model is designed as a temporary solution for 1923 implementations that do not yet support the Network Management 1924 Datastore Architecture (NMDA) defined in RFC YYYY. Such an 1925 implementation cannot implement the module 'ietf-hardware' 1926 properly, since without NMDA support, it is not possible to 1927 distinguish between instances of nodes in the running 1928 configuration and operational state. 1930 The data model in this module is the same as the data model in 1931 'ietf-hardware', except all nodes are marked as 'config false'. 1933 If a server that implements this module but doesn't support NMDA 1934 also supports configuration of hardware components, it SHOULD 1935 also implement the module 'ietf-hardware' in the configuration 1936 datastores. The corresponding state data is found in the 1937 '/hw-state:hardware' subtree. 1939 Copyright (c) 2017 IETF Trust and the persons identified as 1940 authors of the code. All rights reserved. 1942 Redistribution and use in source and binary forms, with or 1943 without modification, is permitted pursuant to, and subject 1944 to the license terms contained in, the Simplified BSD License 1945 set forth in Section 4.c of the IETF Trust's Legal Provisions 1946 Relating to IETF Documents 1947 (http://trustee.ietf.org/license-info). 1949 This version of this YANG module is part of RFC XXXX; see 1950 the RFC itself for full legal notices."; 1952 // RFC Ed.: update the date below with the date of RFC publication 1953 // and remove this note. 1954 revision 2017-12-18 { 1955 description 1956 "Initial revision."; 1957 reference 1958 "RFC XXXX: A YANG Data Model for Hardware Management"; 1959 } 1961 /* 1962 * Features 1963 */ 1965 feature entity-mib { 1966 status deprecated; 1967 description 1968 "This feature indicates that the device implements 1969 the ENTITY-MIB."; 1970 reference "RFC 6933: Entity MIB (Version 4)"; 1971 } 1973 feature hardware-state { 1974 status deprecated; 1975 description 1976 "Indicates the ENTITY-STATE-MIB objects are supported"; 1977 reference "RFC 4268: Entity State MIB"; 1978 } 1980 feature hardware-sensor { 1981 status deprecated; 1982 description 1983 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 1984 reference "RFC 3433: Entity Sensor MIB"; 1985 } 1987 /* 1988 * Data nodes 1989 */ 1991 container hardware { 1992 config false; 1993 status deprecated; 1994 description 1995 "Data nodes representing components."; 1997 leaf last-change { 1998 type yang:date-and-time; 1999 status deprecated; 2000 description 2001 "The time the '/hardware/component' list changed in the 2002 operational state."; 2003 } 2005 list component { 2006 key name; 2007 status deprecated; 2008 description 2009 "List of components. 2011 When the server detects a new hardware component, it 2012 initializes a list entry in the operational state. 2014 If the server does not support configuration of hardware 2015 components, list entries in the operational state are 2016 initialized with values for all nodes as detected by the 2017 implementation. 2019 Otherwise, the following procedure is followed: 2021 1. If there is an entry in the /hardware/component list in 2022 the intended configuration with values for the nodes 2023 'class', 'parent', 'parent-rel-pos' that are equal to 2024 the detected values, then: 2026 1a. If the configured entry has a value for 'mfg-name' 2027 that is equal to the detected value, or if the 2028 'mfg-name' value cannot be detected, then the list 2029 entry in the operational state is initialized with the 2030 configured values for all configured nodes, including 2031 the 'name'. 2033 Otherwise, the list entry in the operational state is 2034 initialized with values for all nodes as detected by 2035 the implementation. The implementation may raise an 2036 alarm that informs about the 'mfg-name' mismatch 2037 condition. How this is done is outside the scope of 2038 this document. 2040 1b. Otherwise (i.e., there is no matching configuration 2041 entry), the list entry in the operational state is 2042 initialized with values for all nodes as detected by 2043 the implementation. 2045 If the /hardware/component list in the intended 2046 configuration is modified, then the system MUST behave as if 2047 it re-initializes itself, and follow the procedure in (1)."; 2048 reference "RFC 6933: entPhysicalEntry"; 2050 leaf name { 2051 type string; 2052 status deprecated; 2053 description 2054 "The name assigned to this component. 2056 This name is not required to be the same as 2057 entPhysicalName."; 2058 } 2060 leaf class { 2061 type identityref { 2062 base ianahw:hardware-class; 2063 } 2064 mandatory true; 2065 status deprecated; 2066 description 2067 "An indication of the general hardware type of the 2068 component."; 2069 reference "RFC 6933: entPhysicalClass"; 2070 } 2072 leaf physical-index { 2073 if-feature entity-mib; 2074 type int32 { 2075 range "1..2147483647"; 2076 } 2077 status deprecated; 2078 description 2079 "The entPhysicalIndex for the entPhysicalEntry represented 2080 by this list entry."; 2081 reference "RFC 6933: entPhysicalIndex"; 2082 } 2083 leaf description { 2084 type string; 2085 status deprecated; 2086 description 2087 "A textual description of component. This node should 2088 contain a string that identifies the manufacturer's name 2089 for the component and should be set to a distinct value 2090 for each version or model of the component."; 2091 reference "RFC 6933: entPhysicalDescr"; 2092 } 2094 leaf parent { 2095 type leafref { 2096 path "../../component/name"; 2097 require-instance false; 2098 } 2099 status deprecated; 2100 description 2101 "The name of the component that physically contains this 2102 component. 2104 If this leaf is not instantiated, it indicates that this 2105 component is not contained in any other component. 2107 In the event that a physical component is contained by 2108 more than one physical component (e.g., double-wide 2109 modules), this node contains the name of one of these 2110 components. An implementation MUST use the same name 2111 every time this node is instantiated."; 2112 reference "RFC 6933: entPhysicalContainedIn"; 2113 } 2115 leaf parent-rel-pos { 2116 type int32 { 2117 range "0 .. 2147483647"; 2118 } 2119 status deprecated; 2120 description 2121 "An indication of the relative position of this child 2122 component among all its sibling components. Sibling 2123 components are defined as components that: 2125 o Share the same value of the 'parent' node; and 2127 o Share a common base identity for the 'class' node. 2129 Note that the last rule gives implementations flexibility 2130 in how components are numbered. For example, some 2131 implementations might have a single number series for all 2132 components derived from 'ianahw:port', while some others 2133 might have different number series for different 2134 components with identities derived from 'ianahw:port' (for 2135 example, one for RJ45 and one for SFP)."; 2137 reference "RFC 6933: entPhysicalParentRelPos"; 2138 } 2140 leaf-list contains-child { 2141 type leafref { 2142 path "../../component/name"; 2143 } 2144 status deprecated; 2145 description 2146 "The name of the contained component."; 2147 reference "RFC 6933: entPhysicalChildIndex"; 2148 } 2150 leaf hardware-rev { 2151 type string; 2152 status deprecated; 2153 description 2154 "The vendor-specific hardware revision string for the 2155 component. The preferred value is the hardware revision 2156 identifier actually printed on the component itself (if 2157 present)."; 2158 reference "RFC 6933: entPhysicalHardwareRev"; 2159 } 2161 leaf firmware-rev { 2162 type string; 2163 status deprecated; 2164 description 2165 "The vendor-specific firmware revision string for the 2166 component."; 2167 reference "RFC 6933: entPhysicalFirmwareRev"; 2168 } 2170 leaf software-rev { 2171 type string; 2172 status deprecated; 2173 description 2174 "The vendor-specific software revision string for the 2175 component."; 2176 reference "RFC 6933: entPhysicalSoftwareRev"; 2177 } 2178 leaf serial-num { 2179 type string; 2180 status deprecated; 2181 description 2182 "The vendor-specific serial number string for the 2183 component. The preferred value is the serial number 2184 string actually printed on the component itself (if 2185 present)."; 2186 reference "RFC 6933: entPhysicalSerialNum"; 2187 } 2189 leaf mfg-name { 2190 type string; 2191 status deprecated; 2192 description 2193 "The name of the manufacturer of this physical component. 2194 The preferred value is the manufacturer name string 2195 actually printed on the component itself (if present). 2197 Note that comparisons between instances of the model-name, 2198 firmware-rev, software-rev, and the serial-num nodes are 2199 only meaningful amongst component with the same value of 2200 mfg-name. 2202 If the manufacturer name string associated with the 2203 physical component is unknown to the server, then this 2204 node is not instantiated."; 2205 reference "RFC 6933: entPhysicalMfgName"; 2206 } 2208 leaf model-name { 2209 type string; 2210 status deprecated; 2211 description 2212 "The vendor-specific model name identifier string 2213 associated with this physical component. The preferred 2214 value is the customer-visible part number, which may be 2215 printed on the component itself. 2217 If the model name string associated with the physical 2218 component is unknown to the server, then this node is not 2219 instantiated."; 2220 reference "RFC 6933: entPhysicalModelName"; 2221 } 2223 leaf alias { 2224 type string; 2225 status deprecated; 2226 description 2227 "An 'alias' name for the component, as specified by a 2228 network manager, and provides a non-volatile 'handle' for 2229 the component. 2231 If no configured value exists, the server MAY set the 2232 value of this node to a locally unique value in the 2233 operational state. 2235 A server implementation MAY map this leaf to the 2236 entPhysicalAlias MIB object. Such an implementation needs 2237 to use some mechanism to handle the differences in size 2238 and characters allowed between this leaf and 2239 entPhysicalAlias. The definition of such a mechanism is 2240 outside the scope of this document."; 2241 reference "RFC 6933: entPhysicalAlias"; 2242 } 2244 leaf asset-id { 2245 type string; 2246 status deprecated; 2247 description 2248 "This node is a user-assigned asset tracking identifier for 2249 the component. 2251 A server implementation MAY map this leaf to the 2252 entPhysicalAssetID MIB object. Such an implementation 2253 needs to use some mechanism to handle the differences in 2254 size and characters allowed between this leaf and 2255 entPhysicalAssetID. The definition of such a mechanism is 2256 outside the scope of this document."; 2257 reference "RFC 6933: entPhysicalAssetID"; 2258 } 2260 leaf is-fru { 2261 type boolean; 2262 status deprecated; 2263 description 2264 "This node indicates whether or not this component is 2265 considered a 'field replaceable unit' by the vendor. If 2266 this node contains the value 'true', then this component 2267 identifies a field replaceable unit. For all components 2268 that are permanently contained within a field replaceable 2269 unit, the value 'false' should be returned for this 2270 node."; 2271 reference "RFC 6933: entPhysicalIsFRU"; 2272 } 2273 leaf mfg-date { 2274 type yang:date-and-time; 2275 status deprecated; 2276 description 2277 "The date of manufacturing of the managed component."; 2278 reference "RFC 6933: entPhysicalMfgDate"; 2279 } 2281 leaf-list uri { 2282 type inet:uri; 2283 status deprecated; 2284 description 2285 "This node contains identification information about the 2286 component."; 2287 reference "RFC 6933: entPhysicalUris"; 2288 } 2290 leaf uuid { 2291 type yang:uuid; 2292 status deprecated; 2293 description 2294 "A Universally Unique Identifier of the component."; 2295 reference "RFC 6933: entPhysicalUUID"; 2296 } 2298 container state { 2299 if-feature hardware-state; 2300 status deprecated; 2301 description 2302 "State-related nodes"; 2303 reference "RFC 4268: Entity State MIB"; 2305 leaf state-last-changed { 2306 type yang:date-and-time; 2307 status deprecated; 2308 description 2309 "The date and time when the value of any of the 2310 admin-state, oper-state, usage-state, alarm-state, or 2311 standby-state changed for this component. 2313 If there has been no change since the last 2314 re-initialization of the local system, this node 2315 contains the date and time of local system 2316 initialization. If there has been no change since the 2317 component was added to the local system, this node 2318 contains the date and time of the insertion."; 2319 reference "RFC 4268: entStateLastChanged"; 2320 } 2321 leaf admin-state { 2322 type hw:admin-state; 2323 status deprecated; 2324 description 2325 "The administrative state for this component. 2327 This node refers to a component's administrative 2328 permission to service both other components within its 2329 containment hierarchy as well other users of its 2330 services defined by means outside the scope of this 2331 module. 2333 Some components exhibit only a subset of the remaining 2334 administrative state values. Some components cannot be 2335 locked, and hence this node exhibits only the 'unlocked' 2336 state. Other components cannot be shutdown gracefully, 2337 and hence this node does not exhibit the 'shutting-down' 2338 state."; 2339 reference "RFC 4268: entStateAdmin"; 2340 } 2342 leaf oper-state { 2343 type hw:oper-state; 2344 status deprecated; 2345 description 2346 "The operational state for this component. 2348 Note that this node does not follow the administrative 2349 state. An administrative state of down does not predict 2350 an operational state of disabled. 2352 Note that some implementations may not be able to 2353 accurately report oper-state while the admin-state node 2354 has a value other than 'unlocked'. In these cases, this 2355 node MUST have a value of 'unknown'."; 2356 reference "RFC 4268: entStateOper"; 2357 } 2359 leaf usage-state { 2360 type hw:usage-state; 2361 status deprecated; 2362 description 2363 "The usage state for this component. 2365 This node refers to a component's ability to service 2366 more components in a containment hierarchy. 2368 Some components will exhibit only a subset of the usage 2369 state values. Components that are unable to ever 2370 service any components within a containment hierarchy 2371 will always have a usage state of 'busy'. Some 2372 components will only ever be able to support one 2373 component within its containment hierarchy and will 2374 therefore only exhibit values of 'idle' and 'busy'."; 2375 reference "RFC 4268, entStateUsage"; 2376 } 2378 leaf alarm-state { 2379 type hw:alarm-state; 2380 status deprecated; 2381 description 2382 "The alarm state for this component. It does not 2383 include the alarms raised on child components within its 2384 containment hierarchy."; 2385 reference "RFC 4268: entStateAlarm"; 2386 } 2388 leaf standby-state { 2389 type hw:standby-state; 2390 status deprecated; 2391 description 2392 "The standby state for this component. 2394 Some components will exhibit only a subset of the 2395 remaining standby state values. If this component 2396 cannot operate in a standby role, the value of this node 2397 will always be 'providing-service'."; 2398 reference "RFC 4268: entStateStandby"; 2399 } 2400 } 2402 container sensor-data { 2403 when 'derived-from-or-self(../class, 2404 "ianahw:sensor")' { 2405 description 2406 "Sensor data nodes present for any component of type 2407 'sensor'"; 2408 } 2409 if-feature hardware-sensor; 2410 status deprecated; 2412 description 2413 "Sensor-related nodes."; 2414 reference "RFC 3433: Entity Sensor MIB"; 2416 leaf value { 2417 type hw:sensor-value; 2418 status deprecated; 2419 description 2420 "The most recent measurement obtained by the server 2421 for this sensor. 2423 A client that periodically fetches this node should also 2424 fetch the nodes 'value-type', 'value-scale', and 2425 'value-precision', since they may change when the value 2426 is changed."; 2427 reference "RFC 3433: entPhySensorValue"; 2428 } 2430 leaf value-type { 2431 type hw:sensor-value-type; 2432 status deprecated; 2433 description 2434 "The type of data units associated with the 2435 sensor value"; 2436 reference "RFC 3433: entPhySensorType"; 2437 } 2439 leaf value-scale { 2440 type hw:sensor-value-scale; 2441 status deprecated; 2442 description 2443 "The (power of 10) scaling factor associated 2444 with the sensor value"; 2445 reference "RFC 3433: entPhySensorScale"; 2446 } 2448 leaf value-precision { 2449 type hw:sensor-value-precision; 2450 status deprecated; 2451 description 2452 "The number of decimal places of precision 2453 associated with the sensor value"; 2454 reference "RFC 3433: entPhySensorPrecision"; 2455 } 2457 leaf oper-status { 2458 type hw:sensor-status; 2459 status deprecated; 2460 description 2461 "The operational status of the sensor."; 2462 reference "RFC 3433: entPhySensorOperStatus"; 2463 } 2464 leaf units-display { 2465 type string; 2466 status deprecated; 2467 description 2468 "A textual description of the data units that should be 2469 used in the display of the sensor value."; 2470 reference "RFC 3433: entPhySensorUnitsDisplay"; 2471 } 2473 leaf value-timestamp { 2474 type yang:date-and-time; 2475 status deprecated; 2476 description 2477 "The time the status and/or value of this sensor was last 2478 obtained by the server."; 2479 reference "RFC 3433: entPhySensorValueTimeStamp"; 2480 } 2482 leaf value-update-rate { 2483 type uint32; 2484 units "milliseconds"; 2485 status deprecated; 2486 description 2487 "An indication of the frequency that the server updates 2488 the associated 'value' node, representing in 2489 milliseconds. The value zero indicates: 2491 - the sensor value is updated on demand (e.g., 2492 when polled by the server for a get-request), 2493 - the sensor value is updated when the sensor 2494 value changes (event-driven), 2495 - the server does not know the update rate."; 2496 reference "RFC 3433: entPhySensorValueUpdateRate"; 2497 } 2498 } 2499 } 2500 } 2502 /* 2503 * Notifications 2504 */ 2506 notification hardware-state-change { 2507 status deprecated; 2508 description 2509 "A hardware-state-change notification is generated when the 2510 value of /hardware/last-change changes in the operational 2511 state."; 2513 reference "RFC 6933, entConfigChange"; 2514 } 2516 notification hardware-state-oper-enabled { 2517 if-feature hardware-state; 2518 status deprecated; 2519 description 2520 "A hardware-state-oper-enabled notification signifies that a 2521 component has transitioned into the 'enabled' state."; 2523 leaf name { 2524 type leafref { 2525 path "/hardware/component/name"; 2526 } 2527 status deprecated; 2528 description 2529 "The name of the component that has transitioned into the 2530 'enabled' state."; 2531 } 2532 leaf admin-state { 2533 type leafref { 2534 path "/hardware/component/state/admin-state"; 2535 } 2536 status deprecated; 2537 description 2538 "The administrative state for the component."; 2539 } 2540 leaf alarm-state { 2541 type leafref { 2542 path "/hardware/component/state/alarm-state"; 2543 } 2544 status deprecated; 2545 description 2546 "The alarm state for the component."; 2547 } 2548 reference "RFC 4268, entStateOperEnabled"; 2549 } 2551 notification hardware-state-oper-disabled { 2552 if-feature hardware-state; 2553 status deprecated; 2554 description 2555 "A hardware-state-oper-disabled notification signifies that a 2556 component has transitioned into the 'disabled' state."; 2558 leaf name { 2559 type leafref { 2560 path "/hardware/component/name"; 2562 } 2563 status deprecated; 2564 description 2565 "The name of the component that has transitioned into the 2566 'disabled' state."; 2567 } 2568 leaf admin-state { 2569 type leafref { 2570 path "/hardware/component/state/admin-state"; 2571 } 2572 status deprecated; 2573 description 2574 "The administrative state for the component."; 2575 } 2576 leaf alarm-state { 2577 type leafref { 2578 path "/hardware/component/state/alarm-state"; 2579 } 2580 status deprecated; 2581 description 2582 "The alarm state for the component."; 2583 } 2584 reference "RFC 4268, entStateOperDisabled"; 2585 } 2587 } 2589 2591 Authors' Addresses 2593 Andy Bierman 2594 YumaWorks 2596 Email: andy@yumaworks.com 2598 Martin Bjorklund 2599 Tail-f Systems 2601 Email: mbj@tail-f.com 2603 Jie Dong 2604 Huawei Technologies 2606 Email: jie.dong@huawei.com 2607 Dan Romascanu 2609 Email: dromasca@gmail.com