Subject: iSCSI Boot Last Call - Technical Comments

From: Mark Bakke <[email-masked]>
Date: Tue, 10 Sep 2002 08:49:16 -0500

I have only a few technical comments on the boot draft.  The editorials
have been sent to the authors.  The draft looks good!

Page 4

>    The "LUN" field is a hexadecimal representation of the 8-byte LU
>    number.  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.

Since most LUNs are just 16 bits (and many of these are even smaller),
I'd like to relax this a bit.  Typing 14 or 15 zeroes plus the actual
LUN value into a field in the DHCP GUI is quite error-prone, since in
a DHCP server's user interface or /etc/dhcpd.conf, this string will be
entered directly by the end user.

So in addition to the rules above, how about:

- If the LUN field contains four or fewer hex digits, these digits
  constitute the LUN number from which to boot.

Page 5

>    It is possible that the port number obtained from the Discovery
>    Service may conflict with the one obtained from the DHCP service. In
>    such a case, the implementor has the option to try both port numbers
>    in the Boot stage.

In this case, I think that we should pick one to take precedence, instead
of leaving it up to the implementor.  Since the discovery service should
have the most up-to-date IP address and port number information, I think
that it should be the one that is used.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Jim Hafner <[email-masked]>
Date: Tue, 10 Sep 2002 07:59:04 -0700

Mark,

I would rather not go the route your going with the LUN number issue. GUIs 
can always do the translation to more nibbles under the covers.  Besides, 
if you have a LUN that has only 16bits or less of significant (i.e., 
nonzero) digits, you'll need to carefully specify where these digits go in 
the 8 byte defined SCSI LUN and that depends on the LUN number convention 
of the target.   So, to avoid that can of worms and the extra descriptions 
required, I'd suggest leaving this as an 8byte (16 hex nibble) field.

On the other point, I have no opinion.

Jim Hafner

Sent by:        [email-masked]
To:     Prasenjit Sarkar <[email-masked]>, Duncan Missimer 
<[email-masked]>, Costa Sapuntzakis <[email-masked]>, 
Elizabeth Rodriguez <[email-masked]>, David Black 
<[email-masked]>, John Hufferd/San Jose/IBM@IBMUS, IPS 
<[email-masked]>
cc: 
Subject:        iSCSI Boot Last Call - Technical Comments

Page 4

Page 5

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Tue, 10 Sep 2002 17:41:18 -0600

Assuming that the requirement for all 16 bits to be present is not changed, the current text is logically contradictory. "...all 16 nibbles must be present. If the LUN field is blank,..." If the LUN field is blank all 16 nibbles are not present. I suggest "...upper case. If the LUN field is not blank, all 16 nibbles must be present."

Pat
-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Tuesday, September 10, 2002 6:49 AM
To: Prasenjit Sarkar; Duncan Missimer; Costa Sapuntzakis; Elizabeth
Rodriguez; David Black; John Hufferd; IPS
Subject: iSCSI Boot Last Call - Technical Comments

Page 4

Page 5

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Wed, 11 Sep 2002 16:39:10 -0600

Mark,

The sentence at the beginning of 5: "This stage is required if the DHCP server (v4 or v6) is unaware of the iSCSI Target Port Name of the iSCSI boot server." is incorrect even if one changes iSCSI Target Port Name to iSCSI Target Name. 

If the DHCP server supplies an iSCSI Target Port Name, then the booting device still needs to use the Discovery stage to convert that name into an address. The only cases where Discovery stage could be skipped is when the DHCP server supplies a servername or where the boot target address is configured into the boot client. The servername doesn't require discovery stage because it is either an IP address or a domain name that the DNS server can convert ot an IP address.

Pat

-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 3:34 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: iSCSI Boot Last Call - Technical Comments

Pat,

On #5, I think that this should say "iSCSI Target Name"; as you said,
portal groups are not necessary for boot.

Mark

[email-masked] wrote:
> 
> Technical
> 
> 4. last two paragraphs:
>    "If the "servername" field is provided by DHCP, then that field is
>    used in conjunction with other associated fields to contact the boot
>    server in the Boot stage (Section 6).
> 
>    However, if the "servername" field is not provided, then the
>    "targetname" field is then used in the Discovery Service stage
>    (Section 5)."
> 
> Shouldn't the second paragraph say "is used in conjunction with the other associated fields"? "targetname" doesn't provide the LUN or protocol. The "port" field is may be relevant because the Target address needs to be fetched and will include port if necessary.
> 
> 5. first paragraph "if the DHCP server ... is unaware of the iSCSI Target Port Name" What does Target port name (defined as iSCSI Target Name together with a label that idenifies it as a target port name and the portal group tag) have to do with this? The DHCP server string definition doesn't include a Target port
 name and even if it did, the discovery service stage would be necessary to convert that into an
address. The discovery service stage is required if the DHCP server provided a target name because
it converts target name to an IP address and port number. It is also required if the DHCP server
didn't provide an iSCSI string.
> 
> Reference [17]: Can a URL be used as a reference? Intel could change the structure of their website and the URL would no longer locate the document. It would be better to reference a document title.
> 
> Editorial
> 
> 4. 5 paragraphs from the end, "several different LU" should be "several different LUs"
> 
> 4. 3 paragraphs from the end, except for the sentence "If the "servername" field is blank ....", all the other statements about defaults are duplicates of statements in the paragraphs where the fields were defined. Moving the statement about servername to the servername paragraphs above and deleting this paragraph.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054