draft-ietf-netconf-netconf-event-notifications-01.txt   draft-ietf-netconf-netconf-event-notifications-02.txt 
NETCONF A. Gonzalez Prieto NETCONF A. Gonzalez Prieto
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track A. Clemm Intended status: Standards Track A. Clemm
Expires: May 4, 2017 Sympotech Expires: November 2, 2017 Huawei
E. Voit E. Voit
E. Nilsen-Nygaard E. Nilsen-Nygaard
A. Tripathy A. Tripathy
Cisco Systems Cisco Systems
S. Chisholm S. Chisholm
Ciena Ciena
H. Trevino H. Trevino
Cisco Systems Cisco Systems
October 31, 2016 May 1, 2017
NETCONF Support for Event Notifications NETCONF Support for Event Notifications
draft-ietf-netconf-netconf-event-notifications-01 draft-ietf-netconf-netconf-event-notifications-02
Abstract Abstract
This document defines the support of [event-notifications] by the This document defines the support of [event-notifications] by the
Network Configuration protocol (NETCONF). [event-notifications] Network Configuration protocol (NETCONF). [event-notifications]
describes capabilities and operations for providing asynchronous describes capabilities and operations for providing asynchronous
message notification delivery. This document discusses how to message notification delivery. This document discusses how to
provide them on top of NETCONF. The capabilities and operations provide them on top of NETCONF. The capabilities and operations
defined between this document and [event-notifications] are intended defined between this document and [event-notifications] are intended
to obsolete RFC 5277. to obsolete RFC 5277.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 4, 2017. This Internet-Draft will expire on November 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 9 skipping to change at page 3, line 9
6.2. Informative References . . . . . . . . . . . . . . . . . 47 6.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Issues that are currently being worked . . . . . . . 47 Appendix A. Issues that are currently being worked . . . . . . . 47
Appendix B. Changes between revisions . . . . . . . . . . . . . 47 Appendix B. Changes between revisions . . . . . . . . . . . . . 47
B.1. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 47 B.1. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
[RFC6241] can be conceptually partitioned into four layers: [RFC6241] can be conceptually partitioned into four layers:
Layer Example Layer Example
+-------------+ +-------------------------------------------+ +-------------+ +-----------------+ +----------------+
| Content | | Configuration data | (4) | Content | | Configuration | | Notification |
+-------------+ +-------------------------------------------+ | | | data | | data |
| | +-------------+ +-----------------+ +----------------+
+-------------+ +-------------------------------------------+ | | |
| Operations | |<get-config>, <edit-config>, <notification>| +-------------+ +-----------------+ |
+-------------+ +-------------------------------------------+ (3) | Operations | | <edit-config> | |
| | | | | | | |
+-------------+ +-----------------------------+ | +-------------+ +-----------------+ |
| RPC | | <rpc>, <rpc-reply> | | | | |
+-------------+ +-----------------------------+ | +-------------+ +-----------------+ +----------------+
| | | (2) | Messages | | <rpc>, | | <notification> |
+-------------+ +-------------------------------------------+ | | | <rpc-reply> | | |
| Transport | | BEEP, SSH, SSL, console | +-------------+ +-----------------+ +----------------+
| Protocol | | | | | |
+-------------+ +-------------------------------------------+ +-------------+ +-----------------------------------------+
(1) | Secure | | SSH, TLS, SOAP/HTTP/TLS, ... |
| Transport | | |
+-------------+ +-----------------------------------------+
Figure 1: NETCONF layer architecture Figure 1: NETCONF layer architecture
This document defines mechanisms that provide an asynchronous message This document defines mechanisms that provide an asynchronous message
notification delivery service for the NETCONF protocol [RFC6241] notification delivery service for the NETCONF protocol [RFC6241]
based on [event-notifications]. This is an optional capability built based on [event-notifications]. This is an optional capability built
on top of the base NETCONF definition. on top of the base NETCONF definition.
[event-notifications] and this document enhance the capabilities of [event-notifications] and this document enhance the capabilities of
RFC 5277 while maintaining backwards capability with existing RFC 5277 while maintaining backwards capability with existing
skipping to change at page 14, line 45 skipping to change at page 14, line 45
provided or if the name of a non-existent stream is provided. provided or if the name of a non-existent stream is provided.
2.5.4. Multiple Subscriptions over a Single NETCONF Session 2.5.4. Multiple Subscriptions over a Single NETCONF Session
Note that [event-notifications] requires supporting multiple Note that [event-notifications] requires supporting multiple
subscription establishments over a single NETCONF session. In subscription establishments over a single NETCONF session. In
contrast, [RFC5277] mandated servers to return an error when a contrast, [RFC5277] mandated servers to return an error when a
create-subscription was sent while a subscription was active on that create-subscription was sent while a subscription was active on that
session. Note that servers are not required to support multiple session. Note that servers are not required to support multiple
create-subscription over a single session, but they MUST support create-subscription over a single session, but they MUST support
multiple establish-suscription over one session. multiple establish-subscription over one session.
2.5.5. Message Flow Examples 2.5.5. Message Flow Examples
+------------+ +-----------+ +------------+ +-----------+
| Client | | Server | | Client | | Server |
+------------+ +-----------+ +------------+ +-----------+
| | | |
| Capability Exchange | | Capability Exchange |
|<---------------------------->| |<---------------------------->|
| | | |
| | | |
skipping to change at page 25, line 14 skipping to change at page 25, line 14
2.8.1. Call Home for Configured Subscriptions 2.8.1. Call Home for Configured Subscriptions
Configured subscriptions are established, modified, and deleted using Configured subscriptions are established, modified, and deleted using
configuration operations against the top-level subtree subscription- configuration operations against the top-level subtree subscription-
config. Once the configuration is set, the server initiates a Call config. Once the configuration is set, the server initiates a Call
Home to each of the receivers in the subscription on the address and Home to each of the receivers in the subscription on the address and
port specified. Once the NETCONF session between the server and the port specified. Once the NETCONF session between the server and the
receiver is established, the server will issue a "subscription- receiver is established, the server will issue a "subscription-
started" notification. After that, the server will send started" notification. After that, the server will send
notifications to the receiver as per the subscription notification. notifications to the receiver as per the subscription.
Note that the server assumes the receiver is aware that calls on the Note that the server assumes the receiver is aware that calls on the
configured port are intended only for pushing notifications. It also configured port are intended only for pushing notifications. It also
assumes that the receiver is ready to accept notifications on the assumes that the receiver is ready to accept notifications on the
session created as part of the Call Home as soon as the NETCONF session created as part of the Call Home as soon as the NETCONF
session is established. This may require coordination between the session is established. This may require coordination between the
client that configures the subscription and the clients for which the client that configures the subscription and the clients for which the
notifications are intended. This coordination is out of the scope of notifications are intended. This coordination is out of the scope of
this document. this document.
skipping to change at page 48, line 10 skipping to change at page 48, line 10
o D4 - Editorial improvements. o D4 - Editorial improvements.
Authors' Addresses Authors' Addresses
Alberto Gonzalez Prieto Alberto Gonzalez Prieto
Cisco Systems Cisco Systems
Email: albertgo@cisco.com Email: albertgo@cisco.com
Alexander Clemm Alexander Clemm
Sympotech Huawei
Email: alex@sympotech.com Email: ludwig@clemm.org
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Einar Nilsen-Nygaard Einar Nilsen-Nygaard
Cisco Systems Cisco Systems
Email: einarnn@cisco.com Email: einarnn@cisco.com
 End of changes. 10 change blocks. 
26 lines changed or deleted 29 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/