Reposting, since my attempts to post this yesterday never showed up: There have been a lot of discussions about having per-interface tunables for many of the IP properties, and the frequently raised question is, "seems like these would be more appopriate as a tunable-per-interface. Why isn't this so?"
The ipadm/libipadm interfaces are being constructed with the ability to set tunables per interface. But thinking over the issue of ndd compatibility in the face of per-interface props: the issue is that if we have a per-interface version of some prop (e.g., ip_icmp_err_interval or ip_send_redirects) whose value is different for different interfaces on the system, then what should '/sbin/ndd -get' print for that prop? So we are faced with doing one of the following: 1. remove the support from ndd and support it only in ipadm, essentially zero compatibilty. 2. change the output of 'ndd -get /dev/ip <prop>'- instead of printing a single int, it will have to print something like (<intf>, <value>) pairs. Both #1 and #2 would break existing scripts that made assumptions about ndd output. In both cases we'd have to send out EOL notices, etc. about the change, if needed 3. provide per-interface prop support in ipadm and leave the "global" setting alone (In addition to complicating our kernel tremendously, I don't even see how this would work. E.g. if the "prop" is some thing like a rate-limit parameter, and the value is different for each interface, then what would the global value be?) 4. dont provide per-interface props in ipadm when the prop is already there in ndd (not a good solution- this makes ndd Stable through some sort of ugly Common Law). Only new props can be tuned per interface. None of these options is ideal, but #2 seems to make the best of a bad-deal. Thoughts? --Sowmini
