> Attached is the 2nd draft of SMF service model for NWAM, thanks to John > Beck's review and the discussion with David Bustos and JBeck. It also > combines the feedback we received from the 1st draft. > > I'd appreciate any comments by COB next Wednesday (9/27). > > Thanks > > -Jan
I'm travelling right now so I can't have the full conversation over e-mail for another two weeks, but here's my major comment: > NWAM will try to obsolete hostname.<if> interfaces. Given that these > interfaces are very well-known and generally used by our customers as > write-to, instead of read-from, interfaces, we need to support them > for backwards compatibility. > > A proposal for these interfaces is that when NWAM starts, it will look at > the existence of these files and translate the information in them to the > SMF repository. I'm happy with this approach, but this is the most complicated part of the change that we need to facilitate. You either need to provide a detailed proposal for the SMF representation of interface and datalink configuration, or I'm happy to sit down with you and sketch something out. But this is where we need to spend a ton of time on the details. I also believe that doing this will require some improvements to underlying SMF mechanisms (i can explain in more detail once I get back from my trip) Also, one design point that I'd like to see preserved is that we separate the thing which does the auto configuration from the thing which knows how to take the SMF representation and plumb up the appropriate kernel abstractions. Keep those two things separate -- don't have them get intertwined inside of NWAM daemon. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
