Anton, you have some very good points in your posting. When David suggested it, I had the impression that it is useful and may even help with the syslog-mib effort. I am still a bit positive in respect to the enterprise ID.
As you probably have seen, I have just put very limited text into -protocol-02 re the enterprise ID. I would really appreciate some votes on the mailing list on wheter or not we should continue with this. > I am relatively neutral to this idea. But I am trying to > understand how > it will be used. What are the anticipated use cases for it? What appealed me was that there is at least a minimum way to identify the orginator. In our log parsers, knowing this would often come very handy. > If we want to use it to differentiate messages from a specific vendor > because it may provide some additional formatting, then one could also > argue that we also need vendor version and potentially vendor product > and on and on. Yes, this is right. But I would expect that the vendor should provide a kind of its own indication of this - maybe with an optional structured data element. > > If we do provide enterprise ID, does it have to be required and in the > header as opposed to structured content? Is filtering on vendor going > to be a common use-case? Good point. Maybe structured content does the trick. The enterprise ID has the advantage that you know it is there, it is compact (message size) and it is within already defined bounds, which probably eases interoprability to other systems (SNMP, eventually NETCONF - I like to reuse prooven technology if there is no really good argument against it). > One area of ambiguity, I think, is a situation where components are > integrated into other applications. Say component X from one > company is > integrated into product Y of another company. Component X > already does > -protocol compliant syslog logging. Which enterprise ID should it use? > Should we leave this as nondeterministic or provide recommendations? Another good point. But I think this is mostly a commercial issue. OEM agreements may force you to use a different vendor ID. I think this is hard to address in an RFC. I would live with that and believe that there will some sites appear that say "vendor ids x, y and z" are actually the same" (as with devices using ZyNos). > Another area of potential ambiguity is relaying. Suppose a > relay gets a > bad message from a Cisco device and needs to fire a diagnostic error > message. Does it use its own enterprise ID for this? If so, my > collector which catches messages only for vendor Cisco won't > catch this, > right? This must go into (obviously to be written) relay rules. My first idea is that if it is a malformed question, we should flag it as "don't know" vendor. I am not sure if 0 would be appropriate, if there is already such a vendor ID defined and if not if it would be within the scope of vendor IDs to request IANA with the assignment of a "syslog I don't know the vendor or don't care" ID. Maybe David has a comment on this ;) Rainer
