On 28 Sep 2015, at 12:35, Paul Hoffman wrote:
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.
I think we have consensus that a good reference for how to retrieve trust anchors is a really, really good thing to have long before anybody starts coming up with dates for the KSK rollover.
To put that more forcefully, I think it'd be a really bad idea if people didn't have solid guidance from the IETF about how things are supposed to work well in advance of the KSK actually rolling.
Assuming I'm not alone in that thinking, perhaps we could look at the current text and consider whether there's a way to de-politicise it to the extent that it does its job and describes current practice.
This doesn't need to be a dnsop document. It could be an AD-sponsored, individual submission. But even in that case the IESG would surely (and reasonably) expect it to be reviewed here to confirm that it does actually document the current state of things.
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.
Fully agree that edits to the benefit of clarity, accuracy and the avoidance of politics seem entirely worthwhile and sensible.
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.
Those who use implementations that follow the guidance in the document (e.g. unbound) don't need to care. Those who don't, in my experience, tend towards trust on first use. Maybe that's good advice.
There's a companion draft draft-jabley-validator-bootstrap that aims to provide this kind of guidance. The goal of draft-jabley-dnssec-trust-anchor was to document how the trust anchors are published, not how to consume them. I think this is a useful separation.
Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
