draft-ietf-teas-yang-rsvp-08.txt   draft-ietf-teas-yang-rsvp-09.txt 
TEAS Working Group V. Beeram TEAS Working Group V. Beeram
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track T. Saad, Ed. Intended status: Standards Track T. Saad, Ed.
Expires: May 2, 2018 R. Gandhi Expires: November 9, 2018 R. Gandhi
Cisco Systems, Inc. Cisco Systems, Inc.
X. Liu X. Liu
Jabil Jabil
I. Bryskin I. Bryskin
Huawei Technologies Huawei Technologies
H. Shah H. Shah
Ciena Ciena
October 29, 2017 May 08, 2018
A YANG Data Model for Resource Reservation Protocol (RSVP) A YANG Data Model for Resource Reservation Protocol (RSVP)
draft-ietf-teas-yang-rsvp-08 draft-ietf-teas-yang-rsvp-09
Abstract Abstract
This document defines a YANG data model for the configuration and This document defines a YANG data model for the configuration and
management of RSVP Protocol. The model covers the building blocks of management of RSVP Protocol. The model covers the building blocks of
the RSVP protocol that can be augmented and used by other RSVP the RSVP protocol that can be augmented and used by other RSVP
extension models such as RVSP extensions to Traffic-Engineering extension models such as RVSP extensions to Traffic-Engineering
(RSVP-TE). The model covers the configuration, operational state, (RSVP-TE). The model covers the configuration, operational state,
remote procedural calls, and event notifications data. remote procedural calls, and event notifications data.
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.
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 https://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 May 2, 2018. This Internet-Draft will expire on November 9, 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 (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
2.1. Module Hierarchy . . . . . . . . . . . . . . . . . . . . 5 2.1. Module Hierarchy . . . . . . . . . . . . . . . . . . . . 5
2.2. State Data Organization . . . . . . . . . . . . . . . . . 6 2.2. Configuration Inheritance . . . . . . . . . . . . . . . . 6
2.3. Configuration Inheritance . . . . . . . . . . . . . . . . 6
3. Model Organization . . . . . . . . . . . . . . . . . . . . . 7 3. Model Organization . . . . . . . . . . . . . . . . . . . . . 7
3.1. RSVP Base YANG Model . . . . . . . . . . . . . . . . . . 7 3.1. RSVP Base YANG Model . . . . . . . . . . . . . . . . . . 7
3.1.1. Global Data . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Global Data . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Interface Data . . . . . . . . . . . . . . . . . . . 8 3.1.2. Interface Data . . . . . . . . . . . . . . . . . . . 9
3.1.3. Neighbor Data . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Neighbor Data . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Session Data . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Session Data . . . . . . . . . . . . . . . . . . . . 9
3.1.5. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9
3.1.6. YANG Module . . . . . . . . . . . . . . . . . . . . . 13 3.1.6. YANG Module . . . . . . . . . . . . . . . . . . . . . 14
3.2. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 31 3.2. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 32
3.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32 3.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32
3.2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 33 3.2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 34
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 44 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 45
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
YANG [RFC6020] is a data definition language that was introduced to YANG [RFC6020] is a data definition language that was introduced to
define the contents of a conceptual data store that allows networked define the contents of a conceptual data store that allows networked
devices to be managed using NETCONF [RFC6241]. YANG is proving devices to be managed using NETCONF [RFC6241]. YANG is proving
relevant beyond its initial confines, as bindings to other interfaces relevant beyond its initial confines, as bindings to other interfaces
(e.g. ReST) and encoding other than XML (e.g. JSON) are being (e.g. ReST) and encoding other than XML (e.g. JSON) are being
defined. Furthermore, YANG data models can be used as the basis of defined. Furthermore, YANG data models can be used as the basis of
skipping to change at page 5, line 21 skipping to change at page 5, line 21
| key-chain | ietf-key-chain | XX | | key-chain | ietf-key-chain | XX |
+---------+----------------------+-----------+ +---------+----------------------+-----------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
2. Design Considerations 2. Design Considerations
2.1. Module Hierarchy 2.1. Module Hierarchy
The RSVP base YANG module augments the "control-plane-protocol" list The RSVP base YANG module augments the "control-plane-protocol" list
in ietf-routing [RFC8022] module with specific RSVP parameters in an in ietf-routing [RFC8349] module with specific RSVP parameters in an
"rsvp" container. It also defines an extensiion identity "rsvp" of "rsvp" container. It also defines an extensiion identity "rsvp" of
base "rt:routing-protocol" to identify the RSVP protocol. base "rt:routing-protocol" to identify the RSVP protocol.
During modeling discussion, some RSVP features are categorized as Some RSVP features are categorized as core to the function of the
core to the functionality of the protocol, and hence, are supported protocol that are supported by most vendors claiming support for RSVP
by all vendors claiming the support for RSVP. These features' protocol. Such features configuration and state are grouped in the
configuration and state were grouped in the RSVP base module. RSVP base module.
Other extended RSVP features are categorized as either optional or Other extended RSVP features are categorized as either optional or
providing additional knobs to provide better tune basic functionality providing knobs to better tune basic functionality of the RSVP
of the RSVP protocol. The support for extended RSVP features by all protocol. The support for extended RSVP features by all vendors is
vendors was considered optional. Such features were grouped in a considered optional. Such features are grouped in a separate RSVP
separate RSVP extended module. extended module.
The augmentation of the RSVP model by other models (e.g. RSVP-TE for The augmentation of the RSVP model by other models (e.g. RSVP-TE for
MPLS or other technologies) are considered outside the scope of this MPLS or other technologies) are outside the scope of this document
document and discussed in separate document(s). and are discussed in separate document(s), e.g.
[I-D.ietf-teas-yang-rsvp-te].
+--------------+ +--------------+
Routing | ietf-routing | Routing | ietf-routing |
+--------------+ +--------------+
o o
| |
+-----------+ +-----------+
RSVP module | ietf-rsvp | RSVP module | ietf-rsvp |
+-----------+ +-----------+
o o
| |
RSVP extended | RSVP extended |
module +--------------------+ module +--------------------+
| ietf-rsvp-extended | | ietf-rsvp-extended |
+--------------------+ +--------------------+
Figure 1: Relationship of RSVP and RSVP extended modules with other Figure 1: Relationship of RSVP and RSVP extended modules with other
protocol modules protocol modules
The RSVP base model does not aim to be feature complete. The primary The RSVP base model does not aim to be feature complete. The primary
intent is to cover a set of standard core features (listed below) intent is to cover a set of standard core features that are commonly
that are commonly in use. in use. For example:
o Authentication ([RFC2747]) o Authentication ([RFC2747])
o Refresh Reduction ([RFC2961]) o Refresh Reduction ([RFC2961])
o Hellos ([RFC3209]) o Hellos ([RFC3209])
o Graceful Restart ([RFC3473], [RFC5063]) o Graceful Restart ([RFC3473], [RFC5063])
The extended RSVP YANG model covers non-basic configuration(s) for The extended RSVP YANG model covers non-basic configuration(s) for
RSVP feature(s) as well as optional RSVP feature that are not a must RSVP feature(s) as well as optional RSVP feature that are not a must
for basic RSVP operation. for basic RSVP operation.
2.2. State Data Organization 2.2. Configuration Inheritance
The Network Management Datastore Architecture (NMDA)
[I-D.dsdt-nmda-guidelines] addresses the "OpState" that was discussed
in the IETF. As per NMDA guidelines for new models and models that
are not concerned with the operational state of configuration
information, this revision of the draft adopts the NMDA proposal for
configuration and state data of this model.
2.3. Configuration Inheritance
The defined data model supports configuration inheritance for The defined data model supports configuration inheritance for
neighbors, and interfaces. Data elements defined in the main neighbors, and interfaces. Data elements defined in the main
container (e.g. the container that encompasses the list of container (e.g. the container that encompasses the list of
interfaces, or neighbors) are assumed to apply equally to all interfaces, or neighbors) are assumed to apply equally to all
elements of the list, unless overridden explicitly for a certain elements of the list, unless overridden explicitly for a certain
element (e.g. interface). Vendors are expected to augment the above element (e.g. interface). Vendors are expected to augment the above
container(s) to provide the list of inheritance command for their container(s) to provide the list of inheritance command for their
implementations. implementations.
3. Model Organization 3. Model Organization
This document divides the RSVP model into two modules: the RSVP base This document divides the RSVP model into two modules: base and
and extended. Each module covers the configuration, state, extended RSVP modules. Each module covers configuration, state,
notification and RPCs of data. The relationship between the notifications and RPCs data. The relationship between the different
different modules is depicted in Figure 1. modules is depicted in Figure 1.
3.1. RSVP Base YANG Model 3.1. RSVP Base YANG Model
This section describes the RSVP base YANG data model. The container The RSVP base YANG data model defines thee container "rsvp" as the
"rsvp" is the top level container in this data model. The presence top level container in this data model. The presence of this
of this container enables the RSVP protocol functionality. container enables the RSVP protocol functionality.
Data for such state is contained under the respective "state" sub- Data for such state is contained under the respective "state" sub-
container of the intended object (e.g. interface) as shown in container of the intended object (e.g. interface) as shown in
Figure 2. Figure 2.
module: ietf-rsvp module: ietf-rsvp
+--rw rsvp! +--rw rsvp!
+--rw globals +--rw globals
+-- rw config
<<intended configuration>>
.
+-- ro state
<<applied configuration>>
<<derived state associated with the tunnel>>
. .
. .
+--rw interfaces +--rw interfaces
+-- rw config
<<intended configuration>>
. .
+-- ro state +-- ro state
<<applied configuration>> <<derived state associated with interfaces>>
<<derived state associated with the tunnel>>
. .
. .
+--rw neighbors +--rw neighbors
+-- rw config
<<intended configuration>>
. .
+-- ro state +-- ro state
<<applied configuration>>
<<derived state associated with the tunnel>> <<derived state associated with the tunnel>>
. .
. .
+--rw sessions +--rw sessions
+-- rw config
<<intended configuration>>
. .
+-- ro state +-- ro state
<<applied configuration>>
<<derived state associated with the tunnel>> <<derived state associated with the tunnel>>
. .
rpcs: rpcs:
+--x global-rpc +--x global-rpc
+--x interfaces-rpc +--x interfaces-rpc
+--x neighbors-rpc +--x neighbors-rpc
+--x sessions-rpc +--x sessions-rpc
notifications: notifications:
+--n global-notif +--n global-notif
+--n interfaces-notif +--n interfaces-notif
skipping to change at page 8, line 37 skipping to change at page 8, line 48
Figure 2: RSVP high-level tree model view Figure 2: RSVP high-level tree model view
The following subsections provide overview of the parts of the model The following subsections provide overview of the parts of the model
pertaining to configuration and state data. pertaining to configuration and state data.
Configuration and state data are organized into those applicable Configuration and state data are organized into those applicable
globally (node scope), per interfaces, per neighbors, or per session. globally (node scope), per interfaces, per neighbors, or per session.
3.1.1. Global Data 3.1.1. Global Data
This branch of the data model covers global configuration and states The global data branch of the model covers configuration and state
that control RSVP protocol behavior. that are applicable the RSVP protocol behavior.
3.1.2. Interface Data 3.1.2. Interface Data
This branch of the data model covers configuration and state elements The interface data branch of the data model covers configuration and
relevant to one or all RSVP interfaces. Any data configuration state elements relevant to one or all RSVP interfaces. Any data
applied at the "interfaces" container level are equally applicable to configuration applied at the "interfaces" container level are equally
all interfaces - unless overridden by explicit configuration under a applicable to all interfaces - unless overridden by explicit
specific interface. configuration under a specific interface.
3.1.3. Neighbor Data 3.1.3. Neighbor Data
This branch of the data model covers configuration of elements The neighbor data branch of the data model covers configuration and
relevant to RSVP neighbors. This would be discussed in detail in state elements relevant to RSVP neighbors.
future revisions.
3.1.4. Session Data 3.1.4. Session Data
This branch of the data model covers configuration of elements The sessions data branch covers configuration of elements relevant to
relevant to RSVP sessions. This would be discussed in detail in RSVP sessions.
future revisions.
3.1.5. Tree Diagram 3.1.5. Tree Diagram
module: ietf-rsvp module: ietf-rsvp
augment augment
/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol: /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:
+--rw rsvp! +--rw rsvp!
+--rw globals +--rw globals
| +--rw sessions | +--rw sessions
| | +--ro session* [local-index] | | +--ro session* [local-index]
skipping to change at page 44, line 32 skipping to change at page 44, line 41
name: ietf-rsvp-extended namespace: urn:ietf:params:xml:ns:yang:ietf- name: ietf-rsvp-extended namespace: urn:ietf:params:xml:ns:yang:ietf-
rsvp-extended prefix: ietf-rsvp-extendeed reference: RFC3209 rsvp-extended prefix: ietf-rsvp-extendeed reference: RFC3209
5. Security Considerations 5. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242]. The NETCONF access control model transport is SSH [RFC6242]. The NETCONF access control model
[RFC6536] provides means to restrict access for particular NETCONF [RFC8341] provides means to restrict access for particular NETCONF
users to a pre-configured subset of all available NETCONF protocol users to a pre-configured subset of all available NETCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in the YANG module which are There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>) in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. effect on network operations.
skipping to change at page 45, line 27 skipping to change at page 45, line 32
Bin Wen Bin Wen
Comcast Comcast
Email: Bin_Wen@cable.comcast.com Email: Bin_Wen@cable.comcast.com
8. References 8. References
8.1. Normative References 8.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", 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,
rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>. 2000, <https://www.rfc-editor.org/info/rfc2747>.
skipping to change at page 46, line 7 skipping to change at page 46, line 12
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<https://www.rfc-editor.org/info/rfc2961>. <https://www.rfc-editor.org/info/rfc2961>.
[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, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
10.17487/RFC3473, January 2003, <https://www.rfc- DOI 10.17487/RFC3473, January 2003,
editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[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,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
GMPLS Resource Reservation Protocol (RSVP) Graceful GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
<https://www.rfc-editor.org/info/rfc5063>. <https://www.rfc-editor.org/info/rfc5063>.
[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,
editor.org/info/rfc6020>. <https://www.rfc-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 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
Protocol (NETCONF) Access Control Model", RFC 6536, DOI RFC 6991, DOI 10.17487/RFC6991, July 2013,
10.17487/RFC6536, March 2012, <https://www.rfc- <https://www.rfc-editor.org/info/rfc6991>.
editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc- Access Control Model", STD 91, RFC 8341,
editor.org/info/rfc6991>. DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Management", RFC 8022, DOI 10.17487/RFC8022, November Routing Management (NMDA Version)", RFC 8349,
2016, <https://www.rfc-editor.org/info/rfc8022>. DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
8.2. Informative References 8.2. Informative References
[I-D.dsdt-nmda-guidelines] [I-D.ietf-teas-yang-rsvp-te]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,
and R. Wilton, "Guidelines for YANG Module Authors and H. Shah, "A YANG Data Model for RSVP-TE", draft-ietf-
(NMDA)", draft-dsdt-nmda-guidelines-01 (work in progress), teas-yang-rsvp-te-03 (work in progress), February 2018.
May 2017.
Authors' Addresses Authors' Addresses
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 41 change blocks. 
100 lines changed or deleted 74 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/