On (01/13/09 03:10), Darren Reed wrote: > One of your comments in the document is whether or not the > link flags should be delegated to dladm - I'd vote yes. It presents > both architectural neatness as well as administrative simplicity > (you're not looking in IP settings to change link layer stuff.)
Ok. That was my feeling as well. > And similarly, consider that IPMP things should be left to the > ipmp tools? Yes, that was something that crossed my mind too. However, if we are going to allow some of these settings from ipadm (e.g., the nofailover flag), then in the interest of being symmetric, it would be nice to have some basic information displayed in the corresponding ipadm show-* sub-command. > With respect to the API, one thing that concerns me is > if you wish to map "ipadm foo-bar" to ipadm_foo_bar()", > how do you handle options that are optional, especially > if/when new ones are added? The hope is that the set of sub-commands would be as complete as possible for a specific feature (e.g., for type=foo, we should have a reasonably comprehensive list of sub-commands for the "foo" feature). However, if the list of sub-commands grows, and the ipadm_foo_bar() interface has been published as Stable, then we'd have to add new options by using version numbers and passing TLV data with ipadm_foo_bar() calls. > What sort of administrative interface is being planned to > manage the IPv6 scope? Can you clarify what exactly you have in mind here? In general, we follow the ietf standards/informational rfc's here but perhaps you have something specific in mind? > And I'd back Alan Maguire's call for a "-t"... the libipadm needs to > support this anyway, in order to properly provide stubs for ifconfig > (which does nothing in a persistent fashion.) but is this non-persistent usage actually useful? One can simulate the same thing by doing a 'ipadm delete-interface' at any point. One solution is to mandate that all options on a targetted interface-object must be either all-persistent or all-temporary, so that the mix-and-match of "-t" will return an error. > To be more nitpicky, section 2.6.2 doesn't seem very self consistent... > > When displaying the properties, I think you've got two different sets of > properties to consider. The first is those that have been applied to > interfaces > that are currently configured. The second is the set of properties that are > to be applied to interfaces that are at some point in time configured. > I think the first set are your properties and the second set are your plumb > time configuration parameters. good point. dladm handles this by using the -P flag (for showing persistent information only). I'll make a note. > > It may even be appropriate to break up your properties into two groups > below that: those that are related to IP intefaces and those that are > related to the protocols themselves. For example, what does it mean > to use ipadm to set tcp_smallest_anon_port for bge0? Or are there > plans to make properties such as these per-IP interface too? The eventual goal is to make every property applicable per interface, returning some appropriate error when the combination is not meaningful (e.g., set-prop tcp_smallest_anon_port on bge0). > I don't think the first paragraph of 5.2 makes a lot of sense. What you're > really running into is the confusion between IP interface names and data > link names. Having a type for each won't fix the confusion, which is The idea is not so much to fix the confusion but to make the distinction explicit so that a caller to libipadm can have some way of keeping them separate. I'll see if I can come up with a better example for this. --Sowmini
