Individual Submission Internet Draft E. Lear Document: draft-lear-config-issues-00.txt Cisco Systems Expires: March 2003 September 2002 On Transport of Configuration Information draft-lear-config-issues-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract How are network elements configured? What are the different ways in which a device receives configuration, and why do they use those particular mechanisms? How do these mechanisms perform for their given use? This document discusses the problem of device configuration and state exchange. As we do so we will point out some protocol considerations, such as the objects being transported, how transfers are initiated, and what the security requirements are. Table of Contents 1. Introduction...................................................2 2. Our Target Audience and What They Do...........................3 2.1 The Individual Small Office or Home (SOHO).................3 2.2 The Small to Medium Sized Businesses.......................4 2.3 Enterprises................................................4 2.4 Service Providers..........................................5 2.5 Common Needs...............................................5 Lear Expires - March2003 [Page 1] draft-lear-config-issues-00.txt August 2003 3. How tools work to meet user needs..............................7 3.1 Limitations................................................7 4. Moving to the solution space: schema(s) and protocols..........8 4.1 Schema! Schema! WhoÆs Got The Schema?.....................9 5. Protocol Design Considerations................................10 5.1 Protocol Operations.......................................12 5.2 Protocol Choices: Use an existing one or grow a new one?..13 Security Considerations..........................................14 References.......................................................15 Acknowledgments..................................................17 Author's Addresses...............................................17 Copyright Statement..............................................17 1. Introduction Many implementations provide their users with ways to send and retrieve both configuration and state information that is wrapped in XML.[2] There is no standard for configuration of devices through XML, and there is no standard transport for this purpose. This document considers the problem of device configuration and state exchange and offers suggestions for a standard network protocol. This work builds on that of others, and the reader is expected to have read [3], [4] and [5]. There are numerous management tasks that can be performed on a device, including fault and performance monitoring and accounting. The task we consider today is the handling of configured state. Non-volatile configuration provides all necessary information for a device to perform its designated function, from the time the power is turned on. Operational state includes configuration state, as modified by alterations made during operation and statistics and information accumulated while in operation. There are two forms of configuration- volatile and non-volatile. A configuration operation that enables or disables service for individuals on a frequent basis is known as provisioning. An example of provisioning is the set of those configuration operations needed to create a dial-in account and/or create an electronic mailbox. As a matter of course, provisioning operations are driven by events, such as a customer calling up and requesting an account, or the billing system turning off a customerÆs account due to lack of payment. Lear Expires - March 2003 [Page 2] draft-lear-config-issues-00.txt August 2003 configuration protocol __________ ...................................>| | . |Enterprise| . _________ _________ | VPN | | v | | | | | Server B| | _______ | EDGE | | ISP core| |__________| |-|_______|<---->| ROUTER |-->| | __ | home | A | | | |PC|-| router ^ |_________| | | |A_| D . |_________| __________ . | | . | Enhanced | ...................................>| Service | configuration protocol | Manager C| |__________| Figure 1: SOHO / ISP Problem Space 2. Our Target Audience and What They Do There are different types of individuals who need their devices considered. Figure 1 illustrates a simple SOHO/ISP diagram. Operators can largely be grouped in the following way. 2.1 The Individual Small Office or Home (SOHO) This group usually has a very simple configuration, in our example owning PC A and having home router D. They largely want a device to work from the moment it is plugged in. They would prefer the device operate securely. In some cases, where configuration is required, it must be straight forward, and it must require as little interaction with the existing environment. In todayÆs world, configuration web pages are common for everything from small firewalls to power distribution systems. In some cases, a customer may delegate the task of configuration to a service provider, as the service provider is more likely to be able to answer questions necessary for a deviceÆs proper configuration. Indeed, some network devices may enforce a service provider policy, such as packet policing.[6] Indeed, it may be necessary to delegate a portion of a configuration to different service providers. A case in point is when someone wishes to use the same device to connect to the wide area network, an enterprise VPN, and a media controller of some form. Thus, the SOHO user has a need for split configuration. Lear Expires - March 2003 [Page 3] draft-lear-config-issues-00.txt August 2003 Somehow, the SOHO device must receive configuration from the VPN manager and the media device, not to mention the service provider, and potentially the SOHO user. A reasonable approach would be for the SOHO user to configure the device through a web page or other craft interface with the IP addresses of the management systems of the ISP, the VPN server, and the media controller. Another would be for the device to learn this information through some sort of auto-configuration system. This can at least be done for the ISP, as it is with DOCSIS.[7] In all cases with the exception of the configuration web page, we note that the SOHO device will initiate the communication with the manager, and NOT the other way around. 2.2 The Small to Medium Sized Businesses Small to medium businesses (SMBs) will have a few devices that need configuring. They will largely want to use common tools such as web browsers or a simple command line or menu driven interface to configure devices. SMBs perform configuration operations initially by hand. As they grow they may automate some tasks either by purchasing or downloading free software or by developing their own simple tools, probably through the use of a scripting language such as Perl or TCL.[8,9] In most cases, the tools currently used contact the network element, and not the other way around (i.e., the exact opposite of SOHO devices). 2.3 Enterprises As they grow into larger enterprises SMBs will begin to automate their provisioning operations, tying them to their hiring procedures or web based request pages. Enterprises often require that accounting information be tied to a service offered to an individual employee within a company. For instance, a departmental account will be billed for the use of a pager or a dial-up account. Enterprises have enough money to buy tools off the shelf and customize them as is appropriate to their environment. They also have business logic that they may tie to particular services. For instance, a taxi dispatch service may have a method to dispatch calls that sends notifications to available taxis of a certain group. Enterprises may also have enough money to develop tools from scratch when it is necessary to perform their core business functions. For instance, a ski lift at a resort might be configured with certain limitations, such as "only allow premier members through this gate". Often enterprises may wish to control equipment both in the office and at the employee home, to enforce a security policy or to maintain service quality. Indeed enterprises may delegate some or all of this function to a service provider. Lear Expires - March 2003 [Page 4] draft-lear-config-issues-00.txt August 2003 The tools enterprises use typically must navigate the differences between vendors in order to retrieve and send configuration information. Those tools typically initiate contact to a device that has been configured on a craft interface. 2.4 Service Providers Service providers vary widely from small local community providers to gigantic national telecommunications concerns. Although they differ in scale, small and large service providers share in common the goal to automate provisioning as much as possible in order to minimize human interaction with the customer. Indeed the provisioning tasks are also largely similar between the two. Examples include actions like creating a VPN, provisioning a circuit, or increasing the quota of a web account. In many cases, a provisioning operation involves multiple transactions, any one of which could fail, requiring rollback of the others. Small service providers will likely not be able to afford fancy service provisioning tools that have well defined programmatic and web interfaces. As is the case with SMBs, they are unlikely to have people dedicated to developing tools, and they will often write tools in scripting languages such as Perl and TCL. And of course they will have to debug the tools they write. In each case, they will want to interpose their business logic for accounting, billing, fault, and performance management. Large service providers are similar to enterprises in that they are likely to have developers available to customize tools that they have either procured or built. Very large service providers are likely to have their own proprietary provisioning systems that encompass inventory control as well as some sort of work flow management. In addition, large service providers will specialize functions. A provisioning system may modify provider edge interfaces as well as control customer edge gear, such as cable or DSL modems; a first level support person may need be allowed to review configurations; and a second or third tier support person may have full reign of a device. In a way not unlike SOHO devices, service provider devices may require some sort of authorization approach (more on this later). 2.5 Common Needs In any event, one requirement that seems to cross all borders to be able to atomically roll forward or backward a configuration action. In addition, as devices grow in size, service providers and enterprises require the ability to retrieve only the information they Lear Expires - March 2003 [Page 5] draft-lear-config-issues-00.txt August 2003 are interested in, and no more. For instance, one may request information on a particular network interface, in order to reconfigure it. Retrieving and processing an entire configuration of hundreds or thousands of interfaces when one only needs a few lines is costly, both computationally and in terms of network bandwidth. Another requirement that crosses all boundaries is the ability to minimize and automate configuration. The history of configuration of devices has been that of prearranged access and exchange. A Radius server is configured so that login and enable access can be authenticated, or a password file can be copied from a master server, or a device can be configured within a Kerberos realm. Starting with the SOHO environment, and moving upwards it is strongly desirable that devices be able to operate with minimal or no operator intervention. Thus such devices must be able to automatically configure themselves. In doing so they may need to be aware of other devices, such as DNS & DHCP servers, as well as various network management tools, such as a configuration manager or a fault management tool. Once theyÆre aware of those devices, because new functionality will be incrementally added over time, both management tool and device must be able to discover the otherÆs capabilities. On the other hand, auto-configuration begs the question of whose information one can trust. Without knowing who to trust, a device must either not come into service until it has been told who to trust, or it must simply record who it decided to trust. That "who" is in and of itself an interesting question. One reasonable answer is a valid certificate from a well-known certificate hierarchy of the management tools it is interacting with. While this wouldnÆt prevent damage, it would at least document who authorized the damage. Another answer for "who", in particular for small devices, might allow for an implied trust based on port. This is the case for small firewalls. In addressing all of these concerns, one common desire is that any standards in this area -- as always -- should be as complex as necessary, but no more so. In particular, when considering any RPC mechanisms, this concern must be addressed. Finally, a basic requirement of nearly all groups of network users is the ability to review changes within a network configuration. This is necessary as part of the fault resolution process, to determine what's changed. Maybe someone fat fingered an access list or disabled an interface. A concise view of each device configuration, and in particular recent changes to that configuration, is strongly desirable. Lear Expires - March 2003 [Page 6] draft-lear-config-issues-00.txt August 2003 3. How tools work to meet user needs There are three configuration models that fall out from our discussion in Section 2. First, there is the trivial case: a person connects either to a serial port or via telnet or a web interface (i.e., HTTP) and directly configures a device.[10] In some cases the person might use a tool that generates SNMP "gets" and "sets" to configure a device. This is the mechanism classically used by SOHO customers for everything from a small network HUB to printers and wireless devices. The second model is equally classic: a network manager connects to the device, having used some sort of discovery process, and configures it based on a request from either an automated process or a person. The manager is said to configure the managed element. Those tools might again use SNMP or they will more likely use some sort of scripting mechanism to communicate with the device. Very large deployments require something different. They require the element to register with an element manager in order to receive its initial configuration, as well as any changes that may be necessary over time. Many cable and DSL systems use this method today through DOCSIS and PPP, respectively.[11] It is important to recognize that even though the element is the connection initiator in the classic sense, the element manager may at some point need to initiate an action on the element. There is no standard protocol to do this, although dynamic host configuration protocol (DHCP) has been employed in some cases.[12] 3.1 Limitations The available toolset for configuration and provisioning operations includes SNMP and associated MIBs, vendor specific CLI that is configured through telnet or SSH.[13,14,15] For very simple devices, the web is also used. From a network standpoint, even where it is possible to use standard MIBs to monitor fault and performance of a service, it is often not possible to configure those services in the same way. Indeed it is not possible to retrieve a device configuration in a concise way with SNMP, as it is difficult for an automated tool to determine what information is persistent, or for that matter even present, without walking the MIB tree (an expensive operation). Persistent and volatile information is intermixed throughout the MIBs. While it might be possible to provide a table of contents within a MIB to keep track of such information, a better approach would allow for the reference of the same data in different contexts to indicate whether one wants to review volatile or non-volatile information. Lear Expires - March 2003 [Page 7] draft-lear-config-issues-00.txt August 2003 Another complaint that is frequently heard about SNMP is the use of binary encoding rules (BER) to represent information on the wire. BER is used in SNMP for good reason, in as much as it provides a very compact data representation. In the case of configuration objects, however, the need for such compactness is not clear. Indeed such rules require specialized tools to configure and retrieve information. One common complaint is that such specialized tools are not plentiful enough, and do not receive sufficient attention that they are considered robust or easy to use. On the other hand, vendor CLI and SSH or telnet offers an equally daunting set of problems. For one, the CLI between vendors is necessarily different, as each vendor or implementation expresses functionality in a way intended to distinguish it from others. In addition, such CLI tends to be built for humans to read and understand. Thus, if a programmer makes a spelling error she would correct it, particularly if the error changes the semantic meaning of the exchange. Unfortunately, while computers can cope with spelling errors, they have a very difficult time coping with change. While this is a well-understood problem in terms of scriptwriters, what is not so clear to many is just how CLI-based scripts can and have impeded development. Because changes between elements and element managers are often not synchronized, the addition of a column of information in a table, or the restructuring of a command may lead to misinterpretation or misconfiguration. For these reasons and others, no standard way to configure devices has yet to succeed within the Internet. However, it now seems possible that at least a portion of the problem can be standardized while we further consider other portions. 4. Moving to the solution space: schema(s) and protocols Experience has demonstrated a clear approach that allows for successful incremental development: find a way to modularize the problem and then work on the modules. Experience also has demonstrated where those modules are for network management.[16] With SNMP, for example, there are basically, three: the protocol used to transport information, the organization of that information (a schema), and definitions of individual objects within that schema. Here we propose to use that same model with one change: protocol operations themselves should largely be a function of the organization of information. As has been said and written, XML has conveniently entered into the fray, providing a (mostly) readable syntax with which one can use a schema. XML provides a very generic framework around which one can Lear Expires - March 2003 [Page 8] draft-lear-config-issues-00.txt August 2003 provide oneÆs schema and data dictionary or name space to easily expose configuration functionality. This in and of itself does not provide programmer interface stability between releases of software. That is what standards organizations and vendor discipline are for. However, the mere ability to have a more structured way to retrieve and send configuration information, or to cause certain actions, is an improvement over what previously existed. An XML schema provides a natural scoping, around which authorization mechanisms can be built. Split configuration needs could thus be addressed. In addition, because XML is used for everything under the sun, numerous tool sets are being built for it. These tool sets will be useful for things OTHER than network management, and that is a key distinguishing factor over SNMP. Thus, the fad may have snowballed itself into a useful mechanism. Indeed a brief survey shows that many leading vendors are supporting XML on at least some of their products. None of the information transported is standardized, but it is at the most basic level wrapped in angle brackets. 4.1 Schema! Schema! WhoÆs Got The Schema? Whose responsibility is it to derive a schema? At one level, the IETF has already done a tremendous amount of work on MIBs, and many vendors have implemented them. Clearly we want to retain this work as we move forward. Numerous efforts have provided translations between SMIv2 MIBs and XML Schema Definitions (XSDs).[17] Rather than start with a battle over schemas, letÆs accept that in fact multiple schemas exist, provided by both vendors and standards organizations, much in the same way that enterprises MIBs exist, and that this is likely to remain the case for a very long time. While it is perhaps desirable for all devices to use standard data models and schemas, as a matter of modularity, we leave it to others to define them. There is at least one additional reason to do so: it remains unproven that configuration information could be sufficiently divorced from implementation that complex configuration tasks can in fact be standardized. Indeed the native protocol operations themselves could be limited to the transmission of XML and a response code that may also include some XML. Operations that have more meaning than that must be defined within a particular schema, again, in order to preserve modularity. Lear Expires - March 2003 [Page 9] draft-lear-config-issues-00.txt August 2003 For example, there could exist a schema that maps directly to the managed information base (MIB) tree. The SNMP operations that act upon that tree are "get", "getnext", "set", etc. On the other hand, there could exist a schema that looks an awfully lot like a CLI, whose operations include "configure", "reboot", "debug", "reset card", etc. 5. Protocol Design Considerations A protocol addressing this space will carry transactions back and forth, in one direction or another. Although transactions do not require a session, experience has taught us that a session is in fact required to avoid the need to re-authenticate for every transaction. In addition, many configuration objects can be quite large, and there is a need for congestion avoidance. Finally, reliable communications are desirable for most such operations. For these reasons we assume for the following discussion that a connection-oriented protocol such as TCP or SCTP is used. In considering a protocol we will look at the following tasks: o Connection establishment o Transport encryption and authentication o Capabilities exchange o Protocol operations and transmission of configuration objects o Responses o Disconnection The rest of this section discusses the first three bullets and disconnection. Protocol operations and transmission of XML objects and associated responses are discussed in Section 5.1. The circumstances of a device may determine the direction of connection establishment. Typically element managers contact the elements they wish to manage and send configuration. This is particularly true for SNMP and for tools that "screen scrape" (i.e., connect to an element over telnet or ssh and then navigate the user interface). In some circumstances, however, it is desirable for devices to connect to an element manager in order to request configuration data. This is done with COPS-PR[18]. In the former case, the network manager needs to know about the device before the device can be managed. In the latter case, the device needs to know about the network manager before it can be managed. While there are tradeoffs in scaling properties and complexity with either model, we assume that both are valid. Indeed another reason we concern ourselves with connection direction is that firewalls and NATs may limit so-called "inbound" TCP Lear Expires - March 2003 [Page 10] draft-lear-config-issues-00.txt August 2003 connections. Thus, either the element manager or managed element may initiate a transport connection. Once a connection is established, it must be possible to secure the connection and for each end to authenticate itself to the other. There are several approaches that are commonly used today, including transport layer security (TLS) and Kerberos.[19,20]. Others may come along. A flexible approach is desirable to enable both these and future mechanisms without having to update the protocol specification. Even within these approaches there are variations. For instance, it might be desirable for one end to use certificates and another to use user names. This allows, for example, existing configuration authentication mechanisms such as Radius[21] to be used. Operations may require authentication on either side of a connection. That authentication might even take a different form on either side of a connection. For instance, an element may attempt to request its configuration from an element manager, and thus be required to authenticate itself. Or, as more typically seen, an element manager may attempt to deliver some instructions and be required to authenticate to the element. In either case, because of the nature of the problem, it is probably safe to assume that if there is to be any authentication it should occur once, directly after a connection is established. Once each side knows who the other is, it should be possible for them to learn the capabilities of the other, subject to whatever authorization may be imposed. When we say capabilities, we really mean some sort of defined schema. This is the point where an element manager might learn which language it must use to configure a device, and perhaps which version of that language. It is possible that for compatibility reasons, a device may understand more than one schema. It is also possible that schemas may develop for very specific purposes. Again, while not precluding such scenarios, it is beyond the scope of this work to specify how many schemas may be employed, or their use. What will be necessary is a namespace for schemas from which to choose. At this point we are ready to exchange XML. Typically, the element manager will initiate such a transfer, but an element might just as easily request a particular object. How those objects are identified or named will vary based on the schema in use [XXX name spaces?? XXX]. It is possible that multiple schemas may be used, and therefore we must avoid ambiguities. It is possible to design a protocol such that each message would state which schema is used. This would be analogous to starting every sentence with "IÆm speaking English". Identifying the context at the beginning of a Lear Expires - March 2003 [Page 11] draft-lear-config-issues-00.txt August 2003 communication is probably good enough for the uses described in earlier sections. Connections may be very long-lived, such as in COPS-PR, or they may exist for brief periods of time. Disconnection may occur for many reasons, and just as with any protocol, may be planned or unplanned. The protocol should allow for either side to initiate a connection close. 5.1 Protocol Operations As we previously discussed, requests may be initiated in either direction. We must now discuss the structure of a request. For illustrative purposes alone we consider a few lines of XML that demonstrates a small handful of functions: à In this illustrative example, an interface is configured with an ipv4 address and mask. can be viewed as either transaction content or a protocol operation. In this case we could conceivably take the angle brackets away, were we to agree to all the mechanisms to manipulate configuration. Because we canÆt, we may place a thin wrapper around , and allow the element to be defined within individual schema. Note that the problem gets more difficult the further inward one goes. For instance, not every device may route, and therefore have a . A key goal for the protocol is to provide sufficient maximum utility while remaining stable. Thus, the actual protocol operations need to be fairly basic, allowing for the semantic requests to be placed in some structured way (in this case XML) and responses to be sent in a similar manner. Still there are several common operations that we would like to perform on the device, associated with the above configuration. One would be to commit it, and another would be to roll it back. There are probably others. It is likely that such operations are within the bounds of standardization. Lear Expires - March 2003 [Page 12] draft-lear-config-issues-00.txt August 2003 5.2 Protocol Choices: Use an existing one or grow a new one? Because XML itself is just a text-based syntax, there are numerous ways to transport it such that it gets to a destination intact, and a response returns reasonably intact. One could even use Email or Netnews (donÆt laugh, moving control information through such mechanisms is nothing new).[22] However, realistically speaking since we are talking about network control, we require an interactive protocol that provides responses in real time, as opposed to a store- and-forward mechanism. The protocols people use today to transport XML and other configuration data are SSH, HTTP, SSL, and Blocks Extensible Exchange Protocol (BEEP).[23] Each protocol has advantages and disadvantages. To start with, SSH is perhaps the most widely deployed protocol that provides some amount of ad-hoc security. Indeed, with the IETF just having standardized it, it has the advantage of having gone through some security review, and it requires very little infrastructure to use. Keys are exchanged out of band, and they may be aggregated through whatever mechanism an administrator wishes to use. Of course, this same advantage is also a disadvantage, because there is no standard way for a device to determine whether or not to trust another device. Once an authenticated connection is established, however, there is no way to determine supported schemas, and there is no clear way to know when a response should even be expected, never mind whether the actual XML has been acted upon. Were we to use SSH, we would have to add a layer between the transport and the XML to accomplish this. HTTP and SSL are two peas in a pod. SSL provides a layer of security for HTTP that sits on top of it. Of all the mechanisms used to move XML today, HTTP is clearly the protocol of choice, through the use of GETs and POSTs.[24] HTTP has the enormous benefit of a large amount of available tools to scale its delivery. Still, architecturally, the server and the client look very different. An HTTP client submits requests and a server submits responses. This clearly does not naturally fit a model where requests could come from either side. A rebuttal to this limitation is that the protocol could be so general as to encompass every conceivable requirement, and therefore be impossible to implement. Clearly a balanced approach is required. SSL is useful in a way similar to SSH, in that it provides for an authentication model. SSL uses a hierarchical certificate approach that is widely deployed. However, what happens in environments where either a certificate authority is temporarily unavailable, or where there is never access to the certificate hierarchy? Also, generating and enrolling certificates in new devices is a hard problem. An easier approach is to verify through a certificate one side of a connection, and then using a shared secret for the other side, a Lear Expires - March 2003 [Page 13] draft-lear-config-issues-00.txt August 2003 common approach used on the web. SSL supports such an approach, as does TLS. BEEP is a new addition to the IETF protocol suite, and is not today heavily used to move device configuration information. Although it suffers from limited implementation, it was designed with the notion that XML or another blocks of data. BEEP was designed not so much with one specific application involved, but as a framework applications could use to exchange data with one another, in a secure way, if so desired. BEEP also matches the model that we discussed above in two other respects: first, while providing framing, it provides very little in the way of application protocol operations. Second, it allows either side to initiate a transaction. However, BEEP is not perfectly simple. While the protocol provides for security and framing, it also requires the use of control and data channels within a single stream, thus increasing implementation complexity, where it is not yet clear that the use of a channelized stream is warranted.[25,26] Here again, we see a tradeoff between generalization and specific optimization. There are numerous other protocols that could be considered. The actual choice must be made in the context of customer requirements. Security Considerations Configuration of devices is by its nature a sensitive activity. Whatever mechanisms advance must be able to allow for a flexible authentication model, as well as encryption. Each device must be able to authenticate itself. Bootstrapping is a particularly tricky case in such an environment, as it may not be possible for a newly purchased device to authenticate itself to anyone. Therefore, an initial enrollment step with some sort of out of band data may be necessary. Splitting of responsibilities for a configuration requires particular attention. A known ages-old operator requirement is that a configuration be viewed discretely, as one file. This is necessary for debugging purposes, among many other reasons. In addition, some responsibilities may not be easily partitioned. Various studies of policy demonstrate the need to understand and avoid such conflicts.[27] In the context of authorization, it must be possible to audit configuration changes, and that audit capability needs to scale nicely. One concern about SNMP is that provisioning would be implemented through a number of sets. In order to reduce load there Lear Expires - March 2003 [Page 14] draft-lear-config-issues-00.txt August 2003 must be a way to aggregate those sets into a concise configuration operation that can be traced back to the entity that initiated it. If something more concise is used in the first place, the aggregation may be less necessary. A better understanding is needed in this area. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Marsh, J. Ed., XML Base, W3C Recommendation, June 2001. 3 Woodcock, B., ôOperator Requirements of Infrastructure Management Methodsö, draft-ops-operator-req-mgmt-02.txt, Work In Progress. 4 Wasserman, M., ôConcepts and Requirements for XML Network Configurationö, draft-wasserman-xmlconf-req-00.txt, Work in Progress. 5 Bierman, A., ôNetwork Management Observationsö, draft-bierman-nm- observations-00.txt, Work In Progress. 6 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and Weiss, W., ôAn Architecture for Differentiated Servicesö, RFC 2475, December 1998. 7 Cable Television Laboratories, "Data of Cable Service Interface Specification: Operations Support System Interface Specification", SP-OSSIv2.0-I02-020617, June 2002. 8 Wall, L., Christianson, T., Orwant, J., ôProgramming Perl 3rd Editionö, OÆReilly & Associates, July 2000. 9 Ousterhout, J., ôTcl: An Embeddable Command Languageö, USENIX Conference Proceedings, ppg. 133-146, January 1990. 10 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., ôHypertext Transfer Protocol û HTTP/1.1ö, RFC 2616, June 1999. 11 Simpson, W., ed., "The Point to Point Protocol", RFC 1661, July, 1994. 12 Droms, R., ôDynamic Host Configuration Protocolö, RFC 2131, March 1997. Lear Expires - March 2003 [Page 15] draft-lear-config-issues-00.txt August 2003 13 Harrington, D., Wijnen, B., ôAn Architecture for Describing SNMP Management Frameworksö, RFC 2571, May 1999. 14 McKenzie, A.M., ôTelnet Protocol Specificationsö, RFC 495, May 1973. 15 Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., Lethinen, S., ôSSH Transport Layer Protocolö, Work in Progress, draft-ietf- secsh-transport-14.txt, March 2002. 16 Wasserman, M., ôConcepts and Requirements for XML Network Configurationö, draft-wasserman-xmlconf-req-00.txt, Work in progress. 17 Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., ed., ôXML Schema Part 1: Structuresö, W3C Recommendation, May 2001. 18 Chan, K., et al., ôCOPS Usage for Provisioning (COPS-PR)ö, RFC 3084, March 2001. 19 Dierks, T., Allen, C., ôThe TLS Protocol Version 1.0ö, RFC 2246, January 1999. 20 Kohl, J., Neuman, C., ôThe Kerberos Network Authentication Service (V5)ö, RFC 1510, September 1993. 21 Rigney, C., Willens, S., Rubens, A, Simpson, W., ôRemote Authentication Dial In User Service (RADIUS)ö, RFC 2865, June 2000. 22 Smith, R., Gottesman, S., Hobbs, B., Lear, E., Kristofferson, D., Benton, D., Smith, P., ôA mechanism for maintaining up-to-date GenBank database via Usenetö, Computational Applied Biosciences, ppg. 111-112, January 1991. 23 Rose, M., ôThe Blocks Extensible Exchange Protocol Coreö, RFC 3080, March 2001. 24 Moore, K., ôOn the use of HTTP as a substrateö, RFC 3205, February 2002. 25 Postel, J., ed., ôTransmission Control Protocolö, RFC 793, September 1981. 26 Stewart, R., Xie, Q., Morneault, K., Charp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V., ôStream Control Transmission Protocolö, RFC 2960, October 2000. Lear Expires - March 2003 [Page 16] draft-lear-config-issues-00.txt August 2003 27 Moore, B., Elleson, E., Strassner, J., Westerinan, A., "Policy Core Information Model-- Version 1 Specification", RFC 3060, February, 2001. Acknowledgments This document is based on the work of Andy Bierman, Fred Baker, Bill Woodcock, and Margaret Wassmerman. Substantial input came from Marshall Rose and Dave Crocker, as well as numerous operators. Author's Addresses Eliot Lear Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134 Email: lear@cisco.com Copyright Statement Copyright (C) The Internet Society 2002. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Lear Expires - March 2003 [Page 17] draft-lear-config-issues-00.txt August 2003 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lear Expires - March 2003 [Page 18]