Hi Rainer, > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > I see the argument. Do you think that relying on something already > accepted - like BEEP XML in RFC3080 is a solution? As far as > I can see, > RFC3080 is increasingly becoming implemented. So while not > full XML, it > may be a standard that works "as expected"? >
OK, you're dragging me kicking and screaming into this discussion. ;-) BEEP ... Difficult problem. Is this existing technology to leverage or not? As a CTO architect for a major equipment vendor, I have concerns about whether BEEP is being accepted by the industry. I am not yet recommending that my company implement it in our devices because I am not seeing customer demand for it, competitive pressures for it, engineers' excitement about this new technology, or adoption by other standards bodies. I am not yet seeing it implemented in the devices of major equipment vendors. I suspect that means other companies are also not seeing customer demand for BEEP. Since BEEP is really an engineering infrastructural element rather than a customer feature, that's to be somewhat expected, but I suspect other companies are also not seeing engineering demand for BEEP. Among IETF protocol designers, there is fairly strong promotion and acceptance of BEEP, and a number of WGs are building upon it. Personally, as a protocol designer myself, I think BEEP is lightweight and serves valuable purposes, especially the ability to simplify leveraging existing protocols. A few WGs have chosen to build upon BEEP, but I haven't seen demand for the protocols built upon BEEP either, and I suspect part of that is the dependency on the BEEP protocol which isn't currently available in the devices. Adopting these new protocols involves implementing not just one unproven technology; it requires implementing two unproven technologies. I haven't seen IDWG widely accepted in the IDS market; I haven't seen vendors building the BEEP-dependent syslog proposals. NetConf is still debating the same issue of whether BEEP has yet been adopted widely, and is planning to ask the operators at NANOG next month whether they want the features of BEEP in the Netconf solution. http://www.ietf.org/IESG/implementation.html shows no implementation reports for BEEP, IDWG, syslog-reliable, etc. I've checked the beepcore and roadrunner BEEP implementation web sites, and searched the web with Google, and I turn up a few open source applications, but I don't see major software or hardware vendors represented. As the NETCONF work shows, the trend is moving toward acceptance of XML and toward Web Services. BEEP may not go far enough to compete with, and interoperate with, the likes of protocols supported in web services such as SOAP. Part of the issue is, if the goal is leveraging existing protocols and interoperability between protocols, and if web services already promises these benefits, then does BEEP offer too little to justify adding it to the protocols supported on devices, if we might want to support more full-fledged protocols for web services? I think the industry has not decided it wants to go all the way to web services level integration yet, has decided it wants something better than a free-for-all, but isn't convinced that moving to BEEP is the right answer. Whether a proposed standard really becomes a standard is far more dependent on whether the industry accepts it than on what the IETF says. I recommend the WG look closely to see whether BEEP is really being accepted by the industry, or just by other WGs within the IETF, before making a decision to build a dependency on BEEP or to emulate the XML-subset design of BEEP. I would love to see some solid information to show that major vendors are implementing BEEP before I see this (or any other) WG create dependencies on it. dbh
