> Or, for now, we choose not to create any smf instance for temporary > configuration. We only represent persistent configuration via smf > instances. Thus, we don't have to worry about removing them during next > reboot. And we'll add temporary configuration support later when we have > some support from smf framework to handle such temporary instance. But, > the questions here are that: > Is this an acceptable way to represent networking configuration? > Do we have any plan to add temporary instance support in smf framework?
FWIW, as I stated at the meeting, I fear this approach *is* unacceptable in the long-term, because it means that the administrator (or tools) can no longer rely on SMF to provide the current state of these system services. The result is that the SMF representation of IP interfaces and datalinks becomes only meaningful as an implementation convenience for tools such as NWAM, which was one of the things that mws was vehemently against in the original Clearview UV SMF proposal. Put differently: if the intent is for each configured IP interface or datalink to be represented in SMF, then that needs to be visible in SMF regardless of whether it will persist across reboot. If that's not the intent, then I'd like to understand what the intent is. If SMF doesn't provide the functionality necessary to do what we need, then it should be extended rather than compromised. -- meem
