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/