Some concern was originally expressed that this document had political
implications. A lot of effort has gone into expressing this work in neutral
terms during the 18 months since this document was submitted to the ISE.
Although the work may never have the support of the whole DNS community, the
purpose of publication is to report on experience with the experiment - how
that information is handled is up to the reader.
-03 was shown to the DNSOPS chairs and to the OPS ADs at the time.
Stephane Bortzmeyer, Geoff Huston, Craig Partridge, and SM reviewed -03 and
that led to considerable discussions with the ISEB. This resulted in a request
from Nevil as the ISE to the authors to change the tone and direction of the
draft...
> My Editorial Board have discussed your draft, and SM has sent you
> a review of it (as you say below). Craig Partridge also had a brief
> look at it, and had these comments:
>
> "Clearly a valuable bit of work. (I'm far enough gone from doing DNS
> development that I don't have a political position on, so I'm just
> enjoying the experiment).
>
> It is nowhere close to be a conference-ready paper (which may be why
> they picked the RFC route). As a simple example, section 4.2.2.
> simply states that in phase one they "confirmed that using multiple
> ZSKs works in the wild." But they never state their metric or
> operational requirements for defining "works". I also found no
> measurements and a number of sections where the document expects the
> reader to be deep into the technical innards of the DNS to be able to
> understand the point of the discussion.
>
> The RFC also contains the kind of little nits (bugs) that we'd expect
> in an RFC reporting on field experience but not necessarily in a
> conference paper."
>
> At this stage, my (and my Editorial Board's) view is that:
>
> (i) In its present form, the document is not ready for RFC
> publication or even asking people to take the time to do
> detailed technical reviews. It lacks a clear explanation of, or
> references to, the goals of the Yeti activity, what problems
> you are trying to solve, etc. A discussion of tests performed
> is relevant, worth consideration for publication as an RFC, and
> helpful as information for the community only in that context.
>
> (ii) Why do you think the RFC Series is more appropriate for this sort
> of publication than the normal professional literature?
>
> (iii) We are aware, based on some very preliminary reviews, that
> the Yeti work (and perhaps these tests) are extremely
> controversial in the community. It is not the role of the
> Independent Submission process to either take sides in that
> controversy or to try to resolve it. We would consequently
> expect either that any revision submitted for publication would
> explore the controversies in a balanced way or that we would
> solicit and expect to publish a piece that would reflect the
> opposing point of view.
>
> So now, I won't continue working with it until the above points are
> satisfactorily addressed.
---------
Three more revisions were made and that gave Nevil enough confidence to review
-06...
> I've read it through carefully; it's a lot better than the -03 version.
> If you have some reviewers for it, do please ask them to review it,
> and cc their reviews to me. I've asked my Editorial Board members to
> see what they think of this version. I'll summarise their comments and
> send them to you.
>
> Meanwhile, it doesn't have a Security Considerations section; it needs
> one. It doesn't have to be very long or detailed, but it needs to point
> out the obvious security aspects of an experimental system like this
> (e.g. could hackers corrupt it by adding in an extra yeti root?).
>
> A few comments:
> p4: s/when considered the/considering the/
> s2.2 This section's last paragraph says that 'experimentation confirms
> this to be the case.' It would be a much stronger argument if
> you could give some actual measurement results to support it.
> s2.3 What's a 'Yeti-Root server _renumbering_ event'?
> s3.4 You use a github repository for a 'repository of service data'.
> Does that raise any security concerns for the system?
> s3.5 Same comment as for section 2.2
> s3.7 Appendix C lists server IPv6 addresses, but no measures of test
> traffic volumes (e.g. "x Mp/s" for Million packets/second)
> s4.6 s/Knot/Knot DNS Server/ ?
> p25 'service quality reported from end-users of the system was high,
> in the main case indistinguishable from that of the production Root
> Server System.' Units here - "in the main case" is awfully vague.
> How was service quality defined and measured? Usually that would be
> something like "97% of requests were resolved within 100 ms, 1.5%
> of requests timed out, and 0.7% of requests failed because of system
> problems." Maybe you only mean that users perceived yeti DNS
> performance to be about the same as that of the production DNS
> system? If that's all you meant, say so!
The ISEB considered -06 adequate subject to addressing Nevil's review.
-07 addressed Nevil's review
It was hard to find further reviewers and so Adrian also did a review.
-08 updated for Adrian's comments and moved status to Experimental.