1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? See http://opensolaris.org/os/project/nwam/design/ of which snapshots have been placed in the case materials directory in HTML, text, PDF and PostScript format. - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? The product in the small is new, but it is a change to Solaris networking. The release taxonomoy sought is Minor. - If your project is an evolution of a previous project... It is not. - What is the motivation for it, in general as well as specific terms? To simplify and automate network configuration on Solaris. - What are the expected benefits for Sun? Gain new customers by reducing a major barrier to entry. - By what criteria will you judge its success? Complaints going down about how hard it is to configure networking. 2. Describe how your project changes the user experience, upon installation and during normal operation. The user, especially the laptop user, doesn't have to fiddle with ifconfig (or wificonfig for laptops); instead, an ethernet cable (or lack thereof) is auto-detected and networking is brought up on the appropriate interface. - What does the user perceive when the system is upgraded from a previous release? That everything still works, but networking info is more obvious. 3. What is its plan? - What is its current status? Design complete, in implementation of phase 0. - Has a design review been done? In progress via . - Are there multiple delivery phases? Yes. This review is an umbrella for the whole project (all phases) and other cases (probably fast-tracks) will deal with the details of each phase. In particular, a separate fast-track for Phase 0 has already been filed (PSARC 2007/136). * Phase 0 * automatic management of "simple" network interfaces * simple means no support for VLANs, aggregations, IPMP * tunnels (for VPNs, including punchin) will be supported * wireless will be supported, with WEP keys prompted for on the first visit to a given WLAN and automatic connecting subsequently * limitation: only one interface active at a time. * an "off" switch (so machines with complex configurations can continue to function smoothly, using current mechanisms) * profiles (automatically updating multiple system attributes whenever a new network "Environment" is detected) would *not* be supported, but would be "roll your own" * Phase 1, everything in phase 0 +: * profile support (automatically updating multiple system attributes whenever a new network "Environment" is detected) * a CLI * a GUI * SMF: each link & IP interface will have its own instance under the NWAM service * Phase 2, everything in phase 1 +: * management of "complex" network interfaces (VLANs, aggregations, IPMP) * TBD later phase: * any "modem" type functionality (i.e., PPP used for broadband access) 4. Are there related projects in Sun? Yes. - ... what is the proposal's relationship to their work? * We interact with certain Gnome network tools; we are working with JDS on this. * We looked into providing some of the network manager D-Bus APIs, but decided that was not in our scope. However, we do have long-term plans for a D-Bus to NWAM bridge. * Service Discovery and Link-Local Addresses for IPv4 are complementary projects. * Duckwater is something which will interact closely with us. - Which not-yet-delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? * Phase 0: none * Phase 1: * SMF Templates * Enhanced SMF Profiles * Clearview: * Nemo Unification & Vanity Naming * IP Tunneling Device Driver * Phase 2: * Clearview: * IPMP Rearchitecture - What other projects, if any, depend on this one? Caiman - Are you updating, copying or changing functional areas maintained by other groups? Yes, we are working with JDS on our GUI. There are some DHCP changes which we have planned (in our design) to make querying for what info we would get possible before deciding to accept it, but we have not yet planned (in our implementation) to do this. Longer term, there may be some PPP work, but that is only in a later phase if at all. - How are you coordinating and communicating with them? The appropriate people are on our I-team mailing list. - Do they "approve" of what you propose? If not, please explain the areas of disagreement. Yes 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. * Updates to SUNWcsr, other ON packages * New daemon & CLI (and GUI) will link with new libnwam * New SMF services to replace network/physical, network/initial and network/service 6. Describe the project's hardware platform dependencies. None - Explain any reasons why it would not work on both SPARC and Intel? None 7. System administration - How will the project's deliverables be installed and (re)configured? As part of core Solaris packaging; configuration is automatic (that's the whole point of this project). - How will the project's deliverables be uninstalled? N/A (part of the OS) - Does it use inetd to start itself? No. - Does it need installation within any global system tables? No. - Does it use a naming service such as NIS, NIS+ or LDAP? It manages them rather than uses them. - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? Nothing new. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? We will be using RBAC. No SMC/WBEM plans. - Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? Not in phase 0, but I imagine Gary will make us do this sooner or later. - What tunable parameters are exported? Network links and interfaces. - Can they be changed without rebooting the system? Yes - What ranges are appropriate for each tunable? The same as at present; we will just be providing a simpler mechanism for tweaking these things. - What are the commitment levels associated with each tunable (these are interfaces)? The same as they are now. 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? It improves network availability. - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) We expect to detect network configuration problems and report them via GUI pop-ups. - What are the project's effects on boot time requirements? TBD. - How does the project handle dynamic reconfiguration (DR) events? Very well. - What mechanisms are provided for continuous availability of service? SMF(5) - Does the project call panic()? No - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? GUI pop-ups where possible, plus syslog messages. - How does the project deal with failure and recovery? Via SMF(5) and an internal marker, also routing sockets and sysevents for detecting changes; see section 5.4.2 of our design doc for details. - Does it ever require reboot? No - How does your project deal with network failures (including partition and re- integration)? N/A - How do you handle the failure of hardware that your project depends on? We detect it (via routing sockets & sysevents) and adjust accordingly. - Can it save/restore or checkpoint and recover? Yes - Can its files be corrupted by failures? To the extent that any file-system can have such failures. - Does it clean up any locks/files after crashes? Yes 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? Yes, via SMF(5); the mechanism will be detailed in the subsequent cases. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? SMF(5), e.g., `svcs -x`. - What statistics does the subsystem export, and by what mechanism? Which network interfaces are up, with which IP address. Mechanism is GUI control panel. - What state information is logged? All sorts, depending on the log level. - In principle, would it be possible for a program to tune the activity of your project? Yes 10. What are the security implications of this project? - What security issues do you address in your project? This is not a security project per se, but we do make sure that WEP keys are stored securely, that RBAC and least privilege are used properly. There is the issue that a user plugging an ethernet cable into a system will result in an automatic network configuration action, which has security implications. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? We don't think this will have an effect, but we are talking to Gary to make sure. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? No - Please justify the introduction of any (all) new setuid executables. N/A - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) None - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. RBAC, file-system modes - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. PRIV_SYS_NET_CONFIG, PRIV_NET_RAWACCESS, PRIV_PROC_EXEC, PRIV_PROC_FORK, PRIV_PROC_SETID. See section 8.1.2 of our design doc for details. - What parts of the project are active upon default install and how it can be turned off. The service (daemon) is active upon default install. It can be turned off via `svcadm disable`. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Nevada - Environment variables? None - Exit status? N/A - Signals issued? None - Signals caught? (See signal(3HEAD).) SIGCHLD - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? None - Does it use any "hidden" (filename begins with ".") or temp files? No - Does it use any locking files? No - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? XXX TBD - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? N/A - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? So far: libsocket libnsl libinetcfg libsysevent libumem libscf libwladm Expected to come: libdladm libtecla libnwam - Identify and justify the requirement for any static libraries. N/A - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No - Is your project 64-bit clean/ready? N/A (32-bit daemon that runs fine on 64-bit systems). - ... are there any architectural reasons why it would not work in a 64-bit environment? No - Does it interoperate with 64-bit versions? N/A - Does the project depend on particular versions of supporting software (especially Java virtual machines)? XXX TBD - If so, do you deliver a private copy? Expected answer is No. - What happens if a conflicting or incompatible version is already or subsequently installed on the system? N/A (part of the OS). - Is the project internationalized and localized? Yes - Is the project compatible with IPV6 interfaces and addresses? Yes 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? N/A - X properties: Which ones does it depend on? Which ones does it export, and what are their types? None - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? Our GUI will have a Help sub-system; anything else will be whatever the window manager in use provides. - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? N/A - Which window-system toolkit/desktop does your project depend on? GUI is currently planned to use GTk. - Can it execute remotely? XXX This question is too vague: PSARC, please clarify. - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") None that we know of - How does it use colormap entries? Can you share them? N/A as far as we know - Does it handle 24-bit operation? As far as we know 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Committed," "Uncommitted," and "*Private;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Interfaces Imported Interface Classification Comments libwladm functions Consolidation Private libdladm functions Consolidation Private libinetcfg functions Consolidation Private libscf functions Public XXX more to come here Interfaces Exported Interface Classification Comments many libnwam functions Project Private some libnwam functions Committed some SMF FMRIs Committed XXX more to come here - Exported public library APIs and ABIs N/A - Other interfaces none - What other applications should it interoperate with? How will it do so? Various higher level networking services will be affected; SMF(5) will be used to manage this. - Is it "pipeable"? How does it use stdin, stdout, stderr? N/A - Explain the significant file formats, names, syntax, and semantics. Project-private stuff (much TBD) under /etc/nwam - Is there a public namespace? No - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? They will be. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) none - Private ToolTalk usage none - Files XXX TBD - Other XXX TBD - Are the interfaces re-entrant? Yes 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? XXX TBD - What was the commitment level of the previous version? N/A - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? N/A - What are the clients over which a change should be managed? N/A - How is transition to a new version to be accomplished? Upgrade - What are the consequences to ISV's and their customers? Should be unaffected if they use Committed interfaces. 16. How do the interfaces adapt to a changing world? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? This whole project is about making life easier for nomadic computers. 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? N/A - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? Different network configuration specifics would occur, but the same general principles would be applied. - Does your project assume that a Solaris-based system must be in control of the primary administrative node? No 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? The daemon is expected to have a minimal impact. - What are the performance goals of the project? Minimal boot-time impact (exact goal TBD). - How were they evaluated? Boot-time testing. - What is the test or reference platform? TBD, though a variety of platforms are expected to be included. - Does the application pause for significant amounts of time? No, but sometimes scanning for wireless networks can take several seconds. - Can the user interact with the application while it is performing long-duration tasks? Yes - What is your project's MT model? Our daemon is multi-threaded. - How does it use threads internally? We have a set of threads used to manage event sources: * some to collect events and hand them to a main loop * another to catch signals * another for scanning wireless - How does it expect its client to use threads? N/A - If it uses callbacks, can the called entity create a thread and recursively call back? No public library. - What is the impact on overall system performance? Minimal - What is the average working set of this component? Assuming "average working set" means "virtual memory footprint", then the answer is "about 3MB so far". - How much of this is shared/sharable by other apps? Roughly 2MB at present. - Does this application "wake up" periodically? Yes, it wakes up based on events from interfaces. - How often and under what conditions? N/A - What is the working set associated with this behavior? N/A - Will it require large files/databases (for example, new fonts)? No - Do files, databases or heap space tend to grow with time/load? Don't know yet, expect answer to be "not significantly". - What mechanisms does the user have to use to control this? big hammer: svcadm refresh smaller more finesse tool: resource controls - What happens to performance/system load? Minimal impact 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... * We have a "compatibility switch" in phase 0, and will probably have it (or something like it) in phase 1 as well. In phase 0, we are delivered off by default (for most install media), and the way to enable us is: svcadm disable svc:/network/physical:default svcadm enable svc:/network/physical:nwam This will allow machines with complex configurations to work without issue, and others which may have problems to have an easy fallback mechanism. Long term, we plan to make this moot by adding the ability to handle all those scenarios, but this seems like a wise short-term thing to do. * As noted above, this service is not enabled by default, but it (or its successor service) will be. Since network/physical is already enabled by default, since does not seem to present an issue w/rt SMF policy, but there might be an SBD issue in having this new service enabled by default, and enabling network interfaces automatically. (Should automatically enabled interfaces be wrapped with an IP Filter default deny-all policy to make them "safe" until authorized?) - Are there issues or related projects that the ARC should advise the appropriate steering committees? XXX don't know 20. Appendices to include - One-Pager. /shared/sac/Projects/2007/20070307_john.beck - Prototype specification. http://opensolaris.org/os/project/nwam/prototype/ which is being productized under the aegis of /shared/sac/PSARC/2007/136/ - References to other documents. (Place copies in case directory.) Nothing further at this time.