Re: Comments on the current iSCSI draft

[Costa Sapuntzakis <csapuntz@cisco.com>]

Thank you for the excellent, detailed feedback. There are at least a
couple points where the iSCSI draft did not explain itself well.

> * The use of DNS addressing in the protocol as described in sections 3.13,
> Open Data Connection, and section 3.17, Third Party Copy, will force all
> parties to depend on DNS in order for the protocol to work. While system and
> network administrators should be free to make this choice (and invest the
> effort in making DNS suitably robust), this protocol design should NOT be
> based on the assumption that DNS is a robust highly available service.  The
> protocol should be based on IP addresses.

Parties who wish to use IP addresses for extra reliability may encode the
IP addresses in the target names (e.g. 10.0.4.5/dvd). After all, domain
names can represent IP addresses. These type of domain names do not
require DNS for resolution.

Also, domain name resolution will only be required in parties that act as
either initiators or application-level gateways/proxies. 

Domain name resolution does not necessarily imply DNS, though a directory
service like DNS is a compelling method of domain name resolution. UNIX
machines have also used the /etc/hosts file and YP/NIS for resolution.

On the plus side, domain names decouple the iSCSI protocol from the
underlying addressing architecture. The potential deployment of IPv6 will
not require any changes to the iSCSI protocol.

> * The parameter negotiation, described in sections 3.9-12, is very general.
> The free-form text/value format will cost code to parse and may not be
> justified.

An implementation can ignore all free-form text/value pairs
and still operate just fine. This needs to be clarified as a design
goal. The code impact should be minimal.

> * The expected data length and flags, i.e. command direction, should be
> described in the SCB itself and not as separate fields in the SCSI command,
> see section 3.3.

The motivation was that SCSI/PI and ATAPI bridges would not be required
to parse SCBs.

> * A standard CRC should be required, see section 6.1.

A CRC at the TCP layer or higher?
 
> * The target should not gets its name from the initiator, see section 10.1.

I think there's a misunderstanding here. This is used by to direct the TCP
connection to a specific target. We will clarify this in the draft.

> Questions
> --------
> * What value does the ability to do an iSCSI ping add to the existing
> ability to do an ICMP ECHO?  If little or none, this should be omitted, see
> section 3.15.

It makes sure the iSCSI device server is still alive and kicking.

-Costa