IETF conflict review for draft-sekar-dns-llq
conflict-review-sekar-dns-llq-00

If this document is published as Informational now, what is the process
to move it to Historic at a later date, should that be desired?

Section 3.2

   RDATA Format:

   Field Name        Field Type     Description
   ---------------------------------------------------------------------
   OPTION-CODE       u_int16_t      LLQ
   OPTION-LENGTH     u_int16_t      Length of following fields, as
                                    appropriate
   VERSION           u_int16_t      Version of LLQ protocol implemented
   LLQ-OPCODE        u_int16_t      Identifies LLQ operation
   ERROR-CODE        u_int16_t      Identifies LLQ errors
   LLQ-ID            u_int64_t      Identifier for an LLQ
   LEASE-LIFE        u_int32_t      Requested or granted life of LLQ, in
                                    seconds

   This data format, consisting of (OPTION-CODE, OPTION-LEN,
   LLQ-Metadata) tuples, may be repeated an arbitrary number of times in
   the RDATA section, with the RDLEN field set accordingly.

nit: s/OPTION-LEN/OPTION-LENGTH/ for consistency.
Also, if these are all fixed-length fields, isn't OPTION-LENGTH a
constant?

Section 5.2.1

   A client MUST NOT request multiple identical LLQs (i.e., containing
   the same qname/type/class) from a single source IP address and port.
   This requirement is to avoid unnecessary load on servers.

I'm not sure if this is the client's source address used to make the
request, or the server it's asking for a subscription from.

Section 5.3

   The client MUST NOT cache answers after the LLQs LEASE-LIFE expires
   without being refreshed (see Section 7 "LLQ Lease-Life Expiration").

Given all the discussion around serve-stale, it seems that there may be
times where the least bad option is to continue to cache answers in
violation of this MUST NOT, but I can understand not wanting to take a
position on that here.

As Alvaro mentioned, I was also thinking about reflecting Apple's involvement in the title...