> So all of this is being unified now under the newly proposed > datalink.conf, right?
I would think so, except some security sensitive configuration (which is described int the design doc.) > It seems that there is an opportunity to use SMF > as part of introducing this unified data-link properties repository. Are > you expecting that this file will be used for new classes of data-links > coming down the road as well? > I hope so. > All of the above :-) > > There's of course the implementation aspect, where SMF can help manage > these properties. I.e. does it make sense to provide a new configuration > file and management library to capture the properties of data-links, > when SMF already provides similar capabilities through libscf(3LIB). > Other tools such as ksslcfg(1M) are already using SMF for this purpose. > But the value that this can bring to the rest of Solaris architecture in > the longer term is appealing as well. > I am fine to make SMF a repository of the *private* data-link configuration. But at this time, I don't expect to make each link is exposed as a service, and change the current dladm model to SMF administrative model to administer link configuration. > Clearview is clearly focusing on the usability aspects of network > interface management, and SMF is a big part of the management story of > Solaris, so I was hoping to see the view of the Clearview team on how > they see this evolving in the long term. > Clearview makes the network administrative model to be more uniform, and this clearly benefit any potential effort once it is clear what future management model would be. Thanks - Cathy