On 28 Sep 2015, at 4:59, Joe Abley wrote:
Hi all,
We don't seem to be getting anywhere with this draft. (Jakob is going
to bump it to -12; there have been no real updates apart from the
version bump in
I appreciate that the methods described in this document are not
universally liked. I have a feeling that we would get more discussion
if the question was more open-ended, e.g. how should trust anchors be
published?
This document describes existing practice, and provides guidance for
people who need to bootstrap a validator using the mechanisms provided
by ICANN back in 2009/2010 when the root zone was first published.
Here's a suggestion. If we were to consider publishing this document
as-is as a way of describing the current approach, we would at least
have a stable reference to the way we do things today. We could always
consider other approaches and, once implemented by ICANN, publish a
new document that obsoletes or updates this one.
If that's an approach that people could stomach, then I would suggest
the next step is to WGLC this document and for those who would like to
propose different mechanisms to write them down.
We could do that, but the RFC should probably not be published for at
least another six months due to terminology / politics / IANAPLAN, so we
don't need to rush the WG LC either. For example, the draft uses the
phrase "an IANA function performed by ICANN", to which many folks at
layer 9 will object until the transition has already happened.
If the WG wants to adopt this draft before the IANA transition is done,
I would strongly prefer that the document be first adopted before there
is a WG Last Call. Getting the wording in the document about "this is a
current implementation" should be done in more than one step. As a
concrete example, the abstract boldly states "This document describes
how such trust anchors are published" which should instead be "This
document describes one way how such trust anchors are published". Even
the phrase in the abstract "has been cryptographically signed" can be
misread by the ICANN skeptics as "was signed in the past, but isn't
currently". There are other examples in the document that should be
stated more carefully.
Also: how much is this document really needed? Are there operators of
validating resolvers who are unfamiliar with how to get the trust
anchor? It is likely that the most common method for getting the DNSSEC
trust anchor for the DNS is "it came in my distro". If so, then a "how
it is currently done" document needs to emphasize the positive and
(maybe very) negative aspects of this practice.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
