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

["Julian Satran" <Julian_Satran@il.ibm.com>]

----- 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)" <marjorie_krueger@hp.com>         cc:        "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" <mallikarjun_chadalapaka@hp.com>         From:        Julian Satran/Haifa/IBM@IBMIL         Subject:        Re: iSCSI:Rules for processing keys and other doc organization commen        tsLink

Marjorie,

Some answers in text.

Thanks ,
Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com> 20-02-02 03:08

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        "CHADALAPAKA,MALLIKARJUN (HP-Roseville,ex1)" <mallikarjun_chadalapaka@hp.com>         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