Re: iSCSI: Comments on draft 07-97

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

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