Subject: [Gen-art] Gen-ART LC review of draft-ietf-crisp-iris-lwz-06

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 25 Aug 2006 16:04:55 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art