RE: TargetAlias in SendTarget response

Only problem I see is that spec isnt very lenient on what keys may be sent
during Discovery:

Appendix D:
A SendTargets command consists of a single Text request PDU.
This PDU contains exactly one text key and value. The text key MUST
be SendTargets. The expected response depends upon the value, as
well as whether the session is a discovery or operational session.

The language 'exactly one text key abd value' here is troublesome.  A simple
target that gets anything but a Sendtargets=<something> key during login may
simply fail login rather than respond to that key with NotUnderstood.


Bill




-----Original Message-----
From: Rick McNeal [mailto:[email protected]] 
Sent: Wednesday, May 31, 2006 12:48 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Ips] TargetAlias in SendTarget response

I must not have made myself clear. The expectation would be that the  
target would only send the TargetAlias if a key was sent first by the  
Intiator. For example Sun's initiator could send:

X-com.sun.sendaliases=true

during the login phase when the SessionType=Discovery. The Solaris  
target would then add the TargetAlias information to a  
SendTargets=All response only if that value were true. This wouldn't  
cause any other initiators or targets to break since they  
(initiators) either will not send the key or understand the key  
(targets).

If other folks feel that such a feature is worth prompting then I'll  
write up a proposal to create a new X#sendaliasinfo=true type key.

On May 31, 2006, at 9:52 AM, [email protected] wrote:

> If the purpose is to find the alias of a target in a discovery  
> session,
> wouldn't it be better to define a new text key SendTargetAlias="Target
> Name". This would not break existing implementations (either initiator
> or target).
>
> Legacy targets (those that do not support this key) would just reject
> the request. Legacy initiators would never issue it.
>
> Jacob Cherian
>
>
>
> -----Original Message-----
> From: Rick McNeal [mailto:[email protected]]
> Sent: Wednesday, May 31, 2006 8:18 AM
> To: Eddy Quicksall
> Cc: [email protected]; David Weibel; Sandars,Ken
> Subject: Re: [Ips] TargetAlias in SendTarget response
>
> During a discovery session the TargetName is not sent because it's
> not known. The thought was that in the text response for the
> SendTargets=All the target could return:
>
>      TargetName=iqn.xxxx
>      TargetAlias=fubar
>      TargetAddress=yyyy (1 or more)
>
> To do this without changing the specification means adding a new key
> which is sent by the initiator.
>
> On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote:
>
>> Weren't you looking for a way to display the target alias of the
>> target that was used for discovery? If so then TargetName would not
>> need to be sent.
>>
>> Or are you saying that for every target reported there would be a
>> TargetAlias?
>>
>> Eddy
>>
>> ----- Original Message ----- From: "Rick McNeal"  
>> <[email protected]>
>> To: "Eddy Quicksall" <[email protected]>
>> Cc: <[email protected]>; "David Weibel" <[email protected]>;
>> "Sandars,Ken" <[email protected]>
>> Sent: Wednesday, May 31, 2006 8:40 AM
>> Subject: Re: [Ips] TargetAlias in SendTarget response
>>
>>
>>> Since the TargetName is not required during the discovery session
>>> how would a target know which TargetAlias to return? Not to
>>> mention that during a discovery session there could be many
>>> targets which are discovered.
>>>
>>> It seems like using having an extra key sent by the initiator
>>> during  the discovery session would be the simplest method.
>>>
>>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote:
>>>
>>>> TargetAlias would be allowed in a discovery session if it is not
>>>> in response to the SendTargets key.
>>>>
>>>> Would that be OK? Then there would be no need to change the spec.
>>>>
>>>> Eddy
>>>>
>>>> ----- Original Message ----- From: "Sandars, Ken"
>>>> <[email protected]>
>>>> To: "David Weibel" <[email protected]>; <[email protected]>
>>>> Sent: Thursday, May 25, 2006 10:46 PM
>>>> Subject: RE: [Ips] TargetAlias in SendTarget response
>>>>
>>>>
>>>> Hi David,
>>>>
>>>> It's certainly a nice idea, and I cannot remember why the
>>>> TargetAlias
>>>> was excluded from the SendTargets response. Since it would be
>>>> optional
>>>> the target can decide if there are any security issues or FUD with
>>>> sending it or not.
>>>>
>>>> The benefit is it avoids the rather clumsy sequence of doing a
>>>> (discovery) login and logout to each target found in the original
>>>> unnamed discovery session just to provoke the target into sending
>>>> the
>>>> TargetAlias as part of the login phase.
>>>>
>>>> However, it cannot just be added now without potentially breaking
>>>> some
>>>> initiators which are not expecting it, or are actively ensuring
>>>> it is
>>>> not sent.
>>>>
>>>> Perhaps a new IO,LO,Declarative key could be introduced for use
>>>> by the
>>>> initiator to indicate its willingness to accept TargetAlias as
>>>> part of
>>>> the SendTarget's response?
>>>>
>>>> Cheers
>>>> Ken
>>>>
>>>>> -----Original Message-----
>>>>> From: David Weibel [mailto:[email protected]]
>>>>> Sent: 26 May 2006 08:11
>>>>> To: [email protected]
>>>>> Subject: [Ips] TargetAlias in SendTarget response
>>>>>
>>>>>
>>>>> I was wondering what people would think about adding the
>>>>> allowed and suggested use of TargetAlias during a SendTargets
>>>>> response.  This would be an optional component of the response.
>>>>> The goal would be to send the alias earlier in the discovery
>>>>> process so the initiator software could also present it earlier
>>>>> to the user.
>>>>>
>>>>> This would require the ammendment of Appendix D. "No text
>>>>> keys other than TargetName and TargetAddress are permitted
>>>>> within a SendTargets response."  Along with some additional
>>>>> text.
>>>>>
>>>>> _______________________________________________
>>>>> Ips mailing list
>>>>> [email protected]
>>>>> https://www1.ietf.org/mailman/listinfo/ips
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ips mailing list
>>>> [email protected]
>>>> https://www1.ietf.org/mailman/listinfo/ips
>>>>
>>>>
>>>> _______________________________________________
>>>> Ips mailing list
>>>> [email protected]
>>>> https://www1.ietf.org/mailman/listinfo/ips
>>>
>>> ----
>>> Rick McNeal
>>>
>>> A good friend will come and bail you out of jail...but, a true
>>> friend will be sitting next to you saying, "Damn...that was fun! "
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ips mailing list
>>> [email protected]
>>> https://www1.ietf.org/mailman/listinfo/ips
>>
>
> ----
> Rick McNeal
>
> A good friend will come and bail you out of jail...but, a true friend
> will be sitting next to you saying, "Damn...that was fun! "
>
>
>
>
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
>
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips

----
Rick McNeal

A good friend will come and bail you out of jail ... but, a true  
friend will be sitting next to you saying, "Damn ... that was fun!"



_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips