--- 1/draft-ietf-teas-yang-rsvp-14.txt 2020-09-03 20:13:13.735247571 -0700 +++ 2/draft-ietf-teas-yang-rsvp-15.txt 2020-09-03 20:13:13.823249797 -0700 @@ -1,24 +1,24 @@ TEAS Working Group V. Beeram Internet-Draft T. Saad Intended status: Standards Track Juniper Networks -Expires: January 28, 2021 R. Gandhi +Expires: March 7, 2021 R. Gandhi Cisco Systems, Inc. X. Liu Volta Networks I. Bryskin Individual - July 27, 2020 + September 03, 2020 A YANG Data Model for Resource Reservation Protocol (RSVP) - draft-ietf-teas-yang-rsvp-14 + draft-ietf-teas-yang-rsvp-15 Abstract This document defines a YANG data model for the configuration and management of RSVP Protocol. The model covers the building blocks of the RSVP protocol that can be augmented and used by other RSVP extension models such as RSVP extensions to Traffic-Engineering (RSVP-TE). The model is divided into base and extended modules that cover data for configuration, operational state, remote procedure calls, and event notifications. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 28, 2021. + This Internet-Draft will expire on March 7, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -173,27 +173,27 @@ protocol. The support for RSVP extended features by all vendors is considered optional. Such features are grouped in a separate RSVP extended module. The relationship between the base and RSVP extended YANG modules and the IETF routing YANG model is shown in Figure 1. +--------------+ Routing | ietf-routing | +--------------+ - o + ^ | +-----------+ RSVP module | ietf-rsvp | +-----------+ - o - | o: augment relationship + ^ + | ^: augment relationship RSVP extended | module +--------------------+ | ietf-rsvp-extended | +--------------------+ Figure 1: Relationship of RSVP and RSVP extended modules with other protocol modules 3.2. Design Considerations @@ -223,22 +223,22 @@ 3.3. Model Notifications Notifications data modeling is key in any defined data model. [RFC8639] and [RFC8641] define a subscription and push mechanism for YANG datastores. This mechanism currently allows the user to: o Subscribe notifications on a per client basis - o Specify subtree filters or xpath filters so that only interested - contents will be sent. + o Specify subtree filters [RFC6241] or xpath filters [RFC8639] so + that only interested contents will be sent. o Specify either periodic or on-demand notifications. 4. RSVP Base YANG Model The RSVP base module defines the main building blocks for modeling the RSVP protocol and augments the IETF routing module. 4.1. Module Structure @@ -2090,21 +2090,21 @@ This document registers two YANG modules in the YANG Module Names registry [RFC6020]. name: ietf-rsvp namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp prefix: rsvp reference: RFCXXXX name: ietf-rsvp-extended namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp-extended - prefix: rsvp-extendeed + prefix: rsvp-extended reference: RFCXXXX 7. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS