Hi, 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.
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. It would be good if the format selected for content in the syslog protocol could be reused easily in the parallel SNMP protocol. The idea of a syslog relay fragmenting an snmp notification is just wrong. One protocol does not travel within the other; they are independent protocols. 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 > > >
