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

The following approval message was sent
From: The IESG
To: draft-sekar-dns-llq@ietf.org,
    Adrian Farrel ,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-sekar-dns-llq-06

The IESG has completed a review of draft-sekar-dns-llq-06 consistent with
RFC5742.

The IESG has no problem with the publication of 'Apple's DNS Long-Lived
Queries protocol'  as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
DNSSD, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-sekar-dns-llq/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-sekar-dns-llq/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

This document is indeed related to some work in DSNSD as it is the previous version of draft-ietf-dnssd-push. The links between those 2 documents are well documented.