Hello Ben,
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/history/
That seems more effective than sending private messages.
thanks,
Rob
Hi,
I found two issues with [this draft]. The document mentions unattributed "concerns" in a few places. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF.
Secondly, I found the entire section "3.5.1.5.2. DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.
thanks,
Rob
On Mon, Dec 23, 2019 at 2:17 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
On Mon, Dec 23, 2019 at 02:12:27PM -0800, Rob Sayre wrote:
> Hi, here are comments I mistakenly sent to a thread about another dprive
> last call. Summary: the section about "DoH Specific Considerations" is
> highly questionable, and seems like advocacy rather than a representation
> of IETF consensus.
In the future it would be good to send them as a separate thread, so that
the threading structure doesn't confuse someone into thinking that the
topics covered in your message relate only to the issues raised in the
original secdir review. Sometimes when the IESG is going through the mail
archives to determine whether all raised issues have been addressed, it's
easiest to go on a thread-by-thread basis, in which case new comments sent
like this could be missed by accident.
(To be clear, I think re-sending again in a new thread is worse than
leaving things as-is, for this particular case.)
Thanks,
Ben
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
