iSCSI-boot: comments

["Mallikarjun C." <cbm@rose.hp.com>]

Attached are some comments on the iSCSI boot draft, rev05.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


>1. Requirements
>
>   1. There must be no restriction of network topology between the iSCSI
>   boot client and the boot server. 

Need to add "other than those in effect for establishing the iSCSI session."

....

>   2. The following represents the minimum information required for an
>   iSCSI boot client to contact an iSCSI boot server: (a) the client's
>   IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery
>   Port Name; 

Suggest an "iSCSI Target Port Name" in place of "Service Delivery Port Name"
- same comment for all places in this document wher SDP is used.  SAM-2
no longer uses the term....

Also, I'd think the iSCSI target portal address is required, unless 
discovery is being presumed before boot...

.....

>
>   Additional information may be required at each stage of the boot
>   process.
>
>   3. It is possible for the iSCSI boot client to have none of the above
>   information or capability on starting.
>
>   4. The client should be able to complete boot without user
>   intervention (for boots that occur during an unattended power-up).
>   However, there should be a mechanism for the user to input values so
>   as to bypass stages of the boot protocol.
>
>   5. Additional protocol software (for example, DHCP) may be necessary
>   if the minimum information required for an iSCSI session is not
>   provided.

#3 and #5 above don't sound like requirements to me - particularly #3.

.....
>4. DHCP stage
>
>   In order to use an iSCSI boot server, the following pieces of
>   information are required.

for an iSCSI boot client? [ if this is true, the following bullet 
may be reworded as "its own IP address"....]

>
>   - The IP address of the iSCSI boot client (IPv4 or IPv6)
>
>   - The IP transport endpoint for the iSCSI service delivery port for
>   the iSCSI boot server.  If the transport is TCP, for example, this
>   has to resolve to an IP address and a TCP port number.

It is useful to note that iSCSI currently is defined only for TCP.

>
>   - The eight-byte LUN structure identifying the device within the

I wouldn't use "device" at all here - it is a "Logical Unit" per SAM-2.

>   iSCSI boot server.

It appears to me that all the above information is realized *after*
using the "DHCP stage".  It would be useful to state this, particularly
when presented at the beginning of the section as the "required information".

.....

>   Unless otherwise specified here, DHCP fields such as the client ID
>   and gateway information are used identically with applications other
>   than iSCSI.

S/b "identically with applications other than iSCSI."
W/  "in an identical way as applications other than iSCSI do."

>
....
>   The fields "servername", "port", "protocol" and "LUN" are optional
>   and should be left blank if there are no corresponding values. The
>   "targetname" field is not optional and must be provided.
>
>   Thv "servername" is the name of iSCSI server and contains either a

Typo above - "Thv".

.....

>   The "LUN" field is a 16 byte hexadecimal representation of the 8-byte

16-nibble?  I'd actually prefer "8 byte".

>   LU number in hex. Digits above 9 may be either lower or upper case,
>   and all 16 nibbles must be present. If the LUN field is blank, then
>   LUN 0 is assumed.
>
>   Note that SCSI targets are allowed to present different LU numberings
>   for different SCSI initiators, so that to our knowledge nothing
>   precludes a SCSI target from exporting several different devices to

S/b "device" W/ "LU"

>   several different SCSI initiators as their respective LU 0s.

S/b "LU" W/ "LUN".

>
>   The "targetname" field is an iSCSI Name that is defined by the naming
>   and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to
>   uniquely identify an iSCSI target.  The use of the targetname
>   component is also defined by the iSCSI standard[4] and is to be used
>   accordingly.

Given that iSCSI now assumed all normative N&D text, I would suggest 
getting rid of the reference to N&D for normative definitions here.

.....
>
>5. Discovery Service stage:

Remove ":"

A general comment on this Stage - the LBA offset within the LUN
(where the boot image starts) could also be discovered by a boot 
client via the service attributes in the SLP Service Advertisement.  
This is perhaps one more reason for employing Discovery Service stage.

BTW, all stages should either be titled "Stage" or "stage".  I see
both now.

>
>   This stage is required if the DHCP server (v4 or v6) is unaware of
>   the Service Delivery Port Name of the iSCSI boot server.  The
>   implemention of the discovery service is to based on the SLP

Remove "to".

>   protocol[1,24].
>
>   The iSCSI boot client may have obtained the targetname of the iSCSI
>   boot server in the DHCP stage (Section 4). In that case, the iSCSI
>   boot client queries the Discovery Service using query string 1 as

Need to define "Discovery Service" before using it ( = "discovery service"
= "an instantiation of SLP DA"?).

>   specified in the iSCSI SLP interaction document[24] to resolve the
>   targetname to an IP address and port number. One this is obtained,

S/b "One" W/ "Once"

A reading of the iscsi-slp draft doesn't lead me to believe that
this translation is necessarily maintained by the DA.  I am not
sure why can't the regular DNS be used here.

Also, a search of the iscsi-slp draft doesn't yield any pointers
to what "query string 1" (or 4) is....

......

>
>   client may contact any iSCSI boot server in the list. Moreover, the
>   the order in which iSCSI boot servers are contacted is also left to

S/b "the order" W/ "order".

>   the discretion of the implementor.
>
>6. Boot Stage
>
....

>
>   However, the use of a discovery session is not recommended because at

The iSCSI discovery session *cannot* be used if any read commands 
are to be performed.

>   this stage (i) a boot server has probably been found and (ii) the

"probably" ?  I presume a boot client would not proceed to Boot Stage
unles a boot server had been found. 

.....

>References
.....
>
>
>   [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm

This URL is broken.  Also, Intel now calls the enhanced PXE as
Boot Integrity Services (BIS).