Ahh okay, here's the real "meat", yes these would be the real meat of the class :grinning: 

One thing relevant here that I also mentioned on @jzupka related RFC is adopting the CLI-centric parameter style really locks this high-level interface into low-level conventions and problems.  It means if we want high-level calls that work with the daemon's REST API, another translation-layer is needed.  Then if you have that, and the CLI or REST API changes, you end up always playing catch-up with them.

Instead, it may work better to write these interfaces so they're almost completely naive  when it comes to "how" underlying/low-level actions are taken.  One pattern I've used before (worked out well) was to come up with a class to represent the desired operational-qualities a.k.a parameters.  Then make these high-level methods just accept instances of that class as a parameter.  That allows the operational-parameter class to easily be extended, documented, and unattested while also helping to hide the underlying low-level details of "how" the higher-level methods behave "under the hood".

Make sense?