Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03.txt

Alfred Hoenes wrote:
> I have submitted a revised version of our RFC 1995bis (IXRF) draft.

Regrettably, I haven't had time to respond to the previous versions of
the draft, but based on a quick review of the -03 version, I think it
still has problems.

In particular, Section 4 (Response Contents) specifies client behavior
where decisions are made based on an RR occurring alone in a message,
or multiple RRs occurring in the same message, which makes the
locations of the boundaries between messages significant.  For
example, the draft says:

>       An IXFR client that receives over connection-oriented transport
>       an IXFR response message (as the first response message related
>       to its IXFR query) that contains only a single SOA RR with sn_n
>       unequal to sn_o MUST discard the response message (see below).

and:

>   c.  The server serial (sn_n) differs from the client serial (sn_o)
>       sent in the Authority section of the IXFR query, and this SOA RR
>       is followed by another SOA RR in the same response message. 

The way I have always interpreted RFC 1995 is that the message
boundaries have no significance to the protocol, and that a server can
break up the ordered stream of RRs forming the IXFR response into
messages at arbitrary points without affecting client behavior.  This
interpretation seems consistent with AXFR, and with the following text
in the draft:

>   The conceptional "answer" carried in a multi-message response is the
>   concatenation of the content of the Answer sections in these response
>   messages, in the order they are sent

I don't think the current Section 4 accurately describes the behavior
of existing implementations (at least not the ones I am familiar
with), nor does it appear to be fully interoperable with those
implementations.  For example, existing servers will send a message of
the form described in the first quoted paragraph above when the second
RR in the transfer is too large to fit in the same message as the
initial SOA, and may conceivably also do it in other circumstances,
such as when that second RR exceeds the 16k compression limit.
Existing clients will accept such a response, but a client following
the draft will not.
-- 
Andreas Gustafsson, gson@araneus.fi
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext