Avoid potential issues with arbitrary non-endpoint-specific sysctls being set per-endpoint (for example, enabling or disabling IPv6 for the whole container using net.ipv6.conf.all.disable_ipv6 would be difficult to deal with).

This is the part where things may become fuzzy. ISTR we either have a hard-coded list of sysctls that were known to be namespaced (net.xxx being one of them), but this was already a blurry line (as some of them depended on kernel version), so not 100% sure if we indeed codified that constrained, or only documented it. I don't have a good answer here though; ideally we wouldn't have to make assumptions (things may change!), but at the same time there could be value in providing useful feedback to the user (this may not result in what you expect it to result in!).

This is the part where things may become fuzzy. ISTR we either have a hard-coded list of sysctls that were known to be namespaced (net.xxx being one of them),

Ah - yes ... https://docs.docker.com/reference/cli/docker/container/run/#sysctl - so, I guess we're safe in terms of namespacing if we limit the new options to net..

Beyond that, and checking the setting is interface-specific - at some later point we may decide to error on settings that definitely break things for a particular driver ... but that's about making the footgun hard to aim, we probably can't remove it completely because we won't know the user's intent.

If we find we need to allow access to more than just net.*.*.<ifname>, we can do that in future - as @corhere pointed out, that's much easier than trying to add restrictions once we've allowed more access than we should.

So, I'd probably leave it at that - rather than try to build in setting-specific warnings which, as you say, will be a moving target?

Existing network drivers only create a single interface, if a future driver creates more than one we'll need to extend the syntax of the new sysctl options.

I think the best UX for such hypothetical driver would be a mechanism that allows to name each iface independently. Then, sysctls would have to be specified with the name component set.

If we want to make sure we can support this in the future, then I think it's best to: 1. keep the name component in the sysctl (no discoverability issue) ; 2. require users to name their interfaces when they want to use net. sysctls. Since that ifname parameter would be new, we can easily forbid all and default to be used. We might need to forbid ethX too. (And I'm even wondering whether this new ifname could be used to make ordering more predictable and container-local.)

One downside with this, we're moving the "multi-iface" problem from the sysctl parameter to the ifname parameter. For such hypothetical driver, I think ifname would be labeled and those labels would be opaque to everything but the driver (eg. --network=name=testnet,driver=hypothetical,ifname=ns=...,ifname=ew=...).

So, I'd probably leave it at that - rather than try to build in setting-specific warnings which, as you say, will be a moving target?

Yes, it's the "moving target" that may be problematic. If these are things we can say for sure (guaranteed) to be non-functional, we could error, but if not, maybe a warning (at best?). And even there, there's a bit of a risk of it becoming a sliding-slope if it means we need to continue codifying too much knowledge about Linux and sysctls (based on assumptions we can currently make).

That said; providing a useful warning to the user also has a place so "win some", "loose some" I guess.

I think the best UX for such hypothetical driver would be a mechanism that allows to name each iface independently. Then, sysctls would have to be specified with the name component set.

Being able to name interfaces in the container might be a good feature - but it'd be nice to keep it separate from this change. Tying the two together for the sake of hypothetical driver might be wasted effort.

But, it's worth knowing we're not backing ourselves into a corner ... so, we'd need a way to refer to the hypothetical driver's interface roles. If the driver has interfaces with roles "ns" and "ew" (which could be instantiated as "eth0"/"eth1", "eth1"/"eth0", "ns0"/"ew0", or anything else if we add an 'ifname' option) - something like this would do the trick, and we'd be able extend the syntax to accommodate it later, if needed? ...
--network name=mynet,sysctl=ns:ipv6.conf.accept_ra=2,sysctl=ew:ipv6.conf.accept_ra=0

If these are things we can say for sure (guaranteed) to be non-functional, we could error, but if not, maybe a warning (at best?). And even there, there's a bit of a risk of it becoming a sliding-slope if it means we need to continue codifying too much knowledge about Linux and sysctls (based on assumptions we can currently make).

Indeed - as a starting point, I suggest we just steer clear. If we find people are getting themselves into trouble with any particular options, or there's a driver that will always break if a setting is modified but people modify it anyway ... we can add an error/warning at that point.

The sysctls will be applied by libnetwork when it moves the interface into the network namespace but, if we find we need a way for drivers to object to settings - we can pass the list of sysctls to the driver (as a generic param / label or whatever it's called) ... for the driver to inspect if it's interested, and raise an error if there's a problem.

Maybe netifsysctl would be a better name than sysctl for the new --network option? (Or similar, maybe netifctl to cut down on the typing?!)

But - something that describes its function a bit more accurately, makes it less surprising that the sysctl name is mangled (and to give us a bit of room for manoeuvre if we ever think of a reason to allow more than 'net....*', unlikely as that seems).