draft-ietf-netmod-yang-model-classification-06.txt   draft-ietf-netmod-yang-model-classification-07.txt 
NETMOD D. Bogdanovic NETMOD D. Bogdanovic
Internet-Draft Volta Networks, Inc. Internet-Draft Volta Networks, Inc.
Intended status: Informational B. Claise Intended status: Informational B. Claise
Expires: October 29, 2017 C. Moberg Expires: November 17, 2017 C. Moberg
Cisco Systems, Inc. Cisco Systems, Inc.
April 27, 2017 May 16, 2017
YANG Module Classification YANG Module Classification
draft-ietf-netmod-yang-model-classification-06 draft-ietf-netmod-yang-model-classification-07
Abstract Abstract
The YANG data modeling language is currently being considered for a The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at wide variety of applications throughout the networking industry at
large. Many standards-defining organizations (SDOs), open source large. Many standards development organizations (SDOs), open source
software projects, vendors and users are using YANG to develop and software projects, vendors and users are using YANG to develop and
publish YANG modules for a wide variety of applications. At the same publish YANG modules for a wide variety of applications. At the same
time, there is currently no well-known terminology to categorize time, there is currently no well-known terminology to categorize
various types of YANG modules. various types of YANG modules.
A consistent terminology would help with the categorization of YANG A consistent terminology would help with the categorization of YANG
modules, assist in the analysis of the YANG data modeling efforts in modules, assist in the analysis of the YANG data modeling efforts in
the IETF and other organizations, and bring clarity to the YANG- the IETF and other organizations, and bring clarity to the YANG-
related discussions between the different groups. related discussions between the different groups.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 October 29, 2017. This Internet-Draft will expire on November 17, 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 33 skipping to change at page 2, line 33
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4
2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6
2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7
3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7
3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8
3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8
3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Engineering Steering Group (IESG) has been actively The Internet Engineering Steering Group (IESG) has been actively
encouraging IETF working groups to use the YANG data modeling encouraging IETF working groups to use the YANG data modeling
language [RFC7950], [RFC7950] and NETCONF protocol [RFC6241] for language [RFC7950], [RFC7950] and NETCONF protocol [RFC6241] for
skipping to change at page 3, line 19 skipping to change at page 3, line 19
This document presents a set of concepts and terms to form a useful This document presents a set of concepts and terms to form a useful
taxonomy for consistent classification of YANG modules in two taxonomy for consistent classification of YANG modules in two
dimensions: dimensions:
o The layering of modules based on their abstraction levels o The layering of modules based on their abstraction levels
o The type of module based on the nature and intent of the content o The type of module based on the nature and intent of the content
The intent of this document is to provide a taxonomy to simplify The intent of this document is to provide a taxonomy to simplify
human communication around YANG modules. The authors acknowledge human communication around YANG modules. While the classification
that the classification boundaries are at times blurry, but believe boundaries are at times blurry, this document should provide a robust
that this document should provide a robust starting point as the YANG starting point as the YANG community gains further experience with
community gains further experience with designing and deploying designing and deploying modules. To be more explicit, it is expected
modules. To be more explicit, the authors believe that the that the classification criteria will change over time.
classification criteria will change over time.
A number of module types have created substantial discussion during A number of module types have created substantial discussion during
the development of this document including those concerned with the development of this document including those concerned with
topologies. Topology modules are useful both on the Network Element topologies. Topology modules are useful both on the Network Element
level (e.g. link-state database content) as well as on the Network level (e.g. link-state database content) as well as on the Network
Service level (e.g. network-wide, configured topologies). In the Service level (e.g. network-wide, configured topologies). In the
end, it is the module developer that classifies the module according end, it is the module developer that classifies the module according
to the initial intent of the module content. to the initial intent of the module content.
This document should provide benefits to multiple audiences: This document should provide benefits to multiple audiences:
skipping to change at page 3, line 47 skipping to change at page 3, line 46
development organizations and industry consortia discussions, development organizations and industry consortia discussions,
whose goals are determined in their respective areas of work. whose goals are determined in their respective areas of work.
o Second, operators might look at the YANG module classification o Second, operators might look at the YANG module classification
type to understand which Network Service YANG modules and Network type to understand which Network Service YANG modules and Network
Element YANG modules are available for their service composition. Element YANG modules are available for their service composition.
It is difficult to determine the module type without inspecting It is difficult to determine the module type without inspecting
the YANG module itself. The YANG module name might provide some the YANG module itself. The YANG module name might provide some
useful information but is not a definite answer. For example, an useful information but is not a definite answer. For example, an
L2VPN YANG module might be a Network Service YANG module, ready to L2VPN YANG module might be a Network Service YANG module, ready to
be used as a service model by network operator. Alternatively, it be used as a service model by a network operator. Alternatively,
might be a Network Element YANG module that contains the L2VPN it might be a Network Element YANG module that contains the L2VPN
data definitions required to be configured on a single device. data definitions required to be configured on a single device.
o And thirdly, this taxonomy would help equipment vendors (whether o And thirdly, this taxonomy would help equipment vendors (whether
physical or virtual), controller vendors, orchestrator vendors to physical or virtual), controller vendors, orchestrator vendors to
explain to their customers the relationship between the different explain to their customers the relationship between the different
YANG modules they support in their products. See Figure 1. YANG modules they support in their products. See Figure 1.
1.1. Terminology 1.1. Terminology
[RFC7950] specifies: [RFC7950] specifies:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
2. First Dimension: YANG Module Abstraction Layers 2. First Dimension: YANG Module Abstraction Layers
Module developers have taken two approaches to developing YANG Module developers have taken two approaches to developing YANG
modules: top-down and bottom-up. The top-down approach starts with modules: top-down and bottom-up. The top-down approach starts with
high level abstractions modeling business or customer requirements high level abstractions modeling business or customer requirements
and maps them to specific networking technologies. The bottom-up and maps them to specific networking technologies. The bottom-up
approach starts with fundamental networking technologies and maps approach starts with fundamental networking technologies and maps
them into more abstract constructs. them into more abstract constructs.
There are currently no specific requirements on, or well-defined best There are currently no specific requirements on, or well-defined best
practices around the development of YANG modules. For the purpose of practices around the development of YANG modules. This document
this document we assume that both approaches (bottom-up and top-down) considers both bottom-up and top-down approaches as they are both
will be used as they both provide benefits that appeal to different used and they each provide benefits that appeal to different groups.
groups.
For layering purposes, this document suggests the classification of For layering purposes, this document suggests the classification of
YANG modules into two distinct abstraction layers: YANG modules into two distinct abstraction layers:
o Network Element YANG Modules describe the configuration, state o Network Element YANG Modules describe the configuration, state
data, operations and notifications of specific device-centric data, operations and notifications of specific device-centric
technologies or features technologies or features
o Network Service YANG Modules describe the configuration, state o Network Service YANG Modules describe the configuration, state
data, operations and notifications of abstract representations of data, operations and notifications of abstract representations of
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Network Service YANG Modules describe the characteristics of a Network Service YANG Modules describe the characteristics of a
service, as agreed upon with consumers of that service. That is, a service, as agreed upon with consumers of that service. That is, a
service module does not expose the detailed configuration parameters service module does not expose the detailed configuration parameters
of all participating network elements and features, but describes an of all participating network elements and features, but describes an
abstract model that allows instances of the service to be decomposed abstract model that allows instances of the service to be decomposed
into instance data according to the Network Element YANG Modules of into instance data according to the Network Element YANG Modules of
the participating network elements. The service-to-element the participating network elements. The service-to-element
decomposition is a separate process with details depending on how the decomposition is a separate process with details depending on how the
network operator chooses to realize the service. For the purpose of network operator chooses to realize the service. For the purpose of
this document we will use the term "orchestrator" to describe a this document, the term "orchestrator" is used to describe to
system implementing such a process. describe a system implementing such a process.
Network Service YANG Modules define service models to be consumed by Network Service YANG Modules define service models to be consumed by
external systems. External systems can be provisioning systems, external systems. External systems can be provisioning systems,
service orchestrators, Operations Support Systems, Business Support service orchestrators, Operations Support Systems, Business Support
Systems and applications exposed to network service consumers, being Systems and applications exposed to network service consumers, being
either internal network operations peole or extarnal customers. either internal network operations people or external customers.
These modules are commonly designed, developed and deployed by These modules are commonly designed, developed and deployed by
network infrastructure teams. network infrastructure teams.
YANG allows for different design patterns to describe network YANG allows for different design patterns to describe network
services, ranging from monolithic to component-based approaches. services, ranging from monolithic to component-based approaches.
The monolithic approach captures the entire service in a single The monolithic approach captures the entire service in a single
module and does not put focus on reusability of internal data module and does not put focus on reusability of internal data
definitions and groupings. The monolithic approach has the definitions and groupings. The monolithic approach has the
advantages of single-purpose development including speed at the advantages of single-purpose development including development speed
expense of reusability. at the expense of reusability.
The component-based approach captures device-centric features (e.g. The component-based approach captures device-centric features (e.g.
the definition of a VRF, routing protocols, or packet filtering) in a the definition of a VRF, routing protocols, or packet filtering) in a
vendor-independent manner. The components are designed for reuse vendor-independent manner. The components are designed for reuse
across many service modules. The set of components required for a across many service modules. The set of components required for a
specific service is then composed into the higher-level service. The specific service is then composed into the higher-level service. The
component-based approach has the advantages of modular development component-based approach has the advantages of modular development
including a higher degree of reusability at the expense of initial including a higher degree of reusability at the expense of initial
speed. development speed.
As an example, an L2VPN service can be built on many different types As an example, an L2VPN service can be built on many different types
of transport network technologies, including e.g. MPLS or carrier of transport network technologies, including e.g. MPLS or carrier
ethernet. A component-based approach would allow for reuse of e.g. ethernet. A component-based approach would allow for reuse of e.g.
UNI-interface definitions independent of the underlying transport UNI-interface definitions independent of the underlying transport
network (e.g. MEF UNI interface or MPLS interface). The monolithic network (e.g. MEF UNI interface or MPLS interface). The monolithic
approach would assume a specific set of transport technologies and approach would assume a specific set of transport technologies and
interface definitions. interface definitions.
Another example for a network service model is [RFC8049]. Although An example of a network service module is in [RFC8049]. It provides
it provides information that can be used to achieve customer service an abstract model for Layer 3 IP VPN service configuration. This
service level agreement, which is more then network service module module includes e.g. the concept of a 'site-network-access' to
classification describes in this document, it provides an abstract represent bearer and connection parameters. An orchestrator receives
model for Layer 3 IP VPN service configuration which is a good operations on service instances according to the service module and
network service model. This module includes e.g. the concept of a decomposes the data into configuration data according to specific
'site-network-access' to represent bearer and connection parameters. Network Element YANG Modules to configure the participating network
An orchestrator receives operations on service instances according to elements to the service. In the case of the L3VPN module, this would
the service module and decomposes the data into specific Network include translating the 'site-network-access' parameters to the
Element YANG Modules to configure the participating network elements appropriate parameters in the Network Element YANG Module implemented
to the service. In the case of the L3VPN module, this would include on the constituent elements.
translating the 'site-network-access' parameters to the appropriate
parameters in the Network Element YANG Module implemented on the
constituent elements.
2.2. Network Element YANG Modules 2.2. Network Element YANG Modules
Network Element YANG Modules describe the characteristics of a Network Element YANG Modules describe the characteristics of a
network device as defined by the vendor of that device. The modules network device as defined by the vendor of that device. The modules
are commonly structured around features of the device, e.g. interface are commonly structured around features of the device, e.g. interface
configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and
firewall rules definitions [I-D.ietf-netmod-acl-model]. firewall rules definitions [I-D.ietf-netmod-acl-model].
Although the [RFC7950], [RFC7950] doesn't explain the relationship of The module provides a coherent data model representation of the
the terms '(YANG) data model' and '(YANG) module', the authors software environment consisting of the operating system and
understand there is a 1:1 relationship between a data model and a applications running on the device. The decomposition, ordering, and
YANG module, but a data model may also be expressed using a execution of changes to the operating system and application
collection of YANG modules (and submodules). The module provides a configuration is the task of the agent that implements the module.
coherent data model representation of the software environment
consisting of the operating system and applications running on the
device. The decomposition, ordering, and execution of changes to the
operating system and application configuration is the task of the
agent that implements the module.
3. Second Dimension: Module Types 3. Second Dimension: Module Types
This document suggests classifying YANG module types as standard YANG This document suggests classifying YANG module types as standard YANG
modules, vendor-specific YANG modules and extensions, or user- modules, vendor-specific YANG modules and extensions, or user-
specific YANG modules and extensions specific YANG modules and extensions
The suggested classification applies to both Network Element YANG The suggested classification applies to both Network Element YANG
Modules and Network Service YANG Modules. Modules and Network Service YANG Modules.
skipping to change at page 8, line 31 skipping to change at page 8, line 24
Augments Augments Augments Augments Augments Augments
+------+-----------------+-------+ +------+-------+ +--------------+ +------+-----------------+-------+ +------+-------+ +--------------+
| Standard | | Vendor | | User | | Standard | | Vendor | | User |
| Modules | | Modules | | Modules | | Modules | | Modules | | Modules |
+--------------------------------+ +--------------+ +--------------+ +--------------------------------+ +--------------+ +--------------+
Figure 2: YANG Module Types Figure 2: YANG Module Types
3.1. Standard YANG Modules 3.1. Standard YANG Modules
Standard YANG Modules are published by standards-defining Standard YANG Modules are published by standards development
organizations (SDOs). While there is no formal definition of what organizations (SDOs). Most SDOs create specifications according to a
construes an SDO, a common feature is that they publish formal process in order to produce a standard that is useful for
specifications along specific processes with content that reflects their constituencies.
some sort of membership consensus. The specifications are developed
for wide use among the membership or for audiences beyond that.
The lifecycle of these modules is driven by the editing cycle of the The lifecycle of these modules is driven by the editing cycle of the
specification and not tied to a specific implementation. specification and not tied to a specific implementation.
Examples of SDOs in the networking industry are the IETF, the IEEE Examples of SDOs in the networking industry are the IETF, the IEEE
and the MEF. and the MEF.
3.2. Vendor-specific YANG Modules and Extensions 3.2. Vendor-specific YANG Modules and Extensions
Vendor-specific YANG Modules are developed by organizations with the Vendor-specific YANG Modules are developed by organizations with the
skipping to change at page 9, line 17 skipping to change at page 9, line 8
It is worth noting that there is an increasing amount of interaction It is worth noting that there is an increasing amount of interaction
between open source projects and SDOs in the networking industry. between open source projects and SDOs in the networking industry.
This includes open source projects implementing published standards This includes open source projects implementing published standards
as well as open source projects contributing content to SDO as well as open source projects contributing content to SDO
processes. processes.
Vendors also develop Vendor-specific Extensions to standard modules Vendors also develop Vendor-specific Extensions to standard modules
using YANG constructs for extending data definitions of previously using YANG constructs for extending data definitions of previously
published modules. This is done using the 'augment' statement that published modules. This is done using the 'augment' statement that
allows locally defined data trees to be augmented into locations in allows locally defined data trees to be added into locations in
externally defined data trees. externally defined data trees.
Vendors use this to extend standard modules to cover the full scope Vendors use this to extend standard modules to cover the full scope
of features in implementations, which commonly is broader than that of features in implementations, which commonly is broader than that
covered by the standard module. covered by the standard module.
3.3. User-specific YANG Modules and Extensions 3.3. User-specific YANG Modules and Extensions
User-specific YANG Modules are developed by organizations that User-specific YANG Modules are developed by organizations that
operate YANG-based infrastructure including devices and operate YANG-based infrastructure including devices and
orchestrators. For example, network administrators in enterprises, orchestrators. For example, network administrators in enterprises,
or at service providers. The intent of these modules is to express or at service providers. The intent of these modules is to express
the specific needs for a certain implementation, above and beyond the specific needs for a certain implementation, above and beyond
what is provided by vendors. what is provided by vendors.
This module type obviously requires the infrastructure to support the This module type obviously requires the infrastructure to support the
introduction of user-provided modules and extensions. This would introduction of user-provided modules and extensions. This would
include ability to describe the service-to-network decomposition in include the ability to describe the service-to-network decomposition
orchestrators and the module to configuration decomposition in in orchestrators and the module to configuration decomposition in
devices. devices.
The lifecycles of these modules are generally aligned with the change The lifecycles of these modules are generally aligned with the change
cadence of the infrastructure. cadence of the infrastructure.
4. Security Considerations 4. Security Considerations
This document doesn't have any Security Considerations. This document doesn't have any Security Considerations.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Acknowledgements 6. Acknowledgements
Thanks to David Ball and David Hansford for feedback and suggestions. Thanks to David Ball and Jonathen Hansford for feedback and
suggestions.
7. Change log [RFC Editor: Please remove] 7. Change log [RFC Editor: Please remove]
version 00: Renamed and small fixes based on WG feedback. version 00: Renamed and small fixes based on WG feedback.
version 01: Language fixes, collapsing of vendor data models and version 01: Language fixes, collapsing of vendor data models and
extensions, and the introduction of user data models and extensions. extensions, and the introduction of user data models and extensions.
version 02: Updated the YANG Module Catalog section, terminology version 02: Updated the YANG Module Catalog section, terminology
alignment (YANG data model versus YANG module), explain better the alignment (YANG data model versus YANG module), explain better the
distinction between the Network Element and Service YANG data models distinction between the Network Element and Service YANG data models
even if sometimes there are grey areas, editorial pass. Changed the even if sometimes there are grey areas, editorial pass. Changed the
use of the term 'model' to 'module' to be better aligned with use of the term 'model' to 'module' to be better aligned with
RFC6020. RFC6020.
version 06: updates based on comments from Adrian Farrel about YANG version 06: updates based on comments from Adrian Farrel about YANG
Data Model for L3VPN Service Delivery. Data Model for L3VPN Service Delivery.
version 07: updates based on comments from Pete Resnick
8. References 8. References
8.1. Normative References 8.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <http://www.rfc-editor.org/info/rfc7223>.
[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,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/ Model for L3VPN Service Delivery", RFC 8049,
RFC8049, February 2017, DOI 10.17487/RFC8049, February 2017,
<http://www.rfc-editor.org/info/rfc8049>. <http://www.rfc-editor.org/info/rfc8049>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-netmod-acl-model] [I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model", "Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-10 (work in progress), March draft-ietf-netmod-acl-model-10 (work in progress), March
2017. 2017.
 End of changes. 21 change blocks. 
61 lines changed or deleted 52 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/