Draft: draft-ietf-crisp-iris-lwz-06 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Friday 8/25/2006 4:05 PM CST IETF LC Date: 8/28/2006 Summary: this draft has some areas that need work before it can be approved as a proposed standard. Questions below are tagged as "Spencer:". The most serious are in Section 3, on the UDP packet format, and in Section 4, on automated processes using this transport at line speed. I have a couple of Spencer/Editorial comments below that aren't part of the Gen-ART review, but I'm sending them so you'll know about them, too. Please look at these comments along with any other Last Call comments you may receive. Before I start - this draft has gotten a fair amount of Last Call traffic, so I'll try to limit my review to new comments. But I did want to mention two areas that are important enough for me to say, "me, too". I'm including the discussion of the need for some words that apply to congestion awareness by reference to http://www1.ietf.org/mail-archive/web/ietf/current/msg43204.html and related messages, which I agree with, but the author has already seen as last call comments. I'm including the discussion of the need for some additional words about security considerations by reference to http://www1.ietf.org/mail-archive/web/ietf/current/msg43191.html and related messages, which I agree with, but the author has already seen as last call comments. Now, on to the show... 1. Introduction Using S-NAPTR [4], IRIS has the ability to define the use of multiple Spencer/Editorial - please expand S-NAPTR on first use. application transports or transfer protocols for different types of registry services, all at the descretion of the server operator. The UDP transfer protocol defined in this document is completely modular and may be used by any registry types. Spencer - it was not clear to me precisely what you meant by "modular". Just "independent of registry types", or something more? 3. Packet Format The UDP packet format for IRIS-LWZ is as follows: +------+------+----------+--------+------------+---------+ field | src | dest | checksum | UDP | payload | payload | | port | port | | length | descriptor | | +------+------+----------+--------+------------+---------+ octets 2 2 2 2 3 or 6..261* 0..n Spencer: Ummm, MY copy of RFC 768 shows 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... Spencer: so it looks like UDP length and checksum seem to be flipped in this specification... 3.1.1. Payload Request Descriptor transaction ID - a 16 bit value identifying the transaction. This value will be returned in the payload response descriptor (Section 3.1.2) and can be used by clients to match requests with responses. Clients SHOULD pick the value randomly and SHOULD NOT use sequences of 16 bit values. Clients MUST NOT set all the bits in this value to 1 (i.e. use a value of 0xFFFF). Spencer: it's not clear to me why "clients picking random values" would be a SHOULD/SHOULD NOT instead of a MUST/MUST NOT, but I'm wondering if this isn't part of the larger "if you're going to send off hundreds of requests back to back - enough that "guessing" attacks will be a problem - you should probably be using BEEP/TCP anyway" discussion. If your point is that "random" is a funny word if you only send one request every week, that's OK, I guess, but I prefer to see guidance on why it's OK to violate a SHOULD. maximum response length - the total length of the UDP packet (i.e. UDP header length + payload descriptor length + XML payload length) that should not be exceeded when responding to this Spencer: "should not" isn't even capitalized here. I'm kind of missing the point (even if the protocol does require the server to pay attention to this limit, the client has to defend against overruns anyway - and if so, why clutter up the protocol?), but assuming there's a reason, why is this not MUST NOT? request. If the server cannot provide a response that is equal to or less than this value, then it MUST respond with size information (Section 3.1.6). 3.1.2. Payload Response Descriptor The purpose of the transaction ID is to allow clients to match requests to responses. A value of 0xFFFF is reserved for server use. The value of the transaction ID is as follows: 1. If the transaction ID in the corresponding request could not be read due to truncation, servers MUST use a transaction ID with Spencer: OK, I'm lost. This is a UDP protocol, so no streaming/realignment going on, so the transaction ID was maybe 11 bytes into the payload, and it got truncated? (Which one of us is confused?) all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor error (see Section 3.1.7). 3.1.3. Payload Header bit 4 - deflate supported ('DS' flag) - If 1, the sender of this packet supports compression using the DEFLATE algorithm. When this bit is 0 in a request, the payload of the response MUST NOT be compressed with DEFLATE. Spencer: I'm trying to visualize why DEFLATE is not mandatory-to-implement - the XML data structures you're moving around aren't small, and they are ascii text which tends to compress at about 4:1 in my experience. The spec doesn't explicitly call out "fallback to TCP", as DNS does, but it does say "send the request with another transfer protocol" in Section 4, and I'd expect that to happen in practice, and to happen more frequently when the server doesn't implement DEFLATE. 4. Interactions 3. If a request can be compressed to a size less than or equal to 4000 octets, send the request using compression. Otherwise use another transfer protocol. 4. If a request yields a size error, send the request with another transfer protocol. Spencer: in 3 and 4 - "send the request with a streaming transfer protocol", perhaps? Spencer: I wish there was some statement about automated processes not firing off lots of UDP-transport requests at wire rate - that would make me feel better if you don't go off to do exponential backoff, etc. Even if it was just "if a request does not generate a response, switch to a congestion-aware transport protocol?" 8. Security Considerations IRIS-LWZ is intended for serving public data; it provides no in-band mechanisms for authentication or encryption. Any application with this need must provide out of band mechanisms to provide it (e.g., IPSec), or use the IRIS transfer protocols that provides such capabilities. Spencer/Editorial: "protocols that provide" (no "s")