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/