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

[Alfred Hönes <[e-mail]>]

Andreas,
thanks for your taking time so quickly now to look into the I-D.

Before entering into the details of later Sections,
I think we should establish a solid base.

So to start with there, my questions are:

Is the high-level description given in Section 2 ...
a)  logically correct (from your point of view) ?
b)  consistent with the terse text in RFC 1995 ?
c)  consistent observed on-the-wire format, and hence with
    implementations ?

If you disagree, please give the details.

But if that's correct, we have the problem that the established
response syntax unfortunately does not allow precise parsing
without knowledge of where the end of the response is.
Based on this insight, the draft tries to describe behavior
that depends on a minimum amount of timing/grouping requirements,
yet still allows "fast" determination of the response mode and
correct parsing of the IXFR response in all corner cases,
without having to rely on precious waiting time in order to
determine whether the last response packet received is indeed
the last response packet the server has sent.
IMO, unfortunately, not all response modes defined in RFC 1995
carry an implied "end tag" (sentinel SOA RR, as in AXFR).

So please allow me to defer going into the details below
until we have established consensus on the above basic points
as laid out in Section 2.
Once this has been done, the client's parsing behavior model
described in Section 4 can be discussed much more efficiently.

Kind regards,
  Alfred.


> 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, [e-mail]
>

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext