Hi Chris, thanks for the housekeeping call ;) I agree, we should first finish what is *now* on the agenda.
Just an important note: the discussion below was initiated by me using the SNMP mapping as an example. The initial question I rose was if a syslog relay (only taling syslog ;)) should be allowed to use multi-part messaging IF the received message is larger than the MTU of the target network. So the original discussion was not about SNMP/syslog, but about straight syslog. I would like to mention this to keep the thread on focus, instead of killing it. So far, Anton commented that a syslog relay should use multi-part messaging if there is no other way to transmit a syslog message to another syslog server. I, too, feel that this is the right way to handle the situation. If somebody does not like this idea, I would appreciate comments. Thanks, Rainer > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 17, 2004 3:21 PM > To: Rainer Gerhards > Cc: Harrington, David; [EMAIL PROTECTED] > Subject: RE: -procotol relay operations > > Hi, > > Just a side-note: I don't mind having the discussion about this on the > list but the concept is outside the current scope of our work. After > we get the current pieces of work submitted to the RFC editor, then we > can discuss if we want to formally address this (with the blessings of > the O&M ADs). > > The concept does apply to Glenn's ID but I believe that he is > asking if > the community feels that _any_ SNMP notification should be sent if > something goes wrong with sending a syslog message. Defining > a syslog to > SNMP gateway is out of scope for his work at this time as well. > > Thanks, > Chris > > On Tue, 17 Feb 2004, Rainer Gerhards wrote: > > > Hi David, > > > > I think we are probably talking about two different things here. > > > > Let me start with this: > > > > > One protocol does not travel within the other; they are > > > independent protocols. > > > > Honestly, I think there was something different being > discussed on this list, and I used this as a sample. I am > primarily refering to this thread here: > http://www.syslog.cc/ietf/autoarc/msg00992.html > > > > Let me sum it up as *I* understand it: > > > > There is some concensus that it is helpful to allow a > syslog message to be feed to an SNMP based system. To do so, > there should be a mapping between a syslog message and an > SNMP trap (or inform?) message. I think the quoted thread was > about this. > > > > So what I see is the following picture: > > > > Device --> syslog relay/gateway --> SNMP > > > > As written, the syslog relay is no less a simple relay but > more an application level gateway between syslog protocol and > SNMP protocol. It must encapsulate/map the syslog message to SNMP. > > > > In general, this is relatively straightforward. Move the > syslog MSG to the SNMP message equivalent and copy some of > the header fields (like timestamp) to the SNMP properties. > > > > It becomes complicated, if the syslog message is of large > size (e.g. 1024 byte) and the SNMP implementation only > supplies message text up to 512 bytes (due to MTU > restrictions). Please note that the numbers are randomly > taken - actual values may be different but I wanted to save > some time on an exact research. I think the provided random > numbers give a good-enough idea. > > > > Now we have the issue that the syslog2SNMP gateway can not > forward the full message via SNMP, simply because the message > text does not fit. > > > > So it has these choices: > > > > - discard message at all (if it can't deliver it > completely, it does deliver nothing) > > - discard the 512 octets at the end that do not fit. These are LOST > > - use syslog multi-part messages and create 3 SNMP messages > > (why three? Syslog multi-part messaging takes some extra > space, so the > > overall message size becomes larger than 1024.) > > > > This is the model I have in mind. Now to the answers: > > > > > > > Assuming you use snmpv3 with e2e encryption, the relay > > > wouldn't be able > > > to access the message contents to fragment it. An SNMP > message should > > > never be fragmented anyway, so using snmp for the example is a bad > > > choice. > > > > The SNMP message will not get "fragmented". It is syslog > multi-part messaging, that is applied to the syslog part of > the gateway, only. SNMP syntax and semantic will not be touched. > > > > > You should definitely not think of snmp as just some type of > > > transport; > > > it is a network management protocol at the same level as > syslog. You > > > shouldn't talk about sending snmp over syslog, and you > shouldn't talk > > > about sending syslog over snmp. SNMP is a parallel NM protocol for > > > specific types of management communications, such as > notifications, so > > > syslog doesn't need to reinvent that wheel. > > > > Well, actually I find some value in the ability to > integrate syslog message into an SNMP solution. I think we > all know this is probably not the best way to do it, but it > may be very handy if the syslog-talking device in question > does not at all support SNMP... > > > > I think that was the spirit behind the quoted discussion > thread above. > > > > > It would be good if the > > > format selected for content in the syslog protocol could be reused > > > easily in the parallel SNMP protocol. > > > > I think the format is far different. The header fields and > some other structured elements will probably be be able to be > mapped to SNMP. But I think it is a mapping (gateway level), > not a pure resue. > > > > And keep in mind, I am *ONLY* talking about syslog-type > message being sent as TRAPS. I am NOT talking about MIB > GET/SET requests. > > > > > The idea of a syslog relay fragmenting an snmp > notification is just > > > wrong. > > > > I agree ... and a syslog relay will never fragment a SNMP > message, because it does not know SNMP at this level. What I > could forsee, however, is: > > > > SNMP Trap --> SNMP/syslog Gateway --> syslog server > > > > In this case, the same semantics as in my first example > would need to apply. If I take the SNMP trap message AND its > size is larger than what is supported in the syslog system, > then the SNMP to syslog Gateway has the same choices. If I > had to implement the gatway, I would probably use syslog > multi-part messaging to transmit the whole message. > > > > > One protocol does not travel within the other; they are > > > independent protocols. > > > > >From a high-level point of view, I would find it desirable > to have rules that would allow to travel syslog data over an > SNMP tunnel and SNMP messages to travel over a syslog tunnel. > In this case, if the sender AND receiver is both syslog (or > both SNMP), I would assume that the message should be > received as a native, unalterated message on the receiver. I > think, however, that this goal is not worth putting big > effort into achieving this. But I don't see anything bad to > at least keep it in mind. > > > > I don't see any bad per sé in allowing one protocol to > travel inside another as long as this does not force any > degradation in either of the protocols. > > > > Rainer > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, February 13, 2004 12:55 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: -procotol relay operations > > > > > > > > Hi WG, > > > > > > > > we talked quite a bit about different MTUs for > different transport > > > > mapping. We may run into a situation where a message is > > > larger than is > > > > actually supported by the transport (e.g a hypothetical > SNMP trap > > > > transport supporting only ~500 octets). As we have multi-part > > > > message in > > > > -protocol, a relay COULD create a multi-part message at this > > > > time. This > > > > could be an elegant solution to the minimum size problem, > > > too. You can > > > > directly compare it it IP fragmentation. > > > > > > > > Question now: Is there any objection against specifying it in > > > > that way, > > > > at least as a MAY rule for relays. I think it definitely has > > > > advantages > > > > - it allows us to care for the unsual cases... > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
