draft-ietf-netmod-entity-07.txt		draft-ietf-netmod-entity-08.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: June 24, 2018 Tail-f Systems		Expires: July 26, 2018 Tail-f Systems
	J. Dong		J. Dong
	Huawei Technologies		Huawei Technologies
	D. Romascanu		D. Romascanu
			January 22, 2018
	December 21, 2017
	A YANG Data Model for Hardware Management		A YANG Data Model for Hardware Management
	draft-ietf-netmod-entity-07		draft-ietf-netmod-entity-08
	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 36 ¶		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 June 24, 2018.		This Internet-Draft will expire on July 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
	2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 3		3. Hardware Data Model . . . . . . . . . . . . . . . . . . . . . 3
	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
	8.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 35		8.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 35
	8.2. YANG Module Registrations . . . . . . . . . . . . . . . . 35		8.2. YANG Module Registrations . . . . . . . . . . . . . . . . 36
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 36		9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	11.1. Normative References . . . . . . . . . . . . . . . . . . 37		11.1. Normative References . . . . . . . . . . . . . . . . . . 37
	11.2. Informative References . . . . . . . . . . . . . . . . . 38		11.2. Informative References . . . . . . . . . . . . . . . . . 39
	Appendix A. Hardware State Data Model . . . . . . . . . . . . . 39		Appendix A. Hardware State Data Model . . . . . . . . . . . . . 39
	A.1. Hardware State YANG Module . . . . . . . . . . . . . . . 40		A.1. Hardware State YANG Module . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
	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
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	+--rw name string		+--rw name string
	+--rw class identityref		+--rw class identityref
	+--ro physical-index? int32 {entity-mib}?		+--ro physical-index? int32 {entity-mib}?
	+--ro description? string		+--ro description? string
	+--rw parent? -> ../../component/name		+--rw parent? -> ../../component/name
	+--rw parent-rel-pos? int32		+--rw parent-rel-pos? int32
	+--ro contains-child* -> ../../component/name		+--ro contains-child* -> ../../component/name
	+--ro hardware-rev? string		+--ro hardware-rev? string
	+--ro firmware-rev? string		+--ro firmware-rev? string
	+--ro software-rev? string		+--ro software-rev? string
	+--rw serial-num? string		+--ro serial-num? string
	+--rw mfg-name? string		+--ro mfg-name? string
	+--rw model-name? string		+--ro model-name? string
	+--rw alias? string		+--rw alias? string
	+--rw asset-id? string		+--rw asset-id? string
	+--ro is-fru? boolean		+--ro is-fru? boolean
	+--ro mfg-date? yang:date-and-time		+--ro mfg-date? yang:date-and-time
	+--rw uri* inet:uri		+--rw uri* inet:uri
	+--ro uuid? yang:uuid		+--ro uuid? yang:uuid
	+--rw state {hardware-state}?		+--rw state {hardware-state}?
	| +--ro state-last-changed? yang:date-and-time		| +--ro state-last-changed? yang:date-and-time
	| +--rw admin-state? admin-state		| +--rw admin-state? admin-state
	| +--ro oper-state? oper-state		| +--ro oper-state? oper-state
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	types in the IANA-maintained "IANA-ENTITY-MIB" registry.		types in the IANA-maintained "IANA-ENTITY-MIB" registry.
	The "class" leaf is a YANG identity that describes the type of the		The "class" leaf is a YANG identity that describes the type of the
	hardware. Vendors are encouraged to either directly use one of the		hardware. Vendors are encouraged to either directly use one of the
	common IANA-defined identities, or derive a more specific identity		common IANA-defined identities, or derive a more specific identity
	from one of them.		from one of them.
	4. Relationship to ENTITY-MIB		4. Relationship to ENTITY-MIB
	If the device implements the ENTITY-MIB [RFC6933], each entry in the		If the device implements the ENTITY-MIB [RFC6933], each entry in the
	"/hardware-state/component" list is mapped to one EntPhysicalEntry.		"/hardware/component" list in the operational state is mapped to one
	Objects that are writable in the MIB are mapped to nodes in the		EntPhysicalEntry. Objects that are writable in the MIB are mapped to
	"/hardware/component" list.		"config true" nodes in the "/hardware/component" list, except
			"entPhysicalSerialNum" which is writable in the MIB, but "config
			false" in the YANG module.
	The "physical-index" leaf MUST contain the value of the corresponding		The "physical-index" leaf MUST contain the value of the corresponding
	entPhysicalEntry's entPhysicalIndex.		entPhysicalEntry's entPhysicalIndex.
	The "class" leaf is mapped to both entPhysicalClass and		The "class" leaf is mapped to both entPhysicalClass and
	entPhysicalVendorType. If the value of the "class" leaf is an		entPhysicalVendorType. If the value of the "class" leaf is an
	identity that is either derived from or is one of the identities in		identity that is either derived from or is one of the identities in
	the "iana-hardware" module, then entPhysicalClass contains the		the "iana-hardware" module, then entPhysicalClass contains the
	corresponding IANAPhysicalClass enumeration value. Otherwise,		corresponding IANAPhysicalClass enumeration value. Otherwise,
	entPhysicalClass contains the IANAPhysicalClass value "other(1)".		entPhysicalClass contains the IANAPhysicalClass value "other(1)".
	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-12-18.yang"		<CODE BEGINS> file "ietf-hardware@2018-01-15.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 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	// RFC Ed.: replace XXXX and YYYY with actual RFC numbers and		// RFC Ed.: replace XXXX and YYYY with actual RFC numbers and
	// remove this note.		// remove this note.
	description		description
	"This module contains a collection of YANG definitions for		"This module contains a collection of YANG definitions for
	managing hardware.		managing hardware.
	This data model is designed for the Network Management Datastore		This data model is designed for the Network Management Datastore
	Architecture defined in RFC YYYY.		Architecture defined in RFC YYYY.
	Copyright (c) 2017 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	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-12-18 {		revision 2018-01-15 {
	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 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	enum giga {		enum giga {
	value 12;		value 12;
	description		description
	"Data scaling factor of 10^9.";		"Data scaling factor of 10^9.";
	}		}
	enum tera {		enum tera {
	value 13;		value 13;
	description		description
	"Data scaling factor of 10^12.";		"Data scaling factor of 10^12.";
	}		}
	enum exa {		enum peta {
	value 14;		value 14;
	description		description
	"Data scaling factor of 10^15.";		"Data scaling factor of 10^15.";
	}		}
	enum peta {		enum exa {
	value 15;		value 15;
	description		description
	"Data scaling factor of 10^18.";		"Data scaling factor of 10^18.";
	}		}
	enum zetta {		enum zetta {
	value 16;		value 16;
	description		description
	"Data scaling factor of 10^21.";		"Data scaling factor of 10^21.";
	}		}
	enum yotta {		enum yotta {
	skipping to change at page 17, line 13 ¶		skipping to change at page 17, line 13 ¶
	this type together with the associated sensor-value-type.		this type together with the associated sensor-value-type.
	A node of this type SHOULD be defined together with nodes of		A node of this type SHOULD be defined together with nodes of
	type sensor-value-type and sensor-value-precision. Together,		type sensor-value-type and sensor-value-precision. Together,
	associated nodes of these three types are used to identify the		associated nodes of these three types are used to identify the
	semantics of a node of type sensor-value.";		semantics of a node of type sensor-value.";
	reference "RFC 3433: EntitySensorDataScale";		reference "RFC 3433: EntitySensorDataScale";
	}		}
	typedef sensor-value-precision {		typedef sensor-value-precision {
	type int32 {		type int8 {
	range "-8 .. 9";		range "-8 .. 9";
	}		}
	description		description
	"A node using this data type represents a sensor value		"A node using this data type represents a sensor value
	precision range.		precision range.
	A node of this type SHOULD be defined together with nodes of		A node of this type SHOULD be defined together with nodes of
	type sensor-value-type and sensor-value-scale. Together,		type sensor-value-type and sensor-value-scale. Together,
	associated nodes of these three types are used to identify the		associated nodes of these three types are used to identify the
	semantics of a node of type sensor-value.		semantics of a node of type sensor-value.
	skipping to change at page 17, line 42 ¶		skipping to change at page 17, line 42 ¶
	The value zero indicates the associated sensor-value node is		The value zero indicates the associated sensor-value node is
	not a fixed-point number.		not a fixed-point number.
	Server implementers must choose a value for the associated		Server implementers must choose a value for the associated
	sensor-value-precision node so that the precision and accuracy		sensor-value-precision node so that the precision and accuracy
	of the associated sensor-value node is correctly indicated.		of the associated sensor-value node is correctly indicated.
	For example, a component representing a temperature sensor		For example, a component representing a temperature sensor
	that can measure 0 degrees to 100 degrees C in 0.1 degree		that can measure 0 degrees to 100 degrees C in 0.1 degree
	increments, +/- 0.05 degrees, would have an		increments, +/- 0.05 degrees, would have a
	sensor-value-precision value of '1', an sensor-value-scale		sensor-value-precision value of '1', a sensor-value-scale
	value of 'units', and an sensor-value ranging from '0' to		value of 'units', and a sensor-value ranging from '0' to
	'1000'. The sensor-value would be interpreted as		'1000'. The sensor-value would be interpreted as
	'degrees C * 10'.";		'degrees C * 10'.";
	reference "RFC 3433: EntitySensorPrecision";		reference "RFC 3433: EntitySensorPrecision";
	}		}
	typedef sensor-value {		typedef sensor-value {
	type int32 {		type int32 {
	range "-1000000000 .. 1000000000";		range "-1000000000 .. 1000000000";
	}		}
	description		description
	"A node using this data type represents an sensor value.		"A node using this data type represents a sensor value.
	A node of this type SHOULD be defined together with nodes of		A node of this type SHOULD be defined together with nodes of
	type sensor-value-type, sensor-value-scale, and		type sensor-value-type, sensor-value-scale, and
	sensor-value-precision. Together, associated nodes of those		sensor-value-precision. Together, associated nodes of those
	three types are used to identify the semantics of a node of		three types are used to identify the semantics of a node of
	this data type.		this data type.
	The semantics of a node using this data type are determined by		The semantics of a node using this data type are determined by
	the value of the associated sensor-value-type node.		the value of the associated sensor-value-type node.
	skipping to change at page 20, line 18 ¶		skipping to change at page 20, line 18 ¶
	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 with values for the nodes		the intended configuration with values for the nodes
	'class', 'parent', 'parent-rel-pos' that are equal to		'class', 'parent', 'parent-rel-pos' that are equal to
	the detected values, then the list entry in operational		the detected values, then the list entry in operational
	state is initialized with the configured values,		state is initialized with the configured values,
	including the 'name'. The leafs 'serial-num',		including the 'name'.
	'mfg-name', and 'model-name' are treated specially; see
	their descriptions for details.
	2. Otherwise (i.e., there is no matching configuration		2. Otherwise (i.e., there is no matching configuration
	entry), the list entry in the operational state is		entry), the list entry in the operational state is
	initialized with values for all nodes as detected by		initialized with values for all nodes as detected by
	the implementation.		the implementation.
	If the /hardware/component list in the intended		If the /hardware/component list in the intended
	configuration is modified, then the system MUST behave as if		configuration is modified, then the system MUST behave as if
	it re-initializes itself, and follow the procedure in (1).";		it re-initializes itself, and follow the procedure in (1).";
	reference "RFC 6933: entPhysicalEntry";		reference "RFC 6933: entPhysicalEntry";
	skipping to change at page 23, line 15 ¶		skipping to change at page 23, line 14 ¶
	type string;		type string;
	config false;		config false;
	description		description
	"The vendor-specific software revision string for the		"The vendor-specific software revision string for the
	component.";		component.";
	reference "RFC 6933: entPhysicalSoftwareRev";		reference "RFC 6933: entPhysicalSoftwareRev";
	}		}
	leaf serial-num {		leaf serial-num {
	type string;		type string;
			config false;
	description		description
	"The vendor-specific serial number string for the		"The vendor-specific serial number string for the
	component. The preferred value is the serial number		component. The preferred value is the serial number
	string actually printed on the component itself (if		string actually printed on the component itself (if
	present).		present).";
	This leaf can be configured. The configured value is used
	only if the server cannot determine the vendor-specific
	serial number from the component itself.";
	reference "RFC 6933: entPhysicalSerialNum";		reference "RFC 6933: entPhysicalSerialNum";
	}		}
	leaf mfg-name {		leaf mfg-name {
	type string;		type string;
			config false;
	description		description
	"The name of the manufacturer of this physical component.		"The name of the manufacturer of this physical component.
	The preferred value is the manufacturer name string		The preferred value is the manufacturer name string
	actually printed on the component itself (if present).		actually printed on the component itself (if present).
	Note that comparisons between instances of the model-name,		Note that comparisons between instances of the model-name,
	firmware-rev, software-rev, and the serial-num nodes are		firmware-rev, software-rev, and the serial-num nodes are
	only meaningful amongst component with the same value of		only meaningful amongst component with the same value of
	mfg-name.		mfg-name.
	If the manufacturer name string associated with the		If the manufacturer name string associated with the
	physical component is unknown to the server, then this		physical component is unknown to the server, then this
	node is not instantiated.		node is not instantiated.";
	This leaf can be configured. The configured value is used
	only if the server cannot determine the vendor-specific
	serial number from the component itself.";
	reference "RFC 6933: entPhysicalMfgName";		reference "RFC 6933: entPhysicalMfgName";
	}		}
	leaf model-name {		leaf model-name {
	type string;		type string;
			config false;
	description		description
	"The vendor-specific model name identifier string		"The vendor-specific model name identifier string
	associated with this physical component. The preferred		associated with this physical component. The preferred
	value is the customer-visible part number, which may be		value is the customer-visible part number, which may be
	printed on the component itself.		printed on the component itself.
	If the model name string associated with the physical		If the model name string associated with the physical
	component is unknown to the server, then this node is not		component is unknown to the server, then this node is not
	instantiated.		instantiated.";
	This leaf can be configured. The configured value is used
	only if the server cannot determine the vendor-specific
	serial number from the component itself.";
	reference "RFC 6933: entPhysicalModelName";		reference "RFC 6933: entPhysicalModelName";
	}		}
	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.
	skipping to change at page 31, line 31 ¶		skipping to change at page 31, line 20 ¶
	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-12-18.yang"		<CODE BEGINS> file "iana-hardware@2018-01-15.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		12025 Waterfront Drive, Suite 300
	Marina del Rey, CA 90292		Los Angeles, CA 90094-2536
			United States
	Tel: +1 310 823 9358
	<mailto:iana@iana.org>";
	description
	"IANA defined identities for hardware class.";
	reference
	// RFC Ed.: replace XXXX with actual path and remove this note.
	"https://www.iana.org/assignments/XXXX";
			Tel: +1 310 301 5800
			E-Mail: iana@iana.org>";
	// RFC Ed.: replace XXXX with actual RFC number and remove this		// RFC Ed.: replace XXXX with actual RFC number and remove this
	// note.		// note.
			description
			"IANA defined identities for hardware class.
			The latest revision of this YANG module can be obtained from
			the IANA web site.
			Requests for new values should be made to IANA via
			email (iana@iana.org).
			Copyright (c) 2018 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, is permitted pursuant to, and subject
			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).
			The initial version of this YANG module is part of RFC XXXX;
			see the RFC itself for full legal notices.";
			reference
			// RFC Ed.: replace PPPP with actual path and remove this note.
			"https://www.iana.org/assignments/PPPP";
	// 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-12-18 {		revision 2018-01-15 {
	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
	*/		*/
	skipping to change at page 37, line 29 ¶		skipping to change at page 37, line 48 ¶
	helpful comments on various draft versions of this document: Bart		helpful comments on various draft versions of this document: Bart
	Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder.		Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-netmod-revised-datastores]		[I-D.ietf-netmod-revised-datastores]
	Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore		and R. Wilton, "Network Management Datastore
	Architecture", draft-ietf-netmod-revised-datastores-08		Architecture", draft-ietf-netmod-revised-datastores-10
	(work in progress), December 2017.		(work in progress), January 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	rfc2119>.		editor.org/info/rfc2119>.
	[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor		[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
	Management Information Base", RFC 3433, DOI 10.17487/		Management Information Base", RFC 3433,
	RFC3433, December 2002, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC3433, December 2002, <https://www.rfc-
	rfc3433>.		editor.org/info/rfc3433>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004, <https://www.rfc-		DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
	editor.org/info/rfc3688>.		editor.org/info/rfc3688>.
	[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,		[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
	DOI 10.17487/RFC4268, November 2005, <https://www.rfc-		DOI 10.17487/RFC4268, November 2005, <https://www.rfc-
	editor.org/info/rfc4268>.		editor.org/info/rfc4268>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/		(TLS) Protocol Version 1.2", RFC 5246,
	RFC5246, August 2008, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	rfc5246>.		editor.org/info/rfc5246>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010, <https://www.rfc-		DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
	editor.org/info/rfc6020>.		editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<https://www.rfc-editor.org/info/rfc6242>.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536, DOI		Protocol (NETCONF) Access Control Model", RFC 6536,
	10.17487/RFC6536, March 2012, <https://www.rfc-		DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
	editor.org/info/rfc6536>.		editor.org/info/rfc6536>.
	[RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.		[RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.
	Chandramouli, "Entity MIB (Version 4)", RFC 6933, DOI		Chandramouli, "Entity MIB (Version 4)", RFC 6933,
	10.17487/RFC6933, May 2013, <https://www.rfc-		DOI 10.17487/RFC6933, May 2013, <https://www.rfc-
	editor.org/info/rfc6933>.		editor.org/info/rfc6933>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-netmod-yang-tree-diagrams]		[I-D.ietf-netmod-yang-tree-diagrams]
	Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-		Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
	ietf-netmod-yang-tree-diagrams-03 (work in progress),		ietf-netmod-yang-tree-diagrams-04 (work in progress),
	December 2017.		December 2017.
	Appendix A. Hardware State Data Model		Appendix A. Hardware State Data Model
	This non-normative appendix contains a data model designed as a		This non-normative appendix contains a data model designed as a
	temporary solution for implementations that do not yet support the		temporary solution for implementations that do not yet support the
	Network Management Datastore Architecture (NMDA) defined in		Network Management Datastore Architecture (NMDA) defined in
	[I-D.ietf-netmod-revised-datastores]. It has the following		[I-D.ietf-netmod-revised-datastores]. It has the following
	structure:		structure:
End of changes. 36 change blocks.
	71 lines changed or deleted		79 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/