Thanks Kacheong for the good questions. Please see my explanation in-line. >Zhenghui Xie wrote: > > > >>The current network/initial will disappear as well, but its current tasks >>will be replaced by 3 services: >>1. Configuring IPsec related stuff will be replaced by IPsec service(s); >> details in Sun Bug ID 6185380. >> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6185380 >>2. Configuring IPv4 and/or IPv6 tunneling will be replaced by a Clearview >> tunneling service; details at Section 10 of IP tunneling design document: >> http://www.opensolaris.org/os/project/clearview/iptun-design.pdf >> >> > > >So how does NWAM work with the above services? Is there a >dependency between the proposed network/profiled and the above >services? I believe this should be clearly stated. > > > good question. It was not specified clearly in the draft. I think they should depend on milestone/network instead and should be enabled by NWAM daemon when the daemon is in IF_RUNNING state.
I will add this to the final draft. (please see below for my explanation of the 3rd draft). > > >>3. The remaining network related configuration will be done by the NWAM >> daemon. >> >>milestone/network is not needed and will be replaced by network/profiled as >>well. After the NWAM daemon reaches the NWAM_IF_RUNNING state, the daemon >>will >>decide whether to switch ULP or not based on user specifications. Switching >>ULP >>means that a set of SMF services will be enabled/disabled, new property values >>will be applied and some SMF services will be refreshed. >> >> > > >There are some discussions about the removal of milestone/network. >So what is the "final" proposal, keep it or remove it? It is not >clear from the discussion what the decision is. Assuming it is >kept, what is the relationship between milestone/network and >network/profiled? > > > The current decision is that milestone/network will remain. I listed two reasons in the temporary 3rd draft. There is no SMF dependency between milestone/network and network/profiled. In stead, milestone/network will be enabled by NWAM daemon when NWAM daemon reaches IF_RUNNING state. >Since a ULP decides which network service is enabled/disabled, how >does NWAM handle the case when a sys admin `svcadm enable` a service >manually? Will NWAM note that and automatically update the current >running ULP to include this service? Is this the right behavior? > > > > Please correct me when I am wrong, David. NWAM ULP will mainly use the framework provided by the enhanced SMF profile project. I remember that the case Kacheong described here is something considered in David's design? Based on my understanding, the sys admin's change will be on the surface of the profile layers, and it will be the one being seen. I am not sure if enhanced SMF profile project will provide some option for the user to write his change to some underneath profile. If it does, then it is quiet easy to let the ULP be updated. If not, I don't think that NWAM should keep track of such changes, because we sort of request user to use our UI to change the ULP. Or maybe I miss something here? >>milestone/name-services will remains as it is now. >> >>III. Dependencies: >>A lot of services currently depend on the services which the NWAM daemon >>will replace. These dependencies will be deleted and NWAM will use profiles >>to manage when to bring them online: >> >> > > >Does it mean that all the services will be made dependent on >network/profiled instead? Or should they be dependent on milestone/ >network? Or should all the dependencies be removed as NWAM will >control if a service is suitable to run or not? It is not clear >what the proposal is. > > > Not all the services will depend on network/profiled. In fact, the previous dependencies that depend on the deleted network services will be gone. And NWAM daemon will leverage the enhanced SMF profile project to enbale these services at appropriate time. I think maybe a figure of the new dependencies will help. I will try to draw one in the final draft. >Maybe all the above questions are already answered. If this is >the case, please send a final write up of the NWAM service model. >Thanks. > > > > The temporary 3rd draft is section 5.4 of the url below http://www.opensolaris.org/os/project/nwam/design/;jsessionid=909CD936D11A07C26E27E193A5B7DD71#network_service The reason that it is temporary and not sent out for review yet is, that Mike Shapiro sent out some valuable comments and suggested we discuss with him more after he come back from vacation. So I merged the comments I received and wrote a temporary draft for John to put it on the website. But changes are expected after we get a detailed feedback from Mike, so I didn't send it out for final review. -Jan
