draft-ietf-netconf-beep-08.txt   draft-ietf-netconf-beep-09.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: July 9, 2006 K. Crozier Expires: September 4, 2006 K. Crozier
January 5, 2006 March 3, 2006
Using the NETCONF Protocol over Blocks Extensible Exchange Protocol Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
(BEEP) (BEEP)
draft-ietf-netconf-beep-08 draft-ietf-netconf-beep-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies an application protocol mapping for the This document specifies an application protocol mapping for the
NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4
2.1. NETCONF Session Establishment . . . . . . . . . . . . . . 4 2.1. NETCONF Session Establishment . . . . . . . . . . . . . . 4
2.2. Starting a Channel for NETCONF . . . . . . . . . . . . . . 4 2.2. Starting a Channel for NETCONF . . . . . . . . . . . . . . 5
2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6 2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6
2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6 2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6
2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 6 2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
skipping to change at page 4, line 10 skipping to change at page 4, line 10
[3]. The SASL profile used by BEEP allows for a simple and direct [3]. The SASL profile used by BEEP allows for a simple and direct
mapping to the existing security model for CLI, while transportlayer mapping to the existing security model for CLI, while transportlayer
security (TLS) [4] provides a strong well tested encryption mechanism security (TLS) [4] provides a strong well tested encryption mechanism
with either server or server and client-side authentication. with either server or server and client-side authentication.
2. BEEP Transport Mapping 2. BEEP Transport Mapping
All NETCONF over BEEP implementations MUST implement the profile and All NETCONF over BEEP implementations MUST implement the profile and
functional mapping between NETCONF and BEEP as described below. functional mapping between NETCONF and BEEP as described below.
For purposes of this document a manager is a NETCONF client, and an
agent is a NETCONF server. Use of client/server language in BEEP is
avoided because of the common notion that in networking clients
connect to servers.
2.1. NETCONF Session Establishment 2.1. NETCONF Session Establishment
Managers may be either BEEP listeners or initiators. Similarly, Managers may be either BEEP listeners or initiators. Similarly,
agents may be either listeners or initiators. Thus the initial agents may be either listeners or initiators. Thus the initial
exchange takes place without regard to whether a manager or the agent exchange takes place without regard to whether a manager or the agent
is the initiator. After the transport connection is established, as is the initiator. After the transport connection is established, as
greetings are exchanged, they SHOULD each announce their support for greetings are exchanged, they SHOULD each announce their support for
TLS and optionally SASL. Once greetings are exchanged, if TLS is to TLS and optionally SASL. Once BEEP greeting messages are exchanged,
be used and available by both parties, the listener STARTs a channel if TLS is to be used and available by both parties, the listener
with the TLS profile. STARTs a channel with the TLS profile.
Once TLS has been started, a new greeting is sent by both initiator Once TLS has been started, a new BEEP greeting message is sent by
and listener, as required by the BEEP RFC. both initiator and listener, as required by the BEEP RFC.
After all BEEP greeting messages are exchanged in order for roles to
be clear, the agent MUST advertise the NETCONF profile. The manager
MUST NOT advertise the NETCONF profile. If the agent side of the
communication (either initiator or listener) receives a BEEP
<greeting> element that contains the NETCONF profile, it MUST close
the connection. Similarly, if neither side issues a NETCONF profile
it is equally an error, and the listener MUST close the connection.
At this point, if SASL is desired, the initiator starts a BEEP At this point, if SASL is desired, the initiator starts a BEEP
channel to perform a SASL exchange to authenticate itself. Upon channel to perform a SASL exchange to authenticate itself. Upon
completion of authentication the channel is closed. That is, the completion of authentication the channel is closed. That is, the
channel is exclusively used to authenticate. channel is exclusively used to authenticate.
Examples of both TLS and SASL profiles can be found in [7]. Examples of both TLS and SASL profiles can be found in [7].
It is anticipated that the SASL PLAIN mechanism will be heavily used It is anticipated that the SASL PLAIN mechanism will be heavily used
in conjunction with TLS.[5] In such cases, in accordance with RFC in conjunction with TLS.[5] In such cases, in accordance with RFC
skipping to change at page 4, line 48 skipping to change at page 5, line 12
about the use of SASL and TLS are mentioned in Security about the use of SASL and TLS are mentioned in Security
Considerations below. Considerations below.
Once authentication has occurred, there is no need to distinguish Once authentication has occurred, there is no need to distinguish
between initiator and listener. We now distinguish between manager between initiator and listener. We now distinguish between manager
and agent, and it is assumed that each knows its role in the and agent, and it is assumed that each knows its role in the
conversation. conversation.
2.2. Starting a Channel for NETCONF 2.2. Starting a Channel for NETCONF
The manager now establishes new channel and specifies the single The manager now establishes a new channel and specifies the single
NETCONF profile. For example: NETCONF profile. For example:
(M = Manager ; A = Agent ) (M = Manager ; A = Agent )
M: MSG 0 1 . 10 48 116 M: MSG 0 1 . 10 48 116
M: Content-type: application/beep+xml M: Content-type: application/beep+xml
M: <start number="1"> M: <start number="1">
M: <profile uri="http://iana.org/beep/netconf" /> M: <profile uri="http://iana.org/beep/netconf" />
M: </start> M: </start>
M: END M: END
skipping to change at page 5, line 49 skipping to change at page 6, line 27
A: http://example.net/router/2.3/core#myfeature A: http://example.net/router/2.3/core#myfeature
A: </capability> A: </capability>
A: </capabilities> A: </capabilities>
A: <session-id>4</session-id> A: <session-id>4</session-id>
A: </hello> A: </hello>
A: END A: END
M: RPY 1 0 . 0 0 M: RPY 1 0 . 0 0
M: END M: END
Certain NETCONF capabilities may require additional BEEP channels. Future NETCONF capabilities may require additional BEEP channels.
When such capabilities are defined, a BEEP mapping must be defined as When such capabilities are defined, a BEEP mapping must be defined as
well. well.
At this point, the NETCONF session is established, and capabilities At this point, the NETCONF session is established, and capabilities
have been exchanged. have been exchanged.
2.3. NETCONF Session Usage 2.3. NETCONF Session Usage
Nearly all NETCONF operations are executed through the <rpc> tag. To Nearly all NETCONF operations are executed through the <rpc> element.
issue an RPC, the manager transmits on the operational channel a BEEP To issue an RPC, the manager transmits on the operational channel a
MSG containing the RPC and its arguments. In accordance with the BEEP MSG containing the RPC and its arguments. In accordance with
BEEP standard, RPC requests may be split across multiple BEEP frames. the BEEP standard, RPC requests may be split across multiple BEEP
frames.
Once received and processed, the agent responds with BEEP RPY Once received and processed, the agent responds with BEEP RPY
messages on the same channel with the response to the RPC. In messages on the same channel with the response to the RPC. In
accordance with the BEEP standard, responses may be split across accordance with the BEEP standard, responses may be split across
multiple BEEP frames. multiple BEEP frames.
2.4. NETCONF Session Teardown 2.4. NETCONF Session Teardown
Upon receipt of <close-session> from the manager, once the agent has Upon receipt of <close-session> from the manager, once the agent has
completed all RPCs, it will close BEEP channel 0. When an agent completed all RPCs, it will close BEEP channel 0. When an agent
skipping to change at page 10, line 14 skipping to change at page 10, line 14
5. Acknowledgments 5. Acknowledgments
This work is the product of the NETCONF IETF working group, and many This work is the product of the NETCONF IETF working group, and many
people have contributed to the NETCONF discussion. Most notably, Rob people have contributed to the NETCONF discussion. Most notably, Rob
Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and
Margaret Wasserman all contributed in some fashion to this work, Margaret Wasserman all contributed in some fashion to this work,
which was originally to be found in the NETCONF base protocol which was originally to be found in the NETCONF base protocol
specification. Thanks also to Weijing Chen, Keith Allen, Juergen specification. Thanks also to Weijing Chen, Keith Allen, Juergen
Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very
constructive participation. constructive participation. The authors would also like to thank
Elwyn Davies for his constructive review.
6. References 6. References
6.1. Normative References 6.1. Normative References
[1] Enns, R., "NETCONF Configuration Protocol", [1] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-08 (work in progress), September 2005. draft-ietf-netconf-prot-08 (work in progress), September 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 12 change blocks. 
18 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/