Hello Meem, Thanks for your comments. Some of your questions on show-address and show-interface will be answered by Vasumathi. Please see in-line
> Some high-level comments: > > * As we discussed in another thread last week, it would be a real shame > to let the current "interface duality" survive the ipadm transition. > That is, right now ifconfig has a notion of separate IPv4 and IPv6 > interfaces that have identical names. I believe this is the wrong > model. Instead, there should be one administrative IP interface > object which can have any number of IPv4 and IPv6 addresses. For this > to work without having a ripple effect, I think you'd need to then > make the logical index field be a tuple of the address family and type > (e.g., v4:2 and v6:2 would be distinct logicals). > Today we already have the facility of representing an interface using two tuples. "-f <inet|inet6> -l <logical num>". We can possibly extend this to achieve what you are saying. > * For dladm, we generally chose to abbreviate subcommand names - e.g., > we have add-aggr, not add-aggregation. I think we should do the same > thing here -- e.g., address -> addr, interface -> if > Sure thing will update the document. > Some low-level comments (not exhaustive): > > * Not sure why "ipmp" is an interface sub-option. The model I'd expect > is that every IP interface has a "class", just like every datalink > has a class. There are at least two classes (ipmp and "normal") and > there may be more depending on how we want to model things (e.g., > other things that "act different" include point-to-point, tunnels, > loopback and vni). > In the case of 'dladm' every sub-command which created the data-link determined the class of the datalink, i.e. create-vnic meant DATALINK_CLASS_VNIC, create-vlan meant DATALINK_CLASS_VLAN, et al. But in ipadm you have one subcommand 'create-interface' to create all interfaces. Now how do we specify the class here? Do we want a command option to specify the class? Also isn't this implementation specific stuff which we would be exposing to Users. > * The "group" suboption absolutely must not be mandatory, and probably > shouldn't exist at all. (Backstory: the group name should be the > same as the interface name from Clearview IPMP onwards; cases where > they're different are historical.) > OK. Will update the document. > * Not sure why tunnel src/dst are specified specially. If these are > the outer IP addresses, why are they not handled by add-addr? If > these are the inner IP addresses, why are they here at all given > dladm *-iptun? > True and it will be removed. > * Seems to be a bunch of stuff glommed into the ADDRTYPE field, like > ipmp-* and iptun-*. This really doesn't belong. > > * There's a lot of information missing from the show-address view that > can matter (IFF_TEMPORARY, IFF_PREFERRED, IFF_DEPRECATED, ...) but > that isn't displayed. > > * Some thought needs to be put into the property names. For instance, > the document has both ip_ttl and ip_def_ttl but really the "ip_" is > totally unnecessary given the context of the command. Further, given > that the general syntax for ipadm uses dashes I'd encourage us to use > dashes here too (yes, mistakes were made in this regard with dladm; > we're looking to fix those). > Sure. Given that for ipadm subcommands set-prop & show-prop, expect '-m <proto_module>' we can clearly get rid of prefixes ip_ or tcp_ or udp_ . Also we will have to think of better names for properties which give away internal names like 'ire' in ip_ire_pathmtu_interval or ip_ire_redirect_interval. yes we will use dashes instead of underscores. thanks ~Girish
