From sacadmin Wed Mar 7 18:59:10 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l282xAYa012737 for ; Wed, 7 Mar 2007 18:59:10 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta0+Sun/8.14.0) with ESMTP id l282x9cO154308; Wed, 7 Mar 2007 18:59:09 -0800 (PST) Message-Id: <200703080259.l282x9cO154308@opal.eng.sun.com> To: psarc@sac.sfbay.sun.com Cc: nwam-core@sun.com Subject: Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <154306.1173322749.1@opal> Date: Wed, 07 Mar 2007 18:59:09 -0800 From: John Beck Status: RO Content-Length: 757 I am self-sponsoring this fast-track, which expires March 14, 2007 per above. The requested release binding is Minor and the Interface Taxonomy is Volatile. This is the first phase of the Network Auto-Magic Project. We are essentially productizing our prototype as an interim fix while we do the implementation of the larger project, PSARC 2007/132, which is scheduled for inception next Wednesday, March 14 (thanks Gary!). The idea is that at the conclusion of the inception review, we will go over this fast-track, by which time it should be clear how it is a step in the right direction. As for the details of this fast-track, the materials directory for this case has an nwamd.1m man page which explains it all. -- John http://blogs.sun.com/jbeck From sacadmin Wed Mar 7 19:08:38 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2838chK012890 for ; Wed, 7 Mar 2007 19:08:38 -0800 (PST) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2838bm2020036; Wed, 7 Mar 2007 19:08:38 -0800 (PST) Message-ID: <45EF7E35.1040403@sun.com> Date: Wed, 07 Mar 2007 19:08:37 -0800 From: Alan Coopersmith User-Agent: Thunderbird 2.0pre (X11/20070214) MIME-Version: 1.0 To: John Beck CC: psarc@sac.sfbay.sun.com, nwam-core@sun.com Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) References: <200703080259.l282x9cO154308@opal.eng.sun.com> In-Reply-To: <200703080259.l282x9cO154308@opal.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 439 John Beck wrote: > I am self-sponsoring this fast-track, which expires March 14, 2007 > per above. The requested release binding is Minor and the Interface > Taxonomy is Volatile. Since NWAM is already a public OpenSolaris project, is there any reason this isn't an Open case (i.e. mailed to psarc-ext instead of psarc)? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Mar 7 19:14:41 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l283Efav013028 for ; Wed, 7 Mar 2007 19:14:41 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta0+Sun/8.14.0) with ESMTP id l283EePO157223; Wed, 7 Mar 2007 19:14:40 -0800 (PST) Message-Id: <200703080314.l283EePO157223@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: Alan Coopersmith cc: psarc@sac.sfbay.sun.com, nwam-core@sun.com Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Wed, 07 Mar 2007 19:08:37 PST." <45EF7E35.1040403@sun.com> References: <200703080259.l282x9cO154308@opal.eng.sun.com> <45EF7E35.1040403@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2007 19:14:40 -0800 From: John Beck Status: RO Content-Length: 656 JBeck> I am self-sponsoring this fast-track, which expires March 14, 2007 JBeck> per above. The requested release binding is Minor and the Interface JBeck> Taxonomy is Volatile. Alan> Since NWAM is already a public OpenSolaris project, is there any reason Alan> this isn't an Open case (i.e. mailed to psarc-ext instead of psarc)? Not a good reason, just my lack of familiarity with the -ext list. I'll ask one of my PSARC buddies in the morning what the best way to handle this is, then do whatever he suggests. Or if this is a common enough mistake, you can just tell me now what the usual corrective action is. -- John http://blogs.sun.com/jbeck From sacadmin Thu Mar 8 04:52:15 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l28CqFUK021945 for ; Thu, 8 Mar 2007 04:52:15 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l28CqEUJ003515; Thu, 8 Mar 2007 07:52:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l28CqEOi003512; Thu, 8 Mar 2007 07:52:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17904.1789.744717.959107@gargle.gargle.HOWL> Date: Thu, 8 Mar 2007 07:52:13 -0500 From: James Carlson To: John Beck Cc: Alan Coopersmith , psarc@sac.sfbay.sun.com, nwam-core@sun.com Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) In-Reply-To: <200703080314.l283EePO157223@opal.eng.sun.com> References: <200703080259.l282x9cO154308@opal.eng.sun.com> <45EF7E35.1040403@sun.com> <200703080314.l283EePO157223@opal.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1088 John Beck writes: > JBeck> I am self-sponsoring this fast-track, which expires March 14, 2007 > JBeck> per above. The requested release binding is Minor and the Interface > JBeck> Taxonomy is Volatile. > > Alan> Since NWAM is already a public OpenSolaris project, is there any reason > Alan> this isn't an Open case (i.e. mailed to psarc-ext instead of psarc)? > > Not a good reason, just my lack of familiarity with the -ext list. I'll ask > one of my PSARC buddies in the morning what the best way to handle this is, > then do whatever he suggests. Or if this is a common enough mistake, you can > just tell me now what the usual corrective action is. My ears are burning. The corrective action is marking the IAM file as 'open' and resending the original announcement to psarc-ext, along with a note warning people commenting on the case that it's open. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jbeck@eng.sun.com Thu Mar 8 07:27:33 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l28FRXaJ024243 for ; Thu, 8 Mar 2007 07:27:33 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta0+Sun/8.14.0) with ESMTP id l28FRSLr183120; Thu, 8 Mar 2007 07:27:28 -0800 (PST) Message-Id: <200703081527.l28FRSLr183120@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: psarc-ext@sac.sfbay.sun.com Cc: nwam-discuss@opensolaris.org Subject: Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg MIME-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1173367430_1580000" Date: Thu, 08 Mar 2007 07:27:28 -0800 From: John Beck Status: RO Content-Length: 4994 This is a multipart MIME message. --==_Exmh_1173367430_1580000 (For those thinking this looks like a repeat, I initially sent this to our internal mailing lists due to a misunderstanding on my part. I am now sending it again to the proper mailing lists with external coverage. Note that the Exposure on this case has been set to open.) I am self-sponsoring this fast-track, which expires March 14, 2007 per below. The requested release binding is Minor and the Interface Taxonomy is Volatile. This is the first phase of the Network Auto-Magic Project. We are essentially productizing our prototype as an interim fix while we do the implementation of the larger project, PSARC 2007/132, which is scheduled for inception next Wednesday, March 14. The idea is that at the conclusion of the inception review, we will go over this fast-track, by which time it should be clear how it is a step in the right direction. As for the details of this fast-track, see the attached nwamd.1m man page which explains it all; I have also placed a copy of this man page in the materials directory of this case. -- John http://blogs.sun.com/jbeck --==_Exmh_1173367430_1580000 Content-Type: text/plain ; name="nwamd.1m"; charset=us-ascii Content-Description: nwamd(1m) man page System Administration Commands nwamd(1M) NAME nwamd - network auto-magic daemon SYNOPSIS /lib/inet/nwamd DESCRIPTION nwamd is a system daemon to manage network interfaces. This daemon is started automatically and should not be invoked directly. It does not constitute a programming interface, but is classified as a private interface. OPERATION Whether this daemon is enabled or not depends on your installation medium. To check: % svcs svc:/network/physical If the value listed in the FMRI column is "svc:/network/physical:default", then the daemon is disabled; conversely, if the value listed is "svc:/network/physical:nwam", then the daemon is enabled. To go from manual mode to auto-magic mode: % svcadm disable svc:/network/physical:default % svcadm enable svc:/network/physical:nwam To go from auto-magic mode to manual mode: % svcadm disable svc:/network/physical:nwam % svcadm enable svc:/network/physical:default Warning: when switching modes like this, all network interfaces will be brought down then back up, thus if a different IP address is configured in this process, existing applications and sessions may be disrupted. PROFILES Note that all interfaces list here are Volatile and may change in a future release. They are documented here so that those wishing to experiment with this may do so. Profiles are a mechanism for making multiple related changes to the system configuration after IP service is available. There is not direct support for them yet, but a "roll your own" mechanism is provided for now. Once an interface is brought up and an IP address is configured for it, the daemon looks for /etc/nwam/ulp/check-conditions; if it exists and is executable, it is run as a non-root user with basic permissions. This is expected to print a single line of output, which is the name of the profile which the user wishes to be activated based on the current conditions. If such a line is read successfully (foo in this example), then /etc/nwam/ulp/foo/bringup is executed. Likewise, when the interface gets torn down for whatever reason, /etc/nwam/ulp/foo/teardown is executed. The bringup and teardown scripts are invoked via pfexec(1) with default basic privileges. Samples for each of these scripts can be found at: * http://opensolaris.org/os/project/nwam/prototype/check-conditions * http://opensolaris.org/os/project/nwam/prototype/bringup * http://opensolaris.org/os/project/nwam/prototype/teardown ATTRIBUTES See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ | Availability | SUNWcsr | +-----------------------------+-----------------------------+ | Interface Stability | Volatile | +-----------------------------+-----------------------------+ SEE ALSO svcs(1), svcadm(1M), attributes(5), smf(5) NOTES The networking service is managed by the service management facility, smf(5), under the service identifier: svc:/network/physical:default Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command. --==_Exmh_1173367430_1580000-- From Darren.Moffat@Sun.COM Thu Mar 8 07:36:39 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l28FadrK024480 for ; Thu, 8 Mar 2007 07:36:39 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l28Facxa028408 for ; Thu, 8 Mar 2007 07:36:38 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l28FaWwW007148 for ; Thu, 8 Mar 2007 15:36:32 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEL00501CN8LP00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.eng.sun.com; Thu, 08 Mar 2007 15:36:32 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEL00ITVCOT9010@d1-emea-09.sun.com>; Thu, 08 Mar 2007 15:36:29 +0000 (GMT) Date: Thu, 08 Mar 2007 15:36:29 +0000 From: Darren J Moffat Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <200703081527.l28FRSLr183120@opal.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: John Beck Cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Message-id: <45F02D7D.5090504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070130) Status: RO Content-Length: 1224 When dealing with WiFi links does Phase 0 use libwladm or does it like the original prototype code use wificonfig directly ? What if anything will be the necessary transition steps for those of us that currently use the prototype when this project integrates - I don't think this question actually has any real impact on the outcome of this fast-track I just want to know and I think this is a reasonable place to ask the question. > The bringup and > teardown scripts are invoked via pfexec(1) with default > basic privileges. So this is a change from the prototype. My current bringup/teardown scripts do "nasty" things like play with the routing and arp tables so that I can NAT my local Solaris and Linux zones. With Phase 0 how do I change the privileges that the bringup/teardown script is given ? Do I just add entries to a specific profile in exec_attr(4) like this: Network Administration:solaris:cmd:::/etc/nwam/ulp/foo/bringup:privs=sys_net_config,basic If it is available and is something like that can this case please list the name of the profile that the bringup/teardown scripts need to be listed in. If it isn't available then that is okay too. -- Darren J Moffat From jbeck@eng.sun.com Thu Mar 8 08:01:07 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l28G16fU025178 for ; Thu, 8 Mar 2007 08:01:06 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta0+Sun/8.14.0) with ESMTP id l28G0xHJ183857; Thu, 8 Mar 2007 08:00:59 -0800 (PST) Message-Id: <200703081600.l28G0xHJ183857@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: Darren J Moffat cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Thu, 08 Mar 2007 15:36:29 GMT." <45F02D7D.5090504@Sun.COM> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <45F02D7D.5090504@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Mar 2007 08:00:59 -0800 From: John Beck Status: RO Content-Length: 1032 Darren> When dealing with WiFi links does Phase 0 use libwladm or does it Darren> like the original prototype code use wificonfig directly ? Both: we have converted one of the five calls and may convert more. We may get to the ideal state of just using libwladm, but we're not sure yet. Not that this is an architectural issue. :-) Darren> What if anything will be the necessary transition steps for those Darren> of us that currently use the prototype when this project integrates Darren> - I don't think this question actually has any real impact on the Darren> outcome of this fast-track I just want to know ... `pkgrm SUNWnwam` should suffice. Short of that, disabling and deleting the profiled service may do it. Doing exactly this testing is on my schedule for later today; I'll let you know if more than this is required. Darren> With Phase 0 how do I change the privileges that the bringup/teardown Darren> script is given ? Michael should be able to answer this later today. -- John http://blogs.sun.com/jbeck From peter.memishian@sun.com Thu Mar 8 22:45:17 2007 Received: from dhcp-cbjs05-219-32.PRC.Sun.COM (dhcp-cbjs05-219-32.PRC.Sun.COM [129.158.219.156]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l296jGAq016523 for ; Thu, 8 Mar 2007 22:45:16 -0800 (PST) Received: from dhcp-cbjs05-219-32.PRC.Sun.COM (localhost [127.0.0.1]) by dhcp-cbjs05-219-32.PRC.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id l296ifqM009017; Fri, 9 Mar 2007 14:44:41 +0800 (CST) Received: (from meem@localhost) by dhcp-cbjs05-219-32.PRC.Sun.COM (8.13.8+Sun/8.13.8/Submit) id l296icBB009014; Fri, 9 Mar 2007 14:44:38 +0800 (CST) X-Authentication-Warning: dhcp-cbjs05-219-32.PRC.Sun.COM: meem set sender to peter.memishian@sun.com using -f From: Peter Memishian MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17905.598.629633.393492@gargle.gargle.HOWL> Date: Fri, 9 Mar 2007 14:44:38 +0800 To: John Beck Cc: Darren J Moffat , nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-Reply-To: <200703081600.l28G0xHJ183857@opal.eng.sun.com> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <45F02D7D.5090504@Sun.COM> <200703081600.l28G0xHJ183857@opal.eng.sun.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Reply-To: peter.memishian@sun.com Status: RO Content-Length: 523 > Darren> When dealing with WiFi links does Phase 0 use libwladm or does it > Darren> like the original prototype code use wificonfig directly ? > > Both: we have converted one of the five calls and may convert more. We > may get to the ideal state of just using libwladm, but we're not sure yet. > Not that this is an architectural issue. :-) Maybe I've misunderstood the ":-)", but using wificonfig programmatically when it is not built for such use certainly seems like an architectural issue to me. -- meem From Darren.Moffat@Sun.COM Fri Mar 9 02:50:41 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l29AoelX020680 for ; Fri, 9 Mar 2007 02:50:40 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l29Aod2x004427 for ; Fri, 9 Mar 2007 02:50:40 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29AoX6A019520 for ; Fri, 9 Mar 2007 10:50:34 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEM00101TYRFF00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sac.eng.sun.com; Fri, 09 Mar 2007 10:50:33 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEM002QVU480J00@d1-emea-09.sun.com>; Fri, 09 Mar 2007 10:50:33 +0000 (GMT) Date: Fri, 09 Mar 2007 10:50:22 +0000 From: Darren J Moffat Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <200703081527.l28FRSLr183120@opal.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: John Beck Cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Message-id: <45F13BEE.5090402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 358 One other question occurred to me last night. If a machine running the phase 0 bits has the TX packages installed what is the expected behaviour ? Is nwamd expected to be able to provide a working TX system in this case (eg a laptop) or is the requirement that you disable nwam if you are running TX until some later phase of nwam ? -- Darren J Moffat From Joel.Buckley@Sun.COM Fri Mar 9 08:42:51 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l29Ggoej025688 for ; Fri, 9 Mar 2007 08:42:50 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l29Ggol0027418 for ; Fri, 9 Mar 2007 08:42:50 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29Ggosp029982 for ; Fri, 9 Mar 2007 16:42:50 GMT Received: from sun.com ([129.147.156.114]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JEN004IDAFD0N00@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Fri, 09 Mar 2007 09:42:50 -0700 (MST) Received: from [129.147.62.30] (Forwarded-For: 129.150.49.249) by bedge3-mail1.central.sun.com (mshttpd); Fri, 09 Mar 2007 09:42:49 -0700 Date: Fri, 09 Mar 2007 09:42:49 -0700 From: Joel Buckley Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <17905.598.629633.393492@gargle.gargle.HOWL> To: John Beck Cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_xMM1/sf77EVpO3swy71wGw)" Content-language: en X-Accept-Language: en Priority: normal References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <45F02D7D.5090504@Sun.COM> <200703081600.l28G0xHJ183857@opal.eng.sun.com> <17905.598.629633.393492@gargle.gargle.HOWL> Status: RO Content-Length: 1243 This is a multi-part message in MIME format. --Boundary_(ID_xMM1/sf77EVpO3swy71wGw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline John, Perhaps a bit off topic... but a potential application :) Could NWAM be utilized to control IP configurations in a 2 node "Active/Standby" configuration? e.g. poor-mans cluster? Does/could NWAM be tied onto FMA? e.g. Keep application service availability tied to network IP Up/Down availability? Cheers, Joel. Joel.Buckley@Sun.COM JIST Development Lead 303-272-5556, x75556 "Luck is a Planned Event." --Boundary_(ID_xMM1/sf77EVpO3swy71wGw) Content-type: text/x-vcard; name=Joel.Buckley.vcf; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Joel.Buckley.vcf Content-description: Card for Joel Buckley begin:vcard n:Buckley;Joel fn:Joel W. Buckley tel;fax:303-272-4194 tel;home:720-226-9370 tel;work:303-272-5556 url:sse.sfbay/interop/jist org:Storage Group;System Test adr:;;500 Eldorado Blvd., BRM05, Room3196;Broomfield;Colorado;80021-3400;USA version:2.1 email;internet:Joel.Buckley@Sun.COM title:JIST Development Lead end:vcard --Boundary_(ID_xMM1/sf77EVpO3swy71wGw)-- From Michael.Hunter@Sun.COM Fri Mar 9 15:01:34 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l29N1YvC004236 for ; Fri, 9 Mar 2007 15:01:34 -0800 (PST) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l29MxY5J002733 for ; Fri, 9 Mar 2007 14:59:34 -0800 (PST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l29MxTBg019967 for ; Fri, 9 Mar 2007 14:59:29 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEN00801RTHFT00@d1-sfbay-09.sun.com> (original mail from Michael.Hunter@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 09 Mar 2007 14:59:29 -0800 (PST) Received: from sun.com ([129.146.106.107]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEN002M4RV0WP11@d1-sfbay-09.sun.com>; Fri, 09 Mar 2007 14:59:25 -0800 (PST) Date: Fri, 09 Mar 2007 14:59:18 -0800 From: Michael Hunter Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: Sender: Michael.Hunter@Sun.COM To: Joel Buckley Cc: John Beck , nwam-discuss@opensolaris.org Message-id: <20070309145918.00003ee1@maudite> Organization: SMI MIME-version: 1.0 X-Mailer: Claws Mail 2.7.0-csw (GTK+ 2.10.1; sparc-sun-solaris2.8) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <45F02D7D.5090504@Sun.COM> <200703081600.l28G0xHJ183857@opal.eng.sun.com> <17905.598.629633.393492@gargle.gargle.HOWL> Status: RO Content-Length: 894 On Fri, 09 Mar 2007 09:42:49 -0700 Joel Buckley wrote: > John, > > Perhaps a bit off topic... but a potential application :) Bcc'ng PSARC as this is OT. We should continue this discussion in nwam-discuss@opensolaris.org. > > Could NWAM be utilized to control IP configurations in a 2 node > "Active/Standby" configuration? e.g. poor-mans cluster? > > Does/could NWAM be tied onto FMA? e.g. Keep application service > availability tied to network IP Up/Down availability? [...] We havn't talked about using NWAM for things like that. For phase 0 the functionality is just not rich enough to do anything useful in that area. But in phase 1 there are some hooks which might allow you to do some sort of slightly warm standby. Read the design on opensolaris.org/os/projects/nwam and comment on nwam-discuss@opensolaris.org if you have further questions. mph From gww@eng.sun.com Wed Mar 14 09:35:46 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2EGZkdZ003765 for ; Wed, 14 Mar 2007 09:35:46 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2EGZjXl009159; Wed, 14 Mar 2007 09:35:45 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2EHZWW9009322; Wed, 14 Mar 2007 09:35:32 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2EHZWdt009321; Wed, 14 Mar 2007 09:35:32 -0800 (PST) Date: Wed, 14 Mar 2007 09:35:32 -0800 (PST) From: Gary Winiger Message-Id: <200703141735.l2EHZWdt009321@marduk.eng.sun.com> To: jbeck@eng.sun.com, psarc-ext@sac.sfbay.sun.com Cc: nwam-discuss@opensolaris.org Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) Status: RO Content-Length: 287 > % svcadm disable svc:/network/physical:nwam > % svcadm enable svc:/network/physical:default As this is equivalent to adding a new service manifest, how does network/physical comply with the smf policy? http://opensolaris.org/os/community/arc/policies/SMF-policy/ Gary.. From jbeck@eng.sun.com Wed Mar 14 09:48:29 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2EGmSIV004978 for ; Wed, 14 Mar 2007 09:48:28 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta1+Sun/8.14.0) with ESMTP id l2EGmKu3290931; Wed, 14 Mar 2007 09:48:20 -0700 (PDT) Message-Id: <200703141648.l2EGmKu3290931@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: Gary Winiger cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Wed, 14 Mar 2007 09:35:32 -0800." <200703141735.l2EHZWdt009321@marduk.eng.sun.com> References: <200703141735.l2EHZWdt009321@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Mar 2007 09:48:20 -0700 From: John Beck Status: RO Content-Length: 427 JBeck> % svcadm disable svc:/network/physical:nwam JBeck> % svcadm enable svc:/network/physical:default Gary> As this is equivalent to adding a new service manifest, Gary> how does network/physical comply with the smf policy? Gary> http://opensolaris.org/os/community/arc/policies/SMF-policy/ I'm not sure of the exact compliance, but I will work with you off-line to get it up to spec. -- John http://blogs.sun.com/jbecke From gww@eng.sun.com Wed Mar 14 09:51:41 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2EGpfBj005098 for ; Wed, 14 Mar 2007 09:51:41 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2EGpf60012983; Wed, 14 Mar 2007 09:51:41 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l2EHpSHn009356; Wed, 14 Mar 2007 09:51:28 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l2EHpS3C009355; Wed, 14 Mar 2007 09:51:28 -0800 (PST) Date: Wed, 14 Mar 2007 09:51:28 -0800 (PST) From: Gary Winiger Message-Id: <200703141751.l2EHpS3C009355@marduk.eng.sun.com> To: gww@eng.sun.com, jbeck@eng.sun.com Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136) Cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org X-Sun-Charset: US-ASCII Status: RO Content-Length: 594 > JBeck> % svcadm disable svc:/network/physical:nwam > JBeck> % svcadm enable svc:/network/physical:default > > Gary> As this is equivalent to adding a new service manifest, > Gary> how does network/physical comply with the smf policy? > Gary> http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > I'm not sure of the exact compliance, but I will work with you > off-line to get it up to spec. Compliance should be straight forward and something desirable anyway to fit into an appropriate Rights Profile so that a user can switch to nwam if it's not already enabled. Gary.. From jbeck@eng.sun.com Thu Mar 15 13:49:05 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FKn4IJ018398 for ; Thu, 15 Mar 2007 13:49:04 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta1+Sun/8.14.0) with ESMTP id l2FKmxh6348108; Thu, 15 Mar 2007 13:48:59 -0700 (PDT) Message-Id: <200703152048.l2FKmxh6348108@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: my message of "Thu, 08 Mar 2007 07:27:28 PST." <200703081527.l28FRSLr183120@opal.eng.sun.com> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1173991697_3415650" Date: Thu, 15 Mar 2007 13:48:59 -0700 From: John Beck Status: RO Content-Length: 5131 This is a multipart MIME message. --==_Exmh_1173991697_3415650 Content-Type: text/plain; charset=us-ascii This case was "almost" approved at yesterday's meeting, meaning that * Bill asked for some extra information in the man page; this has been provided in the new WIRELESS section on which Bill and I just converged. * Joe asked for more time to finish reading up on everything; he sent me mail late yesterday indicating his satisfaction. So I have now marked the case closed approved with today's date. Attached is the revised nwamd(1m) man page. -- John http://blogs.sun.com/jbeck --==_Exmh_1173991697_3415650 Content-Type: text/plain ; name="nwamd.1m"; charset=us-ascii Content-Description: nwamd(1m) man page System Administration Commands nwamd(1M) NAME nwamd - network auto-magic daemon SYNOPSIS /lib/inet/nwamd DESCRIPTION nwamd is a system daemon to manage network interfaces. This daemon is started automatically and should not be invoked directly. It does not constitute a programming interface, but is classified as a private interface. OPERATION Whether this daemon is enabled or not depends on your installation medium. To check: % svcs svc:/network/physical If the value listed in the FMRI column is "svc:/network/physical:default", then the daemon is disabled; conversely, if the value listed is "svc:/network/physical:nwam", then the daemon is enabled. To go from manual mode to auto-magic mode: % svcadm disable svc:/network/physical:default % svcadm enable svc:/network/physical:nwam To go from auto-magic mode to manual mode: % svcadm disable svc:/network/physical:nwam % svcadm enable svc:/network/physical:default Warning: when switching modes like this, all network interfaces will be brought down then back up, thus if a different IP address is configured in this process, existing applications and sessions may be disrupted. PROFILES Note that all interfaces list here are Volatile and may change in a future release. They are documented here so that those wishing to experiment with this may do so. Profiles are a mechanism for making multiple related changes to the system configuration after IP service is available. There is not direct support for them yet, but a "roll your own" mechanism is provided for now. Once an interface is brought up and an IP address is configured for it, the daemon looks for /etc/nwam/ulp/check-conditions; if it exists and is executable, it is run as a non-root user with basic permissions. This is expected to print a single line of output, which is the name of the profile which the user wishes to be activated based on the current conditions. If such a line is read successfully (foo in this example), then /etc/nwam/ulp/foo/bringup is executed. Likewise, when the interface gets torn down for whatever reason, /etc/nwam/ulp/foo/teardown is executed. The bringup and teardown scripts are invoked via pfexec(1) with default basic privileges. Samples for each of these scripts can be found at: * http://opensolaris.org/os/project/nwam/prototype/check-conditions * http://opensolaris.org/os/project/nwam/prototype/bringup * http://opensolaris.org/os/project/nwam/prototype/teardown WIRELESS When no wired link is available, a scan for wireless LANs will be done, and the resulting list offered via a GUI pop-up to prompt the console user to select his/her preference. If a successful connection is made, the WLAN in question will be stored in the plain text file /etc/nwam/known_wifi_nets and subsequently the daemon may connect to any WLAN in that list without prompting again. Should a user wish to revoke his/her preference for a WLAN in that list, editing the file and deleting the line with the entry should suffice. Note, however, that this interface is Volatile and may change in a future release. ATTRIBUTES See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ | Availability | SUNWcsr | +-----------------------------+-----------------------------+ | Interface Stability | Volatile | +-----------------------------+-----------------------------+ SEE ALSO svcs(1), svcadm(1M), attributes(5), smf(5) NOTES The networking service is managed by the service management facility, smf(5), under the service identifier: svc:/network/physical:default Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(1M). The service's status can be queried using the svcs(1) command. --==_Exmh_1173991697_3415650-- From Ed.Gould@Sun.COM Thu Mar 15 13:59:44 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FKxiFU018971 for ; Thu, 15 Mar 2007 13:59:44 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l2FKx4hD001897 for ; Thu, 15 Mar 2007 13:59:04 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2FKwxTN017305 for ; Thu, 15 Mar 2007 12:58:59 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEY00201Q9R0800@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Thu, 15 Mar 2007 13:58:59 -0700 (PDT) Received: from [192.168.0.10] ([75.61.66.242]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEY00MAIQA6DBZI@d1-sfbay-10.sun.com>; Thu, 15 Mar 2007 13:58:54 -0700 (PDT) Date: Thu, 15 Mar 2007 13:58:53 -0700 From: Ed Gould Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <200703152048.l2FKmxh6348108@opal.eng.sun.com> Sender: Ed.Gould@Sun.COM To: John Beck Cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> Status: RO Content-Length: 201 On Mar 15, 2007, at 13:48, John Beck wrote: > Attached is the revised nwamd(1m) man page. I presume a tech writer will edit this before it goes to customers. There are English errors in it. --Ed From jbeck@eng.sun.com Thu Mar 15 14:47:26 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FLlQau019775 for ; Thu, 15 Mar 2007 14:47:26 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta1+Sun/8.14.0) with ESMTP id l2FLlK0L349516; Thu, 15 Mar 2007 14:47:20 -0700 (PDT) Message-Id: <200703152147.l2FLlK0L349516@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: Ed Gould cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Thu, 15 Mar 2007 13:58:53 PDT." References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Mar 2007 14:47:20 -0700 From: John Beck Status: RO Content-Length: 349 JBeck> Attached is the revised nwamd(1m) man page. Ed> I presume a tech writer will edit this before it goes to customers. Correct. Ed> There are English errors in it. Thanks for the off-line feedback about the typo and the unclear "here" reference; I fixed them both (s/list here/listed in this section/). -- John http://blogs.sun.com/jbeck From jbeck@eng.sun.com Thu Mar 15 16:30:29 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FNUTBG021065 for ; Thu, 15 Mar 2007 16:30:29 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta1+Sun/8.14.0) with ESMTP id l2FNUNLp351741; Thu, 15 Mar 2007 16:30:24 -0700 (PDT) Message-Id: <200703152330.l2FNUNLp351741@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: my message of "Thu, 15 Mar 2007 13:48:59 PDT." <200703152048.l2FKmxh6348108@opal.eng.sun.com> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Mar 2007 16:30:23 -0700 From: John Beck Status: RO Content-Length: 1208 > Bill asked for some extra information in the man page; this has been > provided in the new WIRELESS section on which Bill and I just converged. > So I have now marked the case closed approved with today's date. > Attached is the revised nwamd(1m) man page. We just realized that there was an (unintentional) omission in nwamd(1m): the limitation of only one link being active at a time. This was made clear in the materials for PSARC 2007/132 (the umbrella NWAM case), and it was also discussed in the inception review for 132 yesterday. After discussing this will Bill, I am correcting this oversight by adding the following text to nwamd(1m) at the end of the OPERATIONS section: Note that in auto-magic mode, there is a limitation that only one link is active at a time. This mode is thus not recommended for machines which use more than one link at once. For machines with wired and wireless links, wired is preferred by default, although this can be adjusted by altering the order of the lines in the plain text file /etc/nwam/llp. Note, however, that this interface is Volatile and may change in a future release. -- John http://blogs.sun.com/jbeck From jek3@sun.com Thu Mar 15 16:44:29 2007 Received: from jurassic.eng.sun.com (jurassic-68-b.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FNiTwj021157 for ; Thu, 15 Mar 2007 16:44:29 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2FNiORL403622; Thu, 15 Mar 2007 16:44:24 -0700 (PDT) Message-ID: <45F9D992.4020904@sun.com> Date: Thu, 15 Mar 2007 13:41:06 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: John Beck CC: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> In-Reply-To: <200703152330.l2FNUNLp351741@opal.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 866 John Beck wrote: > Note that in auto-magic mode, there is a limitation that > only one link is active at a time. This mode is thus not > recommended for machines which use more than one link at > once. For machines with wired and wireless links, wired > is preferred by default, although this can be adjusted by > altering the order of the lines in the plain text file > /etc/nwam/llp. Note, however, that this interface is > Volatile and may change in a future release. > Which highlights Ed's expressed concern that (I think) he would be OK with this if changing means that /etc/nwam/llp disappears, but that making no other change than deciding its Private in a future release may not sit well with him. Did you follow up with Ed on this? I don't recall a Public interface (any level) ever going Private. - jek3 From jbeck@eng.sun.com Thu Mar 15 16:55:25 2007 Received: from opal.eng.sun.com (opal.SFBay.Sun.COM [129.146.228.54]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2FNtPdx021666 for ; Thu, 15 Mar 2007 16:55:25 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.14.1.Beta1+Sun/8.14.0) with ESMTP id l2FNtJRK352220; Thu, 15 Mar 2007 16:55:19 -0700 (PDT) Message-Id: <200703152355.l2FNtJRK352220@opal.eng.sun.com> X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3 To: Joseph Kowalski cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Thu, 15 Mar 2007 13:41:06 -1000." <45F9D992.4020904@sun.com> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Mar 2007 16:55:19 -0700 From: John Beck Status: RO Content-Length: 1151 Joseph> Which highlights Ed's expressed concern that (I think) he would be OK Joseph> with this if changing means that /etc/nwam/llp disappears, but that Joseph> making no other change than deciding its Private in a future release Joseph> may not sit well with him. Joseph> Did you follow up with Ed on this? Joseph> I don't recall a Public interface (any level) ever going Private. I haven't followed up directly with Ed, but I think I can clarify myself here. Yesterday in the inception meeting for 2007/132 I made a comment about something being private which seemed to make Ed uncomfortable. There was not time to explore that issue then, but now I think I understand it. I didn't realize until just now that Volatile is in the Public set of interface classifications as opposed to the Private set. Now that I understand that, I agree that it would not be appropriate to take a Public interface Private. For our interfaces which are Volatile, it appears we can change or remove them at any time for any reason, which was what I wanted. Sorry for not being fully up to speed on the new classifications. -- John http://blogs.sun.com/jbeck From Ed.Gould@Sun.COM Thu Mar 15 17:03:09 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2G039I4021742 for ; Thu, 15 Mar 2007 17:03:09 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2G0184o003339 for ; Thu, 15 Mar 2007 17:01:08 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2G013Ih008128 for ; Thu, 15 Mar 2007 16:01:03 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEY00F01YLZXH00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Thu, 15 Mar 2007 17:01:03 -0700 (PDT) Received: from [192.168.0.10] ([75.61.66.242]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEY002FYYPNWP77@d1-sfbay-09.sun.com>; Thu, 15 Mar 2007 17:00:59 -0700 (PDT) Date: Thu, 15 Mar 2007 17:00:59 -0700 From: Ed Gould Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <45F9D992.4020904@sun.com> Sender: Ed.Gould@Sun.COM To: Joseph Kowalski Cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, John Beck Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> Status: RO Content-Length: 1335 On Mar 15, 2007, at 16:41, Joseph Kowalski wrote: > Which highlights Ed's expressed concern that (I think) he would be OK > with this if changing means that /etc/nwam/llp disappears, but that > making > no other change than deciding its Private in a future release may not > sit > well with him. Yes. I'm fine with this Volatile interface either disappearing completely or becoming Private with no incompatible changes ever. Note especially the word "ever." That is, it is not acceptable to me to make it Private in one release (even if there are no incompatible changes in that release), then make incompatible changes later. It may be hard to remember that this is a "frozen" interface if it becomes Private (although perhaps Sun Private might do the trick). If the interface is going to vanish in a future release, I would want the case supporting that release to include the transition plan. Similarly, if it becomes Private, I would want that case to describe how the unique status of the interface will be remembered. > Did you follow up with Ed on this? They hadn't, but Joe has summarized my concern correctly, so I presume it was understood at the meeting. > I don't recall a Public interface (any level) ever going Private. It seems like a regression to do so, so I think it is worth avoiding. --Ed From Ed.Gould@Sun.COM Thu Mar 15 17:09:47 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2G09lci021794 for ; Thu, 15 Mar 2007 17:09:47 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l2G07lcT008299 for ; Thu, 15 Mar 2007 17:07:47 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2G07grG026701 for ; Thu, 15 Mar 2007 16:07:42 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JEY00201YW50S00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Thu, 15 Mar 2007 17:07:42 -0700 (PDT) Received: from [192.168.0.10] ([75.61.66.242]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEY002L9Z0TWP97@d1-sfbay-09.sun.com>; Thu, 15 Mar 2007 17:07:41 -0700 (PDT) Date: Thu, 15 Mar 2007 17:07:41 -0700 From: Ed Gould Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <200703152355.l2FNtJRK352220@opal.eng.sun.com> Sender: Ed.Gould@Sun.COM To: John Beck Cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, Joseph Kowalski Message-id: <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> Status: RO Content-Length: 608 On Mar 15, 2007, at 16:55, John Beck wrote: > I didn't realize until just now that Volatile is in the Public set of > interface classifications as opposed to the Private set. The general rule is this: If a customer is allowed to use it (and especially if they're expected to use it), it's Public. If it's Public, it must be documented. In general, Private interfaces are not documented (except internally, of course); if there is public documentation, it must note that the interface is not for public use. The presence of an interface in a header file does not constitute documentation. --Ed From carlsonj@phorcys.east.sun.com Fri Mar 16 06:24:57 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2GDOvBJ002575 for ; Fri, 16 Mar 2007 06:24:57 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2GDOtpo002752; Fri, 16 Mar 2007 09:24:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2GDOtEX002749; Fri, 16 Mar 2007 09:24:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17914.39590.716930.683654@gargle.gargle.HOWL> Date: Fri, 16 Mar 2007 09:24:54 -0400 From: James Carlson To: Ed Gould Cc: Joseph Kowalski , nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, John Beck Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-Reply-To: References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2711 Ed Gould writes: > Yes. I'm fine with this Volatile interface either disappearing > completely or becoming Private with no incompatible changes ever. Note > especially the word "ever." I think that pretty much puts the last nail in the coffin for Volatile as a generally usable classification. The very definition of Volatile is that it allows for incompatible change at any time -- including in Micro releases and patches. That's much more often than "no incompatible change ever." Is it your intention that we should just disallow all "experimental" projects? That's effectively what this project is attempting to do, and the implication of disallowing the use of Volatile for the fluid bits. I'm somewhat in accord with that prohibition, but I think we have a clash with senior management here. > If the interface is going to vanish in a future release, I would want > the case supporting that release to include the transition plan. A transition plan for Volatile? When do we require that? Ed Gould writes: > The general rule is this: If a customer is allowed to use it (and > especially if they're expected to use it), it's Public. If it's > Public, it must be documented. In general, Private interfaces are not > documented (except internally, of course); if there is public > documentation, it must note that the interface is not for public use. > The presence of an interface in a header file does not constitute > documentation. All correct, but "documented" doesn't always mean man pages. It does for "Committed" interfaces, but those at other stability levels can use whatever's appropriate -- white pages, READMEs, blogs, et cetera. For what it's worth, I think this interface actually meets most of the criteria for Uncommitted, but since the express intent of the project team is to deliver one or more experimental versions, and to do so over the life of just one release, Volatile makes much more sense. Anything else would be a straightjacket. Also note that basically none of this matters a whit. You could call it Committed if you like. Because our taxonomy is based on releases, and this project isn't targeting an Update, the interface is not frozen until Nevada actually ships as a release. We apparently have no plans to do that at all at any point in the future. So, by the time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't shipped, we'll still be able to make incompatible changes, even in Committed interfaces. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Ed.Gould@Sun.COM Fri Mar 16 07:56:12 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2GEuCFs004378 for ; Fri, 16 Mar 2007 07:56:12 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l2GEuC3a020491 for ; Fri, 16 Mar 2007 07:56:12 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2GEu720008586 for ; Fri, 16 Mar 2007 06:56:07 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF00060145BUA00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 16 Mar 2007 07:56:07 -0700 (PDT) Received: from [192.168.0.10] ([75.61.66.242]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF0002PZ45IWPA9@d1-sfbay-09.sun.com>; Fri, 16 Mar 2007 07:56:06 -0700 (PDT) Date: Fri, 16 Mar 2007 07:56:06 -0700 From: Ed Gould Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <17914.39590.716930.683654@gargle.gargle.HOWL> Sender: Ed.Gould@Sun.COM To: James Carlson Cc: Joseph Kowalski , nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, John Beck Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> <17914.39590.716930.683654@gargle.gargle.HOWL> Status: RO Content-Length: 2178 On Mar 16, 2007, at 6:24, James Carlson wrote: > Ed Gould writes: >> Yes. I'm fine with this Volatile interface either disappearing >> completely or becoming Private with no incompatible changes ever. >> Note >> especially the word "ever." > > I think that pretty much puts the last nail in the coffin for Volatile > as a generally usable classification. The very definition of Volatile > is that it allows for incompatible change at any time -- including in > Micro releases and patches. > > That's much more often than "no incompatible change ever." > > Is it your intention that we should just disallow all "experimental" > projects? That's effectively what this project is attempting to do, > and the implication of disallowing the use of Volatile for the fluid > bits. I'm somewhat in accord with that prohibition, but I think we > have a clash with senior management here. No, I wasn't intending to ban experimental interfaces. And maybe that's the right way to look at this interface, too. Rather, I had seen this interface more as a case of, we don't have time (== resources) to do this right, so we're going to release it with something ugly (use $EDITOR on a text file) to get by. I guess that's really what I was uncomfortable with. In the end, there may not be a difference to the customer. >> If the interface is going to vanish in a future release, I would want >> the case supporting that release to include the transition plan. > > A transition plan for Volatile? When do we require that? You're right. I withdraw my objection if this is marked Volatile. > Also note that basically none of this matters a whit. You could call > it Committed if you like. Because our taxonomy is based on releases, > and this project isn't targeting an Update, the interface is not > frozen until Nevada actually ships as a release. We apparently have > no plans to do that at all at any point in the future. So, by the > time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't > shipped, we'll still be able to make incompatible changes, even in > Committed interfaces. I think this situation got a lot muddier when SXDE got released. --Ed From sacadmin Fri Mar 16 08:01:01 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2GF11Ts004397 for ; Fri, 16 Mar 2007 08:01:01 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l2GF11Ga023238 for ; Fri, 16 Mar 2007 08:01:01 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2GF0t5N027093 for ; Fri, 16 Mar 2007 07:00:55 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF000H014BUE100@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc-members@sac.sfbay.sun.com; Fri, 16 Mar 2007 08:00:55 -0700 (PDT) Received: from [192.168.0.10] ([75.61.66.242]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF000MY84DJDBDJ@d1-sfbay-10.sun.com>; Fri, 16 Mar 2007 08:00:55 -0700 (PDT) Date: Fri, 16 Mar 2007 08:00:55 -0700 From: Ed Gould Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-reply-to: <17914.39590.716930.683654@gargle.gargle.HOWL> Sender: Ed.Gould@Sun.COM To: James Carlson Cc: Edward Hunter , psarc-members@sac.sfbay.sun.com, Joseph Kowalski , John Beck Message-id: <5cd9cf20c3e3c70fe7b3516abe7c1b3a@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.624) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> <17914.39590.716930.683654@gargle.gargle.HOWL> Status: RO Content-Length: 1649 (I have removed the external addresses [and, by sending to psarc-members, I hope kept it from the case log, which will get published externally] from this part of my comments, since they're more about Sun politics than architecture, and I've included some names. Ed Hunter, if this doesn't make sense out of context, either ask me or see the case log for 2007/136.) On Mar 16, 2007, at 6:24, James Carlson wrote: > Also note that basically none of this matters a whit. You could call > it Committed if you like. Because our taxonomy is based on releases, > and this project isn't targeting an Update, the interface is not > frozen until Nevada actually ships as a release. We apparently have > no plans to do that at all at any point in the future. So, by the > time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't > shipped, we'll still be able to make incompatible changes, even in > Committed interfaces. I think this situation got a lot muddier when SXDE got released and called a product. Some of us (Ed Hunter, Gary and I, at least) had a long email thread with Stephen Harpster late last year about what issues this release raises, without conclusion. We were expecting to have a meeting with Stephen soon after the break, but that never happened. The release went ahead, and Stephen has since left Sun. It is totally unclear to me, and I presume to customers, too, what commitments Sun is intending to make about interfaces in SXDE. I have seen it suggested by Sun employees on public email lists that customers upgrade from S10 to SX to get bug fixes that haven't made their way into S10 yet. --Ed From carlsonj@phorcys.east.sun.com Fri Mar 16 08:09:50 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2GF9nFS004468 for ; Fri, 16 Mar 2007 08:09:50 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2GF9ndE003337; Fri, 16 Mar 2007 11:09:49 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2GF9nee003334; Fri, 16 Mar 2007 11:09:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17914.45884.945385.25534@gargle.gargle.HOWL> Date: Fri, 16 Mar 2007 11:09:48 -0400 From: James Carlson To: Ed Gould Cc: nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, Joseph Kowalski Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-Reply-To: References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> <17914.39590.716930.683654@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2875 Ed Gould writes: > On Mar 16, 2007, at 6:24, James Carlson wrote: > > Is it your intention that we should just disallow all "experimental" > > projects? That's effectively what this project is attempting to do, > > and the implication of disallowing the use of Volatile for the fluid > > bits. I'm somewhat in accord with that prohibition, but I think we > > have a clash with senior management here. > > No, I wasn't intending to ban experimental interfaces. And maybe > that's the right way to look at this interface, too. Rather, I had > seen this interface more as a case of, we don't have time (== > resources) to do this right, so we're going to release it with > something ugly (use $EDITOR on a text file) to get by. Yes; that's close to what I see. > I guess that's > really what I was uncomfortable with. In the end, there may not be a > difference to the customer. I don't think there is. Experimental things are naturally going to have rough edges to them -- I think the questions we have to answer are whether we will allow any experiments and, if so, how best to warn users in what they're stepping. I'm ok with this bit being ugly, provided that users are adequately warned, and that there's a clear and safe alternative. (That alternative is "do nothing" -- the default for phase 0 is to leave the existing scripts and mechanisms in place, so the system behaves exactly the same way unless the user deliberately enables NWAM; presumably and hopefully after reading some documentation.) > > Also note that basically none of this matters a whit. You could call > > it Committed if you like. Because our taxonomy is based on releases, > > and this project isn't targeting an Update, the interface is not > > frozen until Nevada actually ships as a release. We apparently have > > no plans to do that at all at any point in the future. So, by the > > time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't > > shipped, we'll still be able to make incompatible changes, even in > > Committed interfaces. > > I think this situation got a lot muddier when SXDE got released. Quite true. I tried to start a conversation about the confusion inherent in this situation of "releases that aren't releases" _before_ SXDE was released, but was shouted down by the former PAC chair. It is what it is. Anyway, we're veering off-topic for this case. The point I was making was that the disagreement itself was so many angels on the head of a pin; no amount of stability will matter for something integrating into Nevada unless (and until) Nevada actually becomes a release with a schedule and specified content. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Fri Mar 16 08:16:57 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2GFGuiG004510 for ; Fri, 16 Mar 2007 08:16:56 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2GFGt7p003409; Fri, 16 Mar 2007 11:16:55 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2GFGt4q003406; Fri, 16 Mar 2007 11:16:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17914.46310.937740.267762@gargle.gargle.HOWL> Date: Fri, 16 Mar 2007 11:16:54 -0400 From: James Carlson To: Ed Gould Cc: Edward Hunter , psarc-members@sac.sfbay.sun.com, Joseph Kowalski , John Beck Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) In-Reply-To: <5cd9cf20c3e3c70fe7b3516abe7c1b3a@sun.com> References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> <17914.39590.716930.683654@gargle.gargle.HOWL> <5cd9cf20c3e3c70fe7b3516abe7c1b3a@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2192 Ed Gould writes: > I think this situation got a lot muddier when SXDE got released and > called a product. Some of us (Ed Hunter, Gary and I, at least) had a > long email thread with Stephen Harpster late last year about what > issues this release raises, without conclusion. Many of us have tried. > We were expecting to > have a meeting with Stephen soon after the break, but that never > happened. The release went ahead, and Stephen has since left Sun. It > is totally unclear to me, and I presume to customers, too, what > commitments Sun is intending to make about interfaces in SXDE. I have > seen it suggested by Sun employees on public email lists that customers > upgrade from S10 to SX to get bug fixes that haven't made their way > into S10 yet. Frankly, I don't know what SXDE is. We had been operating under the comfortable fiction that the "Solaris Express" program was really just an extended beta test cycle. As beta test, it's not a release, and there are no guarantees at all about stability. Things can change arbitrarily -- even in Committed interfaces -- at any time and without warning. Part of the slide into oblivion was the announcement of "support" for Solaris Express. This created some confusion about just what SX was supposed to be -- is it a supported release or is it still a beta test? We were reassured (at the time) that it's still just beta, and thus no new rules were needed. SXDE seems to be billed as something else. It's supposed to be a "developer's platform" -- something we (Sun) hope to be used in developing third-party applications for Solaris. That makes it qualitatively different from Solaris Express, which was more or less just "the build of the moment." I don't think that we (the ARC and SAC) should *ever* have allowed the PAC to produce a release that does not have a clear content specification or delivery mechanism. SXDE is that blunder. The question now is what to do about it. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jek3@sun.com Sat Mar 17 17:56:16 2007 Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I0uF6C023963 for ; Sat, 17 Mar 2007 17:56:15 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2I0trZu540513; Sat, 17 Mar 2007 17:56:02 -0700 (PDT) Message-ID: <45FC8D3B.7010104@sun.com> Date: Sat, 17 Mar 2007 14:52:11 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: James Carlson CC: Ed Gould , nwam-discuss@opensolaris.org, psarc-ext@sac.sfbay.sun.com, John Beck Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136) References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com> <17914.39590.716930.683654@gargle.gargle.HOWL> In-Reply-To: <17914.39590.716930.683654@gargle.gargle.HOWL> Content-Type: multipart/alternative; boundary="------------080505050908060303010605" Status: RO Content-Length: 6056 This is a multi-part message in MIME format. --------------080505050908060303010605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This seems to be going astray. James Carlson wrote: > Ed Gould writes: > >> Yes. I'm fine with this Volatile interface either disappearing >> completely or becoming Private with no incompatible changes ever. Note >> especially the word "ever." >> > > I think that pretty much puts the last nail in the coffin for Volatile > as a generally usable classification. The very definition of Volatile > is that it allows for incompatible change at any time -- including in > Micro releases and patches. > > That's much more often than "no incompatible change ever." > > Is it your intention that we should just disallow all "experimental" > projects? That's effectively what this project is attempting to do, > and the implication of disallowing the use of Volatile for the fluid > bits. I'm somewhat in accord with that prohibition, but I think we > have a clash with senior management here. > Its a strange concept, but I think what Ed was saying is that if this were to go Private, its interfaces would be frozen at that point in time. This makes a bit of sense, because since its now Private, just how would we notify anybody of a change? We care, because we once documented it. >> If the interface is going to vanish in a future release, I would want >> the case supporting that release to include the transition plan. >> > > A transition plan for Volatile? When do we require that? > Yea, this seemed wrong, if it means "transition period". Telling people how to transition is always appropriate. ... If I were John, I'd make sure that this Volatile interface is simply removed when he is done with it, which perhaps means nothing more than renaming the now Private file. From his earlier post, this seems to be in-line with his thoughts, but I am reading between the lines. > Also note that basically none of this matters a whit. You could call > it Committed if you like. Because our taxonomy is based on releases, > and this project isn't targeting an Update, the interface is not > frozen until Nevada actually ships as a release. We apparently have > no plans to do that at all at any point in the future. So, by the > time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't > shipped, we'll still be able to make incompatible changes, even in > Committed interfaces. > Yea, we should do something about this, like surviving 5 Express Releases counts as a release for the taxonomy. 8^) - jek3 --------------080505050908060303010605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

This seems to be going astray.

James Carlson wrote: 
Ed Gould writes:
  
Yes.  I'm fine with this Volatile interface either disappearing 
completely or becoming Private with no incompatible changes ever.  Note 
especially the word "ever."
    

I think that pretty much puts the last nail in the coffin for Volatile
as a generally usable classification.  The very definition of Volatile
is that it allows for incompatible change at any time -- including in
Micro releases and patches.

That's much more often than "no incompatible change ever."

Is it your intention that we should just disallow all "experimental"
projects?  That's effectively what this project is attempting to do,
and the implication of disallowing the use of Volatile for the fluid
bits.  I'm somewhat in accord with that prohibition, but I think we
have a clash with senior management here.
Its a strange concept, but I think what Ed was saying is that if this were to
go Private, its interfaces would be frozen at that point in time.  This makes
a bit of sense, because since its now Private, just how would we notify
anybody of a change?  We care, because we once documented it.

  

    
If the interface is going to vanish in a future release, I would want 
the case supporting that release to include the transition plan.  
    

  

  

A transition plan for Volatile?  When do we require that?
  



Yea, this seemed wrong, if it means "transition period".  Telling people

how to transition is always appropriate.



...



If I were John, I'd make sure that this Volatile interface is simply
removed

when he is done with it, which perhaps means nothing more than renaming

the now Private file.  From his earlier post, this seems to be in-line
with his

thoughts, but I am reading between the lines.



  
Also note that basically none of this matters a whit.  You could call
it Committed if you like.  Because our taxonomy is based on releases,
and this project isn't targeting an Update, the interface is not
frozen until Nevada actually ships as a release.  We apparently have
no plans to do that at all at any point in the future.  So, by the
time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't
shipped, we'll still be able to make incompatible changes, even in
Committed interfaces.
  



Yea, we should do something about this, like surviving 5 Express
Releases

counts as a release for the taxonomy.   8^)



- jek3








--------------080505050908060303010605--

From jek3@sun.com Sat Mar 17 17:58:33 2007
Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I0wX9T023979
	for ; Sat, 17 Mar 2007 17:58:33 -0700 (PDT)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2I0wAt1540661;
	Sat, 17 Mar 2007 17:58:19 -0700 (PDT)
Message-ID: <45FC8DD8.7050601@sun.com>
Date: Sat, 17 Mar 2007 14:54:48 -1000
From: Joseph Kowalski 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: James Carlson 
CC: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com>  <17914.39590.716930.683654@gargle.gargle.HOWL>
In-Reply-To: <17914.39590.716930.683654@gargle.gargle.HOWL>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 583

James Carlson wrote:
> Ed Gould writes:
>   
>> Yes.  I'm fine with this Volatile interface either disappearing 
>> completely or becoming Private with no incompatible changes ever.  Note 
>> especially the word "ever."
>>     
>
> I think that pretty much puts the last nail in the coffin for Volatile
> as a generally usable classification.  The very definition of Volatile
> is that it allows for incompatible change at any time -- including in
> Micro releases and patches.
>   
Same argument applies to Uncommitted, just at Minor Release points, rather
than "anytime".

- jek3


From jek3@sun.com Sat Mar 17 18:01:37 2007
Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I11bUg024120
	for ; Sat, 17 Mar 2007 18:01:37 -0700 (PDT)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2I10mEP540869;
	Sat, 17 Mar 2007 18:01:12 -0700 (PDT)
Message-ID: <45FC8E72.6030100@sun.com>
Date: Sat, 17 Mar 2007 14:57:22 -1000
From: Joseph Kowalski 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: James Carlson 
CC: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com>  <17914.39590.716930.683654@gargle.gargle.HOWL>
In-Reply-To: <17914.39590.716930.683654@gargle.gargle.HOWL>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 464

Gee, keep hitting return too early...

James Carlson wrote:
> All correct, but "documented" doesn't always mean man pages.  It does
> for "Committed" interfaces, but those at other stability levels can
> use whatever's appropriate -- white pages, READMEs, blogs, et cetera.
>   
For Solaris, it actually does mean man pages.  It may be a vestigial man 
page (an
example of which I sent out this week on a different thread), but a man 
page none
the less.

- jek3


From carlsonj@phorcys.east.sun.com Sat Mar 17 18:13:06 2007
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I1D5Te024271
	for ; Sat, 17 Mar 2007 18:13:05 -0700 (PDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2I1ClrB012336;
	Sat, 17 Mar 2007 21:12:47 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2I1ClJO012333;
	Sat, 17 Mar 2007 21:12:47 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17916.37390.732376.955281@gargle.gargle.HOWL>
Date: Sat, 17 Mar 2007 21:12:46 -0400
From: James Carlson 
To: Joseph Kowalski 
Cc: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
In-Reply-To: <45FC8D3B.7010104@sun.com>
References: <200703081527.l28FRSLr183120@opal.eng.sun.com>
	<200703152048.l2FKmxh6348108@opal.eng.sun.com>
	<200703152330.l2FNUNLp351741@opal.eng.sun.com>
	<45F9D992.4020904@sun.com>
	<200703152355.l2FNtJRK352220@opal.eng.sun.com>
	<79a4b50c5aac272a3f50f22f34a11e1a@sun.com>
	
	<17914.39590.716930.683654@gargle.gargle.HOWL>
	<45FC8D3B.7010104@sun.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
Status: RO
Content-Length: 2094

Joseph Kowalski writes:
> James Carlson wrote:
> > Is it your intention that we should just disallow all "experimental"
> > projects?  That's effectively what this project is attempting to do,
> > and the implication of disallowing the use of Volatile for the fluid
> > bits.  I'm somewhat in accord with that prohibition, but I think we
> > have a clash with senior management here.
> >   
> Its a strange concept, but I think what Ed was saying is that if this 
> were to
> go Private, its interfaces would be frozen at that point in time.  This 
> makes
> a bit of sense, because since its now Private, just how would we notify
> anybody of a change?  We care, because we once documented it.

I see.  In that case, though, we might consider just breaking them
intentionally.

(We documented it, but we documented it as something that you
shouldn't use for anything you care about.)

> If I were John, I'd make sure that this Volatile interface is simply removed
> when he is done with it, which perhaps means nothing more than renaming
> the now Private file.  From his earlier post, this seems to be in-line 
> with his
> thoughts, but I am reading between the lines.

I agree with this.

> > Also note that basically none of this matters a whit.  You could call
> > it Committed if you like.  Because our taxonomy is based on releases,
> > and this project isn't targeting an Update, the interface is not
> > frozen until Nevada actually ships as a release.  We apparently have
> > no plans to do that at all at any point in the future.  So, by the
> > time NWAM phase 1, 2, and 3 come around, and Nevada still hasn't
> > shipped, we'll still be able to make incompatible changes, even in
> > Committed interfaces.
> >   
> Yea, we should do something about this, like surviving 5 Express Releases
> counts as a release for the taxonomy.   8^)

That'd work for me.

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From carlsonj@phorcys.east.sun.com Sat Mar 17 18:22:42 2007
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I1MgMY024413
	for ; Sat, 17 Mar 2007 18:22:42 -0700 (PDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2I1MOK9012358;
	Sat, 17 Mar 2007 21:22:24 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2I1MOht012355;
	Sat, 17 Mar 2007 21:22:24 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17916.37967.988201.965258@gargle.gargle.HOWL>
Date: Sat, 17 Mar 2007 21:22:23 -0400
From: James Carlson 
To: Joseph Kowalski 
Cc: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
In-Reply-To: <45FC8E72.6030100@sun.com>
References: <200703081527.l28FRSLr183120@opal.eng.sun.com>
	<200703152048.l2FKmxh6348108@opal.eng.sun.com>
	<200703152330.l2FNUNLp351741@opal.eng.sun.com>
	<45F9D992.4020904@sun.com>
	<200703152355.l2FNtJRK352220@opal.eng.sun.com>
	<79a4b50c5aac272a3f50f22f34a11e1a@sun.com>
	
	<17914.39590.716930.683654@gargle.gargle.HOWL>
	<45FC8E72.6030100@sun.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
Status: RO
Content-Length: 1579

Joseph Kowalski writes:
> Gee, keep hitting return too early...
> 
> James Carlson wrote:
> > All correct, but "documented" doesn't always mean man pages.  It does
> > for "Committed" interfaces, but those at other stability levels can
> > use whatever's appropriate -- white pages, READMEs, blogs, et cetera.
> >   
> For Solaris, it actually does mean man pages.  It may be a vestigial man 
> page (an
> example of which I sent out this week on a different thread), but a man 
> page none
> the less.

I'm not sure I completely agree.  Our taxonomy says this under
Uncommitted:

  "In some situations, it may be appropriate to document Uncommitted
  interfaces in white papers rather than in standard product
  documentation."

I've always understood this to mean, "for experimental items, it might
be better to document them with non-official documentation, to avoid
accidentally conferring the sort of legitimacy that official
documentation has."

An interface that's intentionally just temporary and will be used as
an expediency until something better's designed sounds to me like an
interface that should at most say "see XREF" in the man page.

Oddly, though, we demand man page entries for Volatile.

(Perhaps we're saying nearly the same thing.  "X exists, but no more
information is available about it here" to me isn't exactly
documentation.)

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From jek3@sun.com Sat Mar 17 20:09:54 2007
Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2I39sR3025698
	for ; Sat, 17 Mar 2007 20:09:54 -0700 (PDT)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2I39L9P546195;
	Sat, 17 Mar 2007 20:09:35 -0700 (PDT)
Message-ID: <45FCAC9C.9060000@sun.com>
Date: Sat, 17 Mar 2007 17:06:04 -1000
From: Joseph Kowalski 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: James Carlson 
CC: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com>  <17914.39590.716930.683654@gargle.gargle.HOWL> <45FC8E72.6030100@sun.com> <17916.37967.988201.965258@gargle.gargle.HOWL>
In-Reply-To: <17916.37967.988201.965258@gargle.gargle.HOWL>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 692

James Carlson wrote:
> An interface that's intentionally just temporary and will be used as
> an expediency until something better's designed sounds to me like an
> interface that should at most say "see XREF" in the man page.
>
> Oddly, though, we demand man page entries for Volatile.
>
> (Perhaps we're saying nearly the same thing.  "X exists, but no more
> information is available about it here" to me isn't exactly
> documentation.
>   
 From the discussion associated with Volatile, it was "$man foo" should 
always
serve as a starting point and you need a place to hang the ATTRIBUTES 
section.

Perhaps we should clean up the ANCIENT Uncommitted entry to align with this.

- jek3



From carlsonj@phorcys.east.sun.com Mon Mar 19 03:53:31 2007
Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2JArVOf024570
	for ; Mon, 19 Mar 2007 03:53:31 -0700 (PDT)
Received: from phorcys.east.sun.com (localhost [127.0.0.1])
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l2JArBmj001142;
	Mon, 19 Mar 2007 06:53:11 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l2JArB27001139;
	Mon, 19 Mar 2007 06:53:11 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17918.27542.432516.569055@gargle.gargle.HOWL>
Date: Mon, 19 Mar 2007 06:53:10 -0400
From: James Carlson 
To: Joseph Kowalski 
Cc: Ed Gould , nwam-discuss@opensolaris.org,
        psarc-ext@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
In-Reply-To: <45FCAC9C.9060000@sun.com>
References: <200703081527.l28FRSLr183120@opal.eng.sun.com>
	<200703152048.l2FKmxh6348108@opal.eng.sun.com>
	<200703152330.l2FNUNLp351741@opal.eng.sun.com>
	<45F9D992.4020904@sun.com>
	<200703152355.l2FNtJRK352220@opal.eng.sun.com>
	<79a4b50c5aac272a3f50f22f34a11e1a@sun.com>
	
	<17914.39590.716930.683654@gargle.gargle.HOWL>
	<45FC8E72.6030100@sun.com>
	<17916.37967.988201.965258@gargle.gargle.HOWL>
	<45FCAC9C.9060000@sun.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
Status: RO
Content-Length: 716

Joseph Kowalski writes:
> > (Perhaps we're saying nearly the same thing.  "X exists, but no more
> > information is available about it here" to me isn't exactly
> > documentation.
> >   
>  From the discussion associated with Volatile, it was "$man foo" should 
> always
> serve as a starting point and you need a place to hang the ATTRIBUTES 
> section.
> 
> Perhaps we should clean up the ANCIENT Uncommitted entry to align with this.

As long as it ends up being self-consistent, I agree.

-- 
James Carlson, Solaris Networking              
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

From sacadmin Mon Mar 19 13:48:00 2007
Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2JKm0M3006175
	for ; Mon, 19 Mar 2007 13:48:00 -0700 (PDT)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2JKls8C700357;
	Mon, 19 Mar 2007 13:47:55 -0700 (PDT)
Message-ID: <45FEF6F7.1020700@sun.com>
Date: Mon, 19 Mar 2007 10:47:51 -1000
From: Joseph Kowalski 
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: James Carlson 
CC: Ed Gould , Edward Hunter ,
        psarc-members@sac.sfbay.sun.com, John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com>  <17914.39590.716930.683654@gargle.gargle.HOWL> <5cd9cf20c3e3c70fe7b3516abe7c1b3a@sun.com> <17914.46310.937740.267762@gargle.gargle.HOWL>
In-Reply-To: <17914.46310.937740.267762@gargle.gargle.HOWL>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 2405

James Carlson wrote:
> Frankly, I don't know what SXDE is.
>
> We had been operating under the comfortable fiction that the "Solaris
> Express" program was really just an extended beta test cycle.  As beta
> test, it's not a release, and there are no guarantees at all about
> stability.  Things can change arbitrarily -- even in Committed
> interfaces -- at any time and without warning.
>   
Well, that would only be the committed interfaces which weren't present 
in S10.
> Part of the slide into oblivion was the announcement of "support" for
> Solaris Express.  This created some confusion about just what SX was
> supposed to be -- is it a supported release or is it still a beta
> test?  We were reassured (at the time) that it's still just beta, and
> thus no new rules were needed.
>   
I think this is still the official *internal* line.
> SXDE seems to be billed as something else.  It's supposed to be a
> "developer's platform" -- something we (Sun) hope to be used in
> developing third-party applications for Solaris.  That makes it
> qualitatively different from Solaris Express, which was more or less
> just "the build of the moment."
>   
If you step into the "way back" machine, we did something similar with Zeus.
It was a platform only designed for development of applications appropriate
for deployment on a future release.  If this were what we were doing and 
saying,
I wouldn't be overly annoyed.  However, as near as I can tell, we are 
trying to
market this without saying what it is or worse, that its exactly what 
the customer
of the moment wants it to be.

I think this (or any) discussion of this would be help by locating and 
distributing
the clear and concise marketing statement on this.  If we can't find 
that for some reason,
we should gather the appropriate pile of other external statements.  I 
know I goofed in
the past by attributing a marketing statement about something else to be 
SXDE.

> I don't think that we (the ARC and SAC) should *ever* have allowed the
> PAC to produce a release that does not have a clear content
> specification or delivery mechanism.  SXDE is that blunder.  The
> question now is what to do about it.
>   
And just how would ARC and SAC done that?  I don't think we officially have
the power.  We approve interfaces, not releases.  Even if we had the 
official power,
I think we would have just been flattened.

- sigh,

- jek3


From sacadmin Mon Mar 19 14:33:58 2007
Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2JLXwNt007353
	for ; Mon, 19 Mar 2007 14:33:58 -0700 (PDT)
Received: from [192.9.61.51] (punchin-rotondo.SFBay.Sun.COM [192.9.61.51])
	by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l2JLXuT07244;
	Mon, 19 Mar 2007 14:33:56 -0700 (PDT)
Message-ID: <45FF01BF.10004@sun.com>
Date: Mon, 19 Mar 2007 14:33:51 -0700
From: Scott Rotondo 
User-Agent: Thunderbird 1.5.0.8 (X11/20061204)
MIME-Version: 1.0
To: Joseph Kowalski 
CC: James Carlson , Ed Gould ,
        Edward Hunter , psarc-members@sac.sfbay.sun.com,
        John Beck 
Subject: Re: [nwam-discuss] Network Auto-Magic Phase 0 (PSARC 2007/136)
References: <200703081527.l28FRSLr183120@opal.eng.sun.com> <200703152048.l2FKmxh6348108@opal.eng.sun.com> <200703152330.l2FNUNLp351741@opal.eng.sun.com> <45F9D992.4020904@sun.com> <200703152355.l2FNtJRK352220@opal.eng.sun.com> <79a4b50c5aac272a3f50f22f34a11e1a@sun.com>  <17914.39590.716930.683654@gargle.gargle.HOWL> <5cd9cf20c3e3c70fe7b3516abe7c1b3a@sun.com> <17914.46310.937740.267762@gargle.gargle.HOWL> <45FEF6F7.1020700@sun.com>
In-Reply-To: <45FEF6F7.1020700@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 795

Joseph Kowalski wrote:

> However, as near as I can tell, we are trying to market this without
> saying what it is or worse, that its exactly what the customer of the
> moment wants it to be.
> 
> I think this (or any) discussion of this would be help by locating
> and distributing the clear and concise marketing statement on this.
> If we can't find that for some reason, we should gather the
> appropriate pile of other external statements.  I know I goofed in 
> the past by attributing a marketing statement about something else to
> be SXDE.

Even if you could find such a marketing statement, bear in mind that it 
is likely to change over time as the customer of the moment changes.

I think all marketing statements have an implicit interface 
classification of Volatile. :-)

	Scott


From jbeck@eng.sun.com Fri May 25 15:32:06 2007
Received: from opal.eng.sun.com (opal [129.146.228.54])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4PMW6P3007196
	for ; Fri, 25 May 2007 15:32:06 -0700 (PDT)
Received: from opal (localhost [127.0.0.1])
	by opal.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4PMUcEa247432;
	Fri, 25 May 2007 15:30:38 -0700 (PDT)
Message-Id: <200705252230.l4PMUcEa247432@opal.eng.sun.com>
X-Mailer: exmh version 2.7.2 2005-Jan-07 with nmh-1.0.3
To: psarc-ext@sac.sfbay.sun.com
Cc: nwam-discuss@opensolaris.org, Anay Panvalkar ,
        Leo Binchy 
Subject: Network Auto-Magic Phase 0 (PSARC 2007/136)
X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 May 2007 15:30:38 -0700
From: John Beck 
Status: RO
Content-Length: 5015

NWAM Phase 0 (PSARC/2007/136) does not include GUI support; the Gnome
Network Admin applet has no function if NWAM is enabled, though it still
functions normally if NWAM is disabled (NWAM is enabled for Developer
Express installed, disabled for all other installs).  Work on NWAM Phase
1 is underway and will include a GUI which EOLs the Network Admin applet.

Until Phase 1 is integrated, we need to be able to let users of the
Network Admin applet know under what conditions it should be used.  This
contract allows the applet to detect whether or not NWAM is enabled and
react accordingly.

(Note to Anay & Leo: each of you doing a reply-all and stating "I agree."
will suffice to "sign" this contract.)

        CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES

0.  Number:

    PSARC/2007/136-01

1.  This contract is between
        a SUPPLIER of INTERFACES and
        a CONSUMER of those INTERFACES,
    both of whom are entities within Sun Microsystems, Incorporated.

2.  The SUPPLIER (definer and/or implementor) is identified by the following:
    Product or Bundle:                      NWAM
    Consolidation:                          ON
    Department or Group:                    ON/Networking
    Bugster Product/Category/SubCategory:   solaris/network/config
    Responsible Manager:                    Anay Panvalkar

3.  The CONSUMER is identified by the following:
    Product or Bundle:                      JDS
    Consolidation:                          Desktop
    Department or Group:                    JDS
    Bugster Product/Category/SubCategory:   jds/gnome/applications
    Responsible Manager:                    Leo Binchy

4.  The INTERFACES are:

    FRMI names:  svc:/network/physical:default
		 svc:/network/physical:nwam

5.  The ARC controlling these INTERFACES is:

    PSARC

6.  The CASE describing (Exporting) these INTERFACES is:

    PSARC/2007/136 - Network Auto-Magic Phase 0

7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
    imposed by the stability levels listed in section 4 above:
 
_Y_ 7a. Although the stability level doesn't normally restrict it,
        SUPPLIER promises to only modify INTERFACES in an incompatible
        way as follows:
        
        The name of the FRMIs will not change until the integration of NWAM
        Phase 1, at which time the network-admin tool should be EOL-ed to
        be replaced by the NWAM UI.

_Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER
        will import INTERFACES from a separate consolidation.

8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make
   best effort to accommodate such changes, which shall then be
   treated in accordance with paragraph 7 above.

9. Notwithstanding paragraphs 7 and 8, a change to any portion
   of the INTERFACES shall be regarded as a completely new set of
   INTERFACES which require both ARC approval and execution of
   a new contract.

10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
    handled as follows:

    SUPPLIER will explicitly notify CONSUMER of impending changes to 
    the FRMI names of the NWAM services with sufficient time for CONSUMER 
    to be able to react to this change.

11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
    follows:

    The FRMI names will operate as outlined in PSARC/2007/136 so that
    consuming it in the form :

        svcs -H -o state svc:/network/physical:nwam
        svcs -H -o state svc:/network/physical:default

    will return the correct states to reflect the operational status of the
    NWAM service (:nwam is online and :default is disabled).

12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
    follows:

    As in this contract and in PSARC/2007/136

13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
    tested as follows:

    When operational, the nwam services will provide its state as "online"
    when the following command is used:

        svcs -H -o state svc:/network/physical:nwam

14. SUPPLIER and CONSUMER agree that this contract can be terminated as
    follows:

    By prior agreement via e-mail.

15. This contract is not valid until "signed" via agreement from the
    SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
    this contract.  E-mail agreement to the contract should be archived
    in the mail archive of CASE; verbal agreement to the contract
    should be noted in the meeting minutes.  This contract remains
    valid until superseded or invalidated.

For SUPPLIER:                   Date:
For CONSUMER:                   Date:
For ARC:                        Date:

    A copy of this contract shall be deposited in the CASE directory as
    "contract-" or in a "contracts" subdirectory.

16. (Not to be filled in until superseded or invalidated.)
    This contract was superseded or invalidated by CASE:
    For ARC:                    Date:

-- John

http://blogs.sun.com/jbeck

From Robert.Odea@Sun.COM Mon May 28 02:53:41 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4S9rfg6008800
	for ; Mon, 28 May 2007 02:53:41 -0700 (PDT)
Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4S9qMUK007302
	for ; Mon, 28 May 2007 02:52:22 -0700 (PDT)
Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120])
	by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4S9qGJX019381
	for ; Mon, 28 May 2007 09:52:16 GMT
Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JIQ00001WO19Q00@d1-emea-10.sun.com>
 (original mail from Robert.Odea@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Mon,
 28 May 2007 10:52:16 +0100 (BST)
Received: from [129.156.220.40] by d1-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JIQ001MNWR3EQ6B@d1-emea-10.sun.com>; Mon,
 28 May 2007 10:52:16 +0100 (BST)
Date: Mon, 28 May 2007 10:53:52 +0100
From: "Robert O'Dea" 
Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136)
In-reply-to: <200705252230.l4PMUcEa247432@opal.eng.sun.com>
Sender: Robert.Odea@Sun.COM
To: John Beck 
Cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org,
        Anay Panvalkar ,
        Leo Binchy 
Message-id: <465AA6B0.2050904@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200705252230.l4PMUcEa247432@opal.eng.sun.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070508)
Status: RO
Content-Length: 5353

I agree on behalf of the desktop team.

Robert O'Dea.

John Beck wrote:
> NWAM Phase 0 (PSARC/2007/136) does not include GUI support; the Gnome
> Network Admin applet has no function if NWAM is enabled, though it still
> functions normally if NWAM is disabled (NWAM is enabled for Developer
> Express installed, disabled for all other installs).  Work on NWAM Phase
> 1 is underway and will include a GUI which EOLs the Network Admin applet.
> 
> Until Phase 1 is integrated, we need to be able to let users of the
> Network Admin applet know under what conditions it should be used.  This
> contract allows the applet to detect whether or not NWAM is enabled and
> react accordingly.
> 
> (Note to Anay & Leo: each of you doing a reply-all and stating "I agree."
> will suffice to "sign" this contract.)
> 
>         CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
> 
> 0.  Number:
> 
>     PSARC/2007/136-01
> 
> 1.  This contract is between
>         a SUPPLIER of INTERFACES and
>         a CONSUMER of those INTERFACES,
>     both of whom are entities within Sun Microsystems, Incorporated.
> 
> 2.  The SUPPLIER (definer and/or implementor) is identified by the following:
>     Product or Bundle:                      NWAM
>     Consolidation:                          ON
>     Department or Group:                    ON/Networking
>     Bugster Product/Category/SubCategory:   solaris/network/config
>     Responsible Manager:                    Anay Panvalkar
> 
> 3.  The CONSUMER is identified by the following:
>     Product or Bundle:                      JDS
>     Consolidation:                          Desktop
>     Department or Group:                    JDS
>     Bugster Product/Category/SubCategory:   jds/gnome/applications
>     Responsible Manager:                    Leo Binchy
> 
> 4.  The INTERFACES are:
> 
>     FRMI names:  svc:/network/physical:default
> 		 svc:/network/physical:nwam
> 
> 5.  The ARC controlling these INTERFACES is:
> 
>     PSARC
> 
> 6.  The CASE describing (Exporting) these INTERFACES is:
> 
>     PSARC/2007/136 - Network Auto-Magic Phase 0
> 
> 7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
>     imposed by the stability levels listed in section 4 above:
>  
> _Y_ 7a. Although the stability level doesn't normally restrict it,
>         SUPPLIER promises to only modify INTERFACES in an incompatible
>         way as follows:
>         
>         The name of the FRMIs will not change until the integration of NWAM
>         Phase 1, at which time the network-admin tool should be EOL-ed to
>         be replaced by the NWAM UI.
> 
> _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER
>         will import INTERFACES from a separate consolidation.
> 
> 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make
>    best effort to accommodate such changes, which shall then be
>    treated in accordance with paragraph 7 above.
> 
> 9. Notwithstanding paragraphs 7 and 8, a change to any portion
>    of the INTERFACES shall be regarded as a completely new set of
>    INTERFACES which require both ARC approval and execution of
>    a new contract.
> 
> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
>     handled as follows:
> 
>     SUPPLIER will explicitly notify CONSUMER of impending changes to 
>     the FRMI names of the NWAM services with sufficient time for CONSUMER 
>     to be able to react to this change.
> 
> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
>     follows:
> 
>     The FRMI names will operate as outlined in PSARC/2007/136 so that
>     consuming it in the form :
> 
>         svcs -H -o state svc:/network/physical:nwam
>         svcs -H -o state svc:/network/physical:default
> 
>     will return the correct states to reflect the operational status of the
>     NWAM service (:nwam is online and :default is disabled).
> 
> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
>     follows:
> 
>     As in this contract and in PSARC/2007/136
> 
> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
>     tested as follows:
> 
>     When operational, the nwam services will provide its state as "online"
>     when the following command is used:
> 
>         svcs -H -o state svc:/network/physical:nwam
> 
> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as
>     follows:
> 
>     By prior agreement via e-mail.
> 
> 15. This contract is not valid until "signed" via agreement from the
>     SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
>     this contract.  E-mail agreement to the contract should be archived
>     in the mail archive of CASE; verbal agreement to the contract
>     should be noted in the meeting minutes.  This contract remains
>     valid until superseded or invalidated.
> 
> For SUPPLIER:                   Date:
> For CONSUMER:                   Date:
> For ARC:                        Date:
> 
>     A copy of this contract shall be deposited in the CASE directory as
>     "contract-" or in a "contracts" subdirectory.
> 
> 16. (Not to be filled in until superseded or invalidated.)
>     This contract was superseded or invalidated by CASE:
>     For ARC:                    Date:
> 
> -- John
> 
> http://blogs.sun.com/jbeck

From anay@sun.com Mon May 28 20:35:09 2007
Received: from engmail4sca.SFBay.Sun.COM (engmail4sca.SFBay.Sun.COM [129.145.155.74])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4T3Z9Hi018453
	for ; Mon, 28 May 2007 20:35:09 -0700 (PDT)
Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5])
	by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l4T3XqPN018872
	for ; Mon, 28 May 2007 20:33:52 -0700 (PDT)
Received: from d1-sfbay-09.sun.com ([192.18.39.119])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4T3XlZq007941
	for ; Mon, 28 May 2007 20:33:47 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JIS003019T8EP00@d1-sfbay-09.sun.com> (original mail from anay@sun.com)
 for psarc-ext@sac.eng.sun.com; Mon, 28 May 2007 20:33:47 -0700 (PDT)
Received: from [192.168.0.201] ([71.135.191.125])
 by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3
 2006)) with ESMTPSA id <0JIS002AU9WADHK0@d1-sfbay-09.sun.com>; Mon,
 28 May 2007 20:33:47 -0700 (PDT)
Date: Mon, 28 May 2007 20:33:42 -0700
From: "Anay S. Panvalkar" 
Subject: Re: Network Auto-Magic Phase 0 (PSARC 2007/136)
In-reply-to: <200705252230.l4PMUcEa247432@opal.eng.sun.com>
Sender: Anay.Panvalkar@sun.com
To: John Beck 
Cc: psarc-ext@sac.sfbay.sun.com, nwam-discuss@opensolaris.org,
        Leo Binchy 
Reply-to: anay@sun.com
Message-id: <465B9F16.3000506@sun.com>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200705252230.l4PMUcEa247432@opal.eng.sun.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
Status: RO
Content-Length: 5317


I agree.

-Anay

John Beck wrote:
> NWAM Phase 0 (PSARC/2007/136) does not include GUI support; the Gnome
> Network Admin applet has no function if NWAM is enabled, though it still
> functions normally if NWAM is disabled (NWAM is enabled for Developer
> Express installed, disabled for all other installs).  Work on NWAM Phase
> 1 is underway and will include a GUI which EOLs the Network Admin applet.
> 
> Until Phase 1 is integrated, we need to be able to let users of the
> Network Admin applet know under what conditions it should be used.  This
> contract allows the applet to detect whether or not NWAM is enabled and
> react accordingly.
> 
> (Note to Anay & Leo: each of you doing a reply-all and stating "I agree."
> will suffice to "sign" this contract.)
> 
>         CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES
> 
> 0.  Number:
> 
>     PSARC/2007/136-01
> 
> 1.  This contract is between
>         a SUPPLIER of INTERFACES and
>         a CONSUMER of those INTERFACES,
>     both of whom are entities within Sun Microsystems, Incorporated.
> 
> 2.  The SUPPLIER (definer and/or implementor) is identified by the following:
>     Product or Bundle:                      NWAM
>     Consolidation:                          ON
>     Department or Group:                    ON/Networking
>     Bugster Product/Category/SubCategory:   solaris/network/config
>     Responsible Manager:                    Anay Panvalkar
> 
> 3.  The CONSUMER is identified by the following:
>     Product or Bundle:                      JDS
>     Consolidation:                          Desktop
>     Department or Group:                    JDS
>     Bugster Product/Category/SubCategory:   jds/gnome/applications
>     Responsible Manager:                    Leo Binchy
> 
> 4.  The INTERFACES are:
> 
>     FRMI names:  svc:/network/physical:default
> 		 svc:/network/physical:nwam
> 
> 5.  The ARC controlling these INTERFACES is:
> 
>     PSARC
> 
> 6.  The CASE describing (Exporting) these INTERFACES is:
> 
>     PSARC/2007/136 - Network Auto-Magic Phase 0
> 
> 7.  The following SPECIAL ARRANGEMENTS are made which modify the rules
>     imposed by the stability levels listed in section 4 above:
>  
> _Y_ 7a. Although the stability level doesn't normally restrict it,
>         SUPPLIER promises to only modify INTERFACES in an incompatible
>         way as follows:
>         
>         The name of the FRMIs will not change until the integration of NWAM
>         Phase 1, at which time the network-admin tool should be EOL-ed to
>         be replaced by the NWAM UI.
> 
> _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER
>         will import INTERFACES from a separate consolidation.
> 
> 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make
>    best effort to accommodate such changes, which shall then be
>    treated in accordance with paragraph 7 above.
> 
> 9. Notwithstanding paragraphs 7 and 8, a change to any portion
>    of the INTERFACES shall be regarded as a completely new set of
>    INTERFACES which require both ARC approval and execution of
>    a new contract.
> 
> 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be
>     handled as follows:
> 
>     SUPPLIER will explicitly notify CONSUMER of impending changes to 
>     the FRMI names of the NWAM services with sufficient time for CONSUMER 
>     to be able to react to this change.
> 
> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as
>     follows:
> 
>     The FRMI names will operate as outlined in PSARC/2007/136 so that
>     consuming it in the form :
> 
>         svcs -H -o state svc:/network/physical:nwam
>         svcs -H -o state svc:/network/physical:default
> 
>     will return the correct states to reflect the operational status of the
>     NWAM service (:nwam is online and :default is disabled).
> 
> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as
>     follows:
> 
>     As in this contract and in PSARC/2007/136
> 
> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be
>     tested as follows:
> 
>     When operational, the nwam services will provide its state as "online"
>     when the following command is used:
> 
>         svcs -H -o state svc:/network/physical:nwam
> 
> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as
>     follows:
> 
>     By prior agreement via e-mail.
> 
> 15. This contract is not valid until "signed" via agreement from the
>     SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by
>     this contract.  E-mail agreement to the contract should be archived
>     in the mail archive of CASE; verbal agreement to the contract
>     should be noted in the meeting minutes.  This contract remains
>     valid until superseded or invalidated.
> 
> For SUPPLIER:                   Date:
> For CONSUMER:                   Date:
> For ARC:                        Date:
> 
>     A copy of this contract shall be deposited in the CASE directory as
>     "contract-" or in a "contracts" subdirectory.
> 
> 16. (Not to be filled in until superseded or invalidated.)
>     This contract was superseded or invalidated by CASE:
>     For ARC:                    Date:
> 
> -- John
> 
> http://blogs.sun.com/jbeck