Thanks for suggestions and editorial work from co-authors and volunteer reviewers. The 06-version of Yeti Testbed experience draft is ready for public review.(Github repo of this draft) Now it is in the queue of IETF Independent Submission Editor(ISE). The comments from reviewer are welcome and to be sent to the ISE.

It is worth mentioning that in this draft, a conclusion section is added for the convenience of audience which includes a brief list of findings and experience. In addition it suggests several topics worthy of future study based on experience gained during the operation of Yeti DNS testbed.

o Priming Truncation and TCP-only Yeti-Root servers: observe and measure the worst-possible case for priming truncation by responding with TC=1 to all priming queries received over UDP transport, forcing clients to retry using TCP. This should also give some insight into the usefulness of TCP-only DNS in general.

o KSK ECDSA Rollover: one possible way to reduce DNSKEY response sizes is to change to an elliptic curve signing algorithm. While in principle this can be done separately for the KSK and the ZSK, the RIPE NCC has done research recently and discovered that some resolvers require that both KSK and ZSK use the same algorithm. This means that an algorithm roll also involves a KSK roll. Performing an algorithm roll at the root would be an interesting challenge.

o Sticky Notify for zone transfer: the non-applicability of IXFR as a zone transfer mechanism in the Yeti DNS testbed could be mitigated by the implementation of a sticky preference for master server for each slave, such that an initial AXFR response could be followed up with IXFR requests without compromising zone integrity in the case (as with Yeti) that equivalent but incongruent versions of a zone are served by different masters.

o Key distribution for zone transfer credentials: the use of a shared secret between slave and master requires key distribution and management whose scaling properties are not ideally suited to systems with large numbers of transfer clients. Other approaches for key distribution and authentication could be considered.