Subject: [iSCSI][Q+RFC] login response, tsid

From: Luben Tuikov <[email-masked]>
Date: Sat, 16 Feb 2002 00:17:39 -0500

From an implementation point of view:

1. TSID is implicitly defined to be an unsigned 16-bit integer.

TSID is only mentioned to be a ``tag'', ``null'', ``0'',
``1'', ``2'', ``entity'' and ``component''.

[NDT] defines ISID, but not TSID.

There need to be a definition of what kind of object TSID
is. _That_ will define the operations which can be performed
on it, not the other way around.

iSCSIv10, 9.1.2 talks only about TSID namespace segregation,
while a TSID object's definition is implicit.

A word on TSID generation MAY be mentioned as well.

2. Login response PDU, status-class, status-detail.

Wouldn't it be better to use one 16-bit unsigned integer
for this information, call it ``status''

Then this ``status'' can be _logically_ split into 
``class'' (8 MSb) and ``detail'' (8 LSb).

But an implementation (HBA, software, etc) will use
it as a 16-bit unsigned integer.

Comments?

-- 
Luben

---

From: "Robert D. Russell" <[email-masked]>
Date: Sat, 16 Feb 2002 12:00:46 -0500 (EST)

> it as a 16-bit unsigned integer.

I see no reason to combine the status class and status detail
fields into 1 field if the implementation just has to split
them apart again.  What benefit is there to combining them?
I vote against this idea.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Luben Tuikov <[email-masked]>
Date: Sun, 17 Feb 2002 23:47:04 -0500

> I vote against this idea.

The reason was that an implementation can manipulate it easier
and as the table on the next page shows it is one field.
It can be fetched off the packet in just one operation
and then if an interpretation is needed it can then
be split __logically__ by whoever needs to know it.

The table next page in the draft (pp. 151-152, v10) does seem
to represent it as _one_ 16 bit number with suitable
description and status.

I.e. the separation is only logical and for all practical
purposes IT IS one field as the table clearly shows.

P.S. My suggestion is exactly what happened to the 
ISID field (pp. 145, 147, v10).

-- 
Luben