The latest stable RouterOS v6.49 adds the ability to configure the SNMPv3 EngineID, as defined in RFC3411, especially Section 5, Page 41,42.
RouterOS enforces an EngineID prefix of "80 00 3A 8C 04", which translates as:
80 - top-bit == 1 == as defined in RFC3411
00 00 3A 8C == 14988 decimal == MikroTik Enterprise ID.
04 == Text.
The default EngineID suffix is an empty string, and hence the full default EngineID is the 5-Byte Hex String "80 00 3A 8C 04".
Prior to v6.49, it seems that the EngineID was always this fixed "80 00 3A 8C 04" Hex String.
The problem is that without explicit configuration, every MikroTik ends up with the same EngineID, which effectively violates the uniqueness referenced in RFC3411 Para 3.1.1.1:
3.1.1.1. snmpEngineID
Within an administrative domain, an snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-to-
one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within that
administrative domain. Note that it is possible for SNMP entities in
different administrative domains to have the same value for
snmpEngineID. Federation of administrative domains may necessitate
assignment of new values.
As it happens, the commonly used net-snmp library maintains a cache mapping of EngineID -> EngineBoots/EngineTime indexed purely on EngineID as far as I can tell.
This leads to a problem if two devices uses the same EngineID, but have different EngineBoots/EngineTime values, or even different SNMPv3 authentication parameters; SNMPv3
authentication breaks under certain conditions.
The common solution to this problem, as witnessed on numerous Cisco or Juniper devices, is to use EngineID "type" 3, which is the MAC address of the lowest interface on the device.
Even here the RFC is ambiguous; it says "lowest IEEE MAC address, canonical order" rather than more explicitly "IEEE MAC address of lowest interface, canonical order",
which is what Cisco/Juniper appear to adhere to. Despite this, we've seen issues on Juniper clusters where both halves of the cluster have the same MAC address on the lowest interface,
but the two halves of the cluster are in reality two different SNMP entities.
I believe RedHat, presumably using the method embedded in the net-snmp library, take a different approach with the SNMP agents on their machines, initialising the EngineID to a pseudo-random number at boot. Other manufacturers' methodology may vary.
The existing RouterOS EngineID is of "type" 4, which is a text field; changing that to "type" 3 is probably too radical. My suggestion is that where the EngineID is NOT explicitly configured, that the actual EngineID-suffix used by the SNMP engine be auto-configured to be either the text-string of the Serial No. of the device or the MAC address of the lowest physical interface.
My personal preference is for the Serial No., but I'm not vehemently wedded to this.
In either case, under these circumstances, dumping the device configuration should NOT display a configured EngineID. This allows for copy/pasting a device configuration from one device to another without the risk of creating two devices with the same EngineID.