I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
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.
Thanks,
Spencer Dawkins
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?" <insert canonical "implementing TCP
state machine into UDP-based application state machine" rant, which I did
not originate and others can deliver more effectively>
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")
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
