iscsi : changes involving tgt portal group tag.

Julian Satran Julian_Satran at il.ibm.com
Tue Mar 5 23:56:04 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Julian Satran" <Julian_Satran at il.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 002A58C8C2256B74_=
Content-Type: text/plain; charset="us-ascii"


The issue is that I am not sure that a target is checking today anything
- (adapter drivers may check oif in their realm they can give out a
TSID).  Nothing else is needed. Does SCSI have to be aware of it?
Perhaps but iSCSI certainly not. Does a "front-end" have to be - again
probably not the name identifies the node. 

Julo 



	"Mallikarjun C." <cbm at rose.hp.com> 


05-03-02 22:34 
Please respond to "Mallikarjun C." 
        
        To:        Julian Satran/Haifa/IBM at IBMIL 
        cc:        <ips at ece.cmu.edu>, <t10 at t10.org> 
        Subject:        Re: iscsi : changes involving tgt portal group
tag. 

       



Julian,

Whatever methods a target is expected to use today to derive the
implicit
TPGT to preclude a duplicate I-T nexus would work after the change as
well,
except the derived value needs to be compared against the (proposed)
TPGT in the Login Request payload.

Please comment if we're missing something.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

----- Original Message -----
From: "Julian Satran" <Julian_Satran at il.ibm.com>
To: "Mallikarjun C." <cbm at rose.hp.com>
Cc: <ips at ece.cmu.edu>; <owner-ips at ece.cmu.edu>; "Santosh Rao"
<santoshr at cup.hp.com>;
<t10 at t10.org>
Sent: Monday, March 04, 2002 10:24 PM
Subject: Re: iscsi : changes involving tgt portal group tag.


> Has a decent target implementation and easy way of checking that the
TPG
> is correct?
>
> Julo
>
>
>
>
> "Mallikarjun C." <cbm at rose.hp.com>
> Sent by: owner-ips at ece.cmu.edu
> 05-03-02 01:12
> Please respond to "Mallikarjun C."
>
>
>         To:     "Santosh Rao" <santoshr at cup.hp.com>, <ips at ece.cmu.edu>
>         cc:     <t10 at t10.org>
>         Subject:        Re: iscsi : changes involving tgt portal group
tag.
>
>
>
> Santosh and Jim,
>
> It appears a good idea to add in the portal group tag in the Login
> Request header for a sanity check by the receiving target portal.
>
> I generally agree with Jim's comments that the duration of persistence
> of a portal group tag is intricately linked to the extent of portal
> reconfiguration.
> Not every target reconfiguration may result in a portal group tag
> reassignment.
> OTOH, some reconfigurations may be so extensive as to cause even a
node
> name change.
>
> Some comments on Santosh's message -
>
> > "If a portal group is re-configured such that all its previously
> > advertised network portals are no longer a part of the portal group,
> > then, the portal group tag (and thereby, the port name/identifier)
> > *MUST* be changed to indicate a new target port."
>
> I am not sure this solves the problem you're trying to get at.  If
none of
> the earlier IP addresses can get an initiator to the SCSI target port
that
> it
> knew of (your scenario), it appears to me that it doesn't matter if
the
> portal group tags are changed or not....A new discovery process should
> update the initiator of the changed portal addresses.
>
> I suggest the following text -
>
>    After a portal group reconfiguration which changed the view of LUs
>    for an initiator with a given set of privileges, the target MUST
change
>    the portal group tag that represents the reconfigured target portal
> group.
>
> > > Under these events, shouldn't all "open/active I_T_L traffic" have
> been
> > > aborted, closed or otherwise ended?  So this shouldn't be an issue
at
> all. 
> >
> > On a session logout & re-login, it is not efficient/necessary to
close
> > and re-open each LUN behind that target port, due to the fact that a
> > target port may have hundred's of LUNs behind it.
>
> I agree with Jim on this one - there should be *no* open/active I_T_L
> nexus
> traffic after a reconfiguration, targets can enforce this via simple
iSCSI
> means
> (reject initiator advances to continue the session for
DefaultTime2Wait+
> DefaultTime2Retain seconds).  In fact, Async logout request requires a
> clean closure that implicitly aborts I/Os.
>
> What you're describing is typical O/S "LUN open" and "LUN close"
> interactions.  I agree that they wouldn't have to be repeated, but
care
> must be taken to ensure that new I/Os (on the new session after
> reconfiguration)
> are not delivered to the incorrect LUs.  It seems that the addition of
> TPGT in the login header and the proposed new text (above) would take
> care of this.
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
> ----- Original Message -----
> From: "Santosh Rao" <santoshr at cup.hp.com>
> To: <ips at ece.cmu.edu>
> Cc: <t10 at t10.org>
> Sent: Monday, March 04, 2002 10:40 AM
> Subject: Re: iscsi : changes involving tgt portal group tag.
>
>
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Santosh Rao <santoshr at cup.hp.com>
> > *
> > Jim,
> >
> > I agree that a "complete re-configuration" of a target port can
result
> > in a new port name & port identifier. However, the tricky part is
the
> > definition of a "complete re-configuration of an iscsi target port",
due
> > to the concepts of portal groups involving multiple network portals.
> >
> > For example, if a portal group (aka, an iscsi target port) were to
be
> > re-configured to include a new network portal [moved from another
portal
> > group], then, the target port itself has not changed, since it is
still
> > accessible through its previously used network portals. What has
changed
> > is the individual network portal that has moved from 1 target port
to
> > another.
> >
> > Hence, it is sufficient, in this case, to maintain persistence of
the
> > target port name/identifier, without requiring any change in port
> > name/identifier. By requiring initiators to send the intended TPGT
(scsi
> > target port name/identifier) along with the login request, this
allows
> > the target port to detect that the network portal is being accessed
to
> > connect to a different target port and it can reject the login.
> >
> > It may be helpful to call out the specific case when a port
> > name/identifier MUST change. How about something like :
> >
> > "If a portal group is re-configured such that all its previously
> > advertised network portals are no longer a part of the portal group,
> > then, the portal group tag (and thereby, the port name/identifier)
> > *MUST* be changed to indicate a new target port."
> >
> > This would allow access to the target port through its un-altered
> > network portals to continue un-disrupted. More comments inline, in
> > response to some of your queries.
> >
> > Thanks,
> > Santosh
> >
> > NOTE : In this discussion target port and target portal group are
used
> > to imply the same entity, within a target node.
> >
> >
> > Jim Hafner wrote:
> >
> > > SAM-2 requires scsi port names to be persistent and
world-wide-unique.
> > > (SAM-2 Rev 22 Section 4.7.7). Quoting from SAM-2 :
> > >
> > > "A scsi port name shall never change and may be used to
persistently
> > > identify a scsi initiator port or target port...".
> > >
> > > <JLH>
> > > There are different ways that one can interpret this "persistent"
> rule. The
> > > intent was that names shouldn't change over time when *identifying
the
> same
> > > object*.   What that means is that if the object changes (in any
> > > discernable way), then the name should change.  So, the object can
> move to
> > > a different piece of hardware, but it can still be named the same
way.
>  If
> > > the object changes, e.g., in this case, reconfigures as a
different
> set of
> > > network portals with different addressing elements, then I would
think
> that
> > > the name should change as well.   That's all the persistence one
> really
> > > needs.
> > >
> > > I'm not sure what that implies about your recommendation.  I don't
see
> any
> > > problem with it, either.
> > > </JLH>
> >
> > I think we may be in agreement. (See reasoning above).
> >
> >
> > >
> > > The rationale for (2) is :
> > > --------------------------
> > > Consider an initiator node establishing multiple sessions to a
scsi
> tgt
> > > port, with each session established to a subset of the network
portals
> > > within the tgt portal group.
> > >
> > > Consider an iscsi transport event involving the re-configuration
of
> > > target portal groups on the iscsi target node. This may be
preceeded
> by
> > > the iscsi sessions seeing an async message "target requests
logout",
> > > followed by session logout, portal group re-configuration, and
then,
> the
> > > initiator re-establishes sessions.
> > >
> > > Across a transport event that results in such session termination
and
> > > re-establishment, the initiator needs to authenticate that it is
still
> > > speaking to the same [i]scsi target port, in order to ensure that
any
> > > open/active I-T-L nexus traffic on that session is not incorrectly
> > > routed to a wrong LUN after such a transport event.
> >
> > > <JLH>
> > > Under these events, shouldn't all "open/active I_T_L traffic" have
> been
> > > aborted, closed or otherwise ended?  So this shouldn't be an issue
at
> all.
> >
> > On a session logout & re-login, it is not efficient/necessary to
close
> > and re-open each LUN behind that target port, due to the fact that a
> > target port may have hundred's of LUNs behind it.
> >
> > All outstanding I/Os need to be aborted. Once the session is
> > re-established [and the target port is authenticated to be the
same],
> > further I/O traffic can be resumed without requiring the SCSI ULP to
> > close and re-open each LUN. Some transport specific clearing effects
may
> > have occurred, which may require additional LUN level activity, in
some
> > cases.
> >
> > (There are analogies to the above model in FCP & SRP, which
authenticate
> > port name/identifier on login, allowing I/O resumption after session
> > termination and re-establishment.)
> >
> >
> > > To prevent such authentication issues, iscsi can send the iscsi
target
> > > port identifier (portal group tag) explicitly in the login
request,
> and
> > > the login can be rejected by the target on a portal group tag
> mis-match.
> > > (if the network portal does not belong to the addressed portal
group
> > > tag).
> > > <JLH>
> > > Did you mean for the initiator to send this TPGT?
> > > </JLH>
> >
> > Yes. The initiator login request must include the target portal
group
> > tag, thus identifying the target port to which a session is being
> > established.
> >
> > Login currently carries no addressing information, since the
addressing
> > is implicit, based on the TCP connection in use. The problem with
this
> > approach is that the login implicitly addresses a network portal,
and
> > not the target port. As seen in the earlier example, the association
of
> > network portal <-> target port can change, and such changes can be
> > detected, if the initiator were to explicitly identify the target
port
> > being logged into.
> >
> > --
> > ##################################
> > Santosh Rao
> > Software Design Engineer,
> > HP-UX iSCSI Driver Team,
> > Hewlett Packard, Cupertino.
> > email : santoshr at cup.hp.com
> > Phone : 408-447-3751
> > ##################################
> > *
> > * For T10 Reflector information, send a message with
> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> >
>
>
>





--=_alternative 002A58C8C2256B74_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">The issue is that I am not sure that a target is checking today anything - (adapter drivers may check oif in their realm they can give out a TSID). &nbsp;Nothing else is needed. Does SCSI have to be aware of it? Perhaps but iSCSI certainly not. Does a "front-end" have to be - again probably not the name identifies the node.</font>
<br>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Mallikarjun C." <cbm at rose.hp.com&gt;</b></font>
<p><font size=1 face="sans-serif">05-03-02 22:34</font>
<br><font size=1 face="sans-serif">Please respond to "Mallikarjun C."</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Julian Satran/Haifa/IBM at IBMIL</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;<ips at ece.cmu.edu&gt;, <t10 at t10.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iscsi : changes involving tgt portal group tag.</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">Julian,<br>
<br>
Whatever methods a target is expected to use today to derive the implicit<br>
TPGT to preclude a duplicate I-T nexus would work after the change as well,<br>
except the derived value needs to be compared against the (proposed)<br>
TPGT in the Login Request payload.<br>
<br>
Please comment if we're missing something.<br>
<br>
Regards.<br>
--<br>
Mallikarjun<br>
<br>
Mallikarjun Chadalapaka<br>
Networked Storage Architecture<br>
Network Storage Solutions Organization<br>
Hewlett-Packard MS 5668<br>
Roseville CA 95747<br>
<br>
----- Original Message -----<br>
From: "Julian Satran" <Julian_Satran at il.ibm.com&gt;<br>
To: "Mallikarjun C." <cbm at rose.hp.com&gt;<br>
Cc: <ips at ece.cmu.edu&gt;; <owner-ips at ece.cmu.edu&gt;; "Santosh Rao" <santoshr at cup.hp.com&gt;;<br>
<t10 at t10.org&gt;<br>
Sent: Monday, March 04, 2002 10:24 PM<br>
Subject: Re: iscsi : changes involving tgt portal group tag.<br>
<br>
<br>
> Has a decent target implementation and easy way of checking that the TPG<br>
> is correct?<br>
><br>
> Julo<br>
><br>
><br>
><br>
><br>
> "Mallikarjun C." <cbm at rose.hp.com&gt;<br>
> Sent by: owner-ips at ece.cmu.edu<br>
> 05-03-02 01:12<br>
> Please respond to "Mallikarjun C."<br>
><br>
><br>
> &nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; "Santosh Rao" <santoshr at cup.hp.com&gt;, <ips at ece.cmu.edu&gt;<br>
> &nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; <t10 at t10.org&gt;<br>
> &nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iscsi : changes involving tgt portal group tag.<br>
><br>
><br>
><br>
> Santosh and Jim,<br>
><br>
> It appears a good idea to add in the portal group tag in the Login<br>
> Request header for a sanity check by the receiving target portal.<br>
><br>
> I generally agree with Jim's comments that the duration of persistence<br>
> of a portal group tag is intricately linked to the extent of portal<br>
> reconfiguration.<br>
> Not every target reconfiguration may result in a portal group tag<br>
> reassignment.<br>
> OTOH, some reconfigurations may be so extensive as to cause even a node<br>
> name change.<br>
><br>
> Some comments on Santosh's message -<br>
><br>
> > "If a portal group is re-configured such that all its previously<br>
> > advertised network portals are no longer a part of the portal group,<br>
> > then, the portal group tag (and thereby, the port name/identifier)<br>
> > *MUST* be changed to indicate a new target port."<br>
><br>
> I am not sure this solves the problem you're trying to get at. &nbsp;If none of<br>
> the earlier IP addresses can get an initiator to the SCSI target port that<br>
> it<br>
> knew of (your scenario), it appears to me that it doesn't matter if the<br>
> portal group tags are changed or not....A new discovery process should<br>
> update the initiator of the changed portal addresses.<br>
><br>
> I suggest the following text -<br>
><br>
> &nbsp; &nbsp;After a portal group reconfiguration which changed the view of LUs<br>
> &nbsp; &nbsp;for an initiator with a given set of privileges, the target MUST change<br>
> &nbsp; &nbsp;the portal group tag that represents the reconfigured target portal<br>
> group.<br>
><br>
> > > Under these events, shouldn't all "open/active I_T_L traffic" have<br>
> been<br>
> > > aborted, closed or otherwise ended? &nbsp;So this shouldn't be an issue at<br>
> all.</font>
<br><font size=2 face="Courier New">> ><br>
> > On a session logout &amp; re-login, it is not efficient/necessary to close<br>
> > and re-open each LUN behind that target port, due to the fact that a<br>
> > target port may have hundred's of LUNs behind it.<br>
><br>
> I agree with Jim on this one - there should be *no* open/active I_T_L<br>
> nexus<br>
> traffic after a reconfiguration, targets can enforce this via simple iSCSI<br>
> means<br>
> (reject initiator advances to continue the session for DefaultTime2Wait+<br>
> DefaultTime2Retain seconds). &nbsp;In fact, Async logout request requires a<br>
> clean closure that implicitly aborts I/Os.<br>
><br>
> What you're describing is typical O/S "LUN open" and "LUN close"<br>
> interactions. &nbsp;I agree that they wouldn't have to be repeated, but care<br>
> must be taken to ensure that new I/Os (on the new session after<br>
> reconfiguration)<br>
> are not delivered to the incorrect LUs. &nbsp;It seems that the addition of<br>
> TPGT in the login header and the proposed new text (above) would take<br>
> care of this.<br>
><br>
> Regards.<br>
> --<br>
> Mallikarjun<br>
><br>
> Mallikarjun Chadalapaka<br>
> Networked Storage Architecture<br>
> Network Storage Solutions Organization<br>
> Hewlett-Packard MS 5668<br>
> Roseville CA 95747<br>
><br>
> ----- Original Message -----<br>
> From: "Santosh Rao" <santoshr at cup.hp.com&gt;<br>
> To: <ips at ece.cmu.edu&gt;<br>
> Cc: <t10 at t10.org&gt;<br>
> Sent: Monday, March 04, 2002 10:40 AM<br>
> Subject: Re: iscsi : changes involving tgt portal group tag.<br>
><br>
><br>
> > * From the T10 Reflector (t10 at t10.org), posted by:<br>
> > * Santosh Rao <santoshr at cup.hp.com&gt;<br>
> > *<br>
> > Jim,<br>
> ><br>
> > I agree that a "complete re-configuration" of a target port can result<br>
> > in a new port name &amp; port identifier. However, the tricky part is the<br>
> > definition of a "complete re-configuration of an iscsi target port", due<br>
> > to the concepts of portal groups involving multiple network portals.<br>
> ><br>
> > For example, if a portal group (aka, an iscsi target port) were to be<br>
> > re-configured to include a new network portal [moved from another portal<br>
> > group], then, the target port itself has not changed, since it is still<br>
> > accessible through its previously used network portals. What has changed<br>
> > is the individual network portal that has moved from 1 target port to<br>
> > another.<br>
> ><br>
> > Hence, it is sufficient, in this case, to maintain persistence of the<br>
> > target port name/identifier, without requiring any change in port<br>
> > name/identifier. By requiring initiators to send the intended TPGT (scsi<br>
> > target port name/identifier) along with the login request, this allows<br>
> > the target port to detect that the network portal is being accessed to<br>
> > connect to a different target port and it can reject the login.<br>
> ><br>
> > It may be helpful to call out the specific case when a port<br>
> > name/identifier MUST change. How about something like :<br>
> ><br>
> > "If a portal group is re-configured such that all its previously<br>
> > advertised network portals are no longer a part of the portal group,<br>
> > then, the portal group tag (and thereby, the port name/identifier)<br>
> > *MUST* be changed to indicate a new target port."<br>
> ><br>
> > This would allow access to the target port through its un-altered<br>
> > network portals to continue un-disrupted. More comments inline, in<br>
> > response to some of your queries.<br>
> ><br>
> > Thanks,<br>
> > Santosh<br>
> ><br>
> > NOTE : In this discussion target port and target portal group are used<br>
> > to imply the same entity, within a target node.<br>
> ><br>
> ><br>
> > Jim Hafner wrote:<br>
> ><br>
> > > SAM-2 requires scsi port names to be persistent and world-wide-unique.<br>
> > > (SAM-2 Rev 22 Section 4.7.7). Quoting from SAM-2 :<br>
> > ><br>
> > > "A scsi port name shall never change and may be used to persistently<br>
> > > identify a scsi initiator port or target port...".<br>
> > ><br>
> > > <JLH><br>
> > > There are different ways that one can interpret this "persistent"<br>
> rule. The<br>
> > > intent was that names shouldn't change over time when *identifying the<br>
> same<br>
> > > object*. &nbsp; What that means is that if the object changes (in any<br>
> > > discernable way), then the name should change. &nbsp;So, the object can<br>
> move to<br>
> > > a different piece of hardware, but it can still be named the same way.<br>
> &nbsp;If<br>
> > > the object changes, e.g., in this case, reconfigures as a different<br>
> set of<br>
> > > network portals with different addressing elements, then I would think<br>
> that<br>
> > > the name should change as well. &nbsp; That's all the persistence one<br>
> really<br>
> > > needs.<br>
> > ><br>
> > > I'm not sure what that implies about your recommendation. &nbsp;I don't see<br>
> any<br>
> > > problem with it, either.<br>
> > > </JLH><br>
> ><br>
> > I think we may be in agreement. (See reasoning above).<br>
> ><br>
> ><br>
> > ><br>
> > > The rationale for (2) is :<br>
> > > --------------------------<br>
> > > Consider an initiator node establishing multiple sessions to a scsi<br>
> tgt<br>
> > > port, with each session established to a subset of the network portals<br>
> > > within the tgt portal group.<br>
> > ><br>
> > > Consider an iscsi transport event involving the re-configuration of<br>
> > > target portal groups on the iscsi target node. This may be preceeded<br>
> by<br>
> > > the iscsi sessions seeing an async message "target requests logout",<br>
> > > followed by session logout, portal group re-configuration, and then,<br>
> the<br>
> > > initiator re-establishes sessions.<br>
> > ><br>
> > > Across a transport event that results in such session termination and<br>
> > > re-establishment, the initiator needs to authenticate that it is still<br>
> > > speaking to the same [i]scsi target port, in order to ensure that any<br>
> > > open/active I-T-L nexus traffic on that session is not incorrectly<br>
> > > routed to a wrong LUN after such a transport event.<br>
> ><br>
> > > <JLH><br>
> > > Under these events, shouldn't all "open/active I_T_L traffic" have<br>
> been<br>
> > > aborted, closed or otherwise ended? &nbsp;So this shouldn't be an issue at<br>
> all.<br>
> ><br>
> > On a session logout &amp; re-login, it is not efficient/necessary to close<br>
> > and re-open each LUN behind that target port, due to the fact that a<br>
> > target port may have hundred's of LUNs behind it.<br>
> ><br>
> > All outstanding I/Os need to be aborted. Once the session is<br>
> > re-established [and the target port is authenticated to be the same],<br>
> > further I/O traffic can be resumed without requiring the SCSI ULP to<br>
> > close and re-open each LUN. Some transport specific clearing effects may<br>
> > have occurred, which may require additional LUN level activity, in some<br>
> > cases.<br>
> ><br>
> > (There are analogies to the above model in FCP &amp; SRP, which authenticate<br>
> > port name/identifier on login, allowing I/O resumption after session<br>
> > termination and re-establishment.)<br>
> ><br>
> ><br>
> > > To prevent such authentication issues, iscsi can send the iscsi target<br>
> > > port identifier (portal group tag) explicitly in the login request,<br>
> and<br>
> > > the login can be rejected by the target on a portal group tag<br>
> mis-match.<br>
> > > (if the network portal does not belong to the addressed portal group<br>
> > > tag).<br>
> > > <JLH><br>
> > > Did you mean for the initiator to send this TPGT?<br>
> > > </JLH><br>
> ><br>
> > Yes. The initiator login request must include the target portal group<br>
> > tag, thus identifying the target port to which a session is being<br>
> > established.<br>
> ><br>
> > Login currently carries no addressing information, since the addressing<br>
> > is implicit, based on the TCP connection in use. The problem with this<br>
> > approach is that the login implicitly addresses a network portal, and<br>
> > not the target port. As seen in the earlier example, the association of<br>
> > network portal <-> target port can change, and such changes can be<br>
> > detected, if the initiator were to explicitly identify the target port<br>
> > being logged into.<br>
> ><br>
> > --<br>
> > ##################################<br>
> > Santosh Rao<br>
> > Software Design Engineer,<br>
> > HP-UX iSCSI Driver Team,<br>
> > Hewlett Packard, Cupertino.<br>
> > email : santoshr at cup.hp.com<br>
> > Phone : 408-447-3751<br>
> > ##################################<br>
> > *<br>
> > * For T10 Reflector information, send a message with<br>
> > * 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
> ><br>
><br>
><br>
><br>
<br>
</font>
<br>
<br>
--=_alternative 002A58C8C2256B74_=--




More information about the T10 mailing list