--- 1/draft-ietf-netmod-entity-04.txt 2017-10-16 07:13:36.222417389 -0700 +++ 2/draft-ietf-netmod-entity-05.txt 2017-10-16 07:13:36.294419084 -0700 @@ -1,22 +1,22 @@ Network Working Group A. Bierman Internet-Draft YumaWorks Intended status: Standards Track M. Bjorklund -Expires: February 22, 2018 Tail-f Systems +Expires: April 19, 2018 Tail-f Systems J. Dong Huawei Technologies D. Romascanu - August 21, 2017 + October 16, 2017 A YANG Data Model for Hardware Management - draft-ietf-netmod-entity-04 + draft-ietf-netmod-entity-05 Abstract This document defines a YANG data model for the management of hardware on a single server. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 22, 2018. + This Internet-Draft will expire on April 19, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,24 +54,26 @@ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 4 3.1. The Components Lists . . . . . . . . . . . . . . . . . . 5 4. Relationship to ENTITY-MIB . . . . . . . . . . . . . . . . . 5 5. Relationship to ENTITY-SENSOR-MIB . . . . . . . . . . . . . . 6 6. Relationship to ENTITY-STATE-MIB . . . . . . . . . . . . . . 7 7. Hardware YANG Module . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + 8.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 35 + 8.2. YANG Module Registrations . . . . . . . . . . . . . . . . 35 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This document defines a YANG [RFC7950] data model for the management of hardware on a single server. The data model includes configuration and system state (status information and counters for the collection of statistics). 1.1. Terminology @@ -84,23 +86,23 @@ The following terms are defined in [I-D.ietf-netmod-revised-datastores] and are not redefined here: o client o server o configuration o system state + o operational state - o operational state datastore - o intended configuration datastore + o intended configuration 1.1.1. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration @@ -297,21 +299,21 @@ | oper-state | entStateOper | | usage-state | entStateUsage | | alarm-state | entStateAlarm | | standby-state | entStateStandby | +------------------------------------------+------------------------+ YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects 7. Hardware YANG Module - file "ietf-hardware@2017-08-21.yang" + file "ietf-hardware@2017-10-16.yang" module ietf-hardware { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-hardware"; prefix hw; import ietf-inet-types { prefix inet; } import ietf-yang-types { @@ -358,21 +360,21 @@ to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2017-08-21 { + revision 2017-10-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Hardware Management"; } /* * Features */ @@ -880,66 +882,65 @@ then this data model is instantiated in the configuration datastores supported by the server. The leaf-list 'datastore' for the module 'ietf-hardware' in the YANG library provides this information."; leaf last-change { type yang:date-and-time; config false; description "The time the '/hardware/component' list changed in the - operational state datastore."; + operational state."; } list component { key name; description "List of components. When the server detects a new hardware component, it - initializes a list entry in the operational state datastore. + initializes a list entry in the operational state. If the server does not support configuration of hardware - components, list entries in the operational state datastore - are initialized with values for all nodes as detected by the + components, list entries in the operational state are + initialized with values for all nodes as detected by the implementation. Otherwise, the following procedure is followed: 1. If there is an entry in the /hardware/component list in - the intended configuration datastore with values for - the nodes 'class', 'parent', 'parent-rel-pos' that are - equal to the detected values, then: + the intended configuration with values for the nodes + 'class', 'parent', 'parent-rel-pos' that are equal to + the detected values, then: 1a. If the configured entry has a value for 'mfg-name' that is equal to the detected value, or if the 'mfg-name' value cannot be detected, then the list - entry in the operational state datastore is - initialized with the configured values for all - configured nodes, including the 'name'. + entry in the operational state is initialized with the + configured values for all configured nodes, including + the 'name'. - Otherwise, the list entry in the operational state - datastore is initialized with values for all nodes as - detected by the implementation. The implementation - may raise an alarm that informs about the 'mfg-name' - mismatch condition. How this is done is outside the - scope of this document. + Otherwise, the list entry in the operational state is + initialized with values for all nodes as detected by + the implementation. The implementation may raise an + alarm that informs about the 'mfg-name' mismatch + condition. How this is done is outside the scope of + this document. 1b. Otherwise (i.e., there is no matching configuration - entry), the list entry in the operational state - datastore is initialized with values for all nodes as - detected by the implementation. + entry), the list entry in the operational state is + initialized with values for all nodes as detected by + the implementation. If the /hardware/component list in the intended - configuration datastore is modified, then the system MUST - behave as if it re-initializes itself, and follow the - procedure in (1)."; + configuration is modified, then the system MUST behave as if + it re-initializes itself, and follow the procedure in (1)."; reference "RFC 6933: entPhysicalEntry"; leaf name { type string; description "The name assigned to this component. This name is not required to be the same as entPhysicalName."; } @@ -997,23 +999,34 @@ reference "RFC 6933: entPhysicalContainedIn"; } leaf parent-rel-pos { type int32 { range "0 .. 2147483647"; } description "An indication of the relative position of this child component among all its sibling components. Sibling - components are defined as components that share the same - instance values of each of the 'parent' and 'class' - nodes."; + components are defined as components that: + + o Share the same value of the 'parent' node; and + + o Share a common base identity for the 'class' node. + + Note that the last rule gives implementations flexibility + in how components are numbered. For example, some + implementations might have a single number series for all + components derived from 'ianahw:port', while some others + might have different number series for different + components with identities derived from 'ianahw:port' (for + example, one for RJ45 and one for SFP)."; + reference "RFC 6933: entPhysicalParentRelPos"; } leaf-list contains-child { type leafref { path "../../component/name"; } config false; description "The name of the contained component."; @@ -1094,21 +1108,21 @@ leaf alias { type string; description "An 'alias' name for the component, as specified by a network manager, and provides a non-volatile 'handle' for the component. If no configured value exists, the server MAY set the value of this node to a locally unique value in the - operational state datastore. + operational state. A server implementation MAY map this leaf to the entPhysicalAlias MIB object. Such an implementation needs to use some mechanism to handle the differences in size and characters allowed between this leaf and entPhysicalAlias. The definition of such a mechanism is outside the scope of this document."; reference "RFC 6933: entPhysicalAlias"; } @@ -1362,21 +1378,21 @@ } /* * Notifications */ notification hardware-state-change { description "A hardware-state-change notification is generated when the value of /hardware/last-change changes in the operational - state datastore."; + state."; reference "RFC 6933, entConfigChange"; } notification hardware-state-oper-enabled { if-feature hardware-state; description "A hardware-state-oper-enabled notification signifies that a component has transitioned into the 'enabled' state."; leaf name { @@ -1432,52 +1449,52 @@ description "The alarm state for the component."; } reference "RFC 4268, entStateOperDisabled"; } } - file "iana-hardware@2017-08-21.yang" + file "iana-hardware@2017-10-16.yang" module iana-hardware { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-hardware"; prefix ianahw; organization "IANA"; contact " Internet Assigned Numbers Authority Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 823 9358 "; description "IANA defined identities for hardware class."; reference - "https://www.iana.org/assignments/ianaentity-mib/ianaentity-mib"; + // RFC Ed.: replace XXXX with actual path and remove this note. + "https://www.iana.org/assignments/XXXX"; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2017-08-21 { + revision 2017-10-16 { description "Initial revision."; - reference "RFC XXXX: A YANG Data Model for Hardware Management"; } /* * Identities */ identity hardware-class { description @@ -1610,32 +1627,47 @@ of component with data storage capability as main functionality, e.g., disk drive (HDD), solid state device (SSD), hybrid (SSHD), object storage (OSD) or other."; } } 8. IANA Considerations + This document defines the initial version of the IANA-maintained + "iana-hardware" YANG module. + + The "iana-hardware" YANG module is intended to reflect the + "IANA-ENTITY-MIB" MIB module so that if a new enumeration is added to + the "IANAPhysicalClass" TEXTUAL-CONVENTION, the same class is added + as an identity derived from "ianahw:hardware-class". + + When the "iana-hardware" YANG module is updated, a new "revision" + statement must be added in front of the existing revision statements. + +8.1. URI Registrations + This document registers two URIs in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registrations are requested to be made. URI: urn:ietf:params:xml:ns:yang:iana-hardware Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-hardware Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. +8.2. YANG Module Registrations + This document registers two YANG modules in the YANG Module Names registry [RFC6020]. name: iana-hardware namespace: urn:ietf:params:xml:ns:yang:iana-hardware prefix: ianahw reference: RFC XXXX name: ietf-hardware namespace: urn:ietf:params:xml:ns:yang:ietf-hardware