WG, this is another posting from the NETCONF WG which I also consider quite important for the syslog WG.
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Harrington > Sent: Tuesday, March 28, 2006 8:26 PM > To: 'Netconf (E-mail)' > Subject: Why are we doing netconf? > > Hi, > > I would like a better understasnding of why we are doing > notifications. I am struck by what appears to me to be two very > different drivers for netconf, and the "why are we doing > notifications?" question relates to these different motivations. > > I have suggested that the O&M and Security communities should work at > establishing a strategic vision about converging aspects of the > various NM protocols and NM security solutions. If this is a path > worth taking, it should be a deliberate decision to do so because > there are some real problems associated with a convergence approach. > > For this reason, I would like to understand what we are trying to > achieve with netconf and the current proposal for notifications, to > determine if the goals are compatible. > > If the purpose of netconf is to provide a machine-friendly, > standardized protocol to eliminate the need for screen scraping CLI > expect scripts, I am not convinced we need notifications in the > netconf protocol. I think the netconf WG has done a reasonably good > job of standardizing the operations, but to achieve the goals, we also > need to improve the parseability of the data that now needs to be > screen scraped. The parseability of the data contained in the > responses coming back must be addressed. If vendors simply take their > existing screens of data and surround them with <cli></cli> tags, then > I think we've failed to eliminate the screen-scraping problem, and > other problems identified by operators at the IAB NM workshop: > > - Some command line interfaces lack a common data model. It is > very > well possible that the same command on different devices, even > from the same vendor, behaves differently. > > - The command line interface is primarily targeted to humans which > can adapt to minor syntax and format changes easily. Using > command line interfaces as a programmatic interface is > troublesome > because of parsing complexities. > > - Command line interfaces often lack proper version control for > the > syntax and the semantics. It is therefore time consuming and > error prone to maintain programs or scripts that interface with > different versions of a command line interface. > > - Since command line interfaces are proprietary, they can not be > used efficiently to automate processes in an environment with a > heterogenous set of devices. > > - The access control facilities, if present at all, are often > ad-hoc > and sometimes insufficient. > > Netconf does not seem to resolve these operational disadvantages of > the CLI, and notifications aren't even mentioned as a problem to be > solved. > > If the purpose of netconf is to standardzie existing practice, and > existing practice is defined as screen scraping CLI expect scripts > plus syslog notifications, then I question whether we need to include > syslog notifications in netconf; syslog works well in its special > niche, and really doesn't need to be added to netconf. > > The Syslog (-security) WG has been working to standardize the message > header format. The syslog community has not reached consensus on the > need to standard message content, except to add a structured data > component. The WG had difficulty even reaching agreement on > standardizing their message header format beyond starting the message > with <PRI>. I do not believe that netconf would be more successful at > standardizing syslog content than the syslog community, so I do not > believe that standardizing syslog message content should be a > justification for adding notifications to netconf, without a long > discussion about the feasibility of accomplishing this goal. I think > the standardization of syslog belongs in a (O&M) syslog WG, not the > netconf WG (and not the syslog security WG). > > If the purpose of netconf is to assimilate the functionality of older > protocols like syslog and SNMP - to integrate them into a collective > netconf structure, and to eventually replace the old protocols with a > new general purpose management protocol minus the known problems, then > netconf has a higher bar to meet in its design requirements than have > been acknowledged. SNMPv3 is complex because it needed to deal with > security issues and troubleshooting requirements and other things; > syslog does not have a standard content format because there are a > wide number of vendors protecting their space, and the demand for > backwards compatibility to all or most existing header formats has > prevented progress in the syslog (security) WG. Faced with > requirements comparable to those faced by the older protocols during > their design, I expect netconf would fail to assimilate them properly. > Therefore, if the purpose of netconf is to be a general purpose NM > protocol, we need to have a serious discussion about the requirements > that must be met to achieve successful assimilation. > > I find the existing proposal has plans to assimilate other protocols - > "The purpose of this [syslog-to-netconf] mapping is to provide an > unambiguous mapping to enable consistent multi-protocol > implementations as well as to enable future migration." and to attempt > to standardize that which the syslog community has failed to > standardize - "The intent is to promote the use of the NETCONF > interface and not to simply provide a wrapper and additional delivery > mechanism for syslog messages. NETCONF events are intended to be well > defined and structured, therefore providing an advantage over the > unstructured and often times arbitrarily defined syslog messages (i.e. > the message field)." > > I am a strong supporter of judicious reuse of NM and security > solutions across NM interfaces, but I believe apparent convergence > opportunities need to be discussed and for each convergence we need > to consider the requirements met by each protocol and whether a > converged solution continues to meet those requirements or > deliberately does not meet some requirements. > > I am bothered by the fact that netconf, a configuration protocol, is > being redesigned in the current proposal to carry syslog messages that > may have nothing to do with configuration, and it is expected that > even more stuff, also possibly not related to configuration, will be > carried in a new event message format. Operators at the IAB Network > Management Workshop apparently did not find syslog sufficiently broken > to request that a new event messaging capability be designed, so I > have concerns that the current proposal includes a brand-new > notification solution. > > If netconf will become the new general purpose mgmt protocol for the > IETF, we should do this deliberately, not as a side-effect of adding a > notification operation to netconf. > > David Harrington > FutureWei Technologies, a Huawei company > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Romascanu, Dan > (Dan) > > Sent: Monday, March 27, 2006 5:20 AM > > To: Andy Bierman > > Cc: Netconf (E-mail) > > Subject: RE: Interim attendance survey > > > > [...] I am aware that this good shape is > > apparent, and there is little agreement on the problem space, and > too > > little review of the draft that includes a proposed solution even to > > determine the level of agreement. I would encourage the WG to focus > on > > discussing the problem space (why are we doing notifications?) and > the > > draft and other options for solutions more intensively on the > > list. Let > > us see in the next couple of weeks if we can reach more convergence > on > > the 'why' and 'how' questions. > > > > If we do have contributions about the scope and reviews of > > the draft and > > solutions on the list we have a chance to better converge and reach > > agreement. If the level of apathy stays the same, I am not sure that > a > > partially attended interim meeting would help. > > > > > > > > -- > to unsubscribe send a message to [EMAIL PROTECTED] with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/netconf/> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
