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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/