[T11.3] ADI: Which way port control?
Paul.A.Suhler at seagate.com
Paul.A.Suhler at seagate.com
Fri Aug 2 09:16:13 PDT 2002
INCITS T11.3 Mail Reflector
Bob Snively and I spoke this morning. Here's his input on port control.
The best solution is probably to prohibit modification of WWNs (and
probably hard assigned loop identifiers) via the primary interface. The
only difficulty this might pose would be in libraries which communicate
with the drive only over the primary interface, rather than over a
dedicated (ADP) port. The working group will have to look at this
carefully, but it's probably a Really Bad Idea for WWNs to be changed in
such a configuration.
We'll also have to consider malicious attempts to change these sorts of
operating parameters, especially if the ADC commands are delivered via
Thanks for the comments, Bob.
----- Forwarded by Paul A Suhler/Seagate on 08/02/2002 09:03 AM -----
Snively To: "'Paul.A.Suhler at seagate.com'" <Paul.A.Suhler at seagate.com>, Brian
<rsnively at bro Forbes <bforbes at brocade.com>
cade.com> cc: Robert Snively <rsnively at brocade.com>
Subject: RE: Which way port control?
I have a mildly strong prejudice against a host being
able to modify hard assigned loop identifier. If hard identifiers
are assigned, they should be assigned by the library only,
using administrative information keyed directly into the library
to provide the base address for the loop identifiers.
I have a very strong prejudice against a host being able
to modify a node or port name. This is a major security
issue and should be avoided at all costs. Again, there is
no problem with the library being able to establish
node and port names using its own base WWN as the kernel
for creating those names as world-wide, unique, and
bound to the library.
My feelings about port control parameters fall somewhere
between those two levels of prejudice. Some of those fall
under the SES command set. Others have problems of disabling
and enabling the same port that is carrying the commands.
As we discussed in our short phone call, the real problem is
not that such commands can be carried from a library control
processor to the components of the library. The real
problem is if devices outside the library on the fabric have
the capability of executing the same commands. The
obvious solution is the absolute prohibition against allowing
devices outside the library to mess with any of these
parameters through any command set.
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Paul.A.Suhler at seagate.com
> The members of the T10 Automation Drive Interface (ADI)
> working group would
> like a bit of feedback from the T10 / T11 community on the best way to
> implement some new features.
> The group is standardizing the interface for libraries to control the
> removable medium devices (usually tape drives) installed in them. One
> scenario is that the drives will power up with their primary interface
> port(s) -- e.g., Parallel SCSI or Fibre Channel -- disabled until the
> library has configured the drive. Typically the library will set the
> (Parallel SCSI) ID or the (Fibre Channel) hard assigned loop
> node name, and port names. Finally, the port is enabled.
> The main question is whether this should be done by:
> Extensions to the existing Fibre Channel Port Control mode
> page (19h) --
> and a new Protocol Specific Port mode page (19h) for Parallel SCSI.
> An entirely new mode page, possibly a subpage within the
> Extended mode
> page (15h)?
> If you want to see the details of a couple of proposed solutions, then
> please see Section 3 of
> which should be available shortly. Don't bother with Rev. 0.
> Paul Suhler
> ADI Working Group Facilitator
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
mailto:t11_3-request at mail.t11.org?subject=unsubscribe
More information about the T10