> > > While it could be considered, I think it would be too risky a change
 > > > even for a Minor release, and maybe even for a Major release.  I don't
 > > > think it would be acceptable to require 3rd party software to be
 > > > modified to undo unwanted persistent configuration.
 > > 
 > > Or we could disallow the mix/match of ifconfig and ipadm.
 > > ifconfig would only be able to do temporary changes, and ipadm only
 > > does the persistent ones.
 > 
 > Sure, but my supposition was that we were building a system in which
 > ifconfig becomes obsolete.  Is that not the case?

If we're not, I think we've failed.  ifconfig is fine as a backward
compatibility tool, but it's simply too broken to be anything more.

 > > Or we could just have all ipadm/ifconifg operations on 
 > > interfaces  to be temporary (only the interface-agnostic operations 
 > > on the tcp/ip module itself would be persistent), and 
 > > implement one single method for persistence thorugh libnwamd.
 > 
 > That's an interestingly different tack on the problem.  I'm not sure how
 > NWAM fits in with this yet, but I had assumed that NWAM was a consumer
 > of the interfaces provided by this project.

My expectation was that NWAM would indeed use libipadm and that
dladm/ipadm would apply changes to the current NWAM profile, and
perhaps dladm/ipadm would have options to apply changes to an
alternate NWAM profile.

-- 
meem

Reply via email to