Re: [dnsext] Review of draft-ietf-dnsext-rfc1995bis-ixfr-00.txt (from Knot DNS team)

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

Lubos,
thanks for your quick review of draft-ietf-dnsext-rfc1995bis-ixfr-00,
which has been forwarded to the mailing list by Ondrej Sury
on 29 Mar 2012, 17:50:52 +0200 (message archived at
  http://www.ietf.org/mail-archive/web/dnsext/current/msg12399.html ).

Inline below I note the actions taken so far on your suggestions,
in my working copy of the draft.  The next draft revision is planned
to be submitted within a week from now.

> Hi,
>
> I got our head engineer of Knot DNS (Lubos Slovak he's in Cc:), who also
> implementor IXFR (from scratch) to review the document and here's the
> result (copying verbatim, just added references to sections and 'nit'
> words):
>
> 1) section 1.4 - nit: "makes freely use" -> s/freely/free

It actually was intended to say: "freely makes use of ...",
and that's what the draft now says.

>
> 2) Section 2, page 8 - nit: "Therefore, is becomes apparent" -> s/is/it

Fixed.

>
> 3) Section 2, last paragraph - why has to RRSIG(SOA) [to] follow
>    the SOA in the AXFR-fallback example?

Actually, there's no "MUST" requirement, but it is good practice
in AXFR implementations to group RRsets together in AXFR responses,
and, according to the base DNSSEC specs, the RRSIG(SOA) conceptionally
is part of the SOA RRset (except in the context of a query for RRSIG,
which does not apply here).  However, server implementations have
found it convenient to send RRsets as contiguous groups within AXFR
responses (because of the manner they are stored, for grouped
inclusion in ordinary DNS responses); similarly, for clients that
choose to perform detailed plausibility checks of received zone
content before serving a new version of the zone data, checking of
consistency likely will comprise a check for equality of TTL values
within RRsets (Section 5.2 of RFC 2181), and maybe even RRSIG
verification, it is beneficial to receive the RRs of RRsets grouped
together (so that common DRAM cache replacement algorithms make it
much more likely to find the related RRs in the most high-speed
memeory comonents present in the system, and hence processing will
be much faster).  Since IXFR is all about speed and optimization
of the zone synchronization process, such server behavior is very
desirable in IXFR implementations as well.

Taking this into account, I have tentatively modified the draft
text to now say:

  "In contrast, in the case of fallback to AXFR, the IXFR response
   would typically convey, in order:"
        ^^^^^^^^^^^

But if implementers do strongly prefer to have IXFR clients find
RRsets grouped together, or at leaest to have the RRSIG(SOA) RRs
always be placed at the beginning (in the case of IXFR fallback
to AXFR), we could make the RR order shown in the draft mandatory
(SHOULD or MUST) for IXFR servers.

Opinions from other implementers?

>
> 4) Section 6.2 - missing RFC2119 language; shoulds and mays are small
>    caps, is that intentional?

The server's purging behavior is difficult to test externally.
It is strongly recommended to use RFC 2119 terms sparingly and
only in cases where the behavior is needed for interoperability
and can be tested by observing externally visible behavior.

The mandatory rules on "fallback to AXFR" IMO are sufficient to
ensure interoperability, and IXFR-ONLY is dedicated to address
efficiency issues that plague deployments in specific circumstances,
so the details of IXFR server purging behavior seem to be local to
implementations, subject to implementation-specific resource
management strategies and resource restrictions, and hence out of
the bailiwick of RFC 2119.  ( :-) )

However, if the WG feels strong about having more detailed, yet
testable, requirements regarding the purging and condensation
strategy of IXFR servers (Sections 6.2 and 6.3 of the I-D),
the draft of course can be modified accordingly.


>
> 5) And today new question have arrised:
>    "What should IXFR client do if it receives incomplete
>    multichunked IXFR response?"
>    A) discard whole transfer and start over;
>    B) save usable chunks (e.g. use data to update zone from sn_o to
>       sn_o+x, where sn_o+x < sn_n)

Section 7.1 already is explicit in saying that an IXFR client "MAY"
follow strategy B).  In particular, the draft says:

|7.  Client Behavior
|
|  [...]
|
|7.1.  Zone Integrity
|
|  The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936
|  [RFC5936] apply in a similar fashion for IXFR.
|
|  However, during the receipt of an incremental IXFR response, and upon
|  successful processing of an SOA RR that serves as a sentinel for the
|  end of any change information chunk, an IXFR client MAY immediately
|  apply and commit to stable storage the SOA serial number change
|  described by that chunk (and previous chunks, if not already done).
|  This operation MUST externally appear as an atomar operation.
|
|  [...]

Please revisit the full text in Section 7.1 for the detailed
considerations and tell us whether that is sufficient.

>
> Ondrej on behalf of Lubos
>
> P.S.: Our Knot DNS team (different people than one of the authors of
>       this document) will do a full review in WGLC.

Thanks in advance!

I hope that the chairs will proceed to issue WGLC on the upcoming
next draft version; experience has show that this is a strong
incentive for the WG to take a closer look at the document and
commenting on it.

> ...
> <snip>  {original draft announcement}  </snip>


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

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