RE: iSCSI: Wrapping up SendTargets

["Mallikarjun C." <cbm@rose.hp.com>]

>
>iSCSI Team,
>I think that Jim has said it well.  I had a proposal about an Annex, for
>the SendTargets, but whether we do that or not, I am getting the feeling
>that most folks think, at least for this version of the protocol that we
>keep SendTargets, and the subset that can be used as a Report Portal
>Groups.  Even Mark, even though he thought he could Hack the SLP Source
>code to do a similar thing, thought that it was best to keep SendTargets.
>
>I would like to propose that we Close on Keeping the SendTargets command,
>and the subset that is either Report Portal Groups or SendTargets <iSCSI
>Target Name> (which returns only the information for that target only).
>
>Now as to where we put the command.  I suggested an Annex, but can clearly
>live with it in the Main document.  I seemed to get very little support for
>the idea of the Annex, and since I think that the functions of Report
>Portal Groups, must be part of the base,  I would like to suggest that we
>either
>1) Place the SendTargets in the Annex, and put a Report Portal Groups in
>the main document, or
>2) Keep the Send Targets in the Main Document and add the argument of
><iSCSI Target Name>
>
>Please state your positions

My support is for option 2 for the reasons that I alrady listed 
in my previous posting.  
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com

>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
>Internet address: hufferd@us.ibm.com
>
>
>Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: Wrapping up SendTargets
>
>
>
>
>Folks,
>
>I think this thread is wandering off the field.
>
>The question is the issue of SendTargets.  Let's remind ourselves of the
>original purpose of this proposed protocol: namely, it's designed for a
>storage box that contains one or more iSCSI target devices to report about
>ITSELF, about what's in it!  This includes both a list of the iSCSI targets
>it has PLUS the session coordination (via tags) of the various
>IPaddress/tcpport combos it supports.
>
>In other words, it's job is to report about itself!  The use of (unicast)
>SLP as an alternative to SendTargets was focused exactly on the same
>question: I ask a single box to tell me about itself.   This function lies
>between the two extremes of (a) static configuration of initiators and (b)
>centralized management via iSNS style services.
>
>Somehow, someway, we need to define a protocol for a box to "tell us about
>itself" in the absense of the centralized management infrastructure.  That
>seems critical to me.  Even if I want to do static configuration, the guy
>doing the configuration needs a way to get at the guts of each new box
>he/she rolls into the environment.
>
>The choices are, it seems, that *every* box would need to support at least
>one of:
>a) SendTargets
>b) modified SLP
>c) iSNS
>
>What's the consensus on the protocol we aim for to solve this middle ground
>discovery problem?
>Jim Hafner
>
>
>
>
>