I’d add a distinct point on that as corollary #7 suggest “safe mode” beeing strongly linked with rule #7 what is IMHO not good as it should be a general advice.
However it’s your list so you decide 
@anav where was the reasoning for this? Anyway, I have a reason for this proposal. More on it later.
I’d add a distinct point on that as corollary #7 suggest “safe mode” beeing strongly linked with rule #7 what is IMHO not good as it should be a general advice.
However it’s your list so you decide >
I am a bit dubious on this one, the present Rules are (in my perverted mind) recommendations to avoid common errors, not suggestions on how to make anyway the errors and get away with them.
In the context of not locking oneself out it makes sense to mention that changes are immediate as a further warning, in the more general way Safe Mode belongs IMHO to the other GP and CSA list.
EDIT: Added in http://forum.mikrotik.com/t/gp-csa-for-mikrotik-devices/182176/1 as point #20 with (hopefully) a balanced view between the two extremes.
As Forest Gump’s Mommy might say:
Forest, if you have safety belts built-in then use them even if they cannot be fully trusted and used as a panacea for everything.
She was very clever Mum
On 7) don’t get locked out. RoMON is a great tool , and MAC Telnet is another good one, if you ever change a remote IP network,
(Maybe not for everyone. Just my experience)
True, but for snapshot and quick return point it’s excellent. I haven’t tried in years, but IIRC textual export was not guaranteed to restore correctly as lines in it were not ordered by dependencies.
Restoring to the different device is a topic of Rule15: if restoring to the different hardware 1) create textual export on old device 2) study block diagram of a new device 3) modify old textual export to fit the new device 4) reset new device without config, connect using MAC and apply your new configuration.
There won’t be any rule 0, 13, 14 or 15, the twelve rules are 12, numbered from 1 to 12.
GP and CSA list items #17 and #18, JFYI:
http://forum.mikrotik.com/t/gp-csa-for-mikrotik-devices/182176/1
You will have to ask the originator, Patrick who Posted the Entry, mine was only a +1, LOL. The reason I gave it a +1 is the amount of time
I spend deleting default config remarks from many responses… From looking at many configs, its clear that those that dont understand RoS dont understand the comments either, so they really dont help much.
I have written in the past NOT to remove the admin user, but to leave it there harmless, without right, with a random very long password.
Now that the CVE is public, you can learn the reasons. In the past I refused to explain why, now you know why.
Off topic discussion is there: https://forum.mikrotik.com/viewtopic.php?t=215057
The requested topic does not exist.
…adn now is there 
http://forum.mikrotik.com/t/cve-2024-54772-information-about/181947/1
was consolidated on a previous related topic already addressed it
According to:
(6) Is there any procedure suggested how to choose that MAC? The lowest interface MAC, the highest? Private? Multi- or unicast? https://www.shiksha.com/online-courses/articles/mac-address-format-and-types/
(8) I’d mention that not all devices after reset have default firewall installed&ready. Existance of firewall rules should be always checked&verified as some could reset/netinstall device with no default configuration.
@BartoszP
#6 There are a few posts by mkx and rextended that go rather deep on the matter, I’ll see if I can understand the written or non-written implications and produce something easy to understand and replicate.
http://forum.mikrotik.com/t/new-mac-address-on-the-bridge-after-the-update/177812/1
http://forum.mikrotik.com/t/script-for-setting-locally-administered-mac-address-on-bridges/177344/1
#8 working on it 
As not only Wiki says that
Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA).
To define LAA MAC the U/L bit of the first octet (bit 1 ) has to be set to 1.
To define Unicast packet the I/G bit of the first octet (bit 0) has to be set to 0 - we need unicast as we expect one-to-one communication with the bridge be possible.
Therefore the first octet should be formatted as ( b=0|1):
bbbbbb10
that gives us 4 posiible types of MAC groups
x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx
I prefer using EE as the first octet as it clearly shows that MAC address is “unusual” however it’s only a matter of “visual taste”. Any other combination is also good.
EDIT:
It should be considered if the “highest” ‘EE’ octet should be used or the “lowest” ‘02’ as if STP comes into play then it has to be chosen properly
if STP comes into play, then one really should set bridge priorities according to topology. One never knows when some “genious” will set MAC 01:00:00:00:00:00 to his bridge while bridge ports are set to default value of edge=auto.
[11] You don’t behave as a jerk on the forum.
- “Google is your friend: search before posting.”
- “Use code tags around configuration and commands.”
- “Mark a topic as ‘solved’ when the original question has been answered.”
“If you ask LLM for help then be consistent asking it untill you solve the problem. Do not ask forum users to correct LLM.”
…
I don’t know 
, these seem to me more like “use some common sense [1]”, I had in mind something more along the lines of “be polite, don’t be senselessly argumentative, respect other members and their ideas, etc.”
What you suggest is more along the lines of the classic:
http://www.catb.org/esr/faqs/smart-questions.html
[1] one of the less common things around, usually