As I mentioned in my reply to Kacheong, I'm working on some of the bigger questions you've raised here, and will be posting something about that shortly. Included here are replies to some of your other issues.
On Wed, Jan 03, 2007 at 07:03:04PM -0800, David Bustos wrote: > Quoth Renee Danson on Wed, Jan 03, 2007 at 04:23:14PM -0800: > > On Tue, Jan 02, 2007 at 12:31:09PM -0800, David Bustos wrote: > > > Quoth Renee Danson on Thu, Dec 21, 2006 at 06:02:11PM -0800: > > > > > > Isn't "external network application" applicable to every network client? > > > I think "Software link provider" or "Link modifying software" would be > > > a better name. > > > > I'm not attached to the name I chose; maybe "link modifying application"? > > Though that might be too specific; some VPN solutions might not modify > > links at all (e.g. bump-in-stack solutions). > > Actually I wask thinking of bump-in-stack VPNs when I suggested "link > modifying" -- the bump is modifying an existing link, as opposed to > punchin, which creates a new one. > > "Tunnel provider" is as close as I can think of to a generic term to > describe both. Tunnel provider isn't really generic at all; there's nothing specific to tunnels here (well, both those examples are, but this section is not just about externally-created tunnels). This is really just a label; and I think it's sufficiently described in the text that worrying too much about the label is not productive. If you think the text could better describe what the label means, let me know and I'll try to improve that. But I'm going to stick with the current name. [...] > > > > * when to activate: whenever possible, never, contingent (on an > > > > NCU), > > > > or on user request > > > > > > Do you have use cases in mind for "whenever possible" and "never"? It > > > seems to me that exclusive VPNs should be connected at administrative > > > direction. > > > > In an earlier message, Jim mentioned one example where you'd want "whenever > > possible": > > > > What about an edge device that links together two private networks > > over the Internet? That's still a VPN, but there's no "user" > > available to request anything, and the VPN itself is likely expected > > to be present at all times -- rather than on demand. > > Yeah, I didn't get that. Did he mean that the machine is supposed to > automatically connect tunnels to two different networks, and then > forward packets between them? If so, that sounds like more of a task > for an external program to set up. I.e., an rc script acts as the user > and instructs the system (through NWAM if necessary) to open the tunnels > and start routing. So I don't think "whenever possible" needs to be > built into NWAM's configuration. Registration of the ENA is an alternative to having an rc script, or making the external thing a service that's dependent on NWAM. If the user desires, or if the ENA is NWAM-aware and uses the API, the ENA can be registered with NWAM and started/stopped by NWAM as needed. Thus, the "whenever possible" option allows something like the VPN example Jim gave to be automatically enabled by NWAM (either at boot or on restart of the NWAM service), rather than requiring an rc script (which of course would only automatically be run on boot). > ... > > > > The registry API will also allow NWAM-aware ENAs to notify NWAM when to > > > > re-run the Environment selection engine; it is expected this will be > > > > desired > > > > when the ENA startup or teardown has completed, and may also be useful > > > > at > > > > other times. > > > > > > This is for link modifiers, right? It seems to me that link creation > > > should automatically trigger environment detection. > > > > Sure, link creation will. But some changes might not be so obvious (the > > aforementioned bump-in-the-stack vpn solutions, for example). > > Right. So I think you should explain that this is being provided for > tunnel-creators which don't create new links (what I call "link > modifiers"). Okay, I'll try to clarify that in my next revision (due out later today). > > > > NWAM will also provide an interface for external entities, including > > > > ENAs, > > > > to load complete Environment specifications. Thus, an NWAM-aware ENA > > > > would be able to specify the Environment that should be activated when > > > > the > > > > ENA is enabled. > > > > > > Would this be to the exclusion of the user's profile? Or some sort of > > > mix? Would the user be able to turn this off? > > > > This would be an additional profile, with its own conditions. The user > > would be able to view it, modify it, delete it, just like any other profile. > > > > The idea is to allow an application to set things up for the user, if that's > > what's desired. > > Ok. I took "should be activated" to mean the application could override > the selection mechanism. I suggest you state otherwise. I'll also address this in the next revision. -renee
