Can you tell us what you have in mind?
we have these 2 half-solutions for saving the configuration, but together they don't add up to a solid one.
backup cannot be transferred among different device families, and it is not editable. more or less that's just a file archive of the ROS internal filesystem - or this is what it looks like.
export is great cause it is textual, it will not grow significantly bigger - opposed to the backup files - and is editable.
but it doesn't contain several things:
- router user credentials - which was understandable until ROS finally dropped the old password scheme and switched to password hashes.
- user public and private ssh-keys - no way to save them unless you do the 'backup'
- certificates - i always tell my students that export is just a collection of commands that can be used to re-create a specific part of the configuration. certificate generation is a bit different, because if you execute the generation command, it will (obviously) produce a different certificate each time. so you can't just include the cert generation command in the export file.
- ssh keys - you can - similarly to certificate export and import host keys, but they're not part of the configuration which makes things difficult. and if anyone want's to play safe, a semi-static hostkey is one of the building blocks to it.
i know, system reset-configuration keep-users "helps" a bit, but basically you cannot use /export to recreate the configuration properly.
just take for example any subsystem that relies on certificates. it is contained in the /export output, but importing it fails, as the referenced certificates don't exist. even if you manually export / re-import the certs, they are created under an auto-generated name, so without manual intervention, importing the config will still fail.
i'd like to have a configuration file that is editable and has all the bells and whistles as the 'binary backup file'. i usually parse the export files and break them down into config objects in my repository. for this thing to work properly, all config data is needed, and the output of the current /export is lacking of quite some.
the other points, like the symmetric encryption of non-management user password entries is just there so an external audit cannot brag about storing cleartext passwords.
the mac address thing is just annoying: you do a verbose export just to see the default settings, and if you copy it over as is to another device, you'll start having multiple routers with the same mac address, and this ain't no fun. doing it manually is certainly possible, i wrote some code to handle this, but wouldn't be easier to export the data in a more senseful way? like only including the mac address field if it is different from the 'orig-mac-address' value?