On Monday 23 September 2002 05:07 pm, Larry Menten wrote:Jon and Glenn, I agree. XML has much to offer in improving the way data is collected and asynchronous notifocations are expressed. Addressing the need to standardize XML-based configuration, data collection, and asynchronous messaging recognizes that these are closely related functions whose standards should be designed together if the full power of the approach is to be realized. I was a little late in subscribing to this list, so I'm sure I missed some interesting discussion. (I'll catch up through the archive.) But if it hasn't been mentioned already, the hierarchical representation of both configuration and dynamic data within EMS and NMS is better mated to the hierarchical representation of the data within the network element than the flattened SMI model. Management paths that do not do this flattening will be simpler, more robust, and more powerful. This holds for the dynamic polled and asynchronous-message acquired data as well as for configuration data. Using two different protocols for management adds other complications as well, such as the need to administer security (daemons, keys, firewall protocols, . . . ) twice (when once is bad enough!) Our system, by the way, also employs XML-expressed transactions for computational services. The need goes beyond just access to state. While I don't suggest that we broaden the charter, we ought to be aware of the need to accommodate transactions that are not related to configuration or to acquisition of dynamic state. On the name-mapping issue: I believe that we will do good if we accommodate name-mapping from SNMP mibs in some useful way. In fact, I have had experience with management systems in which (symbolic) SNMP object names have been adopted within the internal object trees that represent the managed systems. I expect this is not uncommon and would like to hear from others who have seen this done.I think there are several approaches one could take here: 1. Provide a mechanism to associate SNMP OIDs with XML-based configuration data. Like you, I have seen this approach. This preserves the SNMP infrastructure but has the disadvantages of then requiring two infrastructures, SNMP and the XML-based one. It also suffers from problem of mapping between the two, always less efficient. 2. Leave the problem for later. If this is done, it will probably never be solved. 3. Recognize now the need for a common name space for management and use XML for everything. I like a common infrastructure for everything approach. Some do not for legitimate reasons. The management area needs to pick a strategy and go with it. If it is XML fine, just do the whole task not a part. /jonLarry Menten Jon Saperia wrote:Glenn, I have mostly been watching this discussion. I wanted to empahsize how important your comments are from the perspective of building a management application. The name space problem is a critical problem. If there is to be a new standard way to configure systems based on XML, fine. To omit from the basic design of that standard, issues to deal with all the things we expect from SNMP like asynchronous messaging and data collection, would be a big mistake. /jon On Monday 23 September 2002 11:40 am, Glenn Waters wrote:-----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Friday, September 20, 2002 17:34 To: Remco van de Meent Cc: xmlconf@ops.ietf.org Subject: Re: XML versus SOAP/WSDL Performance[...]I was one of the people who brought up SNMP and monitoring at the xmlconf bof... I think the most important point here is that we have a standard mechanism to convert SNMP data naming to XML, so an application can correlate XML and SNMP data. The ability to use XML for monitoring is much less important. I would expect that applications would use XML monitoring for a small amount of data, and continue to use SNMP monitoring for large, or frequently polled, monitoring tasks. AndyAndy, I think that we mostly agree although I think that the ability to monitor using XML is very important. I believe that XML should be available to configure, retrieve status, and retrieve statistics. The reason that I believe this so strongly is that configuration is tied to status/statistics and that more than one protocol to tie the two areas together is problematic. It is problematic since there are almost always fundamental problems mapping between two naming models. The amount of code and complexity that is required to map between naming models is non-trivial. By example, let's say that a routing table entry is configured. One of the first things that an application may want to do after configuring the entry is to check the status of the routing table entry. This means retrieving the status and potentially some statistics. I can't imagine that a management application would want to configure the entry one way then switch to another protocol and naming model to get the statistics. That would just be broken. Cheers, /gww