From Sebastien.Roy@Sun.COM Thu Oct 22 10:42:44 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MHghol016590 for ; Thu, 22 Oct 2009 10:42:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9MHggf4019953 for ; Thu, 22 Oct 2009 10:42:42 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9MHggiQ004661 for ; Thu, 22 Oct 2009 17:42:42 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRX00B00FLQ1K00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Thu, 22 Oct 2009 11:42:42 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRX00G0CFV2GKG0@mail-amer.sun.com>; Thu, 22 Oct 2009 11:42:38 -0600 (MDT) Date: Thu, 22 Oct 2009 13:40:11 -0400 From: Sebastien Roy Subject: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Renee Danson Sommerfeld Message-id: <1256233211.302.36.camel@strat> Organization: Sun Microsystems Status: RO Content-Length: 13705 I'm sponsoring this case for Renee Danson Sommerfeld, it times out on 10/29/2009. The release binding for this case is the same as the case that it updates (PSARC 2008/532 NWAM Phase 1), namely Minor release binding. In the course of completing the implementation of NWAM Phase 1, several interface changes were made. Most were relatively minor; they are all documented below. 1. Nomenclature change Refer to NCU types as link and interface, instead of link and ip. Link-type NCUs currently have one possible class: phys; Interface-type NCUs also have one possible class: ip. There is an expectation that as support for more sophisticated network configurations is added, additional classes will be created. However, the class will always imply the type; therefore commands will generally only use the class descriptor. This is primarily a documentation change; though the CLI tools do have some flag changes as well, described in the next item. 2. Updates to the nwamadm options * Added a new parameter to specify NCU class, to allow differentiation between Link and IP NCUs, if desired. * Change the option letter for specifying the profile-type from 't' to 'p' * Remove the subcommand 'interact' * Add new subcommands: show-events, scan-wifi, select-wifi show-events reports the events published by nwamd. scan-wifi requests a wireless scan on the specified link and prints result list. Much like 'dladm scan-wifi', only it has the effect of updating nwamd's cached list, as well. select-wifi prints the list of available wlans for the specified link, and prompts the user to select one to connect to. * Add option to list subcommand, '-x', which includes explanation of state New subcommand list/syntax for nwamadm: help enable [ -p ] [ -c ] disable [ -p ] [ -c ] list [ -x ] [ -p ] [ -c ] [ ] show-events scan-wifi select-wifi 3. Updates to nwamadm output The output of the 'list' subcommand will include information about the state of the NCUs that make up the currently active NCP. 4. Add '-V' option to nwamcfg's 'get' subcommand Default output from the get command is 'propname=propval'. For ease of scripting, the -V option outputs the value only. Example: % nwamcfg "select wlan Asbury; get priority" priority 0 % nwamcfg "select wlan Asbury; get -V priority" 0 5. Clarification of command-line output stability PSARC 2008/532 incorrectly defined command-line output stability to be Uncommitted; it should be Volatile. 6. Make 'enabled' property common to all NCUs, not just Link NCUs. This change makes the plumbing of ip on a link independent of making the link active. Bringing up a link and plumbing ip on it can still be accomplished with one command ('nwamadm enable -p ncu wpi0'); but it is also possible to separate the two steps ('nwamadm enable -p ncu -c link wpi0' and 'nwamadm enable -p ncu -c ip wpi0'). 7. Use 'enabled' property on all locations, not just those that have manual activation mode. This means that users can choose to activate any location at any given time, even if, for example, the location has conditional activation specified and its conditions are not currently met. If a user does activate a location, effectively overriding automatic selection by nwamd, that location must be explicitly disabled in order to restore automatic selection. 8. 'all' is no longer a valid value for the ip-version property This property allows multiple values; so the value 'all' is not needed, as the desired IP versions may simply be enumerated. This change also means the default value of the property is "ipv4,ipv6" rather than "all". 9. ipv6-addrsrc value change The value 'dhcpv6' is now simply 'dhcp'. Assigning the value to the ipv6-addrsrc property implies that the v6 version of the protocol should be used, no need to differentiate in the names. Also, dhcp and autoconf values must be included if ipv6-addrsrc is set; disabling these two address configuration methods is not allowed at this time. Though this is a change from the legacy Solaris behavior, it is actually more in keeping with the IPv6 specifications, which state that the use of those two address configuration methods is specified by the router, not the host. Adding or removing the value 'static' to/from the ipv6-addrsrc property is allowed. 10. Remove hosts-file, enable-svcs and disable-svcs properties from Location profile Use of the hosts-file property, to replace the /etc/hosts file when changing location, was not particularly useful, and could lead to confusion if some locations specified an alternate file, while others did not. The enable-svcs and disable-svcs properties could lead to similar problems, as naming a service in one of these states what the state of the service should be when the location is active, but is not explicit about what to do when the location is de-activated. The initial state is not taken into account, and really can't be, if each location may-- but is not required to--specify a state for a given service. 11. Add default-route properties to IP Interface NCUs Two new properties, ipv4-default-route and ipv6-default-route, allow the user to specify statically configured default router address(es), to be associated with a specific interface. This provides a static alternative to a DHCP-specified default router, which may be associated with an interface if DHCP is in use. 12. Add support for storing keyslot info with known_wlans Includes addition of a 'keyslot' property to the known_wlan object, extensions to the interfaces and CLIs for setting that value, and support in nwamd for specifying the keyslot when making connections. 13. Change 'upgraded' nwam service property to 'version' Rather than having a simple boolean to indicate whether or not legacy configuration has been updated, we will have a count property which can evolve as needed. It will not exist when the phase 1 bits are installed, and will be set to a value of '1' once pre-phase-1 configuration, if any, has been updated. 14. Clarification of scan_interval service property values If this property is set to 0, periodic wireless scans will not happen while a link is connected. 15. New nwam service property 'condition_check_interval' Allows the user to tune the interval at which conditions are validated for conditionally-activated objects. Asynchronous events can result in changes at any time, but in the absence of events, the conditions will always be re-evaluated at the interval specified by this property. Default value is 120 seconds; minimum is 30 seconds. If set to a value lower than the minimum, the minimum will be used. The stability level of this property is, like all the properties in the nwamd property group, Volatile. 16. Effect on Automatic and User NCPs when links are added/removed Earlier behavior was to add newly-discovered links to all NCPs, both User and Automatic. This had the unfortunate side effect of preventing the user from permanently removing links that they really did not want NWAM to manage from the User NCP: upon restart, nwamd would see that a link was present in the system that did not exist in the User NCP, and promptly add it. This also would force the user to continually recreate configuration for a device that was sometimes removed, e.g. a PC-card wireless adapter. Revised behavior is to make such changes to the Automatic NCP, but not the User NCP. If a link is added to the system, the user must explicitly add it to the User NCP if desired; on removal from the system, it will not be removed from the User NCP. 17. Change upgrade behavior Upon upgrade, earlier nwam link and interface configuration will be imported into the User NCP. However, the Automatic NCP will be active by default. The rationale for this change is that the default config implemented in earlier nwam versions is the same as the Automatic NCP behavior, and we expect that most users will not have made changes, and therefore will want the Automatic NCP. The previously discussed change with respect to automatic addition/removal of inserted/removed links makes this especially desirable. Users who actually modified their earlier configuration (which should be a small minority) can switch to the User NCP to get their changes. There is one exception: if any static addresses are specified in the llp file, it is very clear that the user did in fact modify that file; therefore, if a static address is found, the User NCP will be active upon upgrade. Location profiles did not exist in earlier versions of NWAM, so any configuration that NWAM does based on Location specifications may overwrite previous system configuration. On upgrade, the existing configuration will be saved into a User location. This location will be activated if it includes an nsswitch.conf file which uses a nameservice other than DNS (i.e. a nameservice that cannot be configured by NWAM based solely on information obtained from the network). 18. Add the following functions and flags to the consolidation-private libnwam interface: * nwam_error_t nwam_ncp_get_active_priority_group(int64_t *); Returns the currently active priority group. In addition, changes to the active priority group are reported with an NWAM_EVENT_TYPE_PRIORITY_GROUP event. This allows consumers to track changes to the active group. * NWAM_FLAG_KNOWN_WLAN_NO_COLLISION_CHECK flag As each known_wlan must have a unique priority value, the default behavior upon commit of a known_wlan object is to check for a priority collision and shift existing values as needed. However, in cases where the consumer is writing the complete list, having explicitly set each priority value, such checking is not needed. Passing this flag in the flags parameter of the commit function will skip collision checking. * nwam_error_t nwam_wlan_get_scan_results(const char *linkname, uint_t *num_wlansp, nwam_wlan_t **wlansp); Consumers need a way of requesting the results of the most recent wireless scan; this function provides that. * nwam_*_get_state(nwam_*_handle_t handle, nwam_state_t *state, nwam_aux_state_t *aux_state); Returns the current state of the specified object. * nwam_error_t nwam_wlan_get_selection(const char *linkname, char **essidp, char **bssidp); Returns the selected wlan, if applicable, for the specified link. * add argument to nwam_wlan_select() Additional boolean parameter added to this function to specify whether or not the selected wlan should be added to the known_wlan list. * add property status functions Specific objects and properties may be read-only (or only modifiable by nwamd). Add functions to the API allowing consumers to check for read-only status of objects and properties: nwam_error_t nwam_loc_prop_read_only(const char *prop, boolean_t *ro); nwam_error_t nwam_ncu_prop_read_only(const char *prop, boolean_t *ro); nwam_error_t nwam_enm_prop_read_only(const char *prop, boolean_t *ro); nwam_error_t nwam_ncp_get_read_only(nwam_ncp_handle_t ncph, boolean_t *ro); nwam_error_t nwam_ncu_get_read_only(nwam_ncu_handle_t ncuh, boolean_t *ro); boolean_t nwam_loc_can_set_name(nwam_loc_handle_t loch); boolean_t nwam_enm_can_set_name(nwam_enm_handle_t enmh); boolean_t nwam_known_wlan_can_set_name(nwam_known_wlan_handle_t kwh); 19. Remove support for renaming of NCU objects These objects map to physical links and IP interfaces; renaming thus involves vanity naming and questions of what exactly is intended. For phase 1, renaming of these objects will not be allowed; determining how exactly this should work and implementing appropriately remains future work. Renaming of links can be accommodated by disabling the nwam service, performing the rename, and then enabling nwam. The new link name will be detected and updated in the Automatic NCP; the User NCP will require the user to make appropriate updates. 20. Remove iptun references from the libnwam interface Support for iptun datalinks is planned for a future phase; hooks were included in the API details included with the earlier case. These should be removed until full support is available. 21. Cleanup of exported interfaces in libinetcfg Two functions originally included in the list of exported functions for the consolidation-private libinetcfg are not needed externally, and so will not be exported: icfg_if_protocol() and icfg_is_loopback(). 22. Upgrade the stability level of an interface from PSARC 2006/366, which is consumed by this case: the zone_check_datalink() function was integrated as project-private; the submitter of that case, Erik Nordmark, has agreed to the upgrade of this interface, as documented in PSARC 2006/366, to consolidation private. From Nicolas.Williams@sun.com Thu Oct 22 11:35:21 2009 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MIZKnp017842 for ; Thu, 22 Oct 2009 11:35:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9MIVMIp006251; Thu, 22 Oct 2009 13:31:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9MIVM7I006250; Thu, 22 Oct 2009 13:31:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 22 Oct 2009 13:31:22 -0500 From: Nicolas Williams To: Sebastien Roy Cc: psarc-ext , Renee Danson Sommerfeld Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] Message-ID: <20091022183122.GR892@Sun.COM> References: <1256233211.302.36.camel@strat> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1256233211.302.36.camel@strat> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3336 On Thu, Oct 22, 2009 at 01:40:11PM -0400, Sebastien Roy wrote: > * Add option to list subcommand, '-x', which includes explanation of state Why -x and not -v or -xv or anything more in keeping with other Solaris commands? > 4. Add '-V' option to nwamcfg's 'get' subcommand > Default output from the get command is 'propname=propval'. For ease > of scripting, the -V option outputs the value only. Elsewhere we use -H for scripting output. Why not here? mnemonic reasons? > 7. Use 'enabled' property on all locations, not just those that have manual > activation mode. This means that users can choose to activate any location > at any given time, even if, for example, the location has conditional > activation specified and its conditions are not currently met. > > If a user does activate a location, effectively overriding automatic > selection by nwamd, that location must be explicitly disabled in order > to restore automatic selection. That's weird. Will automatic selection be able to select a disabled location? Why not make it so that enabling a location disables a special "automatic" location, and that you have to enable that one to get back to automatic location selction? > 10. Remove hosts-file, enable-svcs and disable-svcs properties from Location > profile > Use of the hosts-file property, to replace the /etc/hosts file when > changing location, was not particularly useful, and could lead to > confusion if some locations specified an alternate file, while others > did not. > > The enable-svcs and disable-svcs properties could lead to similar > problems, as naming a service in one of these states what the state of > the service should be when the location is active, but is not explicit > about what to do when the location is de-activated. The initial state > is not taken into account, and really can't be, if each location may-- > but is not required to--specify a state for a given service. You could always disable any services which were enabled by enabling a location, when that location is disabled, even if the next location will re-enable [some of] them (which would effectively result in a restart). That would make a lot more sense to me. Similarly for hosts file contents. When a location that has a hosts file is disabled, a hosts file suitable for disconnected operation should be installed, even if the next location to be enabled will specify a hosts file (at which point that hosts file gets installed). I see nothing really confusing about this... > 19. Remove support for renaming of NCU objects > These objects map to physical links and IP interfaces; renaming thus > involves vanity naming and questions of what exactly is intended. For > phase 1, renaming of these objects will not be allowed; determining how > exactly this should work and implementing appropriately remains future > work. > > Renaming of links can be accommodated by disabling the nwam service, > performing the rename, and then enabling nwam. The new link name will > be detected and updated in the Automatic NCP; the User NCP will require > the user to make appropriate updates. For links with MAC addresses the renaming of User NCPs could be done automatically... Nico -- From Darren.Moffat@Sun.COM Thu Oct 22 11:47:48 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MIlmQd017968 for ; Thu, 22 Oct 2009 11:47:48 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9MIllSB004127 for ; Thu, 22 Oct 2009 11:47:47 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9MIlgOi029377 for ; Thu, 22 Oct 2009 18:47:42 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRX00800IQYO000@fe-emea-10.sun.com> for psarc-ext@sac.sfbay.sun.com; Thu, 22 Oct 2009 19:47:30 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRX00BGDIV58OD0@fe-emea-10.sun.com>; Thu, 22 Oct 2009 19:47:30 +0100 (BST) Date: Thu, 22 Oct 2009 19:47:29 +0100 From: Darren J Moffat Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] In-reply-to: <20091022183122.GR892@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Nicolas Williams Cc: Sebastien Roy , psarc-ext , Renee Danson Sommerfeld Message-id: <4AE0A8C1.8040205@Sun.COM> References: <1256233211.302.36.camel@strat> <20091022183122.GR892@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 349 Nicolas Williams wrote: > On Thu, Oct 22, 2009 at 01:40:11PM -0400, Sebastien Roy wrote: >> * Add option to list subcommand, '-x', which includes explanation of state > > Why -x and not -v or -xv or anything more in keeping with other Solaris > commands? -x is in keeping with other Solaris commands, like svcs and zpool. -- Darren J Moffat From Nicolas.Williams@sun.com Thu Oct 22 11:48:24 2009 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MImNHq017980 for ; Thu, 22 Oct 2009 11:48:23 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9MIiTKM006265; Thu, 22 Oct 2009 13:44:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9MIiTEM006264; Thu, 22 Oct 2009 13:44:29 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 22 Oct 2009 13:44:29 -0500 From: Nicolas Williams To: Darren J Moffat Cc: Sebastien Roy , psarc-ext , Renee Danson Sommerfeld Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] Message-ID: <20091022184428.GT892@Sun.COM> References: <1256233211.302.36.camel@strat> <20091022183122.GR892@Sun.COM> <4AE0A8C1.8040205@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE0A8C1.8040205@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 454 On Thu, Oct 22, 2009 at 07:47:29PM +0100, Darren J Moffat wrote: > Nicolas Williams wrote: > >On Thu, Oct 22, 2009 at 01:40:11PM -0400, Sebastien Roy wrote: > >> * Add option to list subcommand, '-x', which includes explanation of > >> state > > > >Why -x and not -v or -xv or anything more in keeping with other Solaris > >commands? > > -x is in keeping with other Solaris commands, like svcs and zpool. Ah, yes. Excuse that brainfart please. From glenn.skinner@sun.com Thu Oct 22 17:04:05 2009 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9N045Kn027480 for ; Thu, 22 Oct 2009 17:04:05 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n9N044NW027593; Thu, 22 Oct 2009 17:04:04 -0700 (PDT) Message-Id: <200910230004.n9N044NW027593@ivrel.sfbay.sun.com> Date: Thu, 22 Oct 2009 17:04:04 -0700 (PDT) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] To: psarc-ext@sac.sfbay.sun.com Cc: renee.sommerfeld@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EjipRQtNTeiLOewRI7nJaA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1090 Date: Thu, 22 Oct 2009 13:40:11 -0400 From: Sebastien Roy Subject: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] ... 4. Add '-V' option to nwamcfg's 'get' subcommand Default output from the get command is 'propname=propval'. For ease of scripting, the -V option outputs the value only. Example: % nwamcfg "select wlan Asbury; get priority" priority 0 % nwamcfg "select wlan Asbury; get -V priority" 0 The example lacks the "=" character. Is it supposed to be there, or not? Also, what stability level does this output have? (If you intend it to be scriptable, it ought to be Committed...) 5. Clarification of command-line output stability PSARC 2008/532 incorrectly defined command-line output stability to be Uncommitted; it should be Volatile. See above. You probably want to call out subcommands that are intended to produce scriptable output and specify their output stability separately. -- Glenn From Kais.Belgaied@Sun.COM Wed Oct 28 16:19:15 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9SNJF52000968 for ; Wed, 28 Oct 2009 16:19:15 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9SNJFvg366368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 16:19:15 -0700 (PDT) Message-ID: <4AE8D173.201@Sun.COM> Date: Wed, 28 Oct 2009 16:19:15 -0700 From: Kais Belgaied User-Agent: Thunderbird 2.0.0.21 (X11/20090311) MIME-Version: 1.0 To: Sebastien Roy CC: psarc-ext , Renee Danson Sommerfeld Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] References: <1256233211.302.36.camel@strat> In-Reply-To: <1256233211.302.36.camel@strat> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2162 On 10/22/09 10:40, Sebastien Roy wrote: > 11. Add default-route properties to IP Interface NCUs > Two new properties, ipv4-default-route and ipv6-default-route, allow > the user to specify statically configured default router address(es), > to be associated with a specific interface. This provides a static > alternative to a DHCP-specified default router, which may be associated > with an interface if DHCP is in use. > alternative to the DHCP-specified default router (returned by dhcpinfo I presume) or in addition to it, as a second default router? > 17. Change upgrade behavior > Upon upgrade, earlier nwam link and interface configuration will be > imported into the User NCP. However, the Automatic NCP will be active > by default. The rationale for this change is that the default config > implemented in earlier nwam versions is the same as the Automatic NCP > behavior, and we expect that most users will not have made changes, and > therefore will want the Automatic NCP. The previously discussed change > with respect to automatic addition/removal of inserted/removed links > makes this especially desirable. Users who actually modified their > earlier configuration (which should be a small minority) can switch to > the User NCP to get their changes. > > There is one exception: if any static addresses are specified in the > llp file, it is very clear that the user did in fact modify that file; > therefore, if a static address is found, the User NCP will be active > upon upgrade. > > Location profiles did not exist in earlier versions of NWAM, so any > configuration that NWAM does based on Location specifications may > overwrite previous system configuration. On upgrade, the existing > configuration will be saved into a User location. This location will > be activated if it includes an nsswitch.conf file which uses a nameservice > other than DNS (i.e. a nameservice that cannot be configured by NWAM > you mean other tan DNS *and* files, ? > based solely on information obtained from the network). > Kais From renee.sommerfeld@sun.com Fri Oct 30 16:53:53 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9UNrq9G026126 for ; Fri, 30 Oct 2009 16:53:52 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9UNrqAj771143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 16:53:52 -0700 (PDT) Received: (from okie@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9UNrpTZ771142; Fri, 30 Oct 2009 16:53:51 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: okie set sender to renee.sommerfeld@sun.com using -f Date: Fri, 30 Oct 2009 16:53:51 -0700 From: Renee Danson Sommerfeld To: Glenn Skinner Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] Message-ID: <20091030235351.GA763179@jurassic-x4600.Eng.Sun.COM> References: <200910230004.n9N044NW027593@ivrel.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910230004.n9N044NW027593@ivrel.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 1658 On Thu, Oct 22, 2009 at 05:04:04PM -0700, Glenn Skinner wrote: > Date: Thu, 22 Oct 2009 13:40:11 -0400 > From: Sebastien Roy > Subject: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 > FastTrack timeout 10/29/2009] > > ... > 4. Add '-V' option to nwamcfg's 'get' subcommand > Default output from the get command is 'propname=propval'. For > ease of scripting, the -V option outputs the value only. > > Example: > % nwamcfg "select wlan Asbury; get priority" > priority 0 > % nwamcfg "select wlan Asbury; get -V priority" > 0 > > The example lacks the "=" character. Is it supposed to be there, or > not? No, it is not intended to be there; the example is correct. > Also, what stability level does this output have? (If you > intend it to be scriptable, it ought to be Committed...) The stability level is addressed in the following item, which you ask about next. > 5. Clarification of command-line output stability > PSARC 2008/532 incorrectly defined command-line output > stability to be Uncommitted; it should be Volatile. > > See above. You probably want to call out subcommands that are > intended to produce scriptable output and specify their output > stability separately. We have an RFE to further address scriptability in the command output, and when we do that, will specify appropriate stability. This particular change (the addition of the -V option) was added specifically because the project is delivering some scripts (smf service methods) which benefitted from this option. -renee From renee.sommerfeld@sun.com Fri Oct 30 17:12:21 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V0CKYX026894 for ; Fri, 30 Oct 2009 17:12:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9V0CKNG774178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 17:12:20 -0700 (PDT) Received: (from okie@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9V0CKJT774177; Fri, 30 Oct 2009 17:12:20 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: okie set sender to renee.sommerfeld@sun.com using -f Date: Fri, 30 Oct 2009 17:12:20 -0700 From: Renee Danson Sommerfeld To: Glenn Skinner Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] Message-ID: <20091031001220.GO691159@jurassic-x4600.Eng.Sun.COM> References: <200910230004.n9N044NW027593@ivrel.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910230004.n9N044NW027593@ivrel.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 1453 On Thu, Oct 22, 2009 at 05:04:04PM -0700, Glenn Skinner wrote: > > ... > 4. Add '-V' option to nwamcfg's 'get' subcommand > Default output from the get command is 'propname=propval'. For > ease of scripting, the -V option outputs the value only. > > Example: > % nwamcfg "select wlan Asbury; get priority" > priority 0 > % nwamcfg "select wlan Asbury; get -V priority" > 0 > > The example lacks the "=" character. Is it supposed to be there, or > not? No, it is not intended to be there; the example is correct. > Also, what stability level does this output have? (If you > intend it to be scriptable, it ought to be Committed...) The stability level is addressed in the following item, which you ask about next: > 5. Clarification of command-line output stability > PSARC 2008/532 incorrectly defined command-line output > stability to be Uncommitted; it should be Volatile. > > See above. You probably want to call out subcommands that are > intended to produce scriptable output and specify their output > stability separately. We have an RFE to further address scriptability in the command output, and when we do that, will specify appropriate stability. This particular change (the addtion of the -V option) was added specifically because the project is delivering some scripts (smf service methods) which benefitted from this option. -renee From glenn.skinner@sun.com Fri Oct 30 17:37:13 2009 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V0bD09027781 for ; Fri, 30 Oct 2009 17:37:13 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n9V0bD77007305; Fri, 30 Oct 2009 17:37:13 -0700 (PDT) Message-Id: <200910310037.n9V0bD77007305@ivrel.sfbay.sun.com> Date: Fri, 30 Oct 2009 17:37:13 -0700 (PDT) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] To: renee.sommerfeld@sun.com Cc: psarc-ext@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nBZ7k38yXPKjKUkzdZ0SqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 2219 Date: Fri, 30 Oct 2009 16:53:51 -0700 From: Renee Danson Sommerfeld Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] On Thu, Oct 22, 2009 at 05:04:04PM -0700, Glenn Skinner wrote: > ... > > 4. Add '-V' option to nwamcfg's 'get' subcommand > Default output from the get command is > 'propname=propval'. For ease of scripting, the -V > option outputs the value only. > > Example: > % nwamcfg "select wlan Asbury; get priority" > priority 0 > % nwamcfg "select wlan Asbury; get -V priority" > 0 > > The example lacks the "=" character. Is it supposed to be > there, or not? No, it is not intended to be there; the example is correct. Ok. (You might want to revise the "'propname=propval'" phrasing in the description above; it certainly led me to expect to see "=" in the output of the first example, and I suspect others will find it confusing as well.) > Also, what stability level does this output have? (If you > intend it to be scriptable, it ought to be Committed...) The stability level is addressed in the following item, which you ask about next. > 5. Clarification of command-line output stability > PSARC 2008/532 incorrectly defined command-line output > stability to be Uncommitted; it should be Volatile. > > See above. You probably want to call out subcommands that are > intended to produce scriptable output and specify their output > stability separately. We have an RFE to further address scriptability in the command output, and when we do that, will specify appropriate stability. This particular change (the addition of the -V option) was added specifically because the project is delivering some scripts (smf service methods) which benefitted from this option. So if you've added "-V" specifically to emit scriptable output, why not declare the corresponding output format to be Committed now rather than waiting? (Not a big deal, I just don't understand the motivation for waiting.) -- Glenn From renee.sommerfeld@sun.com Fri Oct 30 21:24:43 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V4OgNb003636 for ; Fri, 30 Oct 2009 21:24:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9V4OgKJ843754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 21:24:42 -0700 (PDT) Received: (from okie@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9V4OftS843753; Fri, 30 Oct 2009 21:24:41 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: okie set sender to renee.sommerfeld@sun.com using -f Date: Fri, 30 Oct 2009 21:24:41 -0700 From: Renee Danson Sommerfeld To: Glenn Skinner Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] Message-ID: <20091031042441.GA843604@jurassic-x4600.Eng.Sun.COM> References: <200910310037.n9V0bD77007305@ivrel.sfbay.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910310037.n9V0bD77007305@ivrel.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2626 On Fri, Oct 30, 2009 at 05:37:13PM -0700, Glenn Skinner wrote: > Date: Fri, 30 Oct 2009 16:53:51 -0700 > From: Renee Danson Sommerfeld > Subject: Re: 2009/577 [Network Auto-Magic (NWAM) Phase 1 Updates] > > On Thu, Oct 22, 2009 at 05:04:04PM -0700, Glenn Skinner wrote: > > ... > > > > 4. Add '-V' option to nwamcfg's 'get' subcommand > > Default output from the get command is > > 'propname=propval'. For ease of scripting, the -V > > option outputs the value only. > > > > Example: > > % nwamcfg "select wlan Asbury; get priority" > > priority 0 > > % nwamcfg "select wlan Asbury; get -V priority" > > 0 > > > > The example lacks the "=" character. Is it supposed to be > > there, or not? > > No, it is not intended to be there; the example is correct. > > Ok. (You might want to revise the "'propname=propval'" phrasing in > the description above; it certainly led me to expect to see "=" in the > output of the first example, and I suspect others will find it > confusing as well.) Yipes, I hadn't even noticed that. I guess that would explain why you were asking! Yes, I should remove that '=' from the text. > > Also, what stability level does this output have? (If you > > intend it to be scriptable, it ought to be Committed...) > > The stability level is addressed in the following item, which > you ask about next. > > > 5. Clarification of command-line output stability > > PSARC 2008/532 incorrectly defined command-line output > > stability to be Uncommitted; it should be Volatile. > > > > See above. You probably want to call out subcommands that are > > intended to produce scriptable output and specify their output > > stability separately. > > We have an RFE to further address scriptability in the command > output, and when we do that, will specify appropriate stability. > > This particular change (the addition of the -V option) was added > specifically because the project is delivering some scripts (smf > service methods) which benefitted from this option. > > So if you've added "-V" specifically to emit scriptable output, why > not declare the corresponding output format to be Committed now rather > than waiting? (Not a big deal, I just don't understand the motivation > for waiting.) I suppose the motivation is simply to wait until we are committing to a more coherent set of scriptable options. -renee From renee.sommerfeld@sun.com Fri Oct 30 21:33:57 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V4XuQ8003711 for ; Fri, 30 Oct 2009 21:33:56 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9V4Xu5u844897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 21:33:56 -0700 (PDT) Received: (from okie@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9V4Xuph844896; Fri, 30 Oct 2009 21:33:56 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: okie set sender to renee.sommerfeld@sun.com using -f Date: Fri, 30 Oct 2009 21:33:56 -0700 From: Renee Danson Sommerfeld To: Kais Belgaied Cc: Sebastien Roy , psarc-ext Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] Message-ID: <20091031043356.GA843481@jurassic-x4600.Eng.Sun.COM> References: <1256233211.302.36.camel@strat> <4AE8D173.201@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE8D173.201@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2342 On Wed, Oct 28, 2009 at 04:19:15PM -0700, Kais Belgaied wrote: > On 10/22/09 10:40, Sebastien Roy wrote: >> 11. Add default-route properties to IP Interface NCUs >> Two new properties, ipv4-default-route and ipv6-default-route, allow >> the user to specify statically configured default router address(es), >> to be associated with a specific interface. This provides a static >> alternative to a DHCP-specified default router, which may be associated >> with an interface if DHCP is in use. >> > > alternative to the DHCP-specified default router (returned by dhcpinfo I > presume) or in addition to it, as a second default router? In addition to it. dhcpagent applies anything returned by the DHCP server; that is out of nwam's hands. >> 17. Change upgrade behavior >> Upon upgrade, earlier nwam link and interface configuration will be >> imported into the User NCP. However, the Automatic NCP will be active >> by default. The rationale for this change is that the default config >> implemented in earlier nwam versions is the same as the Automatic NCP >> behavior, and we expect that most users will not have made changes, and >> therefore will want the Automatic NCP. The previously discussed change >> with respect to automatic addition/removal of inserted/removed links >> makes this especially desirable. Users who actually modified their >> earlier configuration (which should be a small minority) can switch to >> the User NCP to get their changes. >> >> There is one exception: if any static addresses are specified in the >> llp file, it is very clear that the user did in fact modify that file; >> therefore, if a static address is found, the User NCP will be active >> upon upgrade. >> >> Location profiles did not exist in earlier versions of NWAM, so any >> configuration that NWAM does based on Location specifications may >> overwrite previous system configuration. On upgrade, the existing >> configuration will be saved into a User location. This location will >> be activated if it includes an nsswitch.conf file which uses a nameservice >> other than DNS (i.e. a nameservice that cannot be configured by NWAM >> > > you mean other tan DNS *and* files, ? Correct. Specifically, NIS and LDAP. -renee From renee.sommerfeld@sun.com Fri Oct 30 21:59:14 2009 Received: from jurassic-x4600.sfbay.sun.com (jurassic.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9V4xE6t004256 for ; Fri, 30 Oct 2009 21:59:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9V4xE97846491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 21:59:14 -0700 (PDT) Received: (from okie@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9V4xE9E846490; Fri, 30 Oct 2009 21:59:14 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: okie set sender to renee.sommerfeld@sun.com using -f Date: Fri, 30 Oct 2009 21:59:13 -0700 From: Renee Danson Sommerfeld To: Nicolas Williams Cc: Sebastien Roy , psarc-ext Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] Message-ID: <20091031045913.GB843481@jurassic-x4600.Eng.Sun.COM> References: <1256233211.302.36.camel@strat> <20091022183122.GR892@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091022183122.GR892@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 5835 On Thu, Oct 22, 2009 at 01:31:22PM -0500, Nicolas Williams wrote: > On Thu, Oct 22, 2009 at 01:40:11PM -0400, Sebastien Roy wrote: > > * Add option to list subcommand, '-x', which includes explanation of state > > Why -x and not -v or -xv or anything more in keeping with other Solaris > commands? As Darren already commented, this usage is in keeping with svcs -x, which is why we chose -x. > > 4. Add '-V' option to nwamcfg's 'get' subcommand > > Default output from the get command is 'propname=propval'. For ease > > of scripting, the -V option outputs the value only. > > Elsewhere we use -H for scripting output. Why not here? mnemonic reasons? This is just one option useful for scripting (and was added now because we had some service method scripts that benefit from it); better scripting output is an RFE. The mnemonic we had in mind here was "Value-only". > > 7. Use 'enabled' property on all locations, not just those that have manual > > activation mode. This means that users can choose to activate any location > > at any given time, even if, for example, the location has conditional > > activation specified and its conditions are not currently met. > > > > If a user does activate a location, effectively overriding automatic > > selection by nwamd, that location must be explicitly disabled in order > > to restore automatic selection. > > That's weird. Will automatic selection be able to select a disabled > location? Yes. "Normal" behavior is for nwam to choose what location to enable. Users may create locations with rules about when they should be enabled. But this change makes it possible for the user to explicitly enable a location at any time. The only way to "undo" that action is to either explicitly disable that location, or explicitly enable a different one. NWAM won't override the user's choice. > Why not make it so that enabling a location disables a > special "automatic" location, and that you have to enable that one to > get back to automatic location selction? I'm not sure why you would want that. "automatic location selection" means that nwamd is choosing the best of all available locations, according to specific rules built in to the locations. Trying to map that behavior into some meta-location seems pretty weird to me. > > 10. Remove hosts-file, enable-svcs and disable-svcs properties from Location > > profile > > Use of the hosts-file property, to replace the /etc/hosts file when > > changing location, was not particularly useful, and could lead to > > confusion if some locations specified an alternate file, while others > > did not. > > > > The enable-svcs and disable-svcs properties could lead to similar > > problems, as naming a service in one of these states what the state of > > the service should be when the location is active, but is not explicit > > about what to do when the location is de-activated. The initial state > > is not taken into account, and really can't be, if each location may-- > > but is not required to--specify a state for a given service. > > You could always disable any services which were enabled by enabling a > location, when that location is disabled, even if the next location will > re-enable [some of] them (which would effectively result in a restart). > That would make a lot more sense to me. > > Similarly for hosts file contents. When a location that has a hosts > file is disabled, a hosts file suitable for disconnected operation > should be installed, even if the next location to be enabled will > specify a hosts file (at which point that hosts file gets installed). > > I see nothing really confusing about this... What if the next location doesn't specify a hosts file? It's not a requirement, and *should not* be a requirement. That file "suitable for disconnected operation" is unlikely to be appropriate. The same problem exists, on a larger scale, for the enabled/disabled services list. Not only is it an inappropriate requirement, but it's not at all scalable for each location to specify an enabled/disabled value for every service. That's the only way the enabled/disabled behavior from one location to the next can be completely deterministic. Yes, we could probably design some infrastructure to track all this, and make the behavior deterministic. But that would be diving into the realm of enhanced SMF profiles. The real answer, in my opinion, is for the NWAM team to work with the SMF team to make NWAM locations instances of SMF profiles, and to define, and implement, the features required in SMF to do this. > > 19. Remove support for renaming of NCU objects > > These objects map to physical links and IP interfaces; renaming thus > > involves vanity naming and questions of what exactly is intended. For > > phase 1, renaming of these objects will not be allowed; determining how > > exactly this should work and implementing appropriately remains future > > work. > > > > Renaming of links can be accommodated by disabling the nwam service, > > performing the rename, and then enabling nwam. The new link name will > > be detected and updated in the Automatic NCP; the User NCP will require > > the user to make appropriate updates. > > For links with MAC addresses the renaming of User NCPs could be done > automatically... The problem is, there are a number of incredibly different things that the admin might be trying to accomplish with a link rename. And the rational thing for NWAM to do is very different, depending on which of those things the admin actually wants. Link renaming is still a work in progress, so we felt that for NWAM to jump in with definitive behavior, one way or the other, was premature at this point. -renee From Sebastien.Roy@Sun.COM Wed Nov 11 07:33:40 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nABFXdmX025238 for ; Wed, 11 Nov 2009 07:33:39 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nABFXd0U005363 for ; Wed, 11 Nov 2009 07:33:39 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABFXdSk022360 for ; Wed, 11 Nov 2009 15:33:39 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSY00G00AQ61O00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Wed, 11 Nov 2009 08:33:39 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSY005KBB7MU2E0@mail-amer.sun.com>; Wed, 11 Nov 2009 08:33:23 -0700 (MST) Date: Wed, 11 Nov 2009 10:30:44 -0500 From: Sebastien Roy Subject: Re: Network Auto-Magic (NWAM) Phase 1 Updates [PSARC/2009/577 FastTrack timeout 10/29/2009] In-reply-to: <1256233211.302.36.camel@strat> Sender: Sebastien.Roy@Sun.COM To: psarc-ext Cc: Renee Danson Sommerfeld Message-id: <1257953444.2088.8.camel@strat> Organization: Sun Microsystems References: <1256233211.302.36.camel@strat> Status: RO Content-Length: 347 On Thu, 2009-10-22 at 13:40 -0400, Sebastien Roy wrote: > I'm sponsoring this case for Renee Danson Sommerfeld, it times out on > 10/29/2009. The release binding for this case is the same as the case > that it updates (PSARC 2008/532 NWAM Phase 1), namely Minor release > binding. This case was approved during last week's PSARC meeting. -Seb