SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Comments on draft 07-97




    Steve,

    Sorry for the delay.

    Comments in text.

    Thanks, Julo


    Steve Senum <ssenum@cisco.com>

    28-09-01 18:20
    Please respond to Steve Senum

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        
            Subject:        iSCSI: Comments on draft 07-97

           


    Julian,

    My apologies if you already received this,
    but I never saw a reply, and I think most
    of these comments still apply to 07-99.

    Regards,
    Steve Senum

    ----- Message from Steve Senum <ssenum@cisco.com> on Mon, 24 Sep 2001 12:15:13 -0500 -----
    To: ietf-ips <ips@ece.cmu.edu>
    Subject: iSCSI: Comments on draft 07-97

    Hi Julian,

    Some comments on the draft-ietf-ips-iSCSI-07-97.txt.

    In section 3.10.4:

        3.10.4 Text
           
           The initiator sends the target a set of key=value or key=list pairs
           encoded in UTF-8 Unicode. All the text keys and text values specified
           in this document are to be presented and interpreted in the case they
           appear in this document (they are case sensitive). The key and value
           are separated by a '=' (0x3d) delimiter. Every key=value pair
           (including the last or only pair) MUST be followed by exactly one
           null (0x00) delimiter.  A list is a set of values separated by comma
           (0x2c). Binary items can be encoded using their hexadecimal
           representation (e.g., 8190 is 0x1ffe) or decimal representation. If
           not specified otherwise the maximum length of an individual value
           (not its string representation) is 255 bytes not including the
           delimiter (comma or null).  Large binary items can be encoded using
           the Base64 encoding as specified by [RFC1521] preceded by the 0b.  
           Key names MUST NOT exceed 63 bytes.
           
           The data lengths of a text request or response MUST NOT exceed 4096
           bytes.  
           
           Character strings are represented as plain text. Numeric and binary
           values are represented using decimal numbers, the hexadecimal 0xffff
           encoding or the Base64 encoding. Upper and lower case letters may be
           used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC
           and 0x1ABC are equivalent).  
           

    1. The third paragraph overlaps with the first. I would suggest moving
    all discussion on encodings to a seperate paragraph.
    +++ I am cleaning up a bit the text. More editing will come in 09 +++


    2. Why RFC 1521?  Is was obsoleted by RFC 2045.
    +++ I've fixed that +++


    3. Could you define a "large binary item"?  A value larger than
    32 bits?  Larger than can fit as hexadecimal in 255 characters,
    including the 0x prefix?


    +++ I think we can leave that to the implementer.  The intent is to let them encode whatever they want with any of the 3 methods +++

    4. Can any key use the base64, or only those that specify it?
    If a key specifies it, can it also use decimal and hexadecimal
    encodings?


    +++ any numeric/binary value can be encoded anyhow. I will remove the specific references to make this more obvious +++


    5. You might want to mention something about numbers prefixed
    with '0' being decimal (i.e., 011 is 11 (base 10), not 9 (base 8)),
    since we are sort of following the C language integer number
    conventions.
    +++ I will ++
    6. I don't undertand the "(not its string representation)" clause?
    Does this mean something like ("not its unicode character count")?
    Or say something like:

           If not specified otherwise the maximum length of an
           individual encoded value is 255 bytes not including the
                      ^^^^^^^
           delimiter (comma or null).
    +++ I will say "not its encoded representation"  +++
    7. In the following paragraph:


           Manufacturers may introduce new keys by prefixing them with X-
           followed by their (reversed) domain name, for example the company
           owning the domain acme.com can issue:  
           
              X-com.acme.bar.foo.do_something=0000000000000003

    Why all the zeros?  I would expect something like:

              X-com.acme.bar.foo.do_something=3
    +++ good point will fix +++
    8. Appendix A has:

           [Kerberos]
           KRB_AP_REQ, KRB_AP_REP encoded as base64 strings.

           [Public Key]        
           All the SPKM-* tokens are encoded as base64 strings and their binary
           length (not the encoded length) MUST not exceed 2048 bytes.

           [SRP]
           Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945].
           U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers.

           [CHAP]
           N is a text string, A,A1,A2,I are numbers and C,R are
           large binaries encoded as hexadecimal strings.

    Why are SRP values all defined as numbers?  From my (perhaps wrong)
    understanding of SRP, N, A and B can quite large, like 2048 bits
    or 256 bytes. I would think these should be encoded (always) as base64.
    Also, I belive M and H(...) are 160 bits, and s can go larger than
    32 bits, perhaps they should always be encoded as hexadecimal strings?

    +++ encoding is left to the implementor +++
    Regards,
    Steve Senum





Home

Last updated: Sat Sep 29 06:17:23 2001
6858 messages in chronological order