Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
Brian Dickson <brian.peter.dickson@gmail.com> Wed, 20 March 2019 05:46 UTC
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77FC130F84; Tue, 19 Mar 2019 22:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FIN_FREE=2.7, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej6GY_v-4QML; Tue, 19 Mar 2019 22:46:41 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262D212426E; Tue, 19 Mar 2019 22:46:41 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id k189so8149173qkc.0; Tue, 19 Mar 2019 22:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LYYacSO2tnzoskAztZec85lc3XW+pnHoFVCgxGfYTTo=; b=G3wV3Rwc1FOyY9+52SjkNMlZSu1AZXGkieb52CamLpcoqDyQpTBw0FScLY/oD1akB0 WkkYQKAnuNFnG1SJrVxW6pVTafYe/AxoaZvKhUFGZwUl2nzz3cP5Jbp5S/b5C1onP3lP Hn8GeoCw9a12FQ78P/7MV3+G6PIbo0tHFcOmXBxL3yBAyXz3XOJTJPf6ILzEgVIrPTu6 x8l7J84NgexmzrPGOe1ckPb0PORcAQb5qJwDqwjRDGk2YMunoC6GILZVcgvTtXpmYG9H 4HIjfyyl1oyr61GyxKCh/eVeeJQOWt418W9E02HT51Ilt69OBQ0ikqBK+Z5vxkbpKxBy pySg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LYYacSO2tnzoskAztZec85lc3XW+pnHoFVCgxGfYTTo=; b=EyG+34JLs0/2fRon+/1xBB1mlFPDwqQY/an/hC3mQCVdfjqSwr43zTNpV6f8lHCemR V4RWHRCif6uRuTX0T7hPyB6x6zGRLrelJqoWlK5MG0LkltigLqL4CDqgqPcpfl1JEMjx WsKF/A3BKVWJyOkDv1tjQDKl2rAqMt5OjJ+em+6vjxnwBrQX9vjmsVq2eXWRcb8KfPru XUFVEP0WV1jxOxLdvuvx+aRcJVa9Mp8pdF4zxYzGe3MIq0LPwo6yauHkT3QCLoAzYTjq 2hlQ+RKT+CJExNaj8+ycdjb2Ic3RMP4p0A00HJ4FEW5gR5XipwNkRxfZ+8LnoXCn+QbY RGbA==
X-Gm-Message-State: APjAAAXnOBOiaaXkt/j8hFWaOt4+1L7OZhu8J3IU/VuUrXBjwaSosEET IfQg0INxnPLDKrUFPXrLiYKpQTr3rVRhwXjKmz0=
X-Google-Smtp-Source: APXvYqx4nPJGiFyy94Hj4tgr9pKvpCHIdSncZqTbl7Wy2gAP6VUQWwAR6sjHyqOmFP+CovMN3g4dDV58jBdreXxZqwg=
X-Received: by 2002:a37:6814:: with SMTP id d20mr5182159qkc.102.1553060800175; Tue, 19 Mar 2019 22:46:40 -0700 (PDT)
MIME-Version: 1.0
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net> <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net> <b8c58757-3945-ea19-b018-8e59292abf30@cs.tcd.ie> <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com> <7f0e4b4f-3b69-cc99-37a6-abff7c0573c0@cs.tcd.ie>
In-Reply-To: <7f0e4b4f-3b69-cc99-37a6-abff7c0573c0@cs.tcd.ie>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 19 Mar 2019 22:46:28 -0700
Message-ID: <CAH1iCipyWbsOKwHwTgQrLW4azAUj3Kp0TvD_WiMbT5wcNFm8Ug@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Jared Mauch <jared@puck.nether.net>, dnsop <dnsop@ietf.org>, paul vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>
Content-Type: multipart/alternative; boundary="0000000000004f236605848025b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wmVyenEWdymeee1NPV1hwXbIR90>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 05:46:43 -0000
On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > > On 20/03/2019 03:17, Brian Dickson wrote: > > > - If a network operator has any policy that is enforceable, ONLY the > > technical policy enforcement model scales. > > My mail was about my policy for my home network and explicitly said > that I do not claim that policy ought be followed by all home networks, > never mind other kinds of network. Your argument about scale is not > therefore relevant. (At least, not unless you want to give up all > argument along the lines of "consider the children.") > I am saying, that the work product envisioned by participants of the side meeting, needs to be some framework that scales, regardless of where it gets used. It does not matter whether any policy does or does not require scalable mechanisms. What does matter is that there exist networks where the mechanisms need to scale. What is being envisioned and proposed, is a flexible-enough framework, that scales. If something scales, it scales. If it scales, it won't make it impossible to do what you want, tautologically. Let's try this using classical logic: Suppose there is a rule: "A implies B". The negation of that rule is: "Not B implies Not A". The negation of that rule is NOT: "Not A implies Not B". I believe your argument(s) falls into the "Not A implies Not B" category. (I hope I'm mistaken there.) However, I am also having a little trouble following your actual meaning. More below on my challenge with following what you are saying... > > My policy, for my network, is as defensible as many others. And that > isn't peculiar to home networks. > > > - In such an environment, there are only, ever, "willing users", because, > > in order to use the network, they are required to agree to the policies. > > Wrong. In my home network, my children and their friends have > no real choice to not use the network until they are relatively > economically independent. (And in earlier days, they could not > have given informed consent in any case, being too young.) > So, I am trying to understand. Does their lack of real choice make them unwilling users? Are you arguing that they should be able to bypass whatever rules you have for your children? Do you want your children to be able to undetectably use a third party DNS resolver, such as DoH, and access naughty networks or malware? Or do you want to block that particular use case? I think their category as "unwilling" is mooted by their being minors and not being able to give informed consent. In any case, if you do want to give them (all of them or some of them) access to such third party resolvers, should that not be something explicitly under your control? And should it not be easy to do (where I roughly equate "easy to do" with "scalable", for argument purposes). > > In work environments what you say is also not completely correct, > at least in some EU locales, where employees retain rights of > various kinds whilst at work using an employer-provided n/w. We > don't need to argue the rights and wrongs of that, it just is. > I think I am also having difficulty with the argument here. What is the exact scenario (or set of scenarios) you are using in your example? Is it an employee located in an EU locale, using a work network? And is the employee's network applying policies that violate the employees rights? If the answer to the second question is "yes", I believe there are many recourses that do not involve any technology at all, such as civil suits or whatever mechanisms an employee has under the laws of the EU or their local jurisdiction. I think that any proffered mechanism over and above that is largely redundant, and/or generally within the means of a financially independent adult to work around, e.g. using a personal device on a mobile network not provided by the employer. Or, is the employee's network not applying policies that violate the employees rights, which I think makes the argument moot, since the employee's rights are not actually being infringed. So, yes, the employee has rights, and I don't have any issue with either the existence of rights, or any opinion on whether that is right or wrong. What I don't follow from that is, that any network operator using technology to interfere with those rights, is able to do so with impunity, and that there is a need to provide mechanisms to bypass that technology. Is that really the case, currently, in specific jurisdictions? Can you provide some kind of reference to that, that is verifiable, in the EU? We all know about the issue with authoritarian regimes, and all that. I think we can all agree that in those cases, the use of technological methods to bypass restrictions requires individuals to violate the laws in those places. And I am in no way arguing against the technology involved. I'm saying that outside of those specific jurisdictions/environments, there is no explicit need for making the privacy technology operate in a strictly unilateral mode, in such a way as to evade any sort of detection. I'm saying that it is reasonable to expect that whatever legally-permissible policies any network operator has, can be enforced cooperatively between client (software/devices), network(s) (operator(s)), and server (provider of whatever permitted degree of privacy-enhanced is permitted by network operators' policies). The extent of what I'm suggesting is, aside from the authoritarian regime situation, networks whose policies are not violating local laws (including whatever "rights" laws may apply), need to be able to implement those policies in a scalable fashion, including detecting anomalous activity easily (for e.g. malware detection), and that client software/devices should be able to, at their discretion, negotiate the maximal privacy setting desired, including reaching a privacy equivalent of "no networks available" (don't connect at all). > Once more: my policy for my network is defensible but is not > one I claim ought be followed by everyone. And the same applies > for all of the more intrusive policies being espoused here by > those with concerns about DoH. We (speaking for everyone else) are NOT espousing policies. We are espousing mechanisms for policy enforcement. There is a huge difference. Our position on the enforcement is policy-agnostic. It doesn't matter what the policies themselves are, the mechanisms need to scale. The policies themselves are, honestly, completely out of scope, other than the mechanics. If a particular policy is legal in any jurisdiction on this planet, and is sufficiently well defined and sufficiently distinct from other policies, the policy framework needs to accommodate it. There aren't *that* many conceivable policies that apply to DNS in the intersection spaces of transport protocol (DoH, DoT, TCP, UDP), third party operators (yes/no), encryption (yes/no), and privacy (yes/no/MITM). > That doesn't mean those concerns > are vacuous or otherwise to be ignored, but does mean that > claims as to such-and-such a policy being a necessity are not > valid. Only one counter-example is needed to demonstrate that, > and I've provided one (that is real, not invented). > If it is the EU one, please read above: I don't think it actually does what you think it does, per se. If it is the home network one, it isn't about policy, it is about mechanisms, and your not needing your policy to scale, isn't germane. If anyone needs the policy framework to scale, that needs to be taken into consideration. As long as there is anything close to consensus on the existence of a non-trivial number of networks who require scalable solutions to this problem, that should really be the end of it. I don't understand anyone taking a position that anything doesn't need to scale, and I think that is what you are saying (from your home network bit.) Is that really your position? Brian
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Warren Kumari
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ask Bjørn Hansen
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Michael Sinatra
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Todd
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ralf Weber
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Levine
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Lemon
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator nalini elkins
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Adam Roach
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator 神明達哉
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Levine
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jim Reid
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eric Rescorla
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ray Bellis
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator sthaug
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Joe Abley
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Lemon
- Re: [DNSOP] [Doh] (dhc discovery) New I-D: draft-… Normen B. Kowalewski
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Bill Woodcock
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Livingood, Jason
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Richard Bennett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Richard Bennett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Vittorio Bertola
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Paul Wouters
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Olli Vanhoja
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Daniel Stenberg
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Mark Andrews
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ian Swett
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… sthaug
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Valentin Gosu
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ray Bellis
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Stephen Farrell
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ray Bellis
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Paul Vixie
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy