Subject: Re: iSCSI:Rules for processing keys and other doc organization commen ts

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Feb 2002 12:54:42 +0200

----- Forwarded by Julian Satran/Haifa/IBM on 22-02-02 12:48 -----

Julian Satran
20-02-02 09:55

        To:     "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
        cc:     "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" 
<[email-masked]>
        From:   Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI:Rules for processing keys and other doc organization commen   ts

Marjorie,

Some answers in text.

Thanks ,
Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
20-02-02 03:08

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" 
<[email-masked]>
        Subject:        iSCSI:Rules for processing keys and other doc organization commen       ts

Julian,

I've been trying to figure out which negotiable parameters should be
included in the iSCSI MIB, and in the process of trying to figure this 
out,
I've discovered some omissions in the document, and have some suggestions
regarding the organization/content of certain sections in the document.

The easiest comment to fix:  You've changed the description of the text 
keys
in Sec. 12 and added some information for these keys (use, sender, scope).
That format is not reflected in the other sections that contain key
specifications (Appendix A.3, section 11 - security keys and values)

+++ I will try to align them +++

Another easy fix: Section 11 - the very first paragraph has a spelling
error, SecurityNegotiation is spelled "SecurityNegotiatian"

+++ will fix+++

I'm puzzled by the change in size of certain text key values from 2**16-1 
to
2**24-1  Why are these 24 bit integers rather than 32 bit integers?  I.E,
DataPDULength used to be 2**15-1, now changed to MaxRecvPDULength with 
size
of 2**24-1, which seems like an odd maximum size?

+++ When we had them in the mode pages we where limited to 16 bit 
counters. To express larger values we used a unit of 512byte. Now that we 
don't have mode pages we use byte as a unit and reverted to the limits 
dictated by the PDU format +++

In general, I feel that section 2 has several subsections that have 
outgrown
the main section title of "Overview" - sections containing implementation
details should be moved out of the "Overview" heading into 
A)their own sections 
B)the appropriate detail section heading.

+++ will do that +++

I had a very difficult time determining which keys are "mandatory to
recognize" and in the process of trying to figure that out, discovered 
that
there are very specific details of key processing buried in the "Overview"
section.  I believe that the level of detail specified in section 2.2.4
belongs in section 4 Login, or section 12.

+++ will see what I can do +++

There has been much confusion over the processing of keys - I believe it's
due in part to the fact that the details necessary to process keys reside 
in
7 different sections.  I like your separation of "Overview" from detail
sections, but I would at least like to find all the "details" under the 
same
major section heading, with a single sub-section that cross-references the
sections necessary to frame the key processing picture :-)

I've thought about how this might be fixed, and have the following
suggestion:

Title section 4 "Login and Text Mode Negotiation"
Move current section 4 under this section (4.1)
Move current Section 5 under this new section 4 (4.2) and Title it "Text
Mode Negotiation"
Move the details in Section 2.2.4 to this section.  These details apply to
both Login Negotiations and Text Negotiations, perhaps they can be the
generic comment under the new section 4

+++ will consider - not a bad idea +++

I would also suggest adding a paragraph with the 2.2.4 text specifying 
that
all text keys in sections ??? MUST be recognized, and therefore MUST NOT 
be
answered with "NotUnderstood".  I know that can be inferred by knowing the
details of the whole document, but the poor parser implementor shouldn't
have to read the whole document in detail.

+++ I think it is said - but I will double check +++

Comments?

Regards,
Marjorie