|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: DLB's Last Call comments
David,
I think you have the issue in T9 wrong. That format is not passed in any
iSCSI interchange. It is part of SCSI parameter data.
The item numbered T15, had a lot of discussions, especially in the Naming
and Discovery Team, and the current wordage was the results of a
compromise, where a number of vendors did not have the issue, and strongly
felt that it would be the wrong thing to do with their product. So we
agreed that the SHOULD section would be the right answer for every one.
I also disagree with your item T17. I think those examples are all that is
needed, since there are an infinite number of ways for someone to screw up.
Much of the document, is spent stating what MUST, SHOULD, SHOULD NOT be
done, repeating those at this point would not be useful.
I do not follow your issue with T18. Time outs can occur for reason that
are not something that needs more drastic action. If fact I would assume
that it generally does not need other actions.
In T33, I think we should leave the capability of vendor specific
authentication methods, so that vendors can do their own thing. These are
by definition not interoperable, they are intended to be that way.
I disagree with the editorial rewrite, especially at this late state. If
they were important that should have been brought up earlier. We should
not be discussing editorial style, but whether we have correctly specified
the protocol. We have already changed it a couple of times, and you are
now wanting it changed again. This is a very big spec, and each time we
make changes to pretty up the document, the more that is needed, and
someone else has another preference. It is already better then most of the
other IETF specs. I think this causes a needless delay.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com
Black_David@emc.com@ece.cmu.edu on 07/06/2002 07:29:23 PM
Sent by: owner-ips@ece.cmu.edu
To: ips@ece.cmu.edu
cc:
Subject: iSCSI: DLB's Last Call comments
I've spent the better part of 3 days reading -14, well, most of it -
I didn't check the state machines thoroughly, and my eyes glazed over
on the error handling pseudo-code, so I'll simply have to trust
that Mallikarjun and the other folks involved got that right.
This message contains my Technical comments and the editorial
comments that may involve significant work on the draft. My entire
set of 140 editorial comments is headed to Julian under separate cover.
These comments are submitted as an individual for further discussion
- I am *not* wielding my WG co-chair authority to say that these
have to be done or else ... I can be talked out of many of these
by suitably coherent and convincing technical arguments to the
contrary.
Please DO NOT REPLY to this message - there's too much stuff in
here. Please send a new message with a new subject line to discuss
specific comments below.
Thanks,
--David
-- Technical
[T.1] 2.2.2.2 Response/Status Numbering and Acknowledging
A large absolute difference between StatSN and ExpStatSN may indi-
cate a failed connection. Initiators undertake recovery actions if
the difference is greater than an implementation defined constant
that SHOULD NOT exceed 2**31-1.
That's a requirement, not a description. It needs a "SHOULD" or a
"MUST" between "Initiators" and "undertake".
[T.2] 2.2.6.1 iSCSI Name Requirements
The initiator MUST present both its iSCSI Initiator Name and the
iSCSI Target Name to which it wishes to connect in the first login
request of a new session or connection. The only exception is if a
discovery session (see Section 2.3 iSCSI Session Types) is to be
established; the iSCSI Initiator Name is still required, but the
iSCSI Target Name may be ignored.
"may be ignored" or "omitted"? Section 4.3 appears to indicate that
"omitted" is the correct word, making the correct wording "MAY be omitted".
[T.3] 2.2.6.1 iSCSI Name Requirements
iSCSI names must adhere to the following requirements:
Use upper case "MUST" instead of "must". Likewise for name encoding
requirements a) through d).
[T.4] 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name)
- A date code, in yyyy-mm format. This date MUST be a date
during which the naming authority owned the domain name used
in this format, and SHOULD be the date on which the domain
name was acquired by this naming authority.
Oh dear, what happens if a domain name changes hands twice in the
same month??? One possible way out is to require that the naming
authority owned the domain name at 00:01 GMT on the first day of
the month.
[T.5] 2.8 Message Synchronization and Steering
Since the only mechanism in this class currently specified for iSCSI is
markers, this general architectural framework needs to be removed
(possibly to other drafts, as some of this material is probably
appropriate for an RDDP architecture draft). This section needs to
be refocused on the marker mechanism that iSCSI describes, and include
a discussion of its use when an iSCSI header CRC check fails. I'd
like to see something like one paragraph on what markers are/do,
a sentence or two on how they can be used to recover from an iSCSI
header CRC check failure, and at most one paragraph on how markers
can help steer iSCSI PDUs/payloads into preallocated/queued buffers.
The current 4+ pages devoted to 2.8 and its subsections is
excessive and an invitation to further problems down the line.
[T.6] 2.3 iSCSI Session Types
b) Discovery-session - a session opened only for target discov-
ery; the target MAY accept only text requests with the SendTar-
gets key and a logout request with reason "close the session".
Change "MAY" to "MUST", and say that other requests MUST be rejected.
[T.7] 2.4.1 iSCSI Architecture Model
d) Network Portal - a component of a Network Entity that has a
TCP/IP network address and that may be used by an iSCSI Node
within that Network Entity for the connection(s) within one of its
iSCSI sessions. In an initiator, it is identified by its IP
address. In a target, it is identified by its IP address and its
listening TCP port.
Use of just an IP address to identify an entity such as this doesn't work
throuogh NAPTs (Network Address Port Translators). This issue needs to be
explained at some point, although I don't think it affects protocol
operation.
[T.8] 2.4.1 iSCSI Architecture Model
f) Portals within a Portal Group are expected to have similar
hardware characteristics, as SCSI port specific mode pages
may affect all portals within a portal group. (See Section 2.4.3.2
SCSI Mode Pages).
"similar hardware characteristics" needs to be explained/qualified,
as Section 2.4.3.2 does not contain an adequate explanation of what's
going on here and its hardware implications.
[T.9] 2.4.2 SCSI Architecture Model
The SCSI Port Name is mandatory in iSCSI. When used in SCSI
parameter data, the SCSI port name MUST be encoded as:
- The iSCSI Name in UTF-8 format, followed by
- a comma separator (1 byte), followed by
- the ASCII character 'i' (for SCSI Initiator Port) or the
ASCII character 't' (for SCSI Target Port), followed by
- a comma separator (1 byte), followed by
- zero to 3 null pad bytes so that the complete format is a
multiple of four bytes long, followed by
- the 6byte value of the ISID (for SCSI initiator port) or the
2byte value of the portal group tag (for SCSI target port) in
network byte order (BigEndian).
That's a peculiar format with padding nulls in the middle and
a number concatenated after the padding - for example, it can't
be passed in iSCSI login without format conversion. How about
converting the number to 4 or 12 bytes of hex (ASCII characters)
and moving the padding to the end so the result is actually a
string, and excluding the padding from the definition of the name?
This will increase the maximum length of port names, but produce
names that are easier to deal with.
[T.10] 2.4.3.2 SCSI Mode Pages
Changes via mode pages to the behavior of a portal group via one
iSCSI Target Node should not affect the behavior of this portal group
with respect to other iSCSI Target Nodes, even if the underlying
implementation of a portal group serves multiple iSCSI Target Nodes
in the same Network Entity.
I believe "should not" should be "SHOULD NOT".
[T.11] 4.1 Text Format
decimal-constant: an unsigned decimal number - the digit 0 or a
string of 1 or more digits starting with a non-zero digit.
This encoding is not used for numerical values equal or
greater than 2**64. Decimal-constants are used to encode
numerical values or binary strings. When used to encode
binary strings decimal constants have an implicit byte-length
that is the minimum number of bytes needed to represent the
base2 encoding of the decimal number.
The last sentence is the "decimal binary strings" issue that has been
discussed extensively on the list. One example of the problem is that
the decimal number 15 represents the binary string 0xF, but not the
binary strings 0x0F or 0x000F, and the latter two are not representable
in the decimal format as currently defined. If the difference between
these three matters (e.g., SRP's salt [s] parameter is one example
where this difference does matter) use of decimal format for binary
strings can cause things not to work. Forbidding the use of
decimal representation for binary strings would be the simplest change.
[T.12] 4.1 Text Format
large-numerical-value: an unsigned integer larger than or equal
to 2**64 encoded as a hex constant, or base64-constant.
Unsigned integer arithmetic applies to large-numeric-values.
I believe "larger than or equal to" should be changed to "whose value
may be larger than or equal to", as the current text forbids large
numerical values from representing values less than 2**64, which seems
wrong.
[T.13] 4.1 Text Format
Any iSCSI target or initiator MUST support receiving at least 16384
bytes of key=value data in a negotiation sequence except when indi-
cating support for very long authentication items by offering or
selecting authentication methods such as public key certificates in
which case they MUST support receiving at least 64 kilobytes of
key=value data.
This comment is classified as technical to catch the 16kB minimum as an
open issue. The "such as" text needs to be cleaned up - the point should
be that the 64 kB minimum applies when a authentication method using long
authentication items is offered or accepted, and should be accompanied
by a specific list of authentication methods in this draft that carry
that implication.
[T.14] 4.2 Text Mode Negotiation
During login, and thereafter, some session or connection parameters
are either declared or negotiated through an exchange of textual
information.
How does a declaration differ from a negotiation? It isn't described in
this section, and doesn't seem to be mentioned in any of the subsequent
sections about login, until one gets to the text key definitions.
[T.15] 4.3.1 Login Phase Start
The first Login Response PDU during the Login Phase from the iSCSI
target SHOULD return the TargetPortalGroupTag key that contains the
tag value of the iSCSI portal group servicing the Login Request PDU.
If the iSCSI target implementation supports altering the portal group
configuration (including adding, deleting, and swapping of portals in
a portal group), it MUST return the TargetPortalGroupTag key carry-
ing the tag value of the servicing portal group.
Let's make returning this key a MUST in all cases - less text, simpler
protocol, simpler code at the Initiator.
[T.16] 4.3.4 Connection reinstatement
Targets should support opening a second connection even
when they do not support multiple connections in Full Feature Phase.
Looks like that ought to be an upper case "SHOULD". I think this needs
further discussion. Section 5.2 appears to use a lower case "must"
for this:
Whenever a connection state machine (e.g., CSM-C) enters the
CLEANUP_WAIT state (S8), it must go through the state transitions
additionally described in the connection cleanup state diagram either
a) using a separate full-feature phase connection (let's call it CSM-
E) in the LOGGED_IN state in the same session, or b) using a new
transport connection (let's call it CSM-I) in the FREE state that is
to be added to the same session.
Also, the implications of needing to spend resources (e.g., new transport
connection) to clean up resources need to be described somewhere -
in the worst case, resources for a new transport connection may need to
be reserved to avoid deadlock. It doesn't look like there's a problem
with the transport (TCP) resources themselves, but this could be an
issue for iSCSI connection state resources (what happens if all
connections are in CLEANUP_WAIT and there's no iSCSI connection state
resource available to open a new transport connection?). The answer
is likely to involve killing off a session, but I don't see an
obvious explanation of it. Then I get to Section 5.2.2, which describes
a transition from CLEANUP_WAIT to FREE (M1) that can happen based on
a timeout, and presumably recovers the state resources and hence might
make this all work. Whether an additional connection is needed to
deal with CLEANUP_WAIT and whether it's MUST/SHOULD/MAY needs to be
sorted out, and the various descriptions of it made consistent.
[T.17] 6.4 Format Errors
The following two explicit violations of PDU layout rules are format
errors:
a) illegal contents of the PDU header (except the Opcode) - for
ex., out-of-range values for certain fields
b) inconsistent contents - for ex., value of one field conflicts
with that of another.
Format errors indicate a major implementation flaw in one of the par-
ties.
The two "for ex."s aren't good enough. Details on what is a format error
need
to be spelled out explicitly, given the drastic consequences of committing
one.
[T.18] 6.7 SCSI Timeouts
On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI
initiator MUST abort the command by either using the Abort Task task
management function request, or a "close the connection" Logout if it
intends to continue the session.
I think the first part is over specified - there are a number of task
management
commands that abort the task - if the target is really sick, something much
more serious than Abort Task may be used that not only aborts this task,
but others. It's not clear whether "if it intends to continue the session"
applies only to the logout or to both the task management command and the
logout, nor is it clear what an initiator should do if it doesn't intend to
continue the session.
[T.19] 8.1.1 Conservative Reuse of ISIDs
To both minimize the disruption of legacy applications and to better
facilitate the SCSI features that rely on persistent names for SCSI
ports, iSCSI implementations should attempt to provide a stable pre-
sentation of SCSI Initiator Ports
That's a requirement - change "should" to "SHOULD". This is a technical
comment to (re)open the issue of whether conservative reuse ought to be
a "MUST" - T10 is defining persistent reservation functionality that will
not behave as one might expect in the absence of conservative reuse - at
the very least, this consequence of ignoring the SHOULD needs to be stated.
[T.20] 8.2 Autosense and Auto Contingent Allegiance (ACA)
Autosense refers to the automatic return of sense data to the initia-
tor in case a command did not complete successfully. iSCSI initia-
tors and targets MUST support autosense.
"MUST support" --> "MUST support and use", as this is not just "MUST
implement".
[T.21] 8.3 iSCSI timeouts
iSCSI recovery actions are often dependent on iSCSI time-outs being
recognized and acted upon before SCSI time-outs. Determining the
right time-outs to use for various iSCSI actions (command acknowl-
edgements expected, status acknowledgements, etc.) is very much
dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI
driver). As a guidance the implementer may use an average Nop-Out/
Nop-In turnaround delay multiplied by a "safety factor" (2-3) as a
good estimate for the basic delay of the iSCSI stack for a given con-
nection.
"(2-3}" strikes me as low and providing little resilience to "stupid
network tricks". I'd change that to something like "(e.g., 5x, with a
minimum of several milliseconds)". This is complicated by the fact that
both initiators and targets will likely want to insert delays (in the
hope that something useful turns up that has to be sent) before sending
a NOP to update the various acknowledgement counters (e.g., ExpCmdSN).
[T.22] 9.1 iSCSI PDU Length and Padding
iSCSI PDUs are padded to the closest integer number of four byte
words. The padding bytes SHOULD be 0.
"MUST be transmitted as zero and ignored by the receiver, except for
calculation of the digest CRCs if present" would be better.
Same comment applies to padding bytes for header segments.
[T.23] 9.4.1 Flags (byte 1)
Bits O and U and bits o and u are mutually exclusive.
Need to put some teeth into that. Say that in each pair, it is a protocol
error if both bits are set to 1, and refer to the section for handling that
error.
[T.24] 9.4.4 Residual Count and 9.4.5 Bidirectional Read Residual Count
These should be treated as reserved when they're not valid (O and U are
zero
for Residual Count, o and u are zero for Bidi Read Residual Count) - MUST
be set to zero by sender, MUST be ignored by receiver.
[T.25] 9.5.2 LUN
This field is required for functions that address a specific LU
(ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT
RESET) and is reserved in all others.
Should TASK REASSIGN be added to the list in parentheses?
[T.26] 9.6 Task Management Function Response
For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK
SET, LOGICAL UNIT RESET, TARGET COLD RESET and TARGET WARM RESET, the
target performs the requested Task Management function and sends a
Task Management Response back to the initiator.
TASK REASSIGN does not get a response. Was this intended?
[T.27] 9.12.10 ExpStatSN
This is ExpStatSN for the old connection.
This field is valid only if the Login request restarts a connection
(see Section 4.3.4 Connection reinstatement).
This is for the Login Request PDU. For the initial Login Request PDU in a
login
phase, the description is correct, but thereafter, Login Request should be
using ExpStatSN to acknowledge the Login Responses via their increasing
StatSN values (see 9.13.4). This raises the related question of why
StatSN/
ExpStatSN is being used during login while CmdSN/ExpCmdSN is not being
used.
[T.28] 9.14 Logout Request
A successful completion of a logout request with the reason code of
"close the connection" or "remove the connection for recovery"
results in the discarding of all tasks waiting in the command reor-
dering queue that are allegiant to the connection being logged out.
"discarding" is not what hapapens in the "remove the connection for
recovery
case according to the following text from Section 6.5:
b) Logout the connection for recovery and continue the tasks on a
different connection instance as described in Section 6.1 Retry
and Reassign in Recovery. [OR]
A "discarded" task cannot be "continue"-d. I suspect the text should say
that "close the connection" terminates the tasks, anad "remove the
connection
for recovery" suspends the tasks with the following CmdSN side effects ...
[T.29] 9.14 Logout Request
The entire logout discussion in this section is completely applica-
ble also for an implicit Logout effected by way of a connection rein-
statement or session reinstatement. The Logout reason codes for
implicit Logout are specified as below:
How are these codes used and why are they specified here? Logout Request
is an explicit logout, not implicit.
[T.30] 9.16 SNACK Request
If the initiator MaxRecvDataSegmenTLength changed Data-In PDUs
requested with RunLength 0 (meaning all PDUs after this number) may
be different from the ones originally sent, in order to reflect
changes in MaxRecvDataSegmentLength. Their DataSN starts with the
requested number and is increased by 1 for each resent Data-In PDU.
If DataSN numbers change and a SCSI-Reponse PDU was sent reflecting
the DataSN before retransmission it MUST be resent to reflect the new
numbers.
This was discussed on the list, but there are still some problems here:
(1) If the MaxRecvDataSegmentLength has changed, the only valid Data
SNACK is BegRun=0, RunLength=0 (i.e., resend everything). Attempts
to be more clever than this are an invitation to miscount Data-In
PDUs and cause problems in the initiator. Targets MUST reject
all other Data SNACK requests in this situation.
(2) The new SCSI-Response PDU needs a new StatSN to avoid the initiator
discarding it as a duplicate. Section 2.2.2.2 is silent on
duplicate
detection for StatSN, but discarding duplicates would be a
reasonable
thing for an initiator to do.
(3) The initiator needs some way to know that a new response is coming,
and specifically whether to expect one or two responses. If it
only expects one and two show up, the initiator could reuse the
Task Tag once all the data arrives causing a race in which the
new response could incorrectly complete an unrelated command
(unlikely, but potentially nasty).
This suggests calling out the <BegRun=0, RunLength=0> Data SNACK as having
special behavior:
- It may resegment Data-In PDUs to deal with
MaxRecvDataSegmentLength.
All other Data SNACK requests MUST NOT resegment.
- It *always* generates a new SCSI Response due to the possibility
of resegmentation.
That's not a great solution, because if one ever sets <BegRun=0,
RunLength=0>
in a Data SNACK, the resulting behavior change is dramatic and unexpected.
This leads to the final proposal:
- Specify a new SNACK type code (3) for Resegmenting Data SNACK.
SNACK
Data-In resegmentation is allowed only when this is used.
If
resegmentation would be necessary for a Data SNACK (type 1),
that SNACK MUST be rejected.
- Both BegRun and RunLength MUST be zero for a Resegmenting Data
SNACK, and (unlike reserved fields) these MUST be checked by
the receiver (target).
- A new SCSI Response is always generated as a result of a
Resegmenting
Data-In SNACK, and it has its own StatSN number to deal with
the
fact that the number of Data-In PDUs may have changed,
causing
a change to the ExpDataSN value. This new response also
needs
to be marked to distinguish it from a response that may have
been generated earlier (so the initiator knows to wait for
the
new response) - using a bit in the flags field for this
seems
wrong, so specifying a new Response code value (0x02 - see
9.4.3)
seems like a reasonable way to accomplish this.
- Data SNACK (type 1) now has consistent behavior - it MUST NOT
resegment
and MUST NOT generate a new SCSI response, ever.
This approach also has the potentially useful property of making it easy
to yank out the Resegmenting Data SNACK wart if we ever put restrictions
on the interaction of MaxRecvDatasegmentLength and Data SNACKs (yes, that's
a hint ... this has gotten messy enough that forbidding Data SNACKs when
MaxRecvDataSegmentLength has changed needs to be considered as a possible
alternative).
This issue also affects some text in 9.16.3.
[T.31] 9.16.1 Type
An iSCSI target that does not support recovery within connection MAY
reject the status SNACK with a Reject PDU. If the target supports
recovery within connection, it MAY reject the SNACK after which it
MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
cates "Request Logout".
This should be conditioned on the operational ErrorRecoveryLevel of the
session, not whether the target supports recovery within connection.
[T.32] 10. iSCSI Security Keys and Authentication Methods
Only the following keys can be used during the SecurityNegotiation
stage of the Login Phase:
[ ... snip ...]
AuthMethod and all keys listed under AuthMethod along with all
of their associated keys.
In practice, this forbids vendor-unique authentication methhods, as they
would have to define their own text keys (reusing keys for an existing
AuthMethod is a *bad* idea). OTOH, Section 10.1 appears to allow
vendor-unique authentication methods.
The authentication methods that can be used (appear in the list-of-
options) are either those listed in the following table or are ven-
dor-unique methods:
One of these two needs to change, and see also editorial comment [E.136]
against the above text from Section 10. Forbidding vendor-unique
authentication methods would enhance interoperability.
[T.33] 10.5 Challenge Handshake Authentication Protocol (CHAP)
For the Algorithm, as stated in [RFC1994], one value is required
to be implemented:
5 (CHAP with MD5)
To guarantee interoperability, initiators SHOULD always offer it as
one of the proposed algorithms.
Change that "SHOULD" to a "MUST".
[T.34] 11.1 HeaderDigest and DataDigest
Proprietary algorithms MAY also be negotiated for digests. Whenever a
proprietary algorithm is negotiated, "None" or "CRC32C" should be
listed as an option in order to guarantee interoperability.
Change "negotiatiated" to "offered" and "should" to "MUST".
[T.35] 11.4 TargetName and 11.5 InitiatorName
The descriptions of these keys need to have restrictions on changing them
added - changing a name after it's been used for initial authentication/
authorization can cause security problems. These restrictions may already
exist in the prohibitions on re-negotiating keys, but need to be (re)stated
here.
[T.36] 11.6 TargetAlias and 11.7 InitiatorAlias
Add text here or in Section 10 to say that these keys MUST NOT be used to
make authentication, or authorization (including access control) decisions.
[T.37] 11.12 ImmediateData
If ImmediateData is set to No and InitialR2T is set to No, then the
initiator MUST NOT send unsolicited immediate data, but MAY send one
unsolicited burst of Data-OUT PDUs.
If ImmediateData is set to Yes and InitialR2T is set to No, then the
initiator MAY send unsolicited immediate data and/or one unsolicited
burst of Data-OUT PDUs.
Both of the above uses of "MAY" are problems - my recollection of this
is that if InitialR2T=No and there is data to be sent that falls under
the implicit Initial R2T, then it MUST be sent as unsolicited Data-Out
PDUs.
[T.38] 12. IANA Considerations
The temporary (user) well-known port number for iSCSI connections
assigned by IANA is 3260.
Delete "temporary (user)" insert "TCP" before "port number" or add
instructions for IANA to allocate a system port when this draft is
approved to become an RFC - I think just sticking with 3260 is better.
[T.39] 12. IANA Considerations
If vendor additions of values to existing keys is to be allowed
(e.g., AuthMethod, HeaderDigest, DataDigest) an IANA registry is needed
for each set of values - see [T.32] and [T.34], or the reversed DNS
convention needs to be extended from keys to values - the latter doesn't
sound like a good idea.
-- Editorial
Global Editorial comment: Both the login (4) and error handling (6)
sections
feel like one of those old Adventure mazes of twisty little passages - all
the
details seem to be there, for the most part they're correct, but it's very
hard
to get the proverbial "big picture" of how everything fits together, in
terms
of how the various mechanisms work with each other and how they accomplish
the overall functionality. Both of these could use overview sections
describing
how the functionality breaks down into the pieces described in the
subsections
and how they fit together. Swapping the order of Sections 5 and 6 would
also
be a good idea so that the discussion of Error Handling and Recovery comes
before the state machine descriptions that contain a lot of the details of
how errors are handled. For error handling, moving Section 6.13 to the
front of Section 6 would help organize the Section better, and care should
be
taken to define or replace terms like "restart login" and "recovery R2T"
that are currently used without definitions.
Also the following two editorial comments recommend serious restructuring
of
a portion of the draft:
[E.80] 5.1 Standard Connection State Diagrams
I'm probably going to take grief for this comment because it's a lot of
work,
but I think this section would be significantly clearer if the state and
transition descriptions were split into separate initiator and target
portions, so the order of the subsections would be:
- Initiator diagram
- Initiator state descriptions
- Initiator transition descriptions
- Target diagram
- Target state descriptions
- Target transition descriptions
I guess it's ok to leave the descriptions merged in Section 5.2.
[E.81] 5.3 Session State Diagrams
This should be restructured in a fashion similar to Section 5.1 (see
[E.80]).
If you made it this far, thanks for taking the time to read
everything, --David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 249-6449 FAX: +1 (508) 497-8018
black_david@emc.com Mobile: +1 (978) 394-7754
---------------------------------------------------
Home Last updated: Sun Jul 07 11:18:45 2002 11156 messages in chronological order |