From sacadmin Mon Jan 15 19:22:30 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0G3MTCh017991 for ; Mon, 15 Jan 2007 19:22:29 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0G3MJVF025820; Tue, 16 Jan 2007 11:22:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBX0050EYPD1300@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Jan 2007 19:22:25 -0800 (PST) Received: from sac.sfbay.sun.com ([129.146.175.66]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBX0062XYPCQW30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 15 Jan 2007 19:22:24 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0G3MO2Z017987; Mon, 15 Jan 2007 19:22:24 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l0G3MOde017986; Mon, 15 Jan 2007 19:22:24 -0800 (PST) Date: Mon, 15 Jan 2007 19:22:24 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2006/319 iSNS Server To: PSARC@sun.com Cc: Victor.Li@sun.com, PSARC-coord@sun.com Message-id: <200701160322.l0G3MOde017986@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 351 New Materials submitted for PSARC 2006/319 iSNS Server Status: inception scheduled 01/24/2007 Files: /shared/sac/PSARC/2006/319/inception.materials/iSNS-CLI-Design.pdf /shared/sac/PSARC/2006/319/inception.materials/iSNS-Design.html /shared/sac/PSARC/2006/319/inception.materials/iSNS-Design_files Please let me know if you have questions. - PSARC From sacadmin Wed Jan 17 09:34:43 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HHYg4I009591 for ; Wed, 17 Jan 2007 09:34:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0HHYdR12215; Wed, 17 Jan 2007 10:34:39 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JC000505WTPXJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 09:34:37 -0800 (PST) Received: from sac.sfbay.sun.com ([129.146.175.66]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JC000EGUWTP75D0@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jan 2007 09:34:37 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0HHYaHB009586; Wed, 17 Jan 2007 09:34:36 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l0HHYaRu009585; Wed, 17 Jan 2007 09:34:36 -0800 (PST) Date: Wed, 17 Jan 2007 09:34:36 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2006/319 iSNS Server To: PSARC@sun.com Cc: Victor.Li@sun.com, PSARC-coord@sun.com Message-id: <200701171734.l0HHYaRu009585@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 667 New Materials submitted for PSARC 2006/319 iSNS Server Status: inception scheduled 01/24/2007 Files: /shared/sac/PSARC/2006/319/inception.materials/arch-diagram.gif /shared/sac/PSARC/2006/319/inception.materials/iSNS-CLI-Design.pdf /shared/sac/PSARC/2006/319/inception.materials/iSNS-Design.html /shared/sac/PSARC/2006/319/inception.materials/iSNS-Design_files /shared/sac/PSARC/2006/319/inception.materials/isnsdata.DTD /shared/sac/PSARC/2006/319/inception.materials/isnsmgmtSchema.xsd /shared/sac/PSARC/2006/319/inception.materials/msg-handler.gif /shared/sac/PSARC/2006/319/inception.materials/ReviewQuestions Please let me know if you have questions. - PSARC From sacadmin Fri Feb 2 15:52:27 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l12NqQpK015847 for ; Fri, 2 Feb 2007 15:52:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l12NqNB5015442; Fri, 2 Feb 2007 15:52:23 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCV002050ZBDK00@brm-avmta-1.central.sun.com>; Fri, 02 Feb 2007 16:52:23 -0700 (MST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCV00IT00ZAAZA0@brm-avmta-1.central.sun.com>; Fri, 02 Feb 2007 16:52:23 -0700 (MST) 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 l12NqM1a021903; Fri, 02 Feb 2007 15:52:22 -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 <0JCV00C010SWPB00@d1-sfbay-09.sun.com> (original mail from Hyon.Kim@Sun.COM); Fri, 02 Feb 2007 15:52:22 -0800 (PST) Received: from [129.146.56.83] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCV008CZ0ZA1YFE@d1-sfbay-09.sun.com>; Fri, 02 Feb 2007 15:52:22 -0800 (PST) Date: Fri, 02 Feb 2007 15:51:03 -0800 From: Hyon Kim Subject: isnsadm discussion for PSARC/2006/319 (iSNS Server) Sender: Hyon.Kim@Sun.COM To: psarc@Sun.COM, "Mark A. Carlson" Cc: ISNS Team Message-id: <45C3CE67.2020800@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=windows-1252 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 12800 Here is the project team's response on the isnsadm command line argument discusssion. The team has a list of alternatives which has been discussed with the UIRB owner. Most violate current guidance by CLIP and the CLIP companion, but two are acceptable. The project team would like to choose alternative F below with rationale that is described subsequently. The team would appreicate guidance from PSARC in finalizing the discussion (and constructing feedback to UIRB to clarify things for future cases). The following is the summary, details follow. A) Existing proposal: UIRB Approved. PSARC doesn't like isnsadm add-dd --dd
# add dd to dd set isnsadm add-node --node
# add node to dd B) Alternate 1: UIRB says not CLIP Companion recommended because of mutually exclusive options for a single subcommand, and stylistic inconsistency: isnsadm add --dd
isnsadm add --node
C) Alternate 2: UIRB says not CLIP Companion recommended because of non-hyphenated subcommands. Also, positional paramenters are not CLIP Companion preferred: isnsadm adddd
isnsadm addnode
D) Alternative 3: UIRB says not CLIP compliant for use of double-word subcommands. Also, positional paramenters are not CLIP Companion preferred: isnsadm add dd
isnsadm add node
E) Penultimate Alternative: UIRB says positional paramenters are not CLIP Companion preferred, but could be considered acceptable: isnsadm add-dd
isnsadm add-node
F) Final Alternative: UIRB says acceptable, perhaps preferred though it goes against some mild guidance in the CLIP Companion: isnsadm add-node --dd=
isnsadm add-dd --dd-set=
------------------ Historical background: PSARC 2003/126 iSCSI project (20030305_rick.mcneal) UIRB 2004/636 iSCSI CLI (20040825_john.forte) PSARC 2004/848 Remove SLP from iSCSI (20041223_eric.taylor) SHARC 2005/066 iSCSI Management API (20050202_kenneth.davis) PSARC 2005/307 iSNS Client Support for iSCSI (20050512_waikwan.hui) PSARC 2005/441 iSCSI Target Project (20050725_rick.mcneal) UIRB 2005/539 iSCSI Target CLI (20050919_rick.mcneal) UIRB 2005/543 iSCSI MS/T CLI (20050920_david.weibel) PSARC 2005/591 ISCSI MS/T CLI (20051011_david.weibel) PSARC 2006/622 iSCSI/ZFS integration (20061103_adam.leventhal) PSARC 2006/319 iSNS Server (20060516_victor.li) UIRB 2006/527 iSNS Server CLI (20060907_victor.li) UIRB 2006/674 iSNS Server BUI (20061205_gary.horton) 2005/441's CLI spec: Usage: iscsitadm create [-?] [-?] [] iscsitadm create target iscsitadm create initiator iscsitadm create tpgt Usage: iscsitadm list [-?] [-?] [] iscsitadm list target [OPTIONS] [] iscsitadm list initiator [OPTIONS] [] iscsitadm list tpgt [OPTIONS] [] ...etc... 2005/441's opinion says The other main issue discussed at commitment review was the sytnax of the iscsitadm CLI and why it was not CLIP compli- ant. The project team noted that iscsiadm had been approved by the UIRB and it too was not CLIP compliant. The team wanted the CLIs for iSCSI to be consistent. Hence, the requirements regarding the syntax of the CLI became muddy to the project team. After considerable discussion, the PSARC members decided to approve the iscsitadm interface as is. However, there was the strong desire of the members that a follow on project be considered to bring the interface into CLIP compliance. See PAC advice below regarding CLIP compli- ance. Moreover, members stated that no future CLI would be approved that utilizes the syntax that iscsiadm, iscsitadm and mpathadm employ. 2. The PAC must consider funding a follow on project to fix the syntax used by mpathadm, iscsiadm, and iscsi- tadm to become CLIP compliant. Also, no future pro- jects will be approved that employ the syntax used by these CLIs. In the issues for 2006/319: jdc-6 It seems awkward to have to specify the argument type twice for the add-* and remove-*functions. In other words, "add-dd --dd foo bar" seems redundant (the "dd" type of the argument is specified twice), where either "add-dd foo bar" or "add --dd foo bar" would be more natural. (If this is a CLIP problem, let's do what is usable rather than what the standard says.) Charles LaBrec (UIRB case owner) concludes I don't mean to be overly pedantic, but given that the guidelines were given scrutiny and approval by PSARC, I don't feel I have the latitude to go against them without good justification, at least at the UIRB. I've always felt that ARCs have the capability to override, if they wish (and particularly PSARC, as it governs the guidelines). The only thing I would ask is that there be guidance by a change to CLIP and the companion so that I and project teams know what is the correct direction. Hyon, John Plocher, Mark, and Charles LaBrec (UIRB) looked at several alternatives: A) Existing proposal: isnsadm add-dd --dd
# add dd to dd set isnsadm add-node --node
# add node to dd isnsadm remove-dd --dd
# remove dd from dd set isnsadm remove-node --node
# remove node from dd UIRB Approved. B) Alternate 1 isnsadm add --dd
# add dd to dd set isnsadm add --node
# add node to dd isnsadm remove --dd
# remove dd from dd set isnsadm remove --node
# remove node from dd There is a strong recommendation in the CLIP Companion to avoid having mutually exclusive sets of options for a given subcommand. This clarifies the usage lines and documentation, by making it absolutely clear which options go with which subcommand. In the above case, the syntax is relatively simple, so it wouldn't be as confusing. However, if more options start to be added to one form or the other as the CLI evolves, then we get into this situation. The reference in the CLIP companion is in section 4.3 Subcommands: Q: My subcommand allows two very different uses, and each has mutually unrelated options (e.g., myutility add [-gou] entity and myutility add [-ghklr] entity A: You should revise your design. This suggests that you actually have two different operations, and so should use different names. In this case, one would also have consider an overall "style" issue, as it would seem awkward that some subcommands are single words, and others hyphenated. If this alternative were chosen, it would seem necessary to overhaul all the subcommand names to be consistent. C) Alternate 2: isnsadm adddd
isnsadm addnode
isnsadm removedd
isnsadm removenode
Also from the CLIP Companion, 4.3 Subcommands: In some cases, a utility may operate on a type of object and its sub-objects. In these cases, the subcommand should be a verb followed by a hyphen followed by the name of the kind of object to operate on. Q: I'd prefer to see verbNoun, verbnoun, "verb noun", "verb -t noun" or "noun" as my subcommand form, rather than "verb-noun" A: This is one of these cases where all the possible design alternatives provide roughly the same level of usability. The design question then becomes: what is most consistent? Each of these design possibilities has been closely examined, and the "verb-noun" scheme seems to be the best. "verbNoun" involves mixed capitalization which many dislike. "verbnoun" tends to produce names that are hard to parse when unusual terms appear in them. "verb noun" and "verb -t noun" don't really save any typing and add other complexities. Finally, "noun" doesn't convey any sense of action. In the above, "adddd" seems to be the type of command one would mistype a lot. This alternative also suffers from the usage of positional parameters, which will be discussed later. D) Alternative 3: isnsadm add dd
isnsadm add node
isnsadm remove dd
isnsadm remove node
Double-word subcommands are not CLIP #14 compliant, nor recommended by the Companion: #14: The form “command subcommand [options] [operands]” is appropriate for grouping similar operations. Subcommand names should follow the same conventions as command names as specified in guidelines 1 and 2. #2: Utility names should include lower-case letters (the lower character classification) and digits only from the portable character set. [Subsequently relaxed to include the hyphen by the Companion] Q: I'd prefer to see ... "verb noun", ... as my subcommand form, rather than "verb-noun" A: This is one of these cases where all the possible design alternatives provide roughly the same level of usability. The design question then becomes: what is most consistent? Each of these design possibilities has been closely examined, and the "verb-noun" scheme seems to be the best. .... "verb noun" and "verb -t noun" don't really save any typing and add other complexities.... E) Penultimate Alternative isnsadm add-dd
isnsadm add-mode
isnsadm remove-dd
isnsadm remove-node
Team: The user has to remember the order since there is no option involved. zpool has the simliar syntax. In the CLIP Companion, under 4.6 Operands: Q: I'd like to specify things with operands in a particular order. Rather than using required options, I'd like to say that operand #1 is one thing, operand #2 is another thing, and so on. A: These are called "positional parameters". In general, these seem to be a bad idea. More than two positional parameters is hard for people to remember. In the general case, even two is difficult because it is often hard to remember whether A goes before or after B. One common utility which uses positional parameters reasonably easily is cp, where the last operand is the destination while the preceding are all the things to be moved. Yet, you have probably on occasion not specified the destination item and so moved all the files into some other location than you intended. This demonstrates that this good case can still cause problems. In general, we strongly recommend the use of options (even required options) rather than positionally-significant operands because this reduces the usability problems that positional ones involve. In this case if you think along the lines of: "since I can add more than one dd name, the first is the set and the rest are the dd's", then the syntax makes some sense. Note, however, that this is opposite to the rationale used in the far more commonly used utilities mv and cp, where it's the last one that is the container (i.e., directory)... F) Final Alternative: isnsadm add-node --dd=
isnsadm add-dd --dd-set=
isnsadm remove-node --dd=
isnsadm remove-dd --dd-set=
UIRB: "preferred" The CLIP companion is not very specific on the issue of whether the operands of a command should refer to the "noun" of the subcommand or whether the noun should be referred to in an option. However, an example in the Companion shows the latter, which was the rationale for preferring the CLI syntax that was approved: | qsset create myset|| qsset add-drive -q newdrive myset [ using "long-option notation", the above might look like: ] qsset add-drive --drive=newdrive myset | On reflection, considering this from the principle of consistency and the principle of least surprise, I believe this guidance is suspect, and leads to at least part of the issue raised by the PSARC review. It would seem preferred to have the operands match the object type specified by the "noun". This would eliminate confusion similar to that raised by the discussion for positional parameters--otherwise, users have to remember for each subcommand which argument is the option, and which is the operand. Secondly, it allows for a CLI to extend itself if the design at first only has some kind of "global collection" and later adds "named collections". In other words, "qsset add-drive newdrive" might be an acceptable design initially, and then when named sets are created, the option referring to the set can then simply be added. This is also extensible to situations where an object might be added to more than one class of collection. If this rationale is accepted, the UIRB would like to consider it a precedent for future reviews.|| From Hyon.Kim@Sun.COM Mon Feb 5 08:39:17 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l15GdHWD007214 for ; Mon, 5 Feb 2007 08:39:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l15GdHx15584 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Mon, 5 Feb 2007 09:39:17 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JD000K1J0XFZA00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Feb 2007 08:39:15 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JD000CKT0X7JC70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Feb 2007 08:39:07 -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 l15Gd7Mj026607 for ; Mon, 05 Feb 2007 08:39: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 <0JD0007010UNNQ00@d1-sfbay-09.sun.com> (original mail from Hyon.Kim@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Feb 2007 08:39:07 -0800 (PST) Received: from [129.150.28.77] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JD000M3C0X1BLZ8@d1-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Feb 2007 08:39:07 -0800 (PST) Date: Mon, 05 Feb 2007 08:39:01 -0800 From: Hyon Kim Subject: Re: isnsadm discussion for PSARC/2006/319 (iSNS Server) In-reply-to: <45C3CE67.2020800@sun.com> Sender: Hyon.Kim@Sun.COM To: psarc-ext@Sun.COM Message-id: <45C75DA5.2070904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=windows-1252 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <45C3CE67.2020800@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 13496 I sent the message to the internal psarc alias last Friday. Resending to the external discussion alias... --Hyon Hyon Kim wrote: > > Here is the project team's response on the isnsadm command line > argument discusssion. > > The team has a list of alternatives which has been discussed with the > UIRB owner. Most violate current guidance by CLIP and the CLIP > companion, but two are acceptable. The project team would like to > choose alternative F > below with rationale that is described subsequently. > > The team would appreicate guidance from PSARC in finalizing the > discussion (and constructing feedback to UIRB to clarify things for > future cases). > > The following is the summary, details follow. > > A) Existing proposal: UIRB Approved. PSARC doesn't like > > isnsadm add-dd --dd
# add dd to dd set > isnsadm add-node --node
# add node to dd > > B) Alternate 1: UIRB says not CLIP Companion recommended because of > mutually exclusive options for a single subcommand, and stylistic > inconsistency: > > isnsadm add --dd
> isnsadm add --node
> > C) Alternate 2: UIRB says not CLIP Companion recommended because of > non-hyphenated subcommands. Also, positional paramenters are not CLIP > Companion preferred: > > isnsadm adddd
> isnsadm addnode
> > D) Alternative 3: UIRB says not CLIP compliant for use of double-word > subcommands. Also, positional paramenters are not CLIP Companion > preferred: > > isnsadm add dd
> isnsadm add node
> > E) Penultimate Alternative: UIRB says positional paramenters are not > CLIP Companion preferred, but could be considered acceptable: > > isnsadm add-dd
> isnsadm add-node
> > F) Final Alternative: UIRB says acceptable, perhaps preferred though > it goes against some mild guidance in the CLIP Companion: > > isnsadm add-node --dd=
> isnsadm add-dd --dd-set=
> > ------------------ > > Historical background: > > PSARC 2003/126 iSCSI project (20030305_rick.mcneal) > UIRB 2004/636 iSCSI CLI (20040825_john.forte) > PSARC 2004/848 Remove SLP from iSCSI (20041223_eric.taylor) > SHARC 2005/066 iSCSI Management API (20050202_kenneth.davis) > PSARC 2005/307 iSNS Client Support for iSCSI (20050512_waikwan.hui) > PSARC 2005/441 iSCSI Target Project (20050725_rick.mcneal) > UIRB 2005/539 iSCSI Target CLI (20050919_rick.mcneal) > UIRB 2005/543 iSCSI MS/T CLI (20050920_david.weibel) > PSARC 2005/591 ISCSI MS/T CLI (20051011_david.weibel) > PSARC 2006/622 iSCSI/ZFS integration (20061103_adam.leventhal) > PSARC 2006/319 iSNS Server (20060516_victor.li) > UIRB 2006/527 iSNS Server CLI (20060907_victor.li) > UIRB 2006/674 iSNS Server BUI (20061205_gary.horton) > > 2005/441's CLI spec: > > Usage: iscsitadm create [-?] [-?] [] > iscsitadm create target > iscsitadm create initiator > iscsitadm create tpgt > Usage: iscsitadm list [-?] [-?] [] > iscsitadm list target [OPTIONS] [] > iscsitadm list initiator [OPTIONS] [] > iscsitadm list tpgt [OPTIONS] [] > ...etc... > > 2005/441's opinion says > > The other main issue discussed at commitment review was the > sytnax of the iscsitadm CLI and why it was not CLIP compli- > ant. The project team noted that iscsiadm had been approved > by the UIRB and it too was not CLIP compliant. The team > wanted the CLIs for iSCSI to be consistent. Hence, the > requirements regarding the syntax of the CLI became muddy to > the project team. After considerable discussion, the PSARC > members decided to approve the iscsitadm interface as is. > However, there was the strong desire of the members that a > follow on project be considered to bring the interface into > CLIP compliance. See PAC advice below regarding CLIP compli- > ance. Moreover, members stated that no future CLI would be > approved that utilizes the syntax that iscsiadm, iscsitadm > and mpathadm employ. > > 2. The PAC must consider funding a follow on project to > fix the syntax used by mpathadm, iscsiadm, and iscsi- > tadm to become CLIP compliant. Also, no future pro- > jects will be approved that employ the syntax used by > these CLIs. > > > In the issues for 2006/319: > > jdc-6 It seems awkward to have to specify the argument type twice > for the add-* and remove-*functions. In other words, > "add-dd --dd foo bar" seems redundant (the "dd" type of the > argument is specified twice), where either "add-dd foo bar" or > "add --dd foo bar" would be more natural. > > (If this is a CLIP problem, let's do what is usable rather > than what the standard says.) > > Charles LaBrec (UIRB case owner) concludes > > I don't mean to be overly pedantic, but given that the guidelines > were given scrutiny and approval by PSARC, I don't feel I have the > latitude to go against them without good justification, at least at > the UIRB. I've always felt that ARCs have the capability to > override, if they wish (and particularly PSARC, as it governs the > guidelines). The only thing I would ask is that there be guidance by > a change to CLIP and the companion so that I and project teams know > what is the correct direction. > > Hyon, John Plocher, Mark, and Charles LaBrec (UIRB) looked at several > alternatives: > > A) Existing proposal: > > isnsadm add-dd --dd
# add dd to dd set > isnsadm add-node --node
# add node to dd > isnsadm remove-dd --dd
# remove dd from dd set > isnsadm remove-node --node
# remove node from dd > > UIRB Approved. > > B) Alternate 1 > > isnsadm add --dd
# add dd to dd set > isnsadm add --node
# add node to dd > isnsadm remove --dd
# remove dd from dd set > isnsadm remove --node
# remove node from dd > > There is a strong recommendation in the CLIP Companion to avoid > having mutually exclusive sets of options for a given subcommand. > > This clarifies the usage lines and documentation, by making it > absolutely clear which options go with which subcommand. In the > above case, the syntax is relatively simple, so it wouldn't be as > confusing. However, if more options start to be added to one form or > the other as the CLI evolves, then we get into this situation. > > The reference in the CLIP companion is in section 4.3 Subcommands: > > Q: My subcommand allows two very different uses, and each has > mutually unrelated options (e.g., myutility add [-gou] entity and > myutility add [-ghklr] entity > > A: You should revise your design. This suggests that you actually > have two different operations, and so should use different names. > > In this case, one would also have consider an overall "style" issue, > as it would seem awkward that some subcommands are single words, and > others hyphenated. If this alternative were chosen, it would seem > necessary to overhaul all the subcommand names to be consistent. > > C) Alternate 2: > > isnsadm adddd
> isnsadm addnode
> isnsadm removedd
> isnsadm removenode
> > Also from the CLIP Companion, 4.3 Subcommands: > > In some cases, a utility may operate on a type of object and its > sub-objects. In these cases, the subcommand should be a verb > followed by a hyphen followed by the name of the kind of object to > operate on. > > Q: I'd prefer to see verbNoun, verbnoun, "verb noun", "verb -t > noun" or "noun" as my subcommand form, rather than "verb-noun" > > A: This is one of these cases where all the possible design > alternatives provide roughly the same level of usability. The > design question then becomes: what is most consistent? Each of these > design possibilities has been closely examined, and the "verb-noun" > scheme seems to be the best. "verbNoun" involves mixed > capitalization which many dislike. "verbnoun" tends to produce names > that are hard to parse when unusual terms appear in them. "verb > noun" and "verb -t noun" don't really save any typing and add other > complexities. Finally, "noun" doesn't convey any sense of action. > > In the above, "adddd" seems to be the type of command one would > mistype a lot. > > This alternative also suffers from the usage of positional > parameters, which will be discussed later. > > D) Alternative 3: > > isnsadm add dd
> isnsadm add node
> isnsadm remove dd
> isnsadm remove node
> > Double-word subcommands are not CLIP #14 compliant, nor recommended > by the Companion: > > #14: The form “command subcommand [options] [operands]” is > appropriate for grouping similar operations. Subcommand names should > follow the same conventions as command names as specified in > guidelines 1 and 2. > > #2: Utility names should include lower-case letters (the lower > character classification) and digits only from the portable > character set. [Subsequently relaxed to include the hyphen by the > Companion] > > Q: I'd prefer to see ... "verb noun", ... as my subcommand form, > rather than "verb-noun" > > A: This is one of these cases where all the possible design > alternatives provide roughly the same level of usability. The design > question then becomes: what is most consistent? Each of these design > possibilities has been closely examined, and the "verb-noun" scheme > seems to be the best. .... "verb noun" and "verb -t noun" don't > really save any typing and add other complexities.... > > E) Penultimate Alternative > > isnsadm add-dd
> isnsadm add-mode
> isnsadm remove-dd
> isnsadm remove-node
> > Team: The user has to remember the order since there is no option > involved. zpool has the simliar syntax. > > In the CLIP Companion, under 4.6 Operands: > > Q: I'd like to specify things with operands in a particular order. > Rather than using required options, I'd like to say that operand #1 > is one thing, operand #2 is another thing, and so on. > > A: These are called "positional parameters". In general, these seem > to be a bad idea. More than two positional parameters is hard for > people to remember. In the general case, even two is difficult > because it is often hard to remember whether A goes before or after > B. One common utility which uses positional parameters reasonably > easily is cp, where the last operand is the destination while the > preceding are all the things to be moved. Yet, you have probably on > occasion not specified the destination item and so moved all the > files into some other location than you intended. This demonstrates > that this good case can still cause problems. In general, we > strongly recommend the use of options (even required options) rather > than positionally-significant operands because this reduces the > usability problems that positional ones involve. > > In this case if you think along the lines of: "since I can add more > than one dd name, the first is the set and the rest are the dd's", > then the syntax makes some sense. > Note, however, that this is opposite to the rationale used in the > far more commonly used utilities mv and cp, where it's the last one > that is the container (i.e., directory)... > > F) Final Alternative: > > isnsadm add-node --dd=
> isnsadm add-dd --dd-set=
> isnsadm remove-node --dd=
> isnsadm remove-dd --dd-set=
> > UIRB: "preferred" > > The CLIP companion is not very specific on the issue of whether the > operands of a command should refer to the "noun" of the subcommand > or whether the noun should be referred to in an option. However, an > example in the Companion shows the latter, which was the rationale > for preferring the CLI syntax that was approved: > > | qsset create myset|| > qsset add-drive -q newdrive myset > > [ using "long-option notation", the above might look like: ] > qsset add-drive --drive=newdrive myset > | > > On reflection, considering this from the principle of consistency > and the principle of least surprise, I believe this guidance is > suspect, and leads to at least part of the issue raised by the PSARC > review. > > It would seem preferred to have the operands match the object type > specified by the "noun". This would eliminate confusion similar to > that raised by the discussion for positional parameters--otherwise, > users have to remember for each subcommand which argument is the > option, and which is the operand. Secondly, it allows for a CLI to > extend itself if the design at first only has some kind of "global > collection" and later adds "named collections". In other words, > "qsset add-drive newdrive" might be an acceptable design initially, > and then when named sets are created, the option referring to the > set can then simply be added. This is also extensible to situations > where an object might be added to more than one class of collection. > > If this rationale is accepted, the UIRB would like to consider it a > precedent for future reviews.|| > > > > > From brian.utterback@sun.com Tue Mar 13 10:28:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2DHS0tN023825 for ; Tue, 13 Mar 2007 10:28:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2DHRtbX014342 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 13 Mar 2007 17:28:00 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JEU00D0DR6K2Q00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 13 Mar 2007 10:27:56 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JEU008ZJR6KPW80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 13 Mar 2007 10:27:56 -0700 (PDT) Received: from [129.148.226.17] (sr1-unsh01-05.East.Sun.COM [129.148.226.17]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2DHRtgG002123 for ; Tue, 13 Mar 2007 13:27:55 -0400 (EDT) Date: Tue, 13 Mar 2007 13:27:55 -0400 From: Brian Utterback Subject: PSARC Meeting Minutes 01/24/2007 Inception: 2006/319 To: psarc-ext@sun.com Message-id: <45F6DF1B.7040902@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_wKkoHwLrKqtG/zKcKQ0n3A)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.10pre (X11/20070215) Status: RO Content-Length: 13032 This is a multi-part message in MIME format. --Boundary_(ID_wKkoHwLrKqtG/zKcKQ0n3A) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT This is a resend of the PSARC Meeting minutes for 01/24/07 with only the portions relevant to case 2006/319 retained to allow case mail file to be open on OpenSolaris.org -- blu "Remember 'A Thousand Points of Light'? With a network, we now have a thousand points of failure." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_wKkoHwLrKqtG/zKcKQ0n3A) Content-type: text/plain; name=20070124 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20070124 SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 01/24/2007 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes James Carlson: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes Kais Belgaied: yes Sherri Shieh: yes ATTENDEES - Interns: Don Cragun: yes Peter Dennis: yes Wyllys Ingersoll: no Rick Matthews: no Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Phil Harman: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback yes Michael Haines no Sebastien Roy no Alan Hargreaves yes Darren Reed no David Chieu no Paul Lee no Kevin X. Song no Guests: Alan Coopersmith Mark Carlson James McPherson Hyon Kim Victor Li External callers: Gary Horton Al Hopper --------------------------------------------------------------------------- AGENDA ------- 01/24/2007 glenn ARC business only (This is an open case) 10:00-10:10 ARC Business (internal) (bridge in outside concall number) 10:10-10:55 Inception: iSNS Server (2006/319) Submitter: Victor Li Owner: Mark Carlson Intern: Brian Utterback Interest: hyon.kim@sun.com --------------------------------------------------------------------------- ARC Business ============ [REMOVED] Other Business -------------- [REMOVED] Issues to Escalate ------------------ * Secure By Default, Network Installation Security - are these in affect now? ============================================================================ Inception: iSNS Server (2006/319) Submitter: Victor Li Owner: Mark Carlson Intern: Brian Utterback Interest: hyon.kim@sun.com SUMMARY ======= * Opinion fodder or PAC advice - remote administrator interface * For commitment, this will need to be in the spec (the vendor specific attributes) * Project team should use patch binding. * Project team should list package names as well * Update spec - Project team will be using the SMF agent that will in turn provide the HA agent. * Don't change existing history - if you update it, you change it (updating taxonomies) * Update design doc - explain why this isn't going to reduce the applicability of this specification. * Clean up CLI ISSUES ======= jdc-1 20q10: "Unlike iSCSI the iSNS spec doesn't include authentication as part of the protocol." That seems to conflict with RFC 4171 section 5.5, which describes how authentication is done for iSNS, both for broadcast and unicast. Please clarify. No broadcast/multicast implemented, no auth block needed. jdc-2 Confused by the data store: what things are in SMF? What are the attribute names? What things are in the separate data store? Some appear to be scalars that could be handled by SMF; must they be separate? (Why would the user want to or need to choose a location for the private data store? Why is that configurable?) Will provide property names property names. jdc-3 Is any result caching done? (Such as a negative cache for authentication failures ... ?) no auth done. jdc-4 Need SMF details -- proposed FMRIs. Will provide jdc-5 Does the user have to enable via SMF separately, or does isnsadm do the service enable/disable as required? At minimum, provide detailed error is service is not enabled. Better to sensibly enable. jdc-6 It seems awkward to have to specify the argument type twice for the add-* and remove-*functions. In other words, "add-dd --dd foo bar" seems redundant (the "dd" type of the argument is specified twice), where either "add-dd foo bar" or "add --dd foo bar" would be more natural. (If this is a CLIP problem, let's do what is usable rather than what the standard says.) Will review. To many dd's Must fix before commitment, even if need to overrule UIRB. jdc-7 What privileges are required for the iSNS server itself to run? What UID does it use? Maybe None? Need to read and write data store? Maytbe Daemon? jdc-8 Need to address on-the-wire security, including the use of PKI for the authentication block as well as IPsec profiles needed for unicast data. jdc-9 Is this service multi-level aware for use with TX? Will talk to TX folks. Probably not and not needed. jdc-10 What parts of RFC 4171 are included? What are not? (Such as vendor-specific attributes ... ?) Make more explicit jdc-11 If this project doesn't define the DHCP changes, then it sounds like this case is dependent on a future case that does this. Independent jdc-12 Are SLP extensions expected, per section 2.5.1 of RFC 4171? Not planned now. jdc-13 Is it possible to have a scriptable output format from the CLI? The "Uncommitted" output stability doesn't allow for reliable scripting. Will consider jdc-14 Nit: while you're roping off "DEFAULT" as domain and set names, I suggest adding all names that begin with "SUNW" to the list. It's cheap, and it allows us room for local extensions, if any are ever needed. jdc-15 Nit: the delete-* functions also fail if the object is reserved, correct? Thus "delete-dd-set DEFAULT" would return an error, and wouldn't just say "not found." jdc-16 Nit: Is the door interface really required? (It will force your server to be multithreaded and more complex. If it's possible, relying on the standards-track protocol over loopback and using getpeerucred may be simpler and easier to maintain.) eg-1 20q1 Micro or patch binding? (In practice, "micro" really means "minor" since we don't do micro releases. The difference between patch and micro is that a patch must be removable.) Per 20q11, suggesting integration into S10u11, patch would be required. Change to patch eg-2 20q5 Proposed package names and stabilities? Will list. eg-3 20q8 Is it part of this project to provide the HA Agent for Clustering? Existing HA facility to convert SMF to HA eg-4 20q11 Is anything particular done with the listed signals, or is the default action accepted? Will do the right thing vis a vis SMF. eg-5 20q13 "Standard" and "Evolving" are obsolete taxonomies. Both should be "Committed" This is imported interfaces. Okay as is. eg-6 20q13 Is the output of the CLI an interface (e.g., parseable), or just intended tor human consumption? Covered ajh-1 The imports are using the old taxonomy. This is more a question for the rest of the ARC, is this right (as that's how I assume it's currently defined in the old cases), or should the project be using the new taxonomy? Do we have best practice on this or are we just accepting what seems reasonable? ajh-2 I note the project team's concern over the standard's lack of authentictaion within the protocol, and the risks that were listed in the 20Q. What is the project doing to alleviate those risks and concerns? blu-0 If the data store maintains the current set of attributes for the clients, how do you deal with "stale" data when the service first starts up? Use inquiry blu-1 Nits: Page 1 of iSNS-CLI-Design.pdf: "comments" mispelled. Page 9 of iSNS-CLI-Design.pdf: "Discovery" mispelled. wes-0 terminology/background: what's the expected granularity of a "discovery domain"? Discovery domain adminstrative entity. wes-1 iSNS-Design: "UDP will not be supported for device registration, deregisteration and device query" Will this limitation create an interoperability problem? Is that consistent with: (a) the protocol specification and (b) existing and forseeable iSCSI implementations? if it's consistent with (b) but not (a), what, if anything, are we doing to get the spec clarified? Will research. No known clients require UDP. wes-2 use of SIGKILL to terminate daemon: no graceful shutdown required? wes-3 (4.1.2) "IPsec is deployed at the IP layer so once a connection is made to the server there is no mechanism to securely associate a connection with a control node other than name validation." this is not entirely true. please describe your requirements here in more detail. contact bill offline wes-4 (4.3): ".. will be provided later": by commitment review? wes-5 20Q8: what's the update strategy for the config file in /etc/isns? write-to-temp/fsync/rename? How will that scale up to large deployments with high rates of change? wes-6 20Q18: an 18MByte flat file seems a bit unwieldy. We have enough trouble with /var/sadm/install/contents .... gw-0 Thanks for being proactive relative to SMF and RBAC. gw-1 What doesn't qualify for a Patch release binding? gw-2 Why does isnsadm require sys_config? Better auth dirven than priv driven gw-3 Presumably port 3205 is registered. Is RFC 4171 standards track? Is there any chance of getting proper authentication and authorization for remote management access? currently planned same machine only. gw-4 Is the intent that isnsadm output is a programming interface? If not, perhaps Not an Interface or Volatile. gw-5 Spec 2. "For data store .... LDAP will be examined...." What are the trade offs here? IMO LDAP is not a remote database It is a name service repository (Directory Access Protocol) as in X500 directory. No LDAP! gw-6 Spec 4.1.1.1 Nit: what's the stability of svc:/network/isns_server:default"? 4.1.1.2 The properties need to be in the interface table with stabilities. The man page needs to discuss the authorization values for the action_authorization and value_authorization 4.1.1.3 What's not clear in the SMF policy that value_authorizations have the form solaris.smf.value....? I'd like to update the policy to be clear. Is this clear gw-7 Spec 4.1.2, Just want to be clear, accepting control from a remote system is disabled by default. No remote admin gw-8 How does the svc:/network/isns_server meet the principle of least privilege? I.e., what is the method_credential? Will reduce priv gw-9 What happens if network/isns_server finds port 3205 already bound to? (Goes into maintenance or something else?) gw-10 The interaction with Sun Cluster seems unfriendly and unfortunate. What can be done about it? gw-11 How does svc:/network/isns_server work in a zones environment? gw-12 CLI: Why --long, the vast majority of /usr/sbin/*adm don't have them? What use is -V? Why -? which generally leads to "Not found" rather than help subcommand? kb-01 20Qs. Observability - statistics. A numbers of statistics can be helpful to maintain here, and IMO the project's observability won't be complete without them - # of clients registration . - maximum # concurrent requests reached - # of failures and failures per reason these would be needed for more accurate assessment of the performance of the (virtual) machine dedicated to run the iSNS server, and to gain a better diagnose failures. kb-02 It is not clear to me what administrative actions (what syscall) exactly really need sys_config in this projects. kb-03 20Qs - Security I'm not sure about the justifiction for doors vs opening a port for remote administration. kb-04 20Qs - Q18 about running the iSNS server in a seaparate machine. A Container (Solaris zone with assigned resource controls) sounds like a lighter weight solution for this. kb-05 Functional Spec. DDDereg. What happens to the orphan members of a deregistered DD ? Do they get re-assigned to the default DD since the devices are still operational and reachable? kb-06 Interface table. The DHCP option for iSNS needs to be listed here. NEXT STEP ========= * Project team will resolve all issues from today's meeting before coming back to commitment. --Boundary_(ID_wKkoHwLrKqtG/zKcKQ0n3A)-- From sacadmin Wed Apr 18 07:37:45 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3IEbiei005203 for ; Wed, 18 Apr 2007 07:37:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3IEauH6028543; Wed, 18 Apr 2007 15:36:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGP0050R79MON00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 07:36:58 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP000XV79JFK60@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 07:36:55 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IEascW023311; Wed, 18 Apr 2007 07:36:54 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3IEbcS1005148; Wed, 18 Apr 2007 07:37:38 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l3IEbcnj005147; Wed, 18 Apr 2007 07:37:38 -0700 (PDT) Date: Wed, 18 Apr 2007 07:37:38 -0700 (PDT) From: PSARC-coord@Sun.COM Subject: New PSARC Materials Submitted 2006/319 iSNS Server To: PSARC@Sun.COM Cc: Victor.Li@Sun.COM, PSARC-coord@Sun.COM Message-id: <200704181437.l3IEbcnj005147@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 675 New Materials submitted for PSARC 2006/319 iSNS Server Status: commitment scheduled 04/25/2007 Files: /shared/sac/PSARC/2006/319/commitment.materials/iSNS-CLI-Design.pdf /shared/sac/PSARC/2006/319/commitment.materials/iSNS-Design.pdf /shared/sac/PSARC/2006/319/commitment.materials/iSNS_Cluster.txt /shared/sac/PSARC/2006/319/commitment.materials/isns_server.xml /shared/sac/PSARC/2006/319/commitment.materials/isnsdata.dtd.1 /shared/sac/PSARC/2006/319/commitment.materials/isnsmgmtSchema.xsd /shared/sac/PSARC/2006/319/commitment.materials/issues.response /shared/sac/PSARC/2006/319/commitment.materials/ReviewQuestions Please let me know if you have questions. - PSARC From brian.utterback@sun.com Wed Apr 18 12:18:03 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3IJI3YO019043 for ; Wed, 18 Apr 2007 12:18:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3IJHI3i056333 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 18 Apr 2007 13:17:18 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JGP0040DK8U7300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 18 Apr 2007 12:17:18 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP000LUK8OKR90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 18 Apr 2007 12:17:13 -0700 (PDT) Received: from [129.148.226.13] (sr1-unsh01-03.East.Sun.COM [129.148.226.13]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IJHBim015564 for ; Wed, 18 Apr 2007 15:17:12 -0400 (EDT) Date: Wed, 18 Apr 2007 15:17:11 -0400 From: Brian Utterback Subject: [Fwd: New PSARC Materials Submitted 2006/319 iSNS Server] To: PSARC-EXT@sun.com Message-id: <46266EB7.7090400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.0pre (X11/20070415) Status: RO Content-Length: 1330 Forwarding to PSARC-ext now that the commitment matierials are available at http://opensolaris.org/os/community/arc/caselog/2006/319/ -------- Original Message -------- Subject: New PSARC Materials Submitted 2006/319 iSNS Server Date: Wed, 18 Apr 2007 07:37:38 -0700 (PDT) From: PSARC-coord@sun.com To: PSARC@sun.com CC: Victor.Li@Sun.COM, PSARC-coord@sun.com New Materials submitted for PSARC 2006/319 iSNS Server Status: commitment scheduled 04/25/2007 Files: /shared/sac/PSARC/2006/319/commitment.materials/iSNS-CLI-Design.pdf /shared/sac/PSARC/2006/319/commitment.materials/iSNS-Design.pdf /shared/sac/PSARC/2006/319/commitment.materials/iSNS_Cluster.txt /shared/sac/PSARC/2006/319/commitment.materials/isns_server.xml /shared/sac/PSARC/2006/319/commitment.materials/isnsdata.dtd.1 /shared/sac/PSARC/2006/319/commitment.materials/isnsmgmtSchema.xsd /shared/sac/PSARC/2006/319/commitment.materials/issues.response /shared/sac/PSARC/2006/319/commitment.materials/ReviewQuestions Please let me know if you have questions. - PSARC -- blu "Remember 'A Thousand Points of Light'? With a network, we now have a thousand points of failure." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From sacadmin Wed Apr 25 13:32:49 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 l3PKWnJo020599 for ; Wed, 25 Apr 2007 13:32:49 -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 l3PKVxef009543 for ; Wed, 25 Apr 2007 13:31:59 -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 l3PKVsex018050 for ; Wed, 25 Apr 2007 13:31:54 -0700 (PDT) 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 <0JH200601M6DOJ00@d1-sfbay-10.sun.com> (original mail from Sherri.Shieh@Sun.COM) for PSARC-members@sac.sfbay.sun.com; Wed, 25 Apr 2007 13:31:54 -0700 (PDT) Received: from [129.150.19.183] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH200M6WMD5D7UG@d1-sfbay-10.sun.com> for PSARC-members@sac.sfbay.sun.com; Wed, 25 Apr 2007 13:31:53 -0700 (PDT) Date: Wed, 25 Apr 2007 13:32:11 -0700 From: Sherri Shieh Subject: Pre-draft opinion now available for 2006/319 Sender: Sherri.Shieh@Sun.COM To: "Mark A. Carlson" , Brian Utterback Cc: PSARC-members@sac.sfbay.sun.com Reply-to: Sherri.Shieh@Sun.COM Message-id: <462FBACB.7010809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 924 Mark, Brian, and PSARC members, I went ahead and generated the pre-draft opinion and is now in the case directory: http://sac.eng/arc/PSARC/2006/319/draftopinion.ms If there's anything that I can change or do better, please let me know. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sac-owner Wed Apr 25 14:02:34 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l3PL2XWR022426 for ; Wed, 25 Apr 2007 14:02:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3PL1aDX021265 for <@newsunmail1brm.central.sun.com:sac-review@sun.com>; Thu, 26 Apr 2007 05:01:43 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JH200913NQSXX00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Apr 2007 15:01:40 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH2000GENQSCL40@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Apr 2007 15:01:40 -0600 (MDT) 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 l3PL1ehN021731 for ; Wed, 25 Apr 2007 14:01:40 -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 <0JH200E01NIMHS00@d1-sfbay-09.sun.com> (original mail from Sherri.Shieh@Sun.COM) for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Apr 2007 14:01:40 -0700 (PDT) Received: from [129.150.36.56] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH200AI4NQGCD7F@d1-sfbay-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Apr 2007 14:01:36 -0700 (PDT) Date: Wed, 25 Apr 2007 14:01:41 -0700 From: Sherri Shieh Subject: PSARC Case Approved 04/25/2007 - 2006/319 Sender: Sherri.Shieh@sun.com To: Sherri Shieh Reply-to: Sherri.Shieh@sun.com Message-id: <462FC1B5.9060402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 259 PSARC approved 04/25/2007 Case: iSNS Server (2006/319) Incompatible Changes: none Precedent: none Note: Pre-draft opinion is in the case directory. If more information is needed, please contact the case owner/intern. From brian.utterback@sun.com Mon Aug 13 11:03:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7DI3CjL019116 for ; Mon, 13 Aug 2007 11:03:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7DI0S0I009916 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 13 Aug 2007 11:00:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMQ00H0V4P8SK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 13 Aug 2007 12:00:45 -0600 (MDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMQ005HJ4P1XMC0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 13 Aug 2007 12:00:37 -0600 (MDT) Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l7DI0aw1012585 for ; Mon, 13 Aug 2007 14:00:36 -0400 (EDT) Date: Mon, 13 Aug 2007 14:00:35 -0400 From: Brian Utterback Subject: PSARC/2006/319 iSNS Server [Draft Opinion Review ] To: psarc-ext@sun.com Message-id: <46C09C43.9040806@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_frkpRhbWMdKeu96tGsDZGA)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.7pre (X11/20070811) Status: RO Content-Length: 5842 This is a multi-part message in MIME format. --Boundary_(ID_frkpRhbWMdKeu96tGsDZGA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Please review this opinion and provide comments by 20 August 2007. -- blu Screening ideas are indeed thought up by the Office for Annoying Air Travelers and vetted through the Directorate for Confusion and Complexity - Kip Hawley, Head of the TSA ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_frkpRhbWMdKeu96tGsDZGA) Content-type: text/plain; name=draftopinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=draftopinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: iSNS Server Submitted by: Victor Li File: PSARC/2006/319/opinion.ms Date: April 25, 2007 Committee: Mark Carlson (opinion written by Brian Utter- back), Jim Carlson, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Implement an iSNS server in accordance with IETF RFC 4171. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch binding for the ON consolidation. 3. Interfaces The project exports the following interfaces. ___________________________________________________________________________________ | Interfaces Exported | |_________________________|_________________|_____________________________________| |Interface | Classification | Comments | |_________________________|_________________|_____________________________________| |isnsadm(1M) | Volatile | CLI | |_________________________|_________________|_____________________________________| |isnsadm output: | | | |_________________________|_________________|_____________________________________| | Response label | Volatile | | |_________________________|_________________|_____________________________________| | data-field | Volatile | | |_________________________|_________________|_____________________________________| |_________________________|_________________|_____________________________________| PSARC/2006/319 Copyright 2006 Sun Microsystems - 2 - ___________________________________________________________________________________ | Interfaces Exported | |_________________________|_________________|_____________________________________| |Interface | Classification | Comments | |_________________________|_________________|_____________________________________| | Error response | Volatile | | |_________________________|_________________|_____________________________________| |/etc/isns/isnsdata.xml | Project private| Data store file | |_________________________|_________________|_____________________________________| |/etc/isns/isnsdata.old | Project private| Previous version of data store file| |_________________________|_________________|_____________________________________| |/var/run/isns_server_door| Project private| a file for door interface | |_________________________|_________________|_____________________________________| The project imports the following interfaces. ___________________________________________ | Interfaces Imported | |_____________|________________|__________| |Interface | Classification| Comments| |_____________|________________|__________| |IETF RFC 4171| Standard | | |_____________|________________|__________| |libscf | Evolving | | |_____________|________________|__________| |libdoor | Evolving | | |_____________|________________|__________| Opinion The committe voted to approve the case, with the provision that some minor aspects of the spec be updated. The changes have been made and are reflected in the documents in the final.materials directory. 4. Minority Opinion(s) none 5. Advisory Information On the advice of the committee, the project team has re- classified the CLI interfaces to volatile, but promises to promote them to committed in the next release. 6. Appendices 6.1. Appendix A: Technical Changes Required 1. TCR is to remove the read authorization so that PSARC/2006/319 Copyright 2006 Sun Microsystems - 3 - everyone can read it. 6.2. Appendix B: Technical Changes Advised none 6.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2006/319. commitment.materials/ReviewQuestions commitment.materials/iSNS-CLI-Design.pdf final.materials/iSNS-Design.pdf commitment.materials/iSNS_Cluster.txt final.materials/isns_server.xml commitment.materials/isnsdata.dtd.1 commitment.materials/isnsmgmtSchema.xsd commitment.materials/issues.response PSARC/2006/319 Copyright 2006 Sun Microsystems --Boundary_(ID_frkpRhbWMdKeu96tGsDZGA)-- From sac-owner Tue Oct 30 12:39:16 2007 Received: from dm-east-01.east.sun.com (dm-east-01.East.Sun.COM [129.148.9.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9UJdGQH019457 for ; Tue, 30 Oct 2007 12:39:16 -0700 (PDT) Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9UJZgd2005651; Tue, 30 Oct 2007 15:35:43 -0400 (EDT) Message-ID: <4727878D.7030805@sun.com> Date: Tue, 30 Oct 2007 15:35:41 -0400 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071014) MIME-Version: 1.0 To: sac-review@sac.sfbay.sun.com CC: mark carlson , hyon.kim@sun.com Subject: PSARC/2006/319 iSNS Server [Opinion Review ] Content-Type: multipart/mixed; boundary="------------060106070007070209060105" Status: RO Content-Length: 5882 This is a multi-part message in MIME format. --------------060106070007070209060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please review the enclosed opinion and provide comments by Nov. 7th, 2007. In addition to the enclosed text opinion, the opinion is available in the case directory in ms, ps and pdf format. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --------------060106070007070209060105 Content-Type: text/plain; name="opinion.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opinion.txt" sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: iSNS Server Submitted by: Victor Li File: PSARC/2006/319/opinion.ms Date: April 25, 2007 Committee: Mark Carlson (Brian Utterback), James D. Carlson, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Implement an iSNS server in accordance with IETF RFC 4171. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. See reference [2] for final design docu- ment. The project may be delivered in a patch binding for the ON consolidation. 3. Interfaces The project exports the following interfaces. _______________________________________________________________ | Interfaces Exported | |_________________________|_________________|_________________| |Interface | Classification | Comments | |_________________________|_________________|_________________| |isnsadm(1M) | Volatile | CLI | |_________________________|_________________|_________________| |isnsadm output: | | | |_________________________|_________________|_________________| | Response label | Volatile | | |_________________________|_________________|_________________| |_________________________|_________________|_________________| PSARC/2006/319 Copyright 2006 Sun Microsystems - 2 - _______________________________________________________________ | Interfaces Exported | |_________________________|_________________|_________________| |Interface | Classification | Comments | |_________________________|_________________|_________________| | data-field | Volatile | | |_________________________|_________________|_________________| | Error response | Volatile | | |_________________________|_________________|_________________| |/etc/isns/isnsdata.xml | Project private| Data store file| |_________________________|_________________|_________________| |/etc/isns/isnsdata.old | Project private| Previous ver-| | | | sion of data| | | | store file | |_________________________|_________________|_________________| |/var/run/isns_server_door| Project private| a file for door| | | | interface | |_________________________|_________________|_________________| |IETF RFC 4171 | Standard | | |_________________________|_________________|_________________| The project imports the following interfaces. _______________________________________ | Interfaces Imported | |_________|________________|__________| |Interface| Classification| Comments| |_________|________________|__________| |libscf | Evolving | | |_________|________________|__________| |libdoor | Evolving | | |_________|________________|__________| Opinion The committe voted to approve the case, with the provision that some minor aspects of the spec be updated. The changes have been made and are reflected in the documents in the final.materials directory. 4. Minority Opinion(s) none 5. Advisory Information On the advice of the committee, the project team has re- classified the CLI interfaces to volatile, but promises to promote them to committed in the next release. PSARC/2006/319 Copyright 2006 Sun Microsystems - 3 - 6. Appendices 6.1. Appendix A: Technical Changes Required 1. TCR is to remove the read authorization so that everyone can read it. 6.2. Appendix B: Technical Changes Advised none 6.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2006/319. 1 commitment.materials/iSNS-Design.pdf 2 final.materials/iSNS-Design.pdf Further supplementary material may be found in the following files: commitment.materials/ReviewQuestions commitment.materials/iSNS-CLI-Design.pdf final.materials/iSNS-Design.pdf commitment.materials/iSNS_Cluster.txt final.materials/isns_server.xml commitment.materials/isnsdata.dtd.1 commitment.materials/isnsmgmtSchema.xsd commitment.materials/issues.response PSARC/2006/319 Copyright 2006 Sun Microsystems --------------060106070007070209060105-- From sac-owner Thu Nov 15 12:23:26 2007 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lAFKNQI4009392 for ; Thu, 15 Nov 2007 12:23:26 -0800 (PST) Received: from [129.148.226.18] (sr1-unsh01-06.East.Sun.COM [129.148.226.18]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAFKNOhl015359; Thu, 15 Nov 2007 15:23:25 -0500 (EST) Message-ID: <473CAABC.5090907@sun.com> Date: Thu, 15 Nov 2007 15:23:24 -0500 From: Brian Utterback User-Agent: Thunderbird 2.0.0.7pre (X11/20071110) MIME-Version: 1.0 To: sac-opinion@sac.sfbay.sun.com CC: solaris-pac-opinion@sun.com Subject: PSARC/2006/319 iSNS Server Content-Type: multipart/mixed; boundary="------------010200030106000606050200" Status: RO Content-Length: 5668 This is a multi-part message in MIME format. --------------010200030106000606050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Opinion for archive. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --------------010200030106000606050200 Content-Type: text/plain; name="opinion.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opinion.txt" sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: iSNS Server Submitted by: Victor Li File: PSARC/2006/319/opinion.ms Date: April 25, 2007 Committee: Mark Carlson (Brian Utterback), James D. Carlson, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Implement an iSNS (Internet Storage Name Service) server in accordance with IETF RFC 4171. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch binding for the ON consolidation. 3. Interfaces The project exports the following interfaces. _______________________________________________________________ | Interfaces Exported | |_________________________|_________________|_________________| |Interface | Classification | Comments | |_________________________|_________________|_________________| |isnsadm(1M) | Volatile | CLI | |_________________________|_________________|_________________| |isnsadm output: | | | |_________________________|_________________|_________________| | Response label | Volatile | | |_________________________|_________________|_________________| |_________________________|_________________|_________________| PSARC/2006/319 Copyright 2006 Sun Microsystems - 2 - _______________________________________________________________ | Interfaces Exported | |_________________________|_________________|_________________| |Interface | Classification | Comments | |_________________________|_________________|_________________| | data-field | Volatile | | |_________________________|_________________|_________________| |/etc/isns/isnsdata.xml | Project private| Data store file| |_________________________|_________________|_________________| |/etc/isns/isnsdata.old | Project private| Previous ver-| | | | sion of data| | | | store file | |_________________________|_________________|_________________| |/var/run/isns_server_door| Project private| a file for door| | | | interface | |_________________________|_________________|_________________| |IETF RFC 4171 | Commited | | |_________________________|_________________|_________________| The project imports the following interfaces. _______________________________________ | Interfaces Imported | |_________|________________|__________| |Interface| Classification| Comments| |_________|________________|__________| |libscf | Commited | | |_________|________________|__________| |libdoor | Commited | | |_________|________________|__________| 4. Opinion The committee voted to approve the case, with the provision that some minor aspects of the spec be updated. The changes have been made and are reflected in the documents in the final.materials directory. The committe noted that there was no sensitive information in the iSNS configuration and that there is no need to have a separate read authorization to be able to read it. 5. Minority Opinion(s) none 6. Advisory Information The project team is advised to provide a committed CLI interface in a suqsequent release. PSARC/2006/319 Copyright 2006 Sun Microsystems - 3 - 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The read authorization for the iscsiadm command must be removed. 7.2. Appendix B: Technical Changes Advised none 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2006/319. 1 commitment.materials/iSNS-Design.pdf 2 final.materials/iSNS-Design.pdf Further supplementary material may be found in the following files: commitment.materials/ReviewQuestions commitment.materials/iSNS-CLI-Design.pdf final.materials/iSNS-Design.pdf commitment.materials/iSNS_Cluster.txt final.materials/isns_server.xml commitment.materials/isnsdata.dtd.1 commitment.materials/isnsmgmtSchema.xsd commitment.materials/issues.response PSARC/2006/319 Copyright 2006 Sun Microsystems --------------010200030106000606050200--