|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Comments on draft 07-97Steve, Sorry for the delay. Comments in text. Thanks, Julo
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 -----
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 |