On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote: > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the working > group is either to publish the document as is or to bring the document back > into the working group to address the following issues:
For the record, I've had a document need changes after IESG publication approval that were then made with a WG LC for those changes rather than a repeat of WG LC, IETF LC, and IESG review. I'm surprised that this changes should require "bring[ing] the document back into the working group" if by that you mean going through the full process all over. Though, to be sure, I don't object if that's the required path now, but I don't want people to feel compelled to be against this LC on account of the delay in publication being much bigger, not if there's a shorter method. (Also, I don't mind a delay all that much: it's hardly that big a deal; RFCs often end up stuck in AUTH48 for much much longer!) > - Recommendation of adding denial of existence proofs in the chain provided > by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? I do not. > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both At least (B), and preferably (C). My rationale for (B) is that this is the sort of thing where adding it from the get-go will yield deployment where DANE is not mandatory for the application whereas not adding it now will yield non-deployment of DANE in such applications for a very long time. My rationale for (C) is that (A) is trivial, so might as well throw it in. Mind you, (B) is also trivial (two bytes! to be conveyed however you want, with 0 -> clear the pin to DANE). Thanks, Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
