[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

    • To:
    • Subject: Re: iSCSI:Rules for processing keys and other doc organization commen ts
    • From: "Julian Satran" <>
    • Date: Fri, 22 Feb 2002 12:54:42 +0200
    • Content-Type: multipart/alternative; boundary="=_alternative 003B6641C2256B68_="
    • Importance: Low
    • Sender:

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


    Some answers in text.

    Thanks ,

    "KRUEGER,MARJORIE (HP-Roseville,ex1)" <>

    20-02-02 03:08

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



    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

    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 +++




Last updated: Fri Feb 22 11:17:59 2002
8846 messages in chronological order