Docs for CAP in Sept. (00-287r1)

hafner at hafner at
Tue Aug 15 16:41:41 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* hafner at


There isn't a TransportID for SBP-2 because I wasn't aware of that protocol
(my error, for sure).  I'd only heard about SPI and FCP as established
protocols and SST and SVP (and iSCSI) as emerging.  I was hoping and
expecting that the players in these areas help out to define the
TransportID for those protocols.   I know nothing at all about SBP; do you
have a suggestion on how to do a TransportID for SBP?  I'd welcome a
suggestion and a proposal to that effect.

iSCSI: More generally, how are IETF and T10 going to deal with "mixed"
issues (and not just AccessControls but also third party naming
conventions, etc as needed by extended copy and the like)?   I don't have
any experience in this area and am leaving that up to the more experienced.
My suggestion for TransportIDs and iSCSI is one of:
1)  IETF propose to T10 that SPC-3 spec the Byte0 of the TransportID for
iSCSI and leave the rest of the specification to iSCSI doc, OR
2) IETF propose to T10 that SPC-3 spec the complete TransportID for iSCSI.
I don't think anybody in T10 (including me) would strongly object to either
of these.

AccessID length:  Note that this length is 16 bytes (128 bits) so has lots
of room for almost anything.  On the other hand, spec'ing them in terms of
OUIs is entirely up to the managing application that passes them out. The
access controls SPC-3 spec is silent on how names get generated, it only
specifies how they get used.

You might have confused the AccessID with the first byte of the TransportID
(they are completely independent).  The first byte of the TransportID is
there is specify the protocol of that identifier (so the structure is
self-descriptive).  AccessIDs are an alternative naming convention for
(sets of initiators) and is independent of the transport protocol.

Did I answer you're questions?

Jim Hafner

Peter Johansson <PJohansson at> on 08-15-2000 02:15:23 PM

To:   Jim Hafner/Almaden/IBM at IBMUS
cc:   t10 at
Subject:  Re: Docs for CAP in Sept. (00-287r1)

At 01:33 PM 8/15/00, hafner at wrote:

>1) The TransportID uses Byte0 to identify the transport (00h=SPI, 01h=FCP)

Jim, I think the document ought to define values for all SAM-compatible
transports that have been specified by T10.

For example, how about some value for SBP-2?

In the same vein, how is the continued registry of this field to be
handled? If the IETF, under the work program of the IP Storage group (aka
iSCSI) develops a SAM-compatible transport, how are they to obtain an
Access ID value?

Last suggestion---and I admit it might betray the fact that I haven't been
following this closely. Is the length of Access ID, one byte, cast in
concrete? If not what about 48-bits of Access ID, split into a 24-bit OUI
obtained from the IEEE (T10 already owns one such number) followed by a
24-bit version whose definition is left to the owner of the OUI. This could
get you out of the numbers registration business...

Even if my last suggestion gains no supporters, I think you need to address
the first two concerns.


Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list