[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

RE: TargetAlias in SendTarget response



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:Rick.McNeal@Sun.COM] 
Sent: Wednesday, May 31, 2006 8:18 AM
To: Eddy Quicksall
Cc: ips@ietf.org; David Weibel; Sandars,Ken
Subject: Re:  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" <Rick.McNeal@Sun.COM>
> To: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>
> Cc: <ips@ietf.org>; "David Weibel" <David.Weibel@Sun.COM>;  
> "Sandars,Ken" <ken_sandars@adaptec.com>
> Sent: Wednesday, May 31, 2006 8:40 AM
> Subject: Re:  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"  
>>> <ken_sandars@adaptec.com>
>>> To: "David Weibel" <David.Weibel@Sun.COM>; <ips@ietf.org>
>>> Sent: Thursday, May 25, 2006 10:46 PM
>>> Subject: RE:  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:David.Weibel@Sun.COM]
>>>> Sent: 26 May 2006 08:11
>>>> To: ips@ietf.org
>>>> Subject:  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
>>>> Ips@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ips
>>>>
>>>
>>> _______________________________________________
>>> Ips mailing list
>>> Ips@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ips
>>>
>>>
>>> _______________________________________________
>>> Ips mailing list
>>> Ips@ietf.org
>>> 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
>> Ips@ietf.org
>> 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
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux