draft-ietf-netconf-beep-02.txt   draft-ietf-netconf-beep-03.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft K. Crozier Internet-Draft K. Crozier
Expires: April 18, 2005 Cisco Systems Expires: May 16, 2005 Cisco Systems
October 18, 2004 November 15, 2004
Using the NETCONF Protocol over Blocks Extensible Exchange Protocol Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
(BEEP) (BEEP)
draft-ietf-netconf-beep-02 draft-ietf-netconf-beep-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 34 skipping to change at page 1, line 34
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 April 18, 2005. This Internet-Draft will expire on May 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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).
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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> tag. To
issue an RPC, the manager transmits on the operational channel a BEEP issue an RPC, the manager transmits on the operational channel a BEEP
MSG containing the RPC and its arguments. In accordance with the MSG containing the RPC and its arguments. In accordance with the
BEEP standard, RPC requests may be split across multiple BEEP frames. BEEP standard, RPC requests may be split across multiple BEEP frames.
Once received and processed, the agent responds with BEEP RPYs on the Once received and processed, the agent responds with BEEP RPYs on the
same channel with the response to the RPC. In accordance with the same channel with the response to the RPC. In accordance with the
BEEP standard, responses may be split across multiple BEEP frames. BEEP standard, responses may be
split across 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
needs to initiate a close it will do so by closing BEEP channel 0. needs to initiate a close it will do so by closing BEEP channel 0.
Although not required to do so, the agent should allow for a Although not required to do so, the agent should allow for a
reasonable period for a manager to release an existing lock prior to reasonable period for a manager to release an existing lock prior to
initiating a close. Once the agent has closed channel 0, all locks initiating a close. Once the agent has closed channel 0, all locks
are released, and each side follows tear down procedures as specified are released, and each side follows tear down procedures as specified
in [3]. Having received a BEEP close or having sent <close-session>, in [3]. Having received a BEEP close or having sent <close-session>,
a manager MUST NOT send further requests. If there are additional a manager MUST NOT send further requests. If there are additional
activities due to expanded capabilities, these MUST cease in an activities due to expanded capabilities, these MUST cease in an
orderly manner, and should be properly described in the capability orderly manner, and should be properly described in the capability
mapping. mapping.
2.5 BEEP Profile for NETCONF 2.5 BEEP Profile for NETCONF
There are three commands in the BEEP profile. <rpc> and <rpc-reply>. There are two commands in the BEEP profile. <rpc> and <rpc-reply>.
2.5.1 BEEP Profile 2.5.1 BEEP Profile
<!-- DTD for netconf operations over BEEP <!-- DTD for netconf operations over BEEP
Refer to this DTD as: Refer to this DTD as:
<!ENTITY % NETCONF PUBLIC "netconf/Operation/1.0" ""> <!ENTITY % NETCONF PUBLIC "netconf/Operation/1.0" "">
%NETCONF; %NETCONF;
--> -->
skipping to change at page 12, line 10 skipping to change at page 12, line 10
[10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
Authors' Addresses Authors' Addresses
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
Glatt-com Glatt-com
Glattzentrum, Zurich 8301 Glattzentr
um, Zurich 8301
CH CH
EMail: lear@cisco.com EMail: lear@cisco.com
Ken Crozier Ken Crozier
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
EMail: kcrozier@cisco.com EMail: kcrozier@cisco.com
Appendix A. Change Log Appendix A. Change Log
03, 04: minor gnits relating to <close-session>
02: added comments about locking 02: added comments about locking
01: Removed management channel, rpc-status, rpc-abort, and associated 01: Removed management channel, rpc-status, rpc-abort, and associated
profile changes. profile changes.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
 End of changes. 

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