idnits 2.17.1 draft-ietf-netmod-entity-04.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 (August 21, 2017) is 2439 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-03 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 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: February 22, 2018 Tail-f Systems 6 J. Dong 7 Huawei Technologies 8 D. Romascanu 9 August 21, 2017 11 A YANG Data Model for Hardware Management 12 draft-ietf-netmod-entity-04 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 February 22, 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.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 3 56 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 4 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 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 65 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 36 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 69 1. Introduction 71 This document defines a YANG [RFC7950] data model for the management 72 of hardware on a single server. 74 The data model includes configuration and system state (status 75 information and counters for the collection of statistics). 77 1.1. Terminology 79 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14, [RFC2119]. 84 The following terms are defined in 85 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 87 o client 89 o server 91 o configuration 93 o system state 95 o operational state datastore 96 o intended configuration datastore 98 1.1.1. Tree Diagrams 100 A simplified graphical representation of the data model is used in 101 this document. The meaning of the symbols in these diagrams is as 102 follows: 104 o Brackets "[" and "]" enclose list keys. 106 o Abbreviations before data node names: "rw" means configuration 107 data (read-write) and "ro" state data (read-only). 109 o Symbols after data node names: "?" means an optional node, "!" 110 means a presence container, and "*" denotes a list and leaf-list. 112 o Parentheses enclose choice and case nodes, and case nodes are also 113 marked with a colon (":"). 115 o Ellipsis ("...") stands for contents of subtrees that are not 116 shown. 118 2. Objectives 120 This section describes some of the design objectives for the hardware 121 model. 123 o There are many common properties used to identify hardware 124 components, which need to be supported in the hardware data model. 126 o There are many important information and states about the 127 components, which needs to be collected from the devices which 128 support the hardware data model. 130 o The hardware data model SHOULD be suitable for new implementations 131 to use as is. 133 o The hardware data model defined in this document can be 134 implemented on a system that also implements ENTITY-MIB, thus the 135 mapping between the hardware data model and ENTITY-MIB SHOULD be 136 clear. 138 o The data model should support pre-provisioning of hardware 139 components. 141 3. Hardware Data Model 143 This document defines the YANG module "ietf-hardware", which has the 144 following structure: 146 module: ietf-hardware 147 +--rw hardware 148 +--ro last-change? yang:date-and-time 149 +--rw component* [name] 150 +--rw name string 151 +--rw class identityref 152 +--ro physical-index? int32 {entity-mib}? 153 +--ro description? string 154 +--rw parent? -> ../../component/name 155 +--rw parent-rel-pos? int32 156 +--ro contains-child* -> ../../component/name 157 +--ro hardware-rev? string 158 +--ro firmware-rev? string 159 +--ro software-rev? string 160 +--ro serial-num? string 161 +--rw mfg-name? string 162 +--ro model-name? string 163 +--rw alias? string 164 +--rw asset-id? string 165 +--ro is-fru? boolean 166 +--ro mfg-date? yang:date-and-time 167 +--rw uri* inet:uri 168 +--ro uuid? yang:uuid 169 +--rw state {hardware-state}? 170 | +--ro state-last-changed? yang:date-and-time 171 | +--rw admin-state? admin-state 172 | +--ro oper-state? oper-state 173 | +--ro usage-state? usage-state 174 | +--ro alarm-state? alarm-state 175 | +--ro standby-state? standby-state 176 +--ro sensor-data {hardware-sensor}? 177 +--ro value? sensor-value 178 +--ro value-type? sensor-value-type 179 +--ro value-scale? sensor-value-scale 180 +--ro value-precision? sensor-value-precision 181 +--ro oper-status? sensor-status 182 +--ro units-display? string 183 +--ro value-timestamp? yang:date-and-time 184 +--ro value-update-rate? uint32 186 notifications: 187 +---n hardware-state-change 188 +---n hardware-state-oper-enabled {hardware-state}? 189 | +--ro name? -> /hardware/component/name 190 | +--ro admin-state? -> /hardware/component/state/admin-state 191 | +--ro alarm-state? -> /hardware/component/state/alarm-state 192 +---n hardware-state-oper-disabled {hardware-state}? 193 +--ro name? -> /hardware/component/name 194 +--ro admin-state? -> /hardware/component/state/admin-state 195 +--ro alarm-state? -> /hardware/component/state/alarm-state 197 3.1. The Components Lists 199 The data model for hardware presented in this document uses a flat 200 list of components. Each component in the list is identified by its 201 name. Furthermore, each component has a mandatory "class" leaf. 203 The "iana-hardware" module defines YANG identities for the hardware 204 types in the IANA-maintained "IANA-ENTITY-MIB" registry. 206 The "class" leaf is a YANG identity that describes the type of the 207 hardware. Vendors are encouraged to either directly use one of the 208 common IANA-defined identities, or derive a more specific identity 209 from one of them. 211 4. Relationship to ENTITY-MIB 213 If the device implements the ENTITY-MIB [RFC6933], each entry in the 214 "/hardware-state/component" list is mapped to one EntPhysicalEntry. 215 Objects that are writable in the MIB are mapped to nodes in the 216 "/hardware/component" list. 218 The "physical-index" leaf MUST contain the value of the corresponding 219 entPhysicalEntry's entPhysicalIndex. 221 The "class" leaf is mapped to both entPhysicalClass and 222 entPhysicalVendorType. If the value of the "class" leaf is an 223 identity that is either derived from or is one of the identities in 224 the "iana-hardware" module, then entPhysicalClass contains the 225 corresponding IANAPhysicalClass enumeration value. Otherwise, 226 entPhysicalClass contains the IANAPhysicalClass value "other(1)". 227 Vendors are encouraged to define an identity (derived from an 228 identity in "iana-hardware" if possible) for each enterprise-specific 229 registration identifier used for entPhysicalVendorType, and use that 230 identity for the "class" leaf. 232 The following tables list the YANG data nodes with corresponding 233 objects in the ENTITY-MIB. 235 +--------------------------------+----------------------------------+ 236 | YANG data node in | ENTITY-MIB object | 237 | /hardware/component | | 238 +--------------------------------+----------------------------------+ 239 | name | entPhysicalName | 240 | class | entPhysicalClass | 241 | | entPhysicalVendorType | 242 | physical-index | entPhysicalIndex | 243 | description | entPhysicalDescr | 244 | parent | entPhysicalContainedIn | 245 | parent-rel-pos | entPhysicalParentRelPos | 246 | contains-child | entPhysicalChildIndex | 247 | hardware-rev | entPhysicalHardwareRev | 248 | firmware-rev | entPhysicalFirmwareRev | 249 | software-rev | entPhysicalSoftwareRev | 250 | serial-num | entPhysicalSerialNum | 251 | mfg-name | entPhysicalMfgName | 252 | model-name | entPhysicalModelName | 253 | alias | entPhysicalAlias | 254 | asset-id | entPhysicalAssetID | 255 | is-fru | entPhysicalIsFRU | 256 | mfg-date | entPhysicalMfgDate | 257 | uri | entPhysicalUris | 258 | uuid | entPhysicalUUID | 259 +--------------------------------+----------------------------------+ 261 YANG Data Nodes and Related ENTITY-MIB Objects 263 5. Relationship to ENTITY-SENSOR-MIB 265 If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry 266 in the "/hardware/component" list where the container "sensor-data" 267 exists is mapped to one EntPhySensorEntry. 269 +-------------------------------------+-----------------------------+ 270 | YANG data node in | ENTITY-SENSOR-MIB object | 271 | /hardware/component/sensor-data | | 272 +-------------------------------------+-----------------------------+ 273 | value | entPhySensorValue | 274 | value-type | entPhySensorType | 275 | value-scale | entPhySensorScale | 276 | value-precision | entPhySensorPrecision | 277 | oper-status | entPhySensorOperStatus | 278 | units-display | entPhySensorUnitsDisplay | 279 | value-timestamp | entPhySensorValueTimeStamp | 280 | value-update-rate | entPhySensorValueUpdateRate | 281 +-------------------------------------+-----------------------------+ 283 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 285 6. Relationship to ENTITY-STATE-MIB 287 If the device implements the ENTITY-STATE-MIB [RFC4268], each entry 288 in the "/hardware/component" list where the container "state" exists 289 is mapped to one EntStateEntry. 291 +------------------------------------------+------------------------+ 292 | YANG data node in | ENTITY-STATE-MIB | 293 | /hardware/component/state | object | 294 +------------------------------------------+------------------------+ 295 | state-last-changed | entStateLastChanged | 296 | admin-state | entStateAdmin | 297 | oper-state | entStateOper | 298 | usage-state | entStateUsage | 299 | alarm-state | entStateAlarm | 300 | standby-state | entStateStandby | 301 +------------------------------------------+------------------------+ 303 YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 305 7. Hardware YANG Module 307 file "ietf-hardware@2017-08-21.yang" 309 module ietf-hardware { 310 yang-version 1.1; 311 namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; 312 prefix hw; 314 import ietf-inet-types { 315 prefix inet; 316 } 317 import ietf-yang-types { 318 prefix yang; 319 } 320 import iana-hardware { 321 prefix ianahw; 322 } 324 organization 325 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 327 contact 328 "WG Web: 329 WG List: 331 Editor: Andy Bierman 332 334 Editor: Martin Bjorklund 335 337 Editor: Jie Dong 338 340 Editor: Dan Romascanu 341 "; 343 // RFC Ed.: replace XXXX and YYYY with actual RFC numbers and 344 // remove this note. 346 description 347 "This module contains a collection of YANG definitions for 348 managing hardware. 350 This data model is designed for the Network Management Datastore 351 Architecture defined in RFC YYYY. 353 Copyright (c) 2017 IETF Trust and the persons identified as 354 authors of the code. All rights reserved. 356 Redistribution and use in source and binary forms, with or 357 without modification, is permitted pursuant to, and subject 358 to the license terms contained in, the Simplified BSD License 359 set forth in Section 4.c of the IETF Trust's Legal Provisions 360 Relating to IETF Documents 361 (http://trustee.ietf.org/license-info). 363 This version of this YANG module is part of RFC XXXX; see 364 the RFC itself for full legal notices."; 366 // RFC Ed.: update the date below with the date of RFC publication 367 // and remove this note. 368 revision 2017-08-21 { 369 description 370 "Initial revision."; 371 reference 372 "RFC XXXX: A YANG Data Model for Hardware Management"; 373 } 375 /* 376 * Features 377 */ 379 feature entity-mib { 380 description 381 "This feature indicates that the device implements 382 the ENTITY-MIB."; 383 reference "RFC 6933: Entity MIB (Version 4)"; 384 } 386 feature hardware-state { 387 description 388 "Indicates the ENTITY-STATE-MIB objects are supported"; 389 reference "RFC 4268: Entity State MIB"; 390 } 392 feature hardware-sensor { 393 description 394 "Indicates the ENTITY-SENSOR-MIB objects are supported"; 395 reference "RFC 3433: Entity Sensor MIB"; 396 } 398 /* 399 * Typedefs 400 */ 402 typedef admin-state { 403 type enumeration { 404 enum unknown { 405 value 1; 406 description 407 "The resource is unable to report administrative state."; 408 } 409 enum locked { 410 value 2; 411 description 412 "The resource is administratively prohibited from use."; 413 } 414 enum shutting-down { 415 value 3; 416 description 417 "The resource usage is administratively limited to current 418 instances of use."; 419 } 420 enum unlocked { 421 value 4; 422 description 423 "The resource is not administratively prohibited from 424 use."; 425 } 426 } 427 description 428 "Represents the various possible administrative states."; 429 reference "RFC 4268: EntityAdminState"; 430 } 432 typedef oper-state { 433 type enumeration { 434 enum unknown { 435 value 1; 436 description 437 "The resource is unable to report its operational state."; 438 } 439 enum disabled { 440 value 2; 441 description 442 "The resource is totally inoperable."; 443 } 444 enum enabled { 445 value 3; 446 description 447 "The resource is partially or fully operable."; 448 } 449 enum testing { 450 value 4; 451 description 452 "The resource is currently being tested and cannot 453 therefore report whether it is operational or not."; 454 } 455 } 456 description 457 "Represents the possible values of operational states."; 458 reference "RFC 4268: EntityOperState"; 459 } 461 typedef usage-state { 462 type enumeration { 463 enum unknown { 464 value 1; 465 description 466 "The resource is unable to report usage state."; 467 } 468 enum idle { 469 value 2; 470 description 471 "The resource is servicing no users."; 472 } 473 enum active { 474 value 3; 475 description 476 "The resource is currently in use and it has sufficient 477 spare capacity to provide for additional users."; 478 } 479 enum busy { 480 value 4; 481 description 482 "The resource is currently in use, but it currently has no 483 spare capacity to provide for additional users."; 484 } 485 } 486 description 487 "Represents the possible values of usage states."; 488 reference "RFC 4268, EntityUsageState"; 489 } 491 typedef alarm-state { 492 type bits { 493 bit unknown { 494 position 0; 495 description 496 "The resource is unable to report alarm state."; 497 } 498 bit under-repair { 499 position 1; 500 description 501 "The resource is currently being repaired, which, depending 502 on the implementation, may make the other values in this 503 bit string not meaningful."; 504 } 505 bit critical { 506 position 2; 507 description 508 "One or more critical alarms are active against the 509 resource."; 511 } 512 bit major { 513 position 3; 514 description 515 "One or more major alarms are active against the 516 resource."; 517 } 518 bit minor { 519 position 4; 520 description 521 "One or more minor alarms are active against the 522 resource."; 523 } 524 bit warning { 525 position 5; 526 description 527 "One or more warning alarms are active against the 528 resource."; 529 } 530 bit indeterminate { 531 position 6; 532 description 533 "One or more alarms of whose perceived severity cannot be 534 determined are active against this resource."; 535 } 536 } 537 description 538 "Represents the possible values of alarm states. An alarm is a 539 persistent indication of an error or warning condition. 541 When no bits of this attribute are set, then no active alarms 542 are known against this component and it is not under repair."; 543 reference "RFC 4268: EntityAlarmStatus"; 544 } 546 typedef standby-state { 547 type enumeration { 548 enum unknown { 549 value 1; 550 description 551 "The resource is unable to report standby state."; 552 } 553 enum hot-standby { 554 value 2; 555 description 556 "The resource is not providing service, but it will be 557 immediately able to take over the role of the resource to 558 be backed up, without the need for initialization 559 activity, and will contain the same information as the 560 resource to be backed up."; 561 } 562 enum cold-standby { 563 value 3; 564 description 565 "The resource is to back up another resource, but will not 566 be immediately able to take over the role of a resource to 567 be backed up, and will require some initialization 568 activity."; 569 } 570 enum providing-service { 571 value 4; 572 description 573 "The resource is providing service."; 574 } 575 } 576 description 577 "Represents the possible values of standby states."; 578 reference "RFC 4268: EntityStandbyStatus"; 579 } 581 typedef sensor-value-type { 582 type enumeration { 583 enum other { 584 value 1; 585 description 586 "A measure other than those listed below."; 587 } 588 enum unknown { 589 value 2; 590 description 591 "An unknown measurement, or arbitrary, relative numbers"; 592 } 593 enum volts-AC { 594 value 3; 595 description 596 "A measure of electric potential (alternating current)."; 597 } 598 enum volts-DC { 599 value 4; 600 description 601 "A measure of electric potential (direct current)."; 602 } 603 enum amperes { 604 value 5; 605 description 606 "A measure of electric current."; 608 } 609 enum watts { 610 value 6; 611 description 612 "A measure of power."; 613 } 614 enum hertz { 615 value 7; 616 description 617 "A measure of frequency."; 618 } 619 enum celsius { 620 value 8; 621 description 622 "A measure of temperature."; 623 } 624 enum percent-RH { 625 value 9; 626 description 627 "A measure of percent relative humidity."; 628 } 629 enum rpm { 630 value 10; 631 description 632 "A measure of shaft revolutions per minute."; 633 } 634 enum cmm { 635 value 11; 636 description 637 "A measure of cubic meters per minute (airflow)."; 638 } 639 enum truth-value { 640 value 12; 641 description 642 "Value is one of 1 (true) or 2 (false)"; 643 } 644 } 645 description 646 "A node using this data type represents the sensor measurement 647 data type associated with a physical sensor value. The actual 648 data units are determined by examining a node of this type 649 together with the associated sensor-value-scale node. 651 A node of this type SHOULD be defined together with nodes of 652 type sensor-value-scale and sensor-value-precision. These 653 three types are used to identify the semantics of a node of 654 type sensor-value."; 655 reference "RFC 3433: EntitySensorDataType"; 657 } 659 typedef sensor-value-scale { 660 type enumeration { 661 enum yocto { 662 value 1; 663 description 664 "Data scaling factor of 10^-24."; 665 } 666 enum zepto { 667 value 2; 668 description 669 "Data scaling factor of 10^-21."; 670 } 671 enum atto { 672 value 3; 673 description 674 "Data scaling factor of 10^-18."; 675 } 676 enum femto { 677 value 4; 678 description 679 "Data scaling factor of 10^-15."; 680 } 681 enum pico { 682 value 5; 683 description 684 "Data scaling factor of 10^-12."; 685 } 686 enum nano { 687 value 6; 688 description 689 "Data scaling factor of 10^-9."; 690 } 691 enum micro { 692 value 7; 693 description 694 "Data scaling factor of 10^-6."; 695 } 696 enum milli { 697 value 8; 698 description 699 "Data scaling factor of 10^-3."; 700 } 701 enum units { 702 value 9; 703 description 704 "Data scaling factor of 10^0."; 706 } 707 enum kilo { 708 value 10; 709 description 710 "Data scaling factor of 10^3."; 711 } 712 enum mega { 713 value 11; 714 description 715 "Data scaling factor of 10^6."; 716 } 717 enum giga { 718 value 12; 719 description 720 "Data scaling factor of 10^9."; 721 } 722 enum tera { 723 value 13; 724 description 725 "Data scaling factor of 10^12."; 726 } 727 enum exa { 728 value 14; 729 description 730 "Data scaling factor of 10^15."; 731 } 732 enum peta { 733 value 15; 734 description 735 "Data scaling factor of 10^18."; 736 } 737 enum zetta { 738 value 16; 739 description 740 "Data scaling factor of 10^21."; 741 } 742 enum yotta { 743 value 17; 744 description 745 "Data scaling factor of 10^24."; 746 } 747 } 748 description 749 "A node using this data type represents a data scaling factor, 750 represented with an International System of Units (SI) prefix. 751 The actual data units are determined by examining a node of 752 this type together with the associated sensor-value-type. 754 A node of this type SHOULD be defined together with nodes of 755 type sensor-value-type and sensor-value-precision. Together, 756 associated nodes of these three types are used to identify the 757 semantics of a node of type sensor-value."; 758 reference "RFC 3433: EntitySensorDataScale"; 759 } 761 typedef sensor-value-precision { 762 type int32 { 763 range "-8 .. 9"; 764 } 765 description 766 "A node using this data type represents a sensor value 767 precision range. 769 A node of this type SHOULD be defined together with nodes of 770 type sensor-value-type and sensor-value-scale. Together, 771 associated nodes of these three types are used to identify the 772 semantics of a node of type sensor-value. 774 If a node of this type contains a value in the range 1 to 9, 775 it represents the number of decimal places in the fractional 776 part of an associated sensor-value fixed- point number. 778 If a node of this type contains a value in the range -8 to -1, 779 it represents the number of accurate digits in the associated 780 sensor-value fixed-point number. 782 The value zero indicates the associated sensor-value node is 783 not a fixed-point number. 785 Server implementers must choose a value for the associated 786 sensor-value-precision node so that the precision and accuracy 787 of the associated sensor-value node is correctly indicated. 789 For example, a component representing a temperature sensor 790 that can measure 0 degrees to 100 degrees C in 0.1 degree 791 increments, +/- 0.05 degrees, would have an 792 sensor-value-precision value of '1', an sensor-value-scale 793 value of 'units', and an sensor-value ranging from '0' to 794 '1000'. The sensor-value would be interpreted as 795 'degrees C * 10'."; 796 reference "RFC 3433: EntitySensorPrecision"; 797 } 799 typedef sensor-value { 800 type int32 { 801 range "-1000000000 .. 1000000000"; 803 } 804 description 805 "A node using this data type represents an sensor value. 807 A node of this type SHOULD be defined together with nodes of 808 type sensor-value-type, sensor-value-scale, and 809 sensor-value-precision. Together, associated nodes of those 810 three types are used to identify the semantics of a node of 811 this data type. 813 The semantics of a node using this data type are determined by 814 the value of the associated sensor-value-type node. 816 If the associated sensor-value-type node is equal to 'voltsAC', 817 'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm', 818 then a node of this type MUST contain a fixed point number 819 ranging from -999,999,999 to +999,999,999. The value 820 -1000000000 indicates an underflow error. The value +1000000000 821 indicates an overflow error. The sensor-value-precision 822 indicates how many fractional digits are represented in the 823 associated sensor-value node. 825 If the associated sensor-value-type node is equal to 826 'percentRH', then a node of this type MUST contain a number 827 ranging from 0 to 100. 829 If the associated sensor-value-type node is equal to 'rpm', 830 then a node of this type MUST contain a number ranging from 831 -999,999,999 to +999,999,999. 833 If the associated sensor-value-type node is equal to 834 'truth-value', then a node of this type MUST contain either the 835 value 1 (true) or the value 2 (false)'. 837 If the associated sensor-value-type node is equal to 'other' or 838 unknown', then a node of this type MUST contain a number 839 ranging from -1000000000 to 1000000000."; 840 reference "RFC 3433: EntitySensorValue"; 841 } 843 typedef sensor-status { 844 type enumeration { 845 enum ok { 846 value 1; 847 description 848 "Indicates that the server can obtain the sensor value."; 849 } 850 enum unavailable { 851 value 2; 852 description 853 "Indicates that the server presently cannot obtain the 854 sensor value."; 855 } 856 enum nonoperational { 857 value 3; 858 description 859 "Indicates that the server believes the sensor is broken. 860 The sensor could have a hard failure (disconnected wire), 861 or a soft failure such as out-of-range, jittery, or wildly 862 fluctuating readings."; 863 } 864 } 865 description 866 "A node using this data type represents the operational status 867 of a physical sensor."; 868 reference "RFC 3433: EntitySensorStatus"; 869 } 871 /* 872 * Data nodes 873 */ 875 container hardware { 876 description 877 "Data nodes representing components. 879 If the server supports configuration of hardware components, 880 then this data model is instantiated in the configuration 881 datastores supported by the server. The leaf-list 'datastore' 882 for the module 'ietf-hardware' in the YANG library provides 883 this information."; 885 leaf last-change { 886 type yang:date-and-time; 887 config false; 888 description 889 "The time the '/hardware/component' list changed in the 890 operational state datastore."; 891 } 893 list component { 894 key name; 895 description 896 "List of components. 898 When the server detects a new hardware component, it 899 initializes a list entry in the operational state datastore. 901 If the server does not support configuration of hardware 902 components, list entries in the operational state datastore 903 are initialized with values for all nodes as detected by the 904 implementation. 906 Otherwise, the following procedure is followed: 908 1. If there is an entry in the /hardware/component list in 909 the intended configuration datastore with values for 910 the nodes 'class', 'parent', 'parent-rel-pos' that are 911 equal to the detected values, then: 913 1a. If the configured entry has a value for 'mfg-name' 914 that is equal to the detected value, or if the 915 'mfg-name' value cannot be detected, then the list 916 entry in the operational state datastore is 917 initialized with the configured values for all 918 configured nodes, including the 'name'. 920 Otherwise, the list entry in the operational state 921 datastore is initialized with values for all nodes as 922 detected by the implementation. The implementation 923 may raise an alarm that informs about the 'mfg-name' 924 mismatch condition. How this is done is outside the 925 scope of this document. 927 1b. Otherwise (i.e., there is no matching configuration 928 entry), the list entry in the operational state 929 datastore is initialized with values for all nodes as 930 detected by the implementation. 932 If the /hardware/component list in the intended 933 configuration datastore is modified, then the system MUST 934 behave as if it re-initializes itself, and follow the 935 procedure in (1)."; 936 reference "RFC 6933: entPhysicalEntry"; 938 leaf name { 939 type string; 940 description 941 "The name assigned to this component. 943 This name is not required to be the same as 944 entPhysicalName."; 945 } 946 leaf class { 947 type identityref { 948 base ianahw:hardware-class; 949 } 950 mandatory true; 951 description 952 "An indication of the general hardware type of the 953 component."; 954 reference "RFC 6933: entPhysicalClass"; 955 } 957 leaf physical-index { 958 if-feature entity-mib; 959 type int32 { 960 range "1..2147483647"; 961 } 962 config false; 963 description 964 "The entPhysicalIndex for the entPhysicalEntry represented 965 by this list entry."; 966 reference "RFC 6933: entPhysicalIndex"; 967 } 969 leaf description { 970 type string; 971 config false; 972 description 973 "A textual description of component. This node should 974 contain a string that identifies the manufacturer's name 975 for the component and should be set to a distinct value 976 for each version or model of the component."; 977 reference "RFC 6933: entPhysicalDescr"; 978 } 980 leaf parent { 981 type leafref { 982 path "../../component/name"; 983 require-instance false; 984 } 985 description 986 "The name of the component that physically contains this 987 component. 989 If this leaf is not instantiated, it indicates that this 990 component is not contained in any other component. 992 In the event that a physical component is contained by 993 more than one physical component (e.g., double-wide 994 modules), this node contains the name of one of these 995 components. An implementation MUST use the same name 996 every time this node is instantiated."; 997 reference "RFC 6933: entPhysicalContainedIn"; 998 } 1000 leaf parent-rel-pos { 1001 type int32 { 1002 range "0 .. 2147483647"; 1003 } 1004 description 1005 "An indication of the relative position of this child 1006 component among all its sibling components. Sibling 1007 components are defined as components that share the same 1008 instance values of each of the 'parent' and 'class' 1009 nodes."; 1010 reference "RFC 6933: entPhysicalParentRelPos"; 1011 } 1013 leaf-list contains-child { 1014 type leafref { 1015 path "../../component/name"; 1016 } 1017 config false; 1018 description 1019 "The name of the contained component."; 1020 reference "RFC 6933: entPhysicalChildIndex"; 1021 } 1023 leaf hardware-rev { 1024 type string; 1025 config false; 1026 description 1027 "The vendor-specific hardware revision string for the 1028 component. The preferred value is the hardware revision 1029 identifier actually printed on the component itself (if 1030 present)."; 1031 reference "RFC 6933: entPhysicalHardwareRev"; 1032 } 1034 leaf firmware-rev { 1035 type string; 1036 config false; 1037 description 1038 "The vendor-specific firmware revision string for the 1039 component."; 1040 reference "RFC 6933: entPhysicalFirmwareRev"; 1041 } 1042 leaf software-rev { 1043 type string; 1044 config false; 1045 description 1046 "The vendor-specific software revision string for the 1047 component."; 1048 reference "RFC 6933: entPhysicalSoftwareRev"; 1049 } 1051 leaf serial-num { 1052 type string; 1053 config false; 1054 description 1055 "The vendor-specific serial number string for the 1056 component. The preferred value is the serial number 1057 string actually printed on the component itself (if 1058 present)."; 1059 reference "RFC 6933: entPhysicalSerialNum"; 1060 } 1062 leaf mfg-name { 1063 type string; 1064 description 1065 "The name of the manufacturer of this physical component. 1066 The preferred value is the manufacturer name string 1067 actually printed on the component itself (if present). 1069 Note that comparisons between instances of the model-name, 1070 firmware-rev, software-rev, and the serial-num nodes are 1071 only meaningful amongst component with the same value of 1072 mfg-name. 1074 If the manufacturer name string associated with the 1075 physical component is unknown to the server, then this 1076 node is not instantiated."; 1077 reference "RFC 6933: entPhysicalMfgName"; 1078 } 1080 leaf model-name { 1081 type string; 1082 config false; 1083 description 1084 "The vendor-specific model name identifier string 1085 associated with this physical component. The preferred 1086 value is the customer-visible part number, which may be 1087 printed on the component itself. 1089 If the model name string associated with the physical 1090 component is unknown to the server, then this node is not 1091 instantiated."; 1092 reference "RFC 6933: entPhysicalModelName"; 1093 } 1095 leaf alias { 1096 type string; 1097 description 1098 "An 'alias' name for the component, as specified by a 1099 network manager, and provides a non-volatile 'handle' for 1100 the component. 1102 If no configured value exists, the server MAY set the 1103 value of this node to a locally unique value in the 1104 operational state datastore. 1106 A server implementation MAY map this leaf to the 1107 entPhysicalAlias MIB object. Such an implementation needs 1108 to use some mechanism to handle the differences in size 1109 and characters allowed between this leaf and 1110 entPhysicalAlias. The definition of such a mechanism is 1111 outside the scope of this document."; 1112 reference "RFC 6933: entPhysicalAlias"; 1113 } 1115 leaf asset-id { 1116 type string; 1117 description 1118 "This node is a user-assigned asset tracking identifier for 1119 the component. 1121 A server implementation MAY map this leaf to the 1122 entPhysicalAssetID MIB object. Such an implementation 1123 needs to use some mechanism to handle the differences in 1124 size and characters allowed between this leaf and 1125 entPhysicalAssetID. The definition of such a mechanism is 1126 outside the scope of this document."; 1127 reference "RFC 6933: entPhysicalAssetID"; 1128 } 1130 leaf is-fru { 1131 type boolean; 1132 config false; 1133 description 1134 "This node indicates whether or not this component is 1135 considered a 'field replaceable unit' by the vendor. If 1136 this node contains the value 'true', then this component 1137 identifies a field replaceable unit. For all components 1138 that are permanently contained within a field replaceable 1139 unit, the value 'false' should be returned for this 1140 node."; 1141 reference "RFC 6933: entPhysicalIsFRU"; 1142 } 1144 leaf mfg-date { 1145 type yang:date-and-time; 1146 config false; 1147 description 1148 "The date of manufacturing of the managed component."; 1149 reference "RFC 6933: entPhysicalMfgDate"; 1150 } 1152 leaf-list uri { 1153 type inet:uri; 1154 description 1155 "This node contains identification information about the 1156 component."; 1157 reference "RFC 6933: entPhysicalUris"; 1158 } 1160 leaf uuid { 1161 type yang:uuid; 1162 config false; 1163 description 1164 "A Universally Unique Identifier of the component."; 1165 reference "RFC 6933: entPhysicalUUID"; 1166 } 1168 container state { 1169 if-feature hardware-state; 1170 description 1171 "State-related nodes"; 1172 reference "RFC 4268: Entity State MIB"; 1174 leaf state-last-changed { 1175 type yang:date-and-time; 1176 config false; 1177 description 1178 "The date and time when the value of any of the 1179 admin-state, oper-state, usage-state, alarm-state, or 1180 standby-state changed for this component. 1182 If there has been no change since the last 1183 re-initialization of the local system, this node 1184 contains the date and time of local system 1185 initialization. If there has been no change since the 1186 component was added to the local system, this node 1187 contains the date and time of the insertion."; 1188 reference "RFC 4268: entStateLastChanged"; 1189 } 1191 leaf admin-state { 1192 type admin-state; 1193 description 1194 "The administrative state for this component. 1196 This node refers to a component's administrative 1197 permission to service both other components within its 1198 containment hierarchy as well other users of its 1199 services defined by means outside the scope of this 1200 module. 1202 Some components exhibit only a subset of the remaining 1203 administrative state values. Some components cannot be 1204 locked, and hence this node exhibits only the 'unlocked' 1205 state. Other components cannot be shutdown gracefully, 1206 and hence this node does not exhibit the 'shutting-down' 1207 state."; 1208 reference "RFC 4268: entStateAdmin"; 1209 } 1211 leaf oper-state { 1212 type oper-state; 1213 config false; 1214 description 1215 "The operational state for this component. 1217 Note that this node does not follow the administrative 1218 state. An administrative state of down does not predict 1219 an operational state of disabled. 1221 Note that some implementations may not be able to 1222 accurately report oper-state while the admin-state node 1223 has a value other than 'unlocked'. In these cases, this 1224 node MUST have a value of 'unknown'."; 1225 reference "RFC 4268: entStateOper"; 1226 } 1228 leaf usage-state { 1229 type usage-state; 1230 config false; 1231 description 1232 "The usage state for this component. 1234 This node refers to a component's ability to service 1235 more components in a containment hierarchy. 1237 Some components will exhibit only a subset of the usage 1238 state values. Components that are unable to ever 1239 service any components within a containment hierarchy 1240 will always have a usage state of 'busy'. Some 1241 components will only ever be able to support one 1242 component within its containment hierarchy and will 1243 therefore only exhibit values of 'idle' and 'busy'."; 1244 reference "RFC 4268, entStateUsage"; 1245 } 1247 leaf alarm-state { 1248 type alarm-state; 1249 config false; 1250 description 1251 "The alarm state for this component. It does not 1252 include the alarms raised on child components within its 1253 containment hierarchy."; 1254 reference "RFC 4268: entStateAlarm"; 1255 } 1257 leaf standby-state { 1258 type standby-state; 1259 config false; 1260 description 1261 "The standby state for this component. 1263 Some components will exhibit only a subset of the 1264 remaining standby state values. If this component 1265 cannot operate in a standby role, the value of this node 1266 will always be 'providing-service'."; 1267 reference "RFC 4268: entStateStandby"; 1268 } 1269 } 1271 container sensor-data { 1272 when 'derived-from-or-self(../class, 1273 "ianahw:sensor")' { 1274 description 1275 "Sensor data nodes present for any component of type 1276 'sensor'"; 1277 } 1278 if-feature hardware-sensor; 1279 config false; 1281 description 1282 "Sensor-related nodes."; 1283 reference "RFC 3433: Entity Sensor MIB"; 1285 leaf value { 1286 type sensor-value; 1287 description 1288 "The most recent measurement obtained by the server 1289 for this sensor. 1291 A client that periodically fetches this node should also 1292 fetch the nodes 'value-type', 'value-scale', and 1293 'value-precision', since they may change when the value 1294 is changed."; 1295 reference "RFC 3433: entPhySensorValue"; 1296 } 1298 leaf value-type { 1299 type sensor-value-type; 1300 description 1301 "The type of data units associated with the 1302 sensor value"; 1303 reference "RFC 3433: entPhySensorType"; 1304 } 1306 leaf value-scale { 1307 type sensor-value-scale; 1308 description 1309 "The (power of 10) scaling factor associated 1310 with the sensor value"; 1311 reference "RFC 3433: entPhySensorScale"; 1312 } 1314 leaf value-precision { 1315 type sensor-value-precision; 1316 description 1317 "The number of decimal places of precision 1318 associated with the sensor value"; 1319 reference "RFC 3433: entPhySensorPrecision"; 1320 } 1322 leaf oper-status { 1323 type sensor-status; 1324 description 1325 "The operational status of the sensor."; 1326 reference "RFC 3433: entPhySensorOperStatus"; 1327 } 1329 leaf units-display { 1330 type string; 1331 description 1332 "A textual description of the data units that should be 1333 used in the display of the sensor value."; 1334 reference "RFC 3433: entPhySensorUnitsDisplay"; 1335 } 1337 leaf value-timestamp { 1338 type yang:date-and-time; 1339 description 1340 "The time the status and/or value of this sensor was last 1341 obtained by the server."; 1342 reference "RFC 3433: entPhySensorValueTimeStamp"; 1343 } 1345 leaf value-update-rate { 1346 type uint32; 1347 units "milliseconds"; 1348 description 1349 "An indication of the frequency that the server updates 1350 the associated 'value' node, representing in 1351 milliseconds. The value zero indicates: 1353 - the sensor value is updated on demand (e.g., 1354 when polled by the server for a get-request), 1355 - the sensor value is updated when the sensor 1356 value changes (event-driven), 1357 - the server does not know the update rate."; 1358 reference "RFC 3433: entPhySensorValueUpdateRate"; 1359 } 1360 } 1361 } 1362 } 1364 /* 1365 * Notifications 1366 */ 1368 notification hardware-state-change { 1369 description 1370 "A hardware-state-change notification is generated when the 1371 value of /hardware/last-change changes in the operational 1372 state datastore."; 1373 reference "RFC 6933, entConfigChange"; 1374 } 1376 notification hardware-state-oper-enabled { 1377 if-feature hardware-state; 1378 description 1379 "A hardware-state-oper-enabled notification signifies that a 1380 component has transitioned into the 'enabled' state."; 1382 leaf name { 1383 type leafref { 1384 path "/hardware/component/name"; 1385 } 1386 description 1387 "The name of the component that has transitioned into the 1388 'enabled' state."; 1389 } 1390 leaf admin-state { 1391 type leafref { 1392 path "/hardware/component/state/admin-state"; 1393 } 1394 description 1395 "The administrative state for the component."; 1396 } 1397 leaf alarm-state { 1398 type leafref { 1399 path "/hardware/component/state/alarm-state"; 1400 } 1401 description 1402 "The alarm state for the component."; 1403 } 1404 reference "RFC 4268, entStateOperEnabled"; 1405 } 1407 notification hardware-state-oper-disabled { 1408 if-feature hardware-state; 1409 description 1410 "A hardware-state-oper-disabled notification signifies that a 1411 component has transitioned into the 'disabled' state."; 1413 leaf name { 1414 type leafref { 1415 path "/hardware/component/name"; 1416 } 1417 description 1418 "The name of the component that has transitioned into the 1419 'disabled' state."; 1420 } 1421 leaf admin-state { 1422 type leafref { 1423 path "/hardware/component/state/admin-state"; 1424 } 1425 description 1426 "The administrative state for the component."; 1427 } 1428 leaf alarm-state { 1429 type leafref { 1430 path "/hardware/component/state/alarm-state"; 1431 } 1432 description 1433 "The alarm state for the component."; 1434 } 1435 reference "RFC 4268, entStateOperDisabled"; 1436 } 1438 } 1440 1442 file "iana-hardware@2017-08-21.yang" 1444 module iana-hardware { 1445 yang-version 1.1; 1446 namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; 1447 prefix ianahw; 1449 organization "IANA"; 1450 contact 1451 " Internet Assigned Numbers Authority 1453 Postal: ICANN 1454 4676 Admiralty Way, Suite 330 1455 Marina del Rey, CA 90292 1457 Tel: +1 310 823 9358 1458 "; 1460 description 1461 "IANA defined identities for hardware class."; 1462 reference 1463 "https://www.iana.org/assignments/ianaentity-mib/ianaentity-mib"; 1465 // RFC Ed.: replace XXXX with actual RFC number and remove this 1466 // note. 1468 // RFC Ed.: update the date below with the date of RFC publication 1469 // and remove this note. 1470 revision 2017-08-21 { 1471 description 1472 "Initial revision."; 1474 reference 1475 "RFC XXXX: A YANG Data Model for Hardware Management"; 1476 } 1478 /* 1479 * Identities 1480 */ 1482 identity hardware-class { 1483 description 1484 "This identity is the base for all hardware class 1485 identifiers."; 1486 } 1488 identity unknown { 1489 base ianahw:hardware-class; 1490 description 1491 "This identity is applicable if the hardware class is unknown 1492 to the server."; 1493 } 1495 identity chassis { 1496 base ianahw:hardware-class; 1497 description 1498 "This identity is applicable if the hardware class is an 1499 overall container for networking equipment. Any class of 1500 physical component, except a stack, may be contained within a 1501 chassis; a chassis may only be contained within a stack."; 1502 } 1504 identity backplane { 1505 base ianahw:hardware-class; 1506 description 1507 "This identity is applicable if the hardware class is some sort 1508 of device for aggregating and forwarding networking traffic, 1509 such as a shared backplane in a modular ethernet switch. Note 1510 that an implementation may model a backplane as a single 1511 physical component, which is actually implemented as multiple 1512 discrete physical components (within a chassis or stack)."; 1513 } 1515 identity container { 1516 base ianahw:hardware-class; 1517 description 1518 "This identity is applicable if the hardware class is capable 1519 of containing one or more removable physical entities, 1520 possibly of different types. For example, each (empty or 1521 full) slot in a chassis will be modeled as a container. Note 1522 that all removable physical components should be modeled 1523 within a container component, such as field-replaceable 1524 modules, fans, or power supplies. Note that all known 1525 containers should be modeled by the agent, including empty 1526 containers."; 1527 } 1529 identity power-supply { 1530 base ianahw:hardware-class; 1531 description 1532 "This identity is applicable if the hardware class is a 1533 power-supplying component."; 1534 } 1536 identity fan { 1537 base ianahw:hardware-class; 1538 description 1539 "This identity is applicable if the hardware class is a fan or 1540 other heat-reduction component."; 1541 } 1543 identity sensor { 1544 base ianahw:hardware-class; 1545 description 1546 "This identity is applicable if the hardware class is some sort 1547 of sensor, such as a temperature sensor within a router 1548 chassis."; 1549 } 1551 identity module { 1552 base ianahw:hardware-class; 1553 description 1554 "This identity is applicable if the hardware class is some sort 1555 of self-contained sub-system. If a module component is 1556 removable, then it should be modeled within a container 1557 component; otherwise, it should be modeled directly within 1558 another physical component (e.g., a chassis or another 1559 module)."; 1560 } 1562 identity port { 1563 base ianahw:hardware-class; 1564 description 1565 "This identity is applicable if the hardware class is some sort 1566 of networking port, capable of receiving and/or transmitting 1567 networking traffic."; 1568 } 1569 identity stack { 1570 base ianahw:hardware-class; 1571 description 1572 "This identity is applicable if the hardware class is some sort 1573 of super-container (possibly virtual) intended to group 1574 together multiple chassis entities. A stack may be realized 1575 by a virtual cable, a real interconnect cable attached to 1576 multiple chassis, or multiple interconnect cables. A stack 1577 should not be modeled within any other physical components, 1578 but a stack may be contained within another stack. Only 1579 chassis components should be contained within a stack."; 1580 } 1582 identity cpu { 1583 base ianahw:hardware-class; 1584 description 1585 "This identity is applicable if the hardware class is some sort 1586 of central processing unit."; 1587 } 1589 identity energy-object { 1590 base ianahw:hardware-class; 1591 description 1592 "This identity is applicable if the hardware class is some sort 1593 of energy object, i.e., a piece of equipment that is part of 1594 or attached to a communications network that is monitored, 1595 controlled, or aids in the management of another device for 1596 Energy Management."; 1597 } 1599 identity battery { 1600 base ianahw:hardware-class; 1601 description 1602 "This identity is applicable if the hardware class is some sort 1603 of battery."; 1604 } 1606 identity storage-drive { 1607 base ianahw:hardware-class; 1608 description 1609 "This identity is applicable if the hardware class is some sort 1610 of component with data storage capability as main 1611 functionality, e.g., disk drive (HDD), solid state device 1612 (SSD), hybrid (SSHD), object storage (OSD) or other."; 1613 } 1614 } 1616 1618 8. IANA Considerations 1620 This document registers two URIs in the IETF XML registry [RFC3688]. 1621 Following the format in RFC 3688, the following registrations are 1622 requested to be made. 1624 URI: urn:ietf:params:xml:ns:yang:iana-hardware 1625 Registrant Contact: The IESG. 1626 XML: N/A, the requested URI is an XML namespace. 1628 URI: urn:ietf:params:xml:ns:yang:ietf-hardware 1629 Registrant Contact: The IESG. 1630 XML: N/A, the requested URI is an XML namespace. 1632 This document registers two YANG modules in the YANG Module Names 1633 registry [RFC6020]. 1635 name: iana-hardware 1636 namespace: urn:ietf:params:xml:ns:yang:iana-hardware 1637 prefix: ianahw 1638 reference: RFC XXXX 1640 name: ietf-hardware 1641 namespace: urn:ietf:params:xml:ns:yang:ietf-hardware 1642 prefix: hw 1643 reference: RFC XXXX 1645 9. Security Considerations 1647 The YANG module defined in this memo is designed to be accessed via 1648 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1649 secure transport layer, and the mandatory-to-implement secure 1650 transport is Secure Shell (SSH) [RFC6242]. The NETCONF access 1651 control model [RFC6536] provides the means to restrict access for 1652 particular NETCONF users to a pre-configured subset of all available 1653 NETCONF protocol operations and content. 1655 There are a number of data nodes defined in this YANG module that are 1656 writable/creatable/deletable (i.e., config true, which is the 1657 default). These data nodes may be considered sensitive or vulnerable 1658 in some network environments. Write operations (e.g., edit-config) 1659 to these data nodes without proper protection can have a negative 1660 effect on network operations. These are the subtrees and data nodes 1661 and their sensitivity/vulnerability: 1663 /hardware/component/admin-state: Setting this node to 'locked' or 1664 'shutting-down' can cause disruption of services ranging from 1665 those running on a port to those on an entire device, depending on 1666 the type of component. 1668 Some of the readable data nodes in this YANG module may be considered 1669 sensitive or vulnerable in some network environments. It is thus 1670 important to control read access (e.g., via get, get-config, or 1671 notification) to these data nodes. These are the subtrees and data 1672 nodes and their sensitivity/vulnerability: 1674 /hardware/component: The leafs in this list expose information about 1675 the physical components in a device, which may be used to identify 1676 the vendor, model, version, and specific device-identification 1677 information of each system component. 1679 /hardware/component/sensor-data/value: This node may expose the 1680 values of particular physical sensors in a device. 1682 /hardware/component/state: Access to this node allows one to figure 1683 out what the active and standby resources in a device are. 1685 10. Acknowledgments 1687 The authors wish to thank the following individuals, who all provided 1688 helpful comments on various draft versions of this document: Bart 1689 Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder. 1691 11. Normative References 1693 [I-D.ietf-netmod-revised-datastores] 1694 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1695 and R. Wilton, "Network Management Datastore 1696 Architecture", draft-ietf-netmod-revised-datastores-03 1697 (work in progress), July 2017. 1699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1700 Requirement Levels", BCP 14, RFC 2119, 1701 DOI 10.17487/RFC2119, March 1997, . 1704 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor 1705 Management Information Base", RFC 3433, 1706 DOI 10.17487/RFC3433, December 2002, . 1709 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1710 DOI 10.17487/RFC3688, January 2004, . 1713 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, 1714 DOI 10.17487/RFC4268, November 2005, . 1717 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1718 the Network Configuration Protocol (NETCONF)", RFC 6020, 1719 DOI 10.17487/RFC6020, October 2010, . 1722 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1723 and A. Bierman, Ed., "Network Configuration Protocol 1724 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1725 . 1727 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1728 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1729 . 1731 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1732 Protocol (NETCONF) Access Control Model", RFC 6536, 1733 DOI 10.17487/RFC6536, March 2012, . 1736 [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. 1737 Chandramouli, "Entity MIB (Version 4)", RFC 6933, 1738 DOI 10.17487/RFC6933, May 2013, . 1741 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1742 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1743 . 1745 Authors' Addresses 1747 Andy Bierman 1748 YumaWorks 1750 Email: andy@yumaworks.com 1752 Martin Bjorklund 1753 Tail-f Systems 1755 Email: mbj@tail-f.com 1756 Jie Dong 1757 Huawei Technologies 1759 Email: jie.dong@huawei.com 1761 Dan Romascanu 1763 Email: dromasca@gmail.com