draft-ietf-i2rs-yang-network-topo-10.txt   draft-ietf-i2rs-yang-network-topo-11.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: July 7, 2017 Cisco Expires: August 20, 2017 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Ericsson Ericsson
January 3, 2017 February 16, 2017
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-10.txt draft-ietf-i2rs-yang-network-topo-11.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 7, 2017. This Internet-Draft will expire on August 20, 2017.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7
4. Model Structure Details . . . . . . . . . . . . . . . . . . . 7 4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8
4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8
4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10
4.3. Extending the model . . . . . . . . . . . . . . . . . . . 11 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12
4.4. Discussion and selected design decisions . . . . . . . . 12 4.4. Discussion and selected design decisions . . . . . . . . 12
4.4.1. Container structure . . . . . . . . . . . . . . . . . 12 4.4.1. Container structure . . . . . . . . . . . . . . . . . 12
4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13
4.4.3. Dealing with changes in underlay networks . . . . . . 13 4.4.3. Dealing with changes in underlay networks . . . . . . 13
4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14
4.4.5. Cardinality and directionality of links . . . . . . . 13 4.4.5. Cardinality and directionality of links . . . . . . . 14
4.4.6. Multihoming and link aggregation . . . . . . . . . . 14 4.4.6. Multihoming and link aggregation . . . . . . . . . . 14
4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15
4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.9. Representing the same device in multiple networks . . 14 4.4.9. Representing the same device in multiple networks . . 15
4.4.10. Supporting client-configured and server-provided 4.4.10. Supporting client-configured and server-provided
network topology . . . . . . . . . . . . . . . . . . 15 network topology . . . . . . . . . . . . . . . . . . 16
4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17
5. Interactions with Other YANG Modules . . . . . . . . . . . . 17 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Defining the Abstract Network: network.yang . . . . . . . 17 6.1. Defining the Abstract Network: network.yang . . . . . . . 18
6.2. Creating Abstract Network Topology: network-topology.yang 22 6.2. Creating Abstract Network Topology: network-topology.yang 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC7950] [RFC6991] This document introduces an abstract (base) YANG [RFC7950] [RFC6991]
data model to represent networks and topologies. The data model is data model to represent networks and topologies. The data model is
divided into two parts. The first part of the model defines a divided into two parts. The first part of the model defines a
network model that allows to define network hierarchies (i.e. network network model that allows to define network hierarchies (i.e. network
stacks) and to maintain an inventory of nodes contained in a network. stacks) and to maintain an inventory of nodes contained in a network.
The second part of the model augments the basic network model with The second part of the model augments the basic network model with
information to describe topology information. Specifically, it adds information to describe topology information. Specifically, it adds
skipping to change at page 7, line 5 skipping to change at page 6, line 49
view of the network topology with that of the network elements that view of the network topology with that of the network elements that
it controls. Alternatively, nodes within the network could propagate it controls. Alternatively, nodes within the network could propagate
this understanding to compare and reconcile this understanding either this understanding to compare and reconcile this understanding either
among themselves or with help of a controller. Beyond the network among themselves or with help of a controller. Beyond the network
element and the immediate context of I2RS itself, a network element and the immediate context of I2RS itself, a network
controller might even use the data model to represent its view of the controller might even use the data model to represent its view of the
topology that it controls and expose it to applications north of topology that it controls and expose it to applications north of
itself. Further use cases that the data model can be applied to are itself. Further use cases that the data model can be applied to are
described in [I-D.draft-ietf-i2rs-usecase-reqs-summary]. described in [I-D.draft-ietf-i2rs-usecase-reqs-summary].
In this data model, a network is categorized as either server-
provided or not. If a network is server-provided, then it is
dynamically learned information that can be read from the operational
data-store. For example, as mentioned above, when a network
controller reads a router's topology, that network is server-
provided. This data model can also be used to create or modify
network topologies such as might be associated with an inventory or
with an overlay network. Such a network is not server-provided but
configured. This data model allows a network to refer to a
supporting-network, supporting-nodes, supporting-links, etc.
The model does allow to layer a network that is configured on top of
one that is server-provided. This permits the configuration of
overlay networks on top of networks that are discovered.
Specifically, this data model is structured to support being
implemented as part of the ephemeral data-store
[I-D.draft-ietf-netmod-revised-datastores], defined as requirement
Ephemeral-REQ-03 in [I-D.draft-ietf-i2rs-ephemeral-state]. This
allows a written (e.g. not server-provided) network topology to refer
to a dynamically learned server-provided network. A simple use case
might involve creating an overlay network that is supported by the
dynamically discovered IP routed network topology. When an
implementation places written data for this data model in the
ephemeral data store, then such a network MAY refer to another
network that is server-provided.
An implementation's security policy MAY further restrict what
information the server-provided model is allowed to access in
standard configuration data-stores, or what server-provided network
an ephemeral data store may access. These security policies are
outside the scope of the standardization of this model.
Finally, it should be noted that the model is still subject to update
per ongoing discussions that are related to design decisions
regarding the fact that some layers of the network topology may be
server provided while others may be configured. These issues are
outlined in section 4.4.10.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions and Acronyms 3. Definitions and Acronyms
Datastore: A conceptual store of instantiated management information, Datastore: A conceptual store of instantiated management information,
with individual data items represented by data nodes which are with individual data items represented by data nodes which are
skipping to change at page 17, line 46 skipping to change at page 18, line 32
document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral
topology data that is server provided, the process tasked with topology data that is server provided, the process tasked with
maintaining topology information will load information from the maintaining topology information will load information from the
routing process (such as OSPF) into the data model without relying on routing process (such as OSPF) into the data model without relying on
a configuration datastore. a configuration datastore.
6. YANG Modules 6. YANG Modules
6.1. Defining the Abstract Network: network.yang 6.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "ietf-network@2017-01-03.yang" <CODE BEGINS> file "ietf-network@2017-02-16.yang"
module ietf-network { module ietf-network {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network"; namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nd; prefix nd;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
skipping to change at page 19, line 4 skipping to change at page 19, line 40
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 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 This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-10; draft-ietf-i2rs-yang-network-topo-11;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-10 with RFC draft-ietf-i2rs-yang-network-topo-11 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-01-03 { revision 2017-02-16 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-10 with to draft-ietf-i2rs-yang-network-topo-11 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-10"; "draft-ietf-i2rs-yang-network-topo-11";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 22, line 36 skipping to change at page 23, line 24
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.2. Creating Abstract Network Topology: network-topology.yang 6.2. Creating Abstract Network Topology: network-topology.yang
<CODE BEGINS> file "ietf-network-topology@2017-01-03.yang" <CODE BEGINS> file "ietf-network-topology@2017-02-16.yang"
module ietf-network-topology { module ietf-network-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix lnk; prefix lnk;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-network { import ietf-network {
prefix nd; prefix nd;
skipping to change at page 23, line 49 skipping to change at page 24, line 36
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 This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-10; draft-ietf-i2rs-yang-network-topo-11;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-10 with RFC draft-ietf-i2rs-yang-network-topo-11 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-01-03 { revision 2017-02-16 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-10 with to draft-ietf-i2rs-yang-network-topo-11 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-10"; "draft-ietf-i2rs-yang-network-topo-11";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
same identifier, even if the model is instantiated in same identifier, even if the model is instantiated in
separate datastores. An implementation MAY choose to capture separate datastores. An implementation MAY choose to capture
skipping to change at page 29, line 24 skipping to change at page 30, line 11
URI:urn:ietf:params:xml:ns:yang:ietf-network-topology URI:urn:ietf:params:xml:ns:yang:ietf-network-topology
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.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]: Module Names" registry [RFC6020]:
Name: ietf-network Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nd Prefix: nd
Reference: draft-ietf-i2rs-yang-network-topo-10.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-11.txt (RFC form)
Name: ietf-network-topology Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: lnk Prefix: lnk
Reference: draft-ietf-i2rs-yang-network-topo-10.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-11.txt (RFC form)
8. Security Considerations 8. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is independent of a particular
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the protocol and can be accessed via a number of protocols that need to
secure transport layer, and the mandatory-to-implement secure access YANG-defined data. This includes but is not limited to the
transport is Secure Shell (SSH) [RFC6242]. The NETCONF access NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure
control model [RFC6536] provides the means to restrict access for transport layer and the mandatory-to-implement secure transport is
particular NETCONF users to a pre-configured subset of all available Secure Shell (SSH) [RFC6242].
NETCONF protocol operations and content.
The NETCONF access control model (NACM) [RFC6536] provides the means
to restrict access for particular NETCONF users to a pre-configured
subset of all available NETCONF protocol operations and content.
However, NACM can be applied analogously also to other protocols that
attempt access to YANG-defined data. In fact, it needs to be applied
in the same way and should, like YANG, thus be considered independent
of any particular protocol that is used to access YANG-defined data.
Otherwise, access control rules defined by NACM could be very easily
circumvented simply by using another access mechanism which does not
enforce NACM. The alternative of mandating the introduction of
mechanisms parallel to NACM that specify the same access control
rules for other transports is clearly undesirable, as this would not
only inhibit ease-of-use of systems that implement multiple protocols
to access YANG data, but also open the specter of security holes due
to inconsistencies in articulation and enforcement of rules across
mechanisms that are essentially redundant.
The YANG module defines information that can be configurable in The YANG module defines information that can be configurable in
certain instances, for example in the case of overlay topologies that certain instances, for example in the case of overlay topologies that
can be created by client applications. In such cases, a malicious can be created by client applications. In such cases, a malicious
client could introduce topologies that are undesired. For example, a client could introduce topologies that are undesired. Specifically,
client could remove or add topological links between nodes, which a malicious client could attempt to do the following:
could lead to an undesired and suboptimal topology, which might
impact service levels and network utilization. It is therefore o Remove or add a node, a link, a termination point, by creating or
important that the NETCONF access control model is vigorously applied deleting corresponding elements in the node, link, and termination
to prevent topology configuration by unauthorized clients. point lists, respectively. In the case of a topology that is
server-provided, the server will automaticaly correct such
misconfiguration attempts. In the case of a topology that is
configured, the services provided via this topology might be
disrupted. For example, the topology could be "cut" or be
configured in a suboptimal way, leading to degradation of service
levels and possibly disruption of service.
o Modify the underlay information, i.e. the configuration of
supporting-node, supporting-link, and supporting-termination-
point, respectively. Again, in the case of a topology that is
server-provided, the server will automaticaly correct such
misconfiguration attempts. However, in the case of a topology
that is configured, this will affect the vertical layering and the
way in which the overlay maps onto an overlay. This could be
exploited to severely disrupt the overlay network by degrading
service levels. In addition, it could be exploited to result in
increased consumption of resources in the underlay network, for
example by disrupting congruence between overlay and underlay
nodes which would result in routing and bandwidth utilization
inefficiencies.
For those reasons, it is important that the NETCONF access control
model is vigorously applied to prevent topology misconfiguration by
unauthorized clients.
Topologies that are server-provided and that provide ephemeral Topologies that are server-provided and that provide ephemeral
topology information are less vulnerable, as they provide read-only topology information are less vulnerable, as they provide read-only
access to clients. access to clients.
9. Contributors 9. Contributors
The model presented in this paper was contributed to by more people The model presented in this paper was contributed to by more people
than can be listed on the author list. Additional contributors than can be listed on the author list. Additional contributors
include: include:
o Vishnu Pavan Beeram, Juniper
o Ken Gray, Cisco Systems o Ken Gray, Cisco Systems
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Tony Tkacik o Tony Tkacik
o Kent Watsen, Juniper
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
10. Acknowledgements 10. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, suggestions that were received from Alia Atlas, Andy Bierman, Martin
Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,
Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang.
Watsen, and Xian Zhang.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
skipping to change at page 31, line 19 skipping to change at page 32, line 47
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016. RFC 7950, August 2016.
11.2. Informative References 11.2. Informative References
[I-D.draft-ietf-i2rs-ephemeral-state] [I-D.draft-ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", I-D draft-ietf-i2rs-ephemeral-state-22, Requirements", I-D draft-ietf-i2rs-ephemeral-state-23,
November 2016. November 2016.
[I-D.draft-ietf-i2rs-usecase-reqs-summary] [I-D.draft-ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-
03, November 2016. 30, November 2016.
[I-D.draft-ietf-netconf-yang-push] [I-D.draft-ietf-netconf-yang-push]
Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, Nilsen-Nygaard, E., Bierman, A., and B. Lengyel,
"Subscribing to YANG datastore push updates", I-D draft- "Subscribing to YANG datastore push updates", I-D draft-
ietf-netconf-yang-push-04, October 2016. ietf-netconf-yang-push-04, October 2016.
[I-D.draft-ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", I-D draft-ietf-netmod-revised-datastores-00,
December 2016.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990. Dual Environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
 End of changes. 37 change blocks. 
59 lines changed or deleted 146 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/