RE: iSCSI virtualization proposal

["Douglas Otis" <dotis@sanlight.net>]

John,

Would I be wrong to assume construction of commands would be within an
encapsulation proposal?  The server providing access to the SAN is special
software and providing a definition within the encapsulation proposal is the
only means to standardize Extended Copy or third-party commands.  Some of
the justification for proxies derives from third-party commands.  In that
respect, I think this is why David combined the topic.  Should there be a
different targeting in actual use, at least this definition allows the
server a unique translation into this target space.  This function should
also remove any need for encapsulating IP of hosts as this too would be part
of any lookup process.  These two topics are very much related.  Just as
client access to devices must be secured, so would third-party commands.  As
permissions is only a small aspect of this process, should the server be
able to decide on permissions, it should also be able to decide on the
actual path as these two things go hand in hand.  This feature of providing
a transparent bridge is where the two paths cross and why they are related
and in scope.  The encapsulation definition should not impact T10.  Only
until there is a medium using this addressing would there be a concern.

Doug

> Yaron,
> Jim has a valid point that this is not iSCSI focused.  I see this as a
> Third Party Virtualization, of which a number of companies have such
> products out today.  They also have special host code to support this, as
> you will need here.   But more to the point, it is not iSCSI specific and
> therefore should be pursued with T10.  If that Standard is established,
> then and then only, we should consider it as part of iSCSI.  Lets
> keep this
> out of our discussion on Gateways, Proxies, etc. it does not fit there.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403
> Internet address: hufferd@us.ibm.com
>