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