RE: iSCSI: Support Alias in the protocol

["John Hufferd" <hufferd@us.ibm.com>]

Marjorie,
I did not intend to give a Skewed report.  Since you think I did, I
apologize.

I get so much e-mail I can not remember if you sent it to the list or to
the NDT team, if you say the list, fine, I am not sure it matters, since we
decided in the NDT for me to take it to the meeting in London.

Perhaps it was SNMP instead of SLP, OK, the precedent (see even I can
sometime get some spelling right) is there.  I know you do not think it
counts as much, and that is true, but it does count for something.

Your point that I think you are making -- that a Management tool to input
the Alias is needed so why not leave it up to the Management tool to handle
and remember the Alias etc. -- is perhaps over stated.  All of the
implementations that I am aware of, will have a way to input the Initiator
and Target iSCSI Node Names, etc.  This is really basic stuff, and not a
Tivoli or HP Open View type of management action, especially in small to
mid environments.  Having this basic tool also add the Alias stuff is not a
hard thing to assume.

It also makes since to have the Alias reflected in the MIB, and reported
via SNMP when something happens.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/09/2001 09:41:50 AM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



Well, this interpretation of events is a bit skewed:

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Tuesday, August 07, 2001 9:52 AM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Support Alias in the protocol
>
>
> Today at the 51st meeting of the IETF, I presented an issue that came out
> of the Naming and Discovery Team.

Didn't come out of NDT, I raised it on the IPS list.

>
> That was that some members of the team did not understand why we needed
to
> have an Alias field, which is in the base protocol today, since it was
> technically not needed.

There is no question of "not understanding" anything, the statement of fact
is that this is not used by the protocol, not necessary to the protocol
function, and therefore should be deleted.  I can think of all sorts of
things that "it would be nice for the protocol to do", can I add them all?
It would be nice, for instance, to have a color text command, that would
cause the display on the device to turn a different color - shall we add
that?  Where do you draw the line? ;-)

>The position I presented to the  group was that
> the Naming and Discovery Team did not have consensus, since
> many of us felt that having a Human oriented "Tagging" function was
useful

Many?  Most didn't care!!  A few thought it would "be nice" but agreed it
was not used by the protocol.

..snip..
> One person, at the meeting today, stated that it might not be of extreme
> importance on large Networks with sophisticated Management tools, but it
> was very useful in small to medium environments, where the Management
tools
> were slim.

But it requires a management tool for the alias information to be displayed
to the user.  Does it make a mgmt tool "sophisticated" to add a text label
of it's own to iSCSI target names?  I think not ;-)

> As the conversations when on, it was pointed out by the area director,
> Scott  Bradner, that SLP used a similar Text field in its protocol, so
> there was clearly a president.

This statement is incorrect. Scott made a reference to the fact that *SNMP*
carries this sort of information (mgmt information!).  There is no known
*precident* for this sort of field in a protocol.  Even if you find a
precident, it doesn't mean it's a smart thing to do.

We have been discussing simplifying the protocol.  Deleting this command
doesn't represent a huge simplification, but retaining it on the basis that
"it is nice" is not logical.  The point is where do you draw the line
regarding protocol commands?  Shall we add more "nice to have" things, even
though they aren't used by the protocol but provide some sort of mgmt
function?  Didn't we already go thru this discussion regarding the
SendTargets command?  Let's at least try to be consistant.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com