Re: comments on naming&discovery draft

[Mark Bakke <mbakke@cisco.com>]

Sandeep-

The problem you pointed out in item number 1 creates the need
for an additional iSCSI-level event.  Since the discovery of
targets happens at the iSCSI level, rather than at the SCSI
level, how about adding this to 2.18.1 (in iSCSI-05)?

  4   Network entity indicates that a "target discovery" event
      has occurred.

Upon receiving this message, the initiator should use SendTargets,
or whatever other methods of discovery it is using, to find out
what has changed.  Usually, this would be due to adding a new
target.

We will fix items 2-4; thanks for pointing them out.

Thanks,

Mark

Sandeep Joshi wrote:
> 
> 1) Section 4.2 last line before Section 4.2.1
>     "target MUST send any iSCSI-level async on this session,
>      allowing the initiator to discover new targets.."
> 
>    The session mentioned here is a session to the canonical target.
> 
>    However, the iSCSI 05 draft does not mention any such condition
>    in Sec 2.18 on Async Message.   In there, a SCSI event (note: not
>    iSCSI) is used to notify availability of new targets.
> 
> 2) Appendix C, Section 5 "Stateful Inspection Firewall"
>    It contains statements of the sort "I dont expect/think.."
>    These statements could be rephrased to be impersonal.

I will fix these.

> 3) Section 4.3 Middle of page 17 (After reference to RFC 2608)
>    -> "A target can register either its canonical target, ..."
> 
>    Multiple references to term "target" is confusing.  It can be
>    changed to refer to the term "Network entity" introduced earlier
>    in the document.
>    -> "A network entity can register its canonical target,.."

I will fix this as well.

> 4) Sec 4.2 SendTargets Command
>    The status code 0x42 mentioned is now 0x02 in iSCSI document.
>    A similar mismatch exists in some codes listed in B.4.5.
> 
>    It might help to just use error names and not numbers to avoid
>    this problem.  [readers can do error code "discovery"! ]

Good idea; we will fix this, too.

> -Sandeep

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054