SPC-4: Security Protocol In Supported Protocols

Ralph Weber roweber at IEEE.org
Tue Mar 28 16:58:57 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Kevin,
I recall CAP asking Gerry to move the length field in Table 175
so as to guarantee sufficient reserved bytes for reporting anything
future proposals might find 'interesting' in a general report
function.
Chaos erupted over the Certificates part of Gerry's proposal
(can you tell I am still in ENDL Letter mode?) so it is unclear
whether Gerry asked about moving the length field or not.
Regardless, a followup proposal is need to cement the Certificates
in SPC-4 and anyone who remembers the issue can adjust the
length location as part of processing that proposal.
As for the Tape Data Encryption proposal, that is a totally
different Security Protocol. I strongly doubt that the TCG
is going to take CAP's advice about the data formats for
their Security Protocols. Therefore, I see no reason why
SSC-3 need feel obliged to do anything other than whatever
amuses them.
Put the length field at the end of the data if you want.
Some will call you foolish, but you all have Security
Protocol 20h as your very own sandbox. Just don't come
calling for a new Security Protocol code assignment
because the old one proved unworkable.
All the best,
.Ralph
Kevin D Butt wrote:
>
> Ralph, Gerry, and all,
>
> In SPC-4 rev 4 in looking at the SECURITY PROTOCOL IN command, I have 
> found that there is an inconsistency between where the length field is 
> placed in both listed IN pages.
> In Table 175 — Supported security protocols SECURITY PROTOCOL IN 
> parameter data, the length field is in bytes 6 & 7, but in Table 176 — 
> Supported security protocols SECURITY PROTOCOL IN parameter data the 
> length field is in bytes 2 & 3. Likewise in the proposed Tape Data 
> Encryption security protocol the length is also in bytes 2 & 3.
>
> Having the length field in different bytes makes it very difficult for 
> parsing. In this case it requires that you know a priori what data is 
> coming back. The parser must be CDB aware and also must know about the 
> specific security protocols in order to parse. This seems like a very 
> bad design to me. Can we modify the location of the length bytes in 
> Table 175 — Supported security protocols SECURITY PROTOCOL IN 
> parameter data, to be in bytes 2 & 3 and not in bytes 6 & 7?
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/ 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list