1. abierman-nanog-30may03 1 XML Router Configs BOF Operator Involvement Andy Bierman abierman@cisco.com

2. abierman-nanog-30may03 2 Introduction l The goal of the Netconf WG is to create a standard protocol for programmatic configuration of networks. »The co-chairs are very focused on producing a standard that operators want to use and vendors want to deploy. l Although it’s easy to ignore the IETF WG process and focus on running your network, it will be worth the effort to get involved. »Various ways to participate; some easier than others »The WG really needs input from people with network operations experience to keep the work focused

3. abierman-nanog-30may03 3 WG Details l Mailing List »Discussion: netconf@ops.ietf.org »Subscribe: netconf-request@ops.ietf.org –‘subscribe’ in the message body »Archive: http://ops.ietf.org/lists/netconf/ l WG Charter Page »http://www.ietf.org/html.charters/netconf-charter.htmlhttp://www.ietf.org/html.charters/netconf-charter.html l Please get involved »Read drafts, participate in email discussions, etc. »Send email directly to the co-chairs with your concerns

4. abierman-nanog-30may03 4 Some Charter Details l The Netconf WG is chartered to produce a protocol suitable for network configuration, with the following characteristics: »Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data »Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol »Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) »Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. »Supports integration with existing user authentication methods »Supports integration with existing configuration database systems »Supports network wide configuration transactions (with features such as locking and rollback capability) »Is as transport-independent as possible »Provides support for asynchronous notifications

5. abierman-nanog-30may03 5 Some Issues Already Decided (1/2) l Peer to Peer »Unicast, connection-oriented, synchronous transactions »Either end can initiate the connection l Session Based »User authentication and some protocol characteristics decided at session startup l Extensible Operational Model »Base features + standard extensions + vendor extensions »Extensions determined by capabilities exchange at session startup

6. abierman-nanog-30may03 6 Some Issues Already Decided (2/2) l Transport Independent, but certain requirements of transport are assumed »Connection-oriented »Most security features at transport layer, such as encryption and user authentication l XML data encoding »Good balance between human and machine readable syntax »Config content can also be XML-wrapped (CLI) text l Separation of protocol and data model »Will identify any data model issues which affect the protocol »IETF and vendors will create data models independently of the protocol development »XML Schema (XSD) will probably be used for initial data types and data modeling language

7. abierman-nanog-30may03 7 Issues The WG Needs To Resolve l Transport mappings »BEEP, HTTPS, SSH l RPC Layer »SOAP encoding, xmlconf RPC, or simple request/response l Advanced XML features »WSDL templates, XPath filtering l Protocol Operations »Add, Modify, Delete Variants –Operation as element above data model, element within data model, or attribute within data model elements »Advanced operations: mandatory or optional –Checkpoint, Rollback, Locking »Multi-device operation support »Error Handling »Notifications –Use of Secure Syslog (RFC 3195) or SNMP-like notifications