Subject: RE: profiles - a way to simplify iSCSI

From: [email-masked]
Date: Sat, 23 Jun 2001 07:09:02 +0300

Somesh,

You are still missing my point. Profiles are not proposed "in addition" to
what we have but instead of.
They are not meant to remove features that where introduced for a
legitimate reason or another but rather to limit
the variability in implementations and testing.

Julo

"Somesh Gupta" <[email-masked]> on 22-06-2001 21:16:33

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: profiles - a way to simplify iSCSI

Julian,

I think a number of our colleagues are speaking about the
complexity of the spec as it stands today and the need
to reduce the complexity.

As I said, if a reasonable profile gets agreed upon (I apologise
in advance but I have not seen the ability to say no to feature
creep here), then that will become the de-facto standard. And
everything else will be an appendage.

We might as well do that to start with.

It is much better to do that, and as Steph suggested, add
features that are required in a newer rev of the spec. It is
not as if standards don't evolve.

John Vrabel's message indicates a very good starting point
for pruning the spec (I disagree on the asynch messages).

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, June 22, 2001 8:15 AM
> To: [email-masked]
> Subject: RE: profiles - a way to simplify iSCSI
>
>
>
>
> Robert,
>
> Profiles are meant INSTEAD -OF not in addition to the current set of
> features.
> I appreciate your concerns but I think that I must have misstated the
> profile intention.
> A profile will be an exact mapping of a set of functions we have today.
> As such it will be SIMPLER both to implement and test.
>
> Julo
>
> "Robert Griswold" <[email-masked]> on 22-06-2001 17:19:47
>
> Please respond to "Robert Griswold" <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> Subject:  RE: profiles - a way to simplify iSCSI
>
>
>
>
> Julian:
>
> Well, drawing on my experience from the consumer storage specs
> (ATA/ATAPI/MMC), profiles and features lead to huge interoperability
> problems.  The issue for robust (full featured) targets and initiators
> is they have to chase down every single interpretation of feature sets,
> some that they don't even care about, so the devices are not caught in
> transport or command sequences they have no idea about.  I am in
> agreement with David Black and others who have specified that the iSCSI
> transport needs simplicity rather than complexity; I fear that providing
> still more optional implementations would lead to more problems.  If we
> believe the hype from the press, then iSCSI will make for cheap targets,
> which means fast product schedules and low engineering and test coverage
> from companies that could ship millions of little iSCSI boxes.  A
> tighter iSCSI specification might help keep some of these potential
> interoperability problems from becoming wildfires.
>
> Bob
>
> Robert Griswold
> Technologist
> Crossroads Systems, Inc.
> 512-928-7272
>
>  -----Original Message-----
> From:     [email-masked] [mailto:[email-masked]]
> Sent:     Thursday, June 21, 2001 12:15 PM
> To:  [email-masked]
> Subject:  profiles - a way to simplify iSCSI
>
>
>
> Dear colleagues,
>
> iSCSI keeps getting richer in negotiable parameters/features.
> Although flexibility is a great thing every new negotiable
> parameter/feature get us all worrying about:
>
>    what it will break when used in combination with other
>    parameters/features
>    how are we going to test that all our combinations work as we think
> that
>    they are specified
>    are we understanding/specifying the combinations the same way as
> anybody
>    else
>
>
> I assume that many of you are wondering, as I do, if all this
> flexibility
> is really worth it's price.
> Would the community not be better served by specifying profiles that are
> a
> complete-and-invariable combination of features and very small set of
> numerical parameters?
>
> I would start with 2 profiles:
>
>    the minimal profile (only basic features)
>    the maximum profile (all the features)
>
> and then (only if we are strongly convinced it is needed) add a middle
> point.
>
> Please comment,
> Julo
>
>
>
>
>
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "Somesh Gupta" <[email-masked]>
Date: Sat, 23 Jun 2001 11:30:09 -0700

I think we are just talking past each other so we
should just let it rest. I understand what you
are saying, and I still contend that if a reasonable
profile that does not include all the features gets
agreed upon, then the de-facto acceptance of that
profile will make the features not included in the
profile useless.

We might as well try to take those things out of
the first rev of the spec.

> Sent: Friday, June 22, 2001 9:09 PM
> To: [email-masked]

---

From: "Michael J. S. Smith (PacBell)" <[email-masked]>
Date: Sat, 23 Jun 2001 16:20:22 -0700

I took the liberty of converting the PDF of the Bakke/Burbridge/Congdon
iSCSI table to text using http://access.adobe.com/access_email.html, since I
thought it useful to have this information archived.

Here is the key to the columns again (from Mark's email):

1st column - Section number of an internet-draft version
of this spreadsheet, which we will generate if needed.

2nd column - Category; we divided up the different features
into some categories that made sense to us.  The first set
is common to all iSCSI implementations; the second and third
are for those features that apply just to targets or initiators.

3rd column - Feature; short description of each feature.

4th column - Reference; a reference to the section number of the
iSCSI document that best describes the feature and its status.

5th column - Status.

   M = Mandatory
   O = Optional
   R = Recommended (we have none of these now)
   X = Prohibited (we have none of these, either)

   If numbers appear after the status, e.g. M:4.5, it means that
   the feature is mandatory if the feature numbered 4.5 is
   implemented.  I just noticed that some of our numbers had changed,
   so a few of these might still be typos.

6th column - Value.  This is used if the feature is more than just
a check box; for instance, if an implementation supports "Data Digest -
Other",
it is used to indicate some reference to what "other" means.

I reproduce the conversion result below, exactly as I received it (so there
are some page numbers included, for example). The text is quite readable and
allowed me to easily see the sections marked optional and mandatory. I post
this hoping others find it as useful as I do.

Aloha

Mike Smith

 *Pages 1--16 from  þÿ*
Authors: Mark Bakke, Matthew Burbridge, Paul Congdon
4 iSCSI Common Features
Feature Reference Status Value

4.1
Access Control and
Authorization

4.1.1
Support access control by iSCSI
Initiator Name O

4.1.2
Supports access control by iSCSI
Target Name O
4.2 iSCSI Data Integrity

4.2.1
Support Some Header Digest
Scheme 8.1.3 M
4.2.2 Support Header Digest -None A. 01 M
4.2.3 Support Header Digest -CRC-32C A. 01 M
4.2.4 Support Header Digest -Other A. 01 O other method

4.2.5 Support Some Data Digest Scheme 8.1.3 M
4.2.6 Support Data Digest -None A. 01 M
4.2.7 Support Data Digest -CRC-32C A. 01 M
4.2.8 Support Data Digest -Other A. 01 O other method
4.3 PDU Formats
4.3.1 Support Additional Header Segment 2.2.3 O
4.3.2 Support Extended CDB 2.2.4 O
4.3.3 Support Bi-Directional Data Transfer 2.2.4 O

4.3.4
Set all undefined and reserved bits to
zero 2 M

4.3.5
Set P/ F bit to 0 on PDUs where it is
not used 2.2.2.4 M
4.3.6 Uses LUN field for other purpose 2.2.2.7 O purpose
4.3.7 Task tags are unique over session 2.2.2.8 M

4.4 Data Transfer Mechanism
4.4.1 Support Unsolicited Data 1.2.5 O
4.4.2 Support Immediate Data 1.2.5 O
1
4.4.3 Support Bi-directional data 2.3.5,2.7.7 O
4.4.4
Support piggybacking of status in
Final Data PDU 2.7.7 O

4.4.6 Ready to Transfer (Data Flow) 2.17 M
4.4.7 Deliver commands in CmdSN order 1.2.2.1 M
4.4.8 Support DataSN 1.2.2.3 M

4.4.9
Support Response Numbering
(StatSN) 1.2.2.2 M

4.4.10
Use same StatSN on retried
responses as original PDU 2.4.8 M

4.4.11
Non-immediate commands always
use CmdSN values between
ExpCmdSN and MaxCmdSN 1.2.2.1 M

4.4.12 (target)
Silently ignors commands outside
CmdSN range or duplicates within
range that don't have X-bit set 1.2.2.1 M

4.4.13 (target)
Never issues more than 2^ 32-1 R2Ts
for any given write command 1.2.2.3 M

4.4.14
Set F-bit= 1 when Expected Data
Transfer Length and length of
immediate data are the same 2.3.5 M

4.4.15 (target) Support and enable autosense 2.4.5 M

4.4.16
When target transfer tag is provided,
LUN field is valid and same as
original command 2.7.2 M

4.4.17 Only include StatSN when S-bit= 1 2.7.2 M

4.4.18 (target)
Returns data in increasing buffer
offset order when EMDP mode is
selected 2.7.5 M
2
4.4.19 (initiator)
Delivers all data within a burst in
increasing buffer offset order 2.7.5 M

4.4.20 (target)
Upon successful completion, returns
status in last SCSI Data Packet 2.7.7 O

4.4.21 (target)
If command completes with an error,
response and status is sent is SCSI
Response PDU 2.7.7 M

4.4.22 (target)
Requests chunks of data from
initiator using R2T in any order 2.17.3 O
4.5 Sync & Steering
4.5.1 Support Sync & Steering 1.2.8 O

4.5.2
Retain buffer offsets and end
addresses of each iSCSI PDU 1.2.8.2 M: 4.6

4.5.3
Include steering information in PDU
independent of other layers 1.2.8.2 M: 4.6

4.5.4
Map outgoing stream addresses to
TCP stream sequence numbers 1.2.8.2 M: 4.6

4.5.5
Restricts certain transformations by
Upper Functional Layers 1.2.8.3 O

4.5.6
Use Marker Protocol for Sync and
Steering D. 00 O

4.5.7
Markers indicate the offset to a 4-
byte word boundary D. 06 M: 4.5.6
4.6 MIB Support
4.6.1 Support iSCSI MIB MIB M

4.7
Lower Layer Protocol Features
[e. g. IPSec, Keep Alive, Data
Integrity]

4.7.1
Use TCP keep-alive option to enable
early link failure detection 6.5 O

4.7.2
Support graceful connection
shutdown by sending TCP FINs once
there are no outstanding tasks with
allegiance to the connection 1.2.6 M
3
4.7.3
Respond to TCP FINs by closing
target half of connection after
concluding all outstanding
commands and sending status 1.2.6 O
4.7.4 Use IPSec for Data Integrity O

4.8
Discovery [e. g. Send Targets
support, SLP, etc]

4.8.1
Supports/ Uses SendTargets
command O
4.8.2 Supports/ Uses SLP O

4.8.3 Supports other discovery mechanism O other mechanism
4.8.4
Sends/ Uses async messages for
new targets O

4.8.5
Sends/ Uses async messages for
new LUNs O

4.9
Naming [e. g. scope of iSCSI
name (per port or per device]]

4.9.1
Supports manufacterer-named iSCSI
name (may be based on user
configuration) M naming authority

4.9.2
Supports user-configurable iSCSI
name( s) O

4.9.3
Generates names with Unicode
characters O

4.9.4
Supports user-configurable iSCSI
alias( es) O

4.9.5
Full Unicode Support (names &
aliases can be configured using
Unicode) O

4.9.6
Unicode Comparison Support
(names using Unicode can be
compared) M

4.9.7 (initiator)
Supports common iSCSI name
across NIC/ HBA interfaces
4
4.9.8 (initiator)
NIC/ HBA iSCSI name settable via
API

4.9.9 (initiator) NIC/ HBA ISID range settable via API
4.9.10 Support IPv4 Address Format 1.2.7 M
4.9.11 Support Fully Qualified DNS names 1.2.7 O

4.9.12
Support/ Use Port field in
TargetAddress 1.2.7 O
4.10 Text Mode Negotiation

4.10.1
Use keyword "none" to indicate
missing function 1.2.4 M

4.10.2 Returns keyword "none" 1.2.4 O

4.10.3
Use keyword "reject" to indicate
unsupported or unallowed options 1.2.4 O

4.10.4 (initiator)
Uses same Initiator Task Tag on all
Text commands sent as part of a
negotiation sequence 2.8.2 M

4.10.5
Negotiates operation parameters
outside of login phase 4, 4.3 O

4.10.6
When using security, negotiate all
other iSCSI parameters after security
is established 4.2 O?

4.10.7 (initiator) Negotiates proprietary options 4.2 O values

4.10.8
Terminate text negotiation during
login with Login Response with F-bit=
1 4.3 M
5 iSCSI Target Features
Feature Reference Status Value
5.1 Login Features Supported
5.1.1 Require Initiator name during login 1.2.7 M
5.1.2 Require Target name during login 1.2.7 M
5.1.3 Send Target Alias during login O

5.1.4
Never sets F-bit= 1 when status is
"accept login" and login command
had F-bit= 0 2.11.4 M
5
5.1.5
Sets F-bity when login negoiation is
complete M 5.1.6 Support Partial Login Response M

5.1.7
5.2
Authentication Methods
Supported.

5.2.1 Support some authentication method B. 01 M
5.2.2
Support authentication method -
None B. 01 M

5.2.3
Support authentication method -
CHAP B. 01 O

5.2.4 Support authentication method -SRP B. 01 M
5.2.5
Support authentication method -
Kerberos5 B. 01 O

5.2.6
Support authentication method -
SPKM-1/ 2 B. 01 O

5.2.7
Support authentication method -
Other B. 01 O other method
5.2.8 Support authentication via Ipsec B. 01

5.3 Asynchronous Message Used
5.3.1
Send Async-event to initiators when
target is reset 2.18.1 O

5.3.2
Send Async-event to initiators to
request logout 2.18.1 O

5.3.3
Send Async-event to initiators to
notify connection drop 2.18.1 O

5.3.4
Send Async-event to initiators to
notify all connections dropped 2.18.1 O

5.3.5
Send Async-event to initiators to
notify session termination 2.18.1 O

5.4 Error Handling
5.4.1 Error Detection
5.4.1.1 Format Errors Detection 6.1 M
6
5.4.1.2 Digest Error Detection 6.2 M
5.4.1.3 Sequence Error Detection 6.3 M
5.4.1.4 Protocol Error Detection 6.4 M

5.4.1.4.1
Detect protocol error if PDU other
than login or text is received before
full feature phase 1.2.3 M
5.4.1.5 Error Detection via NOP-ins 2.12 O

5.4.1.6 Send Reject PDU on header digest 2.20 M
5.4.1.7 Send Reject PDU on data digest 2.20 M
5.4.1.8 Send Reject PDU on protocol error 1.2.3 O

5.4.2
Error Recovery Features
Supported
5.4.2.1 Negotiation Recovery 6.7.4 M
5.4.2.2 Issue R2T for error recovery 2.17 O
5.4.2.3 Accept Command with X Bit set 2.2.2.1 O
5.4.2.4 Reject Command with X Bit set 2.2.2.1 O
5.4.2.5 Issue NOP-in to recover Status 2.13,1.2.2 O

5.4.2.6 Issue NOP-in recovery to Data/ Cmds 2.13 O
5.4.2.7
Issue Status PDU if SNACK-Status
received 2.16 O

5.4.2.8
Issue Data PDU if SNACK-Data
received 2.16 O

5.4.2.9
Issue R2T PDU if SNACK-R2T
received 2.16 O

5.4.2.10 Issue Reject if SNACK-Data received 2.16 O
5.4.2.11 Issue Reject if SNACK-R2T received 2.16 O
5.4.2.12
Issue Async on connection
termination 2.18.1 O

5.4.2.13 Issue Async on session termination 2.18.1 O
7
5.5
Session Aggregation Used
[e. g. Connection Aggregation,
Multiple Sessions, Session
Spanning]

5.5.1
Support use of common aggregation
tag in different TargetAddress fields
of SendTargets response NDT M: 5.5.1

5.5.2 Support Multiple Session per Target
5.5.3 Support Multiple Targets
5.5.4 Support Multiple Service Portals

5.5.5
Support multiple sessions from same
initiator O
5.5.6 Support connection allegience 1.2.5 M

5.5.7
Supports linked commands spanned
over multiple connections 1.2.5 O

5.5.8
Supports interleaved unrelated SCSI
commands over session 1.2.5 O

5.5.9
Support opening multiple
connections for purpose of clean-up
(I. e. non-full feature phase) 2.10.1 O

5.5.10
Ignores iSCSI Target name on login
of additional connections 4.1 O

5.5.11
Issues Async message to request
removal of connection from session

5.6
Reboot Behaviour [e. g. Use of
Asynchronous Messages]

5.6.1
Sends async message when about
to reboot, shut down, or fail over to
another device
8
5.7
Session Management
Features Supported [e. g.
Includes features such as
whether the target sends
Redirect status]

5.7.1 Returns "Target Moved Temporarily" 2.11.4 O
5.7.2 Returns "Target Moved Permanently" 2.11.4 O
5.7.3 Returns "Proxy Required" 2.11.4 O
5.7.4 Returns "Target Removed" 2.11.4 O
5.7.5 Returns "Target Conflict" 2.11.4 O

5.7.6
Closes connection specified in CID
after logout 2.15 M

5.7.7
Duplicates up to first 4096 bytes of
data in NOP-Out 2.13 O

5.7.8
When initiating a NOP-In, initiator tag
= 0xffffffff and target tag != 0xffffffff 2.13.1 M

5.7.9
Valid LUN field is included when P-bit=
1 2.13.3 M
5.8 iSCSI Task Management

5.8.1
Returns Initiator Task Tag in all SCSI
Task Management responses 2.5.1 M

5.8.2
On Clear Task Set, enters a Unit
Attention Condition for all other
attached initiators 2.5.1 M

5.8.3
On Target Warm Reset and Target
Cold Reset, enters a Unit Attention
Condition for all attached initiators 2.5.1, 2.6.1 M

5.8.4
On Target Cold Reset, terminates all
TCP conections to all initiators 2.5.1, 2.6.1 M
9
5.8.5
On Target Warm Reset, enters ACA
state on all sessions and LUs where
Unit Attention was reported when
enabled by EnableACA 2.5.1 M

6 iSCSI Initiator Features
Feature Reference Status Value 6.1 Login Features Supported

6.1.1 Send Initiator name during login 1.2.7 M
6.1.2 Send Target name during login 1.2.7 M
6.1.3 Send Initiator Alias during login O

6.1.4
Sets F-bit when login negoiation is
complete M
6.1.5 Accept Partial Login Response M

6.1.6
Support authentication method -
None B. 01 M

6.1.7
Support authentication method -
CHAP B. 01 O

6.1.8 Support authentication method -SRP B. 01 M
6.1.9
Support authentication method -
Kerberos5 B. 01 O

6.1.10
Support authentication method -
SPKM-1/ 2 B. 01 O

6.1.11
Support authentication method -
Other B. 01 O other method
6.1.12 Support authentication via Ipsec B. 01
6.1.13 Supports authenticating target 1.2.3 O

6.1.14
Never issues a Login Command
more than once on same TCP
connection 2.10 M

6.3
Asynchronous Message
Support

6.3.1
Handle Async-event to initiators
when target is reset 2.18.1 O
10
6.3.2
Handle Async-event to initiators to
request logout 2.18.1 O

6.3.3
Handle Async-event to initiators to
notify connection drop 2.18.1 O

6.3.4
Handle Async-event to initiators to
notify all connections dropped 2.18.1 O

6.3.5
Handle Async-event to initiators to
notify session termination 2.18.1 O
6.4 Error Handling
6.4.1 Error Detection
6.4.1.1 Format Errors Detection 6.1 M
6.4.1.2 Digest Error Detection 6.2 M
6.4.1.3 Sequence Error Detection 6.3 M
6.4.1.4 Protocol Error Detection 6.4 M
6.4.1.6 Error Detection via NOP-outs
6.4.2.2 Recovery Within-connection 6.7.2 O
6.4.2.3 Recovery Within-session 6.7.3 O

6.4.2.4
Negotiation Recovery (To be
renamed) 6.7.4 M
6.4.2.5 Session Recovery 6.7.5 O
6.4.2.6 Accept R2T for error recovery 2.17 O
6.4.2.7 Issue SNACK Request (for Status) 2.16 O
6.4.2.8 Issue SNACK Request (for Data) 2.16 O
6.4.2.9 Issue SNACK Request (for R2T) 2.16 O
6.4.2.10 Issue Command with X Bit set 2.2.2.1 O
6.4.2.11 Accept NOP-in to recover Status 2.13 O

6.4.2.12
Accept NOP-in recovery to
Data/ Cmds 2.13 O

6.4.2.13 Resend Data PDU if SACK received 6.3 O

6.5
Session Aggregation Used
[e. g. Connection Aggregation,
Multiple Sessions, Session
Spanning]

6.5.1
Supports single session to span
multiple TCP connections O
11
6.5.2
Supports single session to span
multiple TCP addresses O

6.5.3
Support use of aggregation tag in
SendTargets response M: 5.5

6.5.4
Support use of common aggregation
tag in different TargetAddress fields
of SendTargets response M: 5.5.1

6.5.5
Creates multiple sessions to same
target O
6.5.6 Support connection allegience 1.2.5 M

6.5.7
Sends linked commands over
multiple connections 1.2.5 O

6.5.8
Interleaves unrelated SCSI
commands over session 1.2.5 O

6.5.9
Supports opening multiple
connections for purpose of clean-up
(I. e. non-full feature phase) 2.10.1 O

6.5.10
Uses ISID and TSID of existing
session during login on connections
to be added to same session 2.10.6 M: 6.5

6.5.11
Uses Logout command to remove a
connection from a session 2.14 O

6.5.12
Closes connection specified in CID
after logout 2.15 M

6.5.13
Does NOT specify the following text
parameter on login over new
connections to existing sessions:
MaxConnections, TargetName,
InitiatorName, DataOrder E. 0 M

6.6
Reboot Behaviour [e. g. Use of
Logout]

6.6.1
Sends logout command to targets
during shutdown or reboot O?
6.6.2 Logs out of target when idle O
12
6.7
Session Management
Features Supported
[e. g. Login/ Logout Including
Handling of the various status
code]

6.7.1
Closes connection specified in CID
after logout 2.15 M

6.7.2
Uses immediate delivery for NOP-Out
2.12 O
6.7.3 Uses in-order delivery for NOP-Out 2.12 O
6.7.4 Include Initiator Tag when P-bit= 1 2.12.2 M

6.7.5
Returns Target Tag in response to
NOP-In 2.12.3 M

6.7.6
Includes valid LUN field when Target
Tag is set 2.12.3 M

6.7.7 Sends less than 4096 bytes of data 2.12.4 O
6.8 iSCSI Task Management
6.8.1 Uses Abort Task 2.5.1 O
6.8.2 Uses Abort Task Set 2.5.1 O
6.8.3 Uses Clear ACA 2.5.1 O
6.8.4 Uses Clear Task Set 2.5.1 O
6.8.5 Uses Logical Unit Reset 2.5.1 O
6.8.6 Uses Target Warm Reset 2.5.1 O
6.8.7 Uses Target Cold Reset 2.5.1 O

7
Target iSCSI Maximum and
Minimum Values Min Max
7.1 Number of Sessions
7.2 Number of Sessions Per Target
7.3 Number of Sessions Per Initiator
7.4 Number of Targets

7.5 Number of Service Ports Per Device
7.6 Text Command Size
7.7 Text Value Size
7.8 NOP-in Data Size
13
7.9 NOP-out Data Size
7.10 Within-task Recovery Timeout

8
Initiator iSCSI Maximum and
Minimum Values Min Max
8.1 Number of Sessions
8.2 Number of Sessions Per Target
8.3 Number of Targets

8.4 Number of Service Ports Per Device
8.5 Text Command Size
8.6 Text Value Size
8.7 NOP-in Data Size
8.8 NOP-out Data Size
8.9 Within-task Recovery Timeout
8.10

9 Target Text Parameters Reference Status Value/ Range
9.1 MaxConnections E-08 O
9.2 TargetName E-09 O
9.3 InitiatorName E-10 O
9.4 TargetAlias E-11 O
9.5 InitiatorAlias E-12 O
9.6.1 TargetAddress (DNS) E-13 O
9.6.2 TargetAddress (IPv4) E-13 O
9.7 SendTargets E-14 O
9.8 AccessID E-15 O
9.9 FMarker E-16 O
9.10 RFMarkInt E-17 O
9.11 SFMarkInt E-18 O
9.12 IFMarkInt E-19 O
9.13 InitialR2T E-20 O
9.14 BidiInitialR2T E-21 O
9.15 ImmediateData E-22 O
9.16 DataPDULength( Data Digests on) E-23 O
9.17 DataPDULength( Data Digests off) E-24 O
9.18 FirstBurstSize E-25 O
14
9.19 LogoutLoginMinTime E-26 O
9.20 LogoutLoginMaxTime E-27 O
9.21 EnableACA E-28 O
9.22 MaxOutstandingR2T E-29 O
9.23 DataOrder E-30 O
9.24 BootSession E-31 O

9.25
The Glen-Turner Vendor Specific
Key E-32 O

10 Initiator Text Parameters Reference Status Value/ Range
10.1 MaxConnections E-08 O
10.2 TargetName E-09 O
10.3 InitiatorName E-10 O
10.4 TargetAlias E-11 O
10.5 InitiatorAlias E-12 O
10.6.1 TargetAddress (DNS) E-13 O
10.6.2 TargetAddress (IPv4) E-13 O
10.7 SendTargets E-14 O
10.8 AccessID E-15 O
10.9 FMarker E-16 O
10.10 RFMarkInt E-17 O
10.11 SFMarkInt E-18 O
10.12 IFMarkInt E-19 O
10.13 InitialR2T E-20 O
10.14 BidiInitialR2T E-21 O
10.15 ImmediateData E-22 O
10.16 DataPDULength( Data Digests on) E-23 O
10.17 DataPDULength( Data Digests off) E-24 O
10.18 FirstBurstSize E-25 O
10.19 LogoutLoginMinTime E-26 O
10.20 LogoutLoginMaxTime E-27 O
10.21 EnableACA E-28 O
10.22 MaxOutstandingR2T E-29 O
10.23 DataOrder E-30 O
10.24 BootSession E-31 O

10.25
The Glen-Turner Vendor Specific
Key E-32 O
15

16

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 24 Jun 2001 23:09:34 -0700 (PDT)

> the variability in implementations and testing.

The best way to limit the variability in implementations and testing is
not to include so many "features" in the first place. It's often tempting
to resolve potential conflicts by turning out a "kitchen sink spec" but
that's almost always a worse choice than choosing between one of the
alternatives. Similarly, options are a losing proposition because you have
to implement them because someone else might, but you can't guarantee
they'll be used. So if something doesn't make it into what would have been
the "profile" I'd question why it can't be thrown out altogether. 

As part of the Draft Standards application, "features" not proven to
interoperate with independent implementations have to be removed. So if a
"feature" was inserted merely to keep the peace, has problematic
interoperability or is not on the slate to be independently implemented,
we might as well toss it out. 

"There's never a better time to weed a garden than RIGHT NOW."

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 25 Jun 2001 10:06:42 -0400

> Similarly, options are a losing proposition because you have
> to implement them because someone else might

I thought you didn't have to implement them because it's certain that
someone else won't :^)

Steph