Re: [Fwd: comments on naming&discovery draft]

[julian_satran@il.ibm.com]

I am not sure.  There are some SCSI items in it too (SCSI handles now the
appearnce of new LUs).

I will need a longer discussion with NDT to understand the semantics.

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 12/03/2001 22:25:27

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  [Fwd: comments on naming&discovery draft]





Julian,

in case you skip this one..
your response is required on point (1) for amending iSCSI draft.

-sandeep

Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com
[135.104.2.10])     by aura.research.bell-labs.com (8.9.1/8.9.1) with SMTP
id KAA14926    for <sandeepj@aura.research.bell-labs.com>; Mon, 12 Mar 2001
10:59:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon
Mar 12 10:58:53 EST 2001
Received: from dogwood.cisco.com ([161.44.11.19]) by dusty; Mon Mar 12
10:58:52 EST 2001
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by
dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id
KAA17444; Mon, 12 Mar 2001 10:58:51 -0500 (EST)
Sender: mbakke@cisco.com
Message-ID: <3AACF243.9C30D52C@cisco.com>
Date: Mon, 12 Mar 2001 09:58:59 -0600
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Sandeep Joshi <sandeepj@research.bell-labs.com>
CC: ips@ece.cmu.edu
Subject: Re: comments on naming&discovery draft
References: <200103102223.RAA03513@aura.research.bell-labs.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii


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