Subject: RE: iSCSI: current UNH Plugfest

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Nov 2001 13:36:45 +0200

Bob,

I assume that your statement about request sense refers to a data-in PDU 
not a data segment (e.g., not the data segment of a response PDU). 
Normally a request sense will result in a single input PDU - a Data-IN 
including also the good status for the request sense (if the implementer 
had enough goodwill to collapse the 2 phases). 

As for the MUST the paragraph has already a MUST (MUST support autosense). 

Julo

Robert Snively <[email-masked]>
Sent by: [email-masked]
31-10-01 22:39
Please respond to Robert Snively

        To:     "'Santosh Rao'" <[email-masked]>, Anshul Chadda 
<[email-masked]>
        cc:     [email-masked]
        Subject:        RE: iSCSI: current UNH Plugfest

The "MUST have sense information if CHECK CONDITION" is 
a property of SCSI that requires the use of autosensing,
as iSCSI does. 

It is only non autosensing drivers that will present
CHECK CONDITION indications with sense data missing.

Sense Data will never be generated in a data segment to any command except
REQUEST SENSE.  In that case, CHECK CONDITION will never
be indicated unless the REQUEST SENSE command failed in
some way, and (if autosensing is used), the CHECK CONDITION
will be associated with its own set of sense information in
the response PDU.

Note that if the unit cannot assemble relevant sense information
from the attached hardware, that is in itself a CHECK CONDITION,
and the corresponding inability to access critical hardware
must be posted in the sense information.

That is why MUST is the proper requirement.

Bob

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 11:53 AM
> To: Anshul Chadda
> Cc: [email-masked]
> Subject: Re: iSCSI: current UNH Plugfest
> 
> 
> Anshul,
> 
> I don't know why the initiator should care if the sense data arrived
> along with the CHECK CONDITION scsi status or not. (?)
> 
> Most, if not all, SCSI initiator stacks have some form of indicating
> sense_status from SCSI LLP (hba driver, device driver, 
> mini-port driver,
> etc) to SCSI ULP (class driver, target driver, etc), which indicates
> what the status of the sense operation was and whether sense data is
> available or not.
> 
> For instance, you also need to deal with a scenario where the target
> sends a SCSI status of CHECK CONDITION and accompanies it 
> with the sense
> data in the data segment. However, the initiator encounters a data
> digest error on the sense data data segment and drops the sense data
> data segment. The initiator can always choose to complete the I/O and
> return the SCSI status back to its SCSI ULP, indicating that no sense
> data was available.
> 
> I don't see why you would need the wording tightened to a MUST.
> Initiators must not assume that the sense data will always be 
> available
> on a check condition. The sense operation may be unsuccessful and no
> sense data may be available.
> 
> Regards,
> Santosh
> 
> 
> > Anshul Chadda wrote:
> > 
> > Hello:
> > As this issue has come up with setting CHECK CONDITION in the SCSI
> > Response. It is assumed that if CHECK CONDITION is set in the SCSI
> > Response PDU, then there has to be sense data accompanied 
> with it. So
> > as far as I see it, it would help if the following sentence in the
> > draft has the MUST/must in there. In the current wording, i 
> can think
> > that if there is no data segment in the SCSI Response PDU 
> for a CHECK
> > CONDITION, it is still OK.
> > 
> > In draft 8, the sentence looks like the following:
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> > 
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the Data Segment contains sense data for the
> > failed command.
> > 
> > -------------------------------------------------------
> > 
> > It can be changed to the following:
> > 
> > -------------------------------------------------------
> > 3.4.6 Data Segment - Sense and Response Data Segment
> > 
> > iSCSI targets MUST support and enable autosense. If Status is CHECK
> > CONDITION (0x02), then the target MUST have sense data in the data
> > segment for the failed command.
> > 
> > -------------------------------------------------------
> > 
> > I don't know if there is a reason that the draft has the wording in
> > the current way.  Apologies if this subject has already been
> > discussed.
> > 
> > Regards,
> > Anshul
> > 
> > 
> --------------------------------------------------------------
> ---------------------------------------------------
> > 
> > 5. Some common error situations:
> > 
> >    1) - when a SCSI Response contains a CHECK CONDITION 
> (Status=0x02),
> >       some targets are not including the SenseLength as the first 2
> >       bytes in the data segment.  Although the format of the data
> > segment
> >       is clear from the diagram in section 3.4.6 on page 62 
> of draft 8
> >       (page 63 of draft 8a), the last entry in the diagram for the
> > SCSI
> >       Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
> >       misleading because it mentions only the Sense Data 
> and Response
> >       Data and omits the Sense Length.  It would therefore 
> be helpful
> >       if the last entry in the diagram on page 58 were changed to
> > explicitly
> >       reference the diagram on page 62, as in:
> > 
> >          Data Segment -- see section 3.4.6 (optional)
> > 
> > 
> 
> -- 
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : [email-masked]
> Phone : 408-447-3751
> ##################################
>

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Nov 2001 17:47:37 +0200

Bob,

The spec already says MUST.  I don't agree that saying MUST twice is a 
good practice.

Julo

"Robert D. Russell" <[email-masked]>
01-11-01 16:50
Please respond to "Robert D. Russell"

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: iSCSI: current UNH Plugfest

Julian:

IMHO if we mean MUST then we MUST say MUST.

It is clear from the exchange between Anshul, Santosh and Robert
that we already have different interpretations of what
it means without MUST and hence we have interoperability problems.

In this particular case I agree with Anshul and Robert that the
standard should say MUST.  Santosh's argument that in an error
case the data gets lost does not seem to be relevant --
in error cases lots of information gets lost and recovery is
necessary to get that information back.  The spec provides for
this.  We should not be introducing interoperability problems
because of a situation that may arise in the rare case of an error,
especially when the spec already deals with recovery of that
information when the error is detected.

Thanks,

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

On Thu, 1 Nov 2001, Julian Satran wrote:

> Anshul,
> 
> IMHO a single MUST in the paragraph is strong enough and covers all the 
> cases.
> 
> Julo
> 
> 
> 
> 
> "Anshul Chadda" <[email-masked]>
> 31-10-01 19:34
> Please respond to "Anshul Chadda"
> 
> 
>         To:     <[email-masked]>
>         cc: 
> Response PDU, then there has to be sense data accompanied with it. So as 

> far as I see it, it would help if the following sentence in the draft 
has 
> the MUST/must in there. In the current wording, i can think that if 
there 
> is no data segment in the SCSI Response PDU for a CHECK CONDITION, it is 

> still OK.
failed 
> command.
segment 
> for the failed command.
> I don't know if there is a reason that the draft has the wording in the 
> current way.  Apologies if this subject has already been discussed. 
> 
> Regards,
> Anshul
> 
> 
-----------------------------------------------------------------------------------------------------------------
>    1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
segment
>       is clear from the diagram in section 3.4.6 on page 62 of draft 8
>       (page 63 of draft 8a), the last entry in the diagram for the SCSI
>       misleading because it mentions only the Sense Data and Response
>       Data and omits the Sense Length.  It would therefore be helpful

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Nov 2001 19:30:02 +0200

Bob,

Rereading the text I understand what is confusing. The target name 
mentioned is the one from the previous item!

I will reformulate it to read:

The value must be one of:

all

The initiator is requesting that information on all relevant targets known 
to the implementation be returned.  This value MUST be supported on a 
discovery session, and MAY NOT be supported on an operational session.

<iSCSI-target-name>

If an iSCSI target name is specified, the session should respond with 
addresses for only the named target, if possible.  This value MUST be 
supported on discovery sessions.  A discovery session MUST be capable of 
returning addresses for those targets that would have been returned had 
value=all been designated.

<nothing>

The session should respond with addresses only for the target to which the 
session is logged in.  This MUST be supported on operational sessions, and 
MAY NOT return targets other than the one to which the session is logged 
in.

Thanks,
Julo

01-11-01 18:31

Julian:

Comments below:

> 4. Situation: The initiator and target have successfully completed the
>    login phase for a discovery session and are now in full feature 
phase.
>    The initiator sends a text command containing the single key:
>    "SendTargets=".  What response is expected from the target?
> 
> 
>    Interpretation 1:
> 
>    According to the explanation on page 188 of draft 8 (page 189 of
>    draft 8a):
>    "If no target name is specified, the session should respond with
>    addresses only for the target to which the session is logged in.
>    This MUST be supported on operational sessions, and MAY NOT
>    return targets other than the one to which the session is logged in."
> 
>    However, for a discovery session there is no target per se (the
>    initiator does not specify a TargetName= during login), so the
>    target therefore follows the rule on page 188 of draft 8 (page 189
>    of draft 8a):
> 
> +++
> That is not strictly correct. You may use discovery to determine the 
> addresses and portal groups for a specific target - i.e. you may give a 
> target-name. If you give a target name that is all you get. If don't 
give 
> a name you get all the targets you are allowed to get to.
> ++++

If I understand this reply correctly, you are saying that
in a discovery session, when the initiator sends:
   SendTargets=
it should expect to receive all the targets it is allowed to get to.
Correct?

This leads to 2 further questions/points:

1. Is this response any different from the response the initiator will
get when it sends:
   SendTargets=all

2. If these responses are the same, then the explanation of <nothing>
on page 188 of draft 8 should be changed to indicate that this is what
happens for a discovery session.

Thanks,

Bob Russell
InterOperability Lab

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 1 Nov 2001 21:25:59 +0200

Sandeep - your note made me look - and I found that I forgot the list - 
Sorry - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 01-11-01 21:25 -----

Julian Satran
01-11-01 14:02

        To:     "Robert D. Russell" <[email-masked]>
        cc: 
        From:   Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: current UNH Plugfest

Bob,

Comments in text - thanks - Julo

01-11-01 00:39

        To:     [email-masked]
        cc: 

Attached are the new issues that arose during the iSCSI plugfest
at UNH on Wednesday 31-Oct-2001.

(Note: these issues do not take into account any modifications or
clarifications that occured in the standard due to the issues raised
on Monday or Tuesday.)

Bob Russell
InterOperability Lab

----------------------------------------------------------------------------

1. Are receivers (initiator or target) REQUIRED to check that reserved
   bits and/or fields are set to 0?

   Section 3 on page 48 of draft 8 says:
     "Any bits not defined MUST be set to zero.  Any reserved fields and
     values MUST be 0 unless specified otherwise."

   and Section 8.3 on page 127 of draft 8 says:
     "Explicit violations of the PDU layout rules stated in this document
     are format errors.  This when detected, usually indicates a major
     implementation flaw in one of the parties.

     When a target or an initiator receives an iSCSI PDU with a format
     error, it MUST reset all transport connections in the session
     immediately and escalate the format error to session recovery
     (section 8.11.4)."

   According to these rules, a PDU with reserved bits and/or fields that
   are not set to 0 violates the PDU layout rules.  Therefore, if an
   initiator or target receives such a PDU, it should immediately close
   all connections in the session and go to session recovery.

   Clearly a format error has extremely severe consequences!

   Although all vendors are setting reserved bits and fields to 0 on
   PDUs they are sending, many are NOT checking PDUs they are receiving
   to see if these bits and fields are set to 0.  Basically, vendors are
   saying "who cares if reserved bits and/or fields in incoming PDUs are
   not zero?  We do not want to take the time to do this checking, and
   there is no benefit to doing it.  As long as the non-reserved bits and
   fields are set properly, we can and should proceed.  Any time devoted
   to doing this checking is wasted in 99+% of the cases, and in the
   (unlikely) case that a non-zero bit or field is found, the
   consequences are too severe."

   There should be some statement in the standard to clarify what checking
   is required and what is optional.


+++

As it was said already on this list there are things that a standard 
better leaves unsaid :-)

In accordance with the good tradition of other iSCSI transports I suggest 
we stay silent on this.

+++

2. A similar situation arises with respect to checking the consistency
   of fields such as Version-max, Version-min and Version-active in Login
   Requests and Login Responses.

   For example, consider the Version-max field.

   Section 3.12.5 says:
     "All Login requests within the Login phase MUST carry the same
     Version-max."

   All vendor initiators are setting Version-max correctly on all
   login requests they are sending, but many vendor targets are NOT
   checking received login requests to ensure that this rule is enforced.
   In particular, many targets simply use the Version-max and Version-min
   on the first login request they receive on a new connection, and then
   they ignore these fields on all subsequent login requests in the same
   login phase.

   Strictly speaking, a change in the Version-max field during the login
   phase constitutes a protocol error according to section 8.8 on page 130
   of draft 8:

     "All violations of iSCSI PDU exchange sequences specified in this
     draft are also protocol errors.  This category of errors can be
     addressed only by fixing the implementations; iSCSI defines Reject
     and response codes to enable this".

   Therefore the target should send back a login response with a status
   of 0x0200 and then close the connection.

   However, Section 3.12.5 also says:
     "The target MUST use the value presented with the first login 
request."

   This rule seems to imply that the value CAN change, because if it 
cannot
   change, then it doesn't matter which one of the login requests it is
   taken from, they are all the same anyway.

   The suggestion is to keep the requirement that the target MUST use the
   value presented on the first login request, but to allowed the target
   to ignore the value presented on all subsequent login requests in the
   same login phase.  A similar rewording should be done for the other
   fields.

+++

As above.

+++

3. Can commands be sent out of order on the same connection?

   The behavior of targets is clearly specified in Section 2.2.2.3 on
   page 25 of draft 8, which says:
     "Except for the commands marked for immediate delivery the iSCSI
     target layer MUST eliver the commands for execution in the order
     specified by CmdSN."

   Section 2.2.2.3 on page 26 of draft 8 also says:
     "- CmdSN - the current command Sequence Number advanced by 1 on
     each command shipped except for commands marked for immediate
     delivery."
   but the meaning of the term "shipped" is vague, and does not 
necessarily
   require that the PDUs arrive on the other end of a TCP connection
   in the same order that the CmdSN values were assigned to these PDUs.

   Some initiators have been designed to send commands out of CmdSN
   order on one connection.  Consider the situation where there is only
   one connection and a high-level dispatcher creates a PDU for a SCSI
   command that involves writing immediate data to the target.  This PDU
   is enqueued to a lower-level layer which has to setup, start, and
   wait-for a DMA operation to move the immediate data into an onboard
   buffer before the PDU can be put onto the wire.  While this is
   happening, the dispatcher creates another unrelated PDU for a SCSI
   read command (for example), and when this PDU is passed to the
   lower-level layer it can be sent immediately, ahead of the previous
   write PDU and therefore out of order on this connection.

   The standard clearly allows this to happen if the two PDUs were sent
   on different connections, and seems to imply that this can also happen
   when the two PDUs are sent on the same connection.

   The suggestion is to put in the standard an explicit statement that
   this is allowed or not allowed, as appropriate.
 
   If this is allowed, such a statement would avoid the erroneous
   assumption being made by some target implementers that within a single
   connection, commands will arrive in order.

   If this is not allowed, such a statement would avoid the erroneous
   assumption being made by some initiator implementers that within a
   single connection, commands can be put on the wire out of order.

+++ 

will add an explicit statement saying that this behaviour is forbidden.
2.2.2.1 will contain:

On any given connection, the iSCSI initiator MUST send the commands in the 
order specified by CmdSN.

+++

4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
   now allow: "A value of 0 indicates no limit."

   Is this useful?  Does it buy anything?
+++ 

I have already removed this.
However the numerical negotiation will have 0 (wherever appropriate) as a 
means to indicate "I don't care"

The text suggested for this is:

For numerical negotiations, the value 0 MAY be specified by the offering 
party as a "don't care"/"unlimited" value for parameters that explicitly 
allow it; in this case, the responder may choose any legal value for the 
parameter.

And in the MAXBurstSize etc:

A value of 0 MAY be used as a "don't care" offer in negotiations.

+++

   The difficulties implementers are having with this are:

   1) It is a special case.
   2) It causes discontinuous ranges (for example, [0,64..2**24])
   3) It violates the min/max function normally used for the key.
   4) There is always a limit anyway.

   Consider FirstBurstSize, which can have a value that is described
   as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
   is selected.

   I one side offers 0 to mean unlimited, and the other side
   has a limit, it will reply with that limit, say 128 Kbytes.
   Therefore, the result is not min(0, 128K) but rather max(0, 128K).
   The statement in the standard that "the minimum of the 2 numbers is
   selected" is therefore wrong when one of the numbers is 0.

   Furthermore, when an initiator or target receives an offer for one
   of these keys, it cannot simply check that the offered value is
   legal by testing it against some minimum and maximum.  It must first
   check for 0 and then only if that check shows the value is non-zero
   can it do the min/max range check for legality (i.e., 64-2**24).

   Finally, there is always a limit. If nothing else it is the
   limit imposed by the 24-bit DataSegmentLength field of the PDU
   requesting the transfer.  It is useless to specify a FirstBurstSize
   (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
   the largest possible DataSegmentLength in any PDU that can use
   this value is 2**24-1.

   The suggestion is to just eliminate this special case of 0 and require
   that the range 64-to-(2**24-1) be used instead -- it has exactly the
   same effect in all cases, it is easier to describe in the standard
   because it avoids all the extra words, and it is easier to code
   because it avoids all the special cases.

   NOTE: the standard should specify the limit in the ranges for
   MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
   of 2**24.  The number 2**24 cannot be represented in the 24-bit
   DataSegmentLength field and therefore can never be used.

5. This is a suggestion for a minor rewording in the standard to avoid
   misunderstandings.

   In Appendix E on page 188 of draft 8 it says:

     "The response to this command is a text response containing a list of
     targets and their addresses.  Each target is returned as a target
     record.  A target record begins with the TargetName text key,
     followed by a list of TargetAddress text keys, ..."

   In fact, there are situations where there are no targets and/or no
   addresses.  These situations are clearly defined in the draft after
   the sentences quoted above, but it would help if those sentences
   at least hinted at the possibility that the lists could be empty
   or might not contain addresses.  A possible rewording would be:

     "The response to this command is a text response containing a list of
     zero or more targets and, optionally, their addresses.  Each target
     is returned as a target record.  A target record begins with the
     TargetName text key, followed by a list of zero or more
     TargetAddress text keys, ..."

+++
OK

+++
6. This is a suggestion for another very minor rewording in the standard.

   At the end of section 2.2.3 on page 29 of draft 8 it says:

     "Before full feature phase is established, only Login PDUs are
     allowed. ..."

   The suggested rewording is:

     "Before full feature phase is established, only Login Request and
     Login Response PDUs are allowed. ..."

+++

OK

+++

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 5 Nov 2001 10:11:13 +0200

Bob,

Comments in text.

Thanks,
Julo

02-11-01 01:31

        To:     [email-masked]
        cc: 

Attached are the new issues that arose during the iSCSI plugfest at
UNH on Thursday 1-Nov-2001.

Bob Russell
InterOperability Lab

----------------------------------------------------------------------

There were no new issues today!  Lots of people were busy sending
data and interoperating with each other!  There were, however, a
few suggestions/requests for clarifications in the standard:

1. Since all Login Requests MUST be issued as immediate requests,
the diagram in section 3.12 should show bit 6 of byte 0 as "1",
not "I", and section 3.12.2 should simply be eliminated.

++++

OK - Julo

++++

2. The first paragraph of Appendix D should describe the special
role of the first Login request on the first connection of a new
session.  In particular, there are 3 keys that MUST be sent in
that Login PDU (InitiatorName, SessionType if it is discovery,
TargetName if the session is normal).  This is, in fact, yet
another classification that is currently included within LO, but
LO is too general, since LO allows keys to appear at any time
during the leading login phase, and these keys must appear on the
very first login PDU in that leading login phase.

+++

There is now a text in Section 5 that reads:

The initial Login request of the first connection of a session (primary 
login) MUST include the InitiatorName key=value pair. The primary Login 
request MAY also include the SessionType key=value pair in which case if 
the SessionType is not "discovery" then the leading Login Request MUST 
also include the key=value pair TargetName.

+++

3. A target cannot release its resources for a command until it
receives an ExpStatSN back from the initiator that acknowledges
receipt of the StatSN carried in the SCSI Response to that command.
However, if the initiator does not have any more I/O to perform,
that ExpStatSN will not come back to the target, and the target
may end up holding on to those resources indefinitely.  This is a
situation where initiator non-action can impact target performance,
and could even lead to denial of service attacks if several
initiators were to do this simultaneously to the same target.

The standard provides the NOP-In/Out mechanism to deal with this:

The last paragraph of section 2.2.2 says:
  During periods when traffic on a connection is unidirectional,
  iSCSI NOP-Out/In PDUs may be utilized to synchronize the command
  and status ordering counters of the target and initiator.

and section 3.18 says:
  A NOP-Out may also be used to confirm a changed ExpStatSN if
  there is no other PDU to carry it for a long time.

The question is, is there a recommended mechanism to trigger these
NOP-pings?

Clearly the target could set a timer, and if ExpStatSN is not
received back at the end of the time interval, the target could
send a NOP-in as a ping in order to get the initiator to send back
a NOP-out with the updated ExpStatSN.

Also clearly the initiator could set a timer, and if it has no
traffic to send during the time interval, the initiator could send
a NOP-out to deliver the updated ExpStatSN to the target.
This approach is probably not as reliable as the first, since
a) if the initiator does not do it, only the target gets hurt, and
b) if the connection drops, the target will never receive the NOP-out.
On the other hand, it may be more efficient for the initiator to do
this, since a typical target may be dealing with hundreds of
connections, and the initiator only a few.

Which is the best procedure?  Are there other ways to do this?
What is the recommended way, or is there a reason for the standard
not to recommend a triggering mechanism, in which case, could
the standard suggest methods or provide guidance, especially if there
are better, less obvious ways to do it?

+++

There are no better ways to do it. However we see this a purely an 
implementation matter.
I assume that a target low on resources will try to recover some and ping 
the initiators.

+++

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 5 Nov 2001 10:29:21 +0200

Dave,

It all depends on what assumptions you make about data buffering for 
unsolicited data.
If you assume (conservatively) that you will have enough buffers for all 
possible commands in flight and their unsolicited data
then ordering is not an issue.
If you assume - less conservative - that you have do not have room for all 
and account for the "flight time" to make up for some of the missing 
buffers and perhaps keep some of the data in the "TCP buffers" then 
allowing commands out of order might result in deadlock if the source and 
sink have different ordering.

As shipping commands out of order will hardly get you a real performance 
boost and keeping things in order might have
beneficial effects on the memory sizes required at target I thought that 
we should require ordering.

Regards,
Julo

Dave Sheehy <[email-masked]>
Sent by: [email-masked]
02-11-01 23:18
Please respond to Dave Sheehy

        To:     [email-masked] (IETF IP SAN Reflector)
        cc: 
        Subject:        Re: iSCSI: current UNH Plugfest

> order specified by CmdSN.

Why do you feel this behavior should be forbidden? Targets already have to
order commands across the session. I don't see why it's a problem to 
extend
that to the connection as well. I, for one, believe we should take a 
liberal
stance on this.

Dave Sheehy

---

From: "John Hufferd" <[email-masked]>
Date: Mon, 5 Nov 2001 01:19:04 -0800

Julian,
The TargetName Must be specified on the Initial Login of all non discovery
connections, not just the Leading Login.

.
.
.
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: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 11/05/2001 12:11:13 AM

To:   [email-masked]
cc:

Bob,

Comments in text.

Thanks,
Julo

        To:     [email-masked]
        cc:

Bob Russell
InterOperability Lab

++++

OK - Julo

++++

+++

+++

and section 3.18 says:

+++

+++