Subject: Re: Protocol Action: iSCSI to Proposed Standard

From: Bob Braden <[email-masked]>
Date: Tue, 11 Feb 2003 23:48:12 GMT

*> 
  *> The IESG has approved publishing the following Internet-Draft
  *> as a Proposed Standard:
  *> 
  *> o iSCSI <draft-ietf-ips-iscsi-20.txt>
  *> 
  *> This document is the product of the IP Storage Working Group.
  *> 
  *> The IESG contact persons are Allison Mankin and Scott Bradner.
  *> 
  *>  
  *> Technical Summary
  *>  
  *>  The Small Computer Systems Interface (SCSI) is a family of
  *>  protocols for communicating with I/O devices, especially storage
  *>  devices. SCSI is a client-server architecture. The SCSI protocol
  *>  has been mapped over various transports, including Parallel SCSI,

Transports?

The Webster's New Collegiate Dictionary defines the noun "transport" as
"strong and often intensely pleasurable emotion".  ;-)

All the Internet documentation with which I am familiar, as well as the
OSI reference model, define a "transport layer", but I don't think you
are suggesting SCSI over IP, etc.

Can't we please resist terminology pollution?  In the IETF we call these
[data] link layers.

Bob Braden

  *>  IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are
  *>  I/O specific and have limited distance capabilities. The iSCSI
  *>  protocol defined in draft-ietf-ips-iscsi describes a means of
  *>  transporting of the SCSI packets over TCP/IP, providing for an
  *>  interoperable solution which can take advantage of existing
  *>  Internet infrastructure, Internet management facilities and
  *>  address distance limitations. Mapping over TCP ensures that the
  *>  high volume storage transfers use congestion control.
  *> 
  *>

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Feb 2003 17:17:37 -0500

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 >> All the Internet documentation with which I am familiar, as well
 Mallikarjun> I think we have a case of overlapping vocabulary from
 Mallikarjun> two different domains.

 Mallikarjun> Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is
 Mallikarjun> very clearly a "SCSI transport protocol" (as opposed to
 Mallikarjun> a SCSI application layer protocol).  Parallel SCSI,
 Mallikarjun> Fibre Channel etc. are all "SCSI transports" per SCSI
 Mallikarjun> conventions.  That is all the critiqued abstract is
 Mallikarjun> trying to describe.

Agreed.

Furthermore, certainly Fibre Channel provides a transport layer in the
OSI sense.  It also provides lower layers, but it certainly is a lot
more than a data link layer.

    paul

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 12 Feb 2003 10:24:09 -0800

> All the Internet documentation with which I am familiar, as well as the

I think we have a case of overlapping vocabulary from two different domains.

Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is very clearly
a "SCSI transport protocol" (as opposed to a SCSI application layer protocol).
Parallel SCSI, Fibre Channel etc. are all "SCSI transports" per SCSI conventions.
That is all the critiqued abstract is trying to describe.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 12 Feb 2003 15:51:47 +0200

Dear Mr. Braden,

iSCSI is in fact SCSI over TCP.   As for the noun - the attached is 
Webster-Collegiate page for transport.
You choose to refer to the definition #9 . English is a richer language 
than my Hebrew - we choose
definitions 4 or 5 that seem to fit.

Respectfully yours,
Julo

Bob Braden <[email-masked]> 
Sent by: [email-masked]
12/02/03 01:48

To
[email-masked], [email-masked]
cc
[email-masked], [email-masked]
Subject
Re: Protocol Action: iSCSI to Proposed Standard

  *> 

Transports?

Bob Braden

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Feb 2003 11:26:06 -0500

On Wednesday, Feb 12, 2003, at 13:24 America/Montreal, Mallikarjun C. 

> That is all the critiqued abstract is trying to describe.

In the context of an *Internet* RFC, it seems sensible to use the normal
Internet terminology -- unless one very very clearly indicates that a
term is being used in some different semantic.  One might postulate that
the document's editors and RFC-Editor could work out a mutually 
agreeable
editorial change here to add clarity.

Ran

---

From: Loa Andersson <[email-masked]>
Date: Fri, 14 Feb 2003 08:43:26 +0100

Ran,

would agree to this, and put even stronger

"... Internet RFCs the normal Inernet terminology SHOULD be used, unless 
there
are very stong and explicitly stated reasons not to ..."

it should als  be that the I* have a guiding role in this

/Loa

RJ Atkinson wrote:

> the document's editors and RFC-Editor could work out a mutually agreeable

---

From: Andre Hedrick <[email-masked]>
Date: Sat, 15 Feb 2003 01:00:53 -0800 (PST)

This would not logically include ignoring the rule about everything put to
the wire must be "BIG ENDIAN"?  Obviously everyone knows to ignore this
ruleset when dealing with CRC32C; however, if you are a "BIG ENDIAN" box
you must conform to make your CRC32C put on the wire in "LITTLE ENDIAN".

Of course this is me being picky about following the rules.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

---

From: [email-masked]
Date: Wed, 19 Feb 2003 12:38:11 +0000 (UTC)

> Of course this is me being picky about following the rules.

Funny you would mention that. The CRC32C actually DOES go out in a
Big-Endian manner, in terms of the CRC polinomial powers. It is just that
the polinomial powers have bit 7 (2^0) as being more significant than bit
0 (2^7).

Take care,

Bill