Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator

nalini elkins <nalini.elkins@e-dco.com> Wed, 20 March 2019 03:39 UTC

Return-Path: <nalini.elkins@e-dco.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C3C130F0B for <doh@ietfa.amsl.com>; Tue, 19 Mar 2019 20:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.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 YwH0TNCl4HwC for <doh@ietfa.amsl.com>; Tue, 19 Mar 2019 20:39:16 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 BD9EB12785F for <doh@ietf.org>; Tue, 19 Mar 2019 20:39:15 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id u68so751771lff.7 for <doh@ietf.org>; Tue, 19 Mar 2019 20:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tGZ8Ea9fMXQSaOkxtCD/CCDXfWLcFxopptXGfKBPrSs=; b=yPffSwCG/Z9tswRNLqLqS/yMxPKGioAPCCBxzQ+kc6jTSC1RT2KpSWs1sBjo2I6sob /vmYhrmRjUl4OjwMw6wklMxdkHdUPmcQZKZH1QeU+zSFsIL8TBA+jxcIVVDHQNV3c5OI nyg7gFlnUGbeNnpZqB+K9x3ZSRF94sLUFuAIYcCFFKLvOYYShUzsQHiGH5QHkqadwQXu h985qpgjNtuCzFwE+OL5E84zSXGMAbAudtc7dq9O42KLOID704P5kAloiNgOPJ6qj9V0 WixuTUrXOgwY8NSAfOkJGDE7WvuIhJf2butwul7o0uvHCt1yZHPAKR82LcX5yZyfs1FT QIlA==
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=tGZ8Ea9fMXQSaOkxtCD/CCDXfWLcFxopptXGfKBPrSs=; b=nqqoysj/P0sH+DQtKFyPDr/2a11NSdANw2IvUjpZQblQs8Lm1waHOE57vQhWaP9CuP kYjf2xPkNvllujFq1IAq+u3v6b6zv9xK2C+0PXLpMENCZB/ZpqrZZnMk/7MEsdbwsCIV /9qHJ7nwjPdS499WzRAXZqz4FM29ePnoHavf99GhjgO2kp95sXMeeUn6yvVE4YPRgbGK aMOxb/GANxh6oPR7BDgkBlP80JgVLRHZ5xJ/UzS/7fuDsuzgvQyO3oTkL5J+KRZ70Z4c eGqjyKPN8KFwSdHDB6fFNpU3s0u5Ek1YoG17t4QiA38uIat/YwTlRgvV7kIY6BK341NH X0bg==
X-Gm-Message-State: APjAAAXg540xnXrhNa2WZ5BdfQay1xRfwUU5op7OaufED8q8JPRbVtnn BG+MYBF9iThT1un9dfa+Pg0bxvAwm0+YwOJny0MHUA==
X-Google-Smtp-Source: APXvYqzHKocMbRCDAkmMXQTSgnaxWmmWLht1lze2fBpK/QgRWXOYjcl02S8g2iBmm5pSeQZRC5pgw4N93TW2aTyYIKI=
X-Received: by 2002:a19:95cf:: with SMTP id x198mr14408907lfd.73.1553053153870; Tue, 19 Mar 2019 20:39:13 -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>
In-Reply-To: <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com>
From: nalini elkins <nalini.elkins@e-dco.com>
Date: Wed, 20 Mar 2019 09:09:03 +0530
Message-ID: <CAPsNn2Xyj9y_oOtnfcLWrS558sT3Hy41GOhx9rDe0i4RudCPKg@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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="0000000000008dcc6505847e5d3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Ew8meo40ZOjTDR4TMG-DjtsJtxg>
Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 03:39:19 -0000

Brian,

Thank you for a thoughtful, well-stated, reasonable comment that seeks to
achieve compromise with the points of view of all being considered.

Nalini

On Wed, Mar 20, 2019 at 8:48 AM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> One individualistic data point on this sub-topic, and a real point:
>>
>> On 20/03/2019 01:13, Jared Mauch wrote:
>> > My impression is there are people who will not be satisfied until all
>> traffic looks
>> > identical and you have zero way to protect your home,
>>
>> I do not claim that everyone ought do the same, but I absolutely
>> do claim that encouraging voluntary policy adherence by dealing
>> with the people using the n/w is preferable to many egregiously
>> invasive attempts to force technical policy enforcement on
>> unwilling serf-like users.
>>
>
> So, this is the problem:
> - If a network operator has any policy that is enforceable, ONLY the
> technical policy enforcement model scales.
> - 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..
>
> This makes the argument you have above, a vacuously defined one.
> You want to encourage voluntary policy adherence for a non-existent set of
> otherwise unwilling users.
>
> I understand your position: you would prefer that {some,all} networks were
> not employing policies that {you,some people} disagree with.
> I sympathize, but I disagree. What we need are mechanisms that scale.
> My position (personally) is that we find ways to have scalable, technical
> mechanisms.
> They should allow users (or machine administrators) to be as compliant as
> they are willing, and no more.
> They should allow networks to enforce their policies, while treading as
> lightly as possible.
> It should be possible to use technical means to handle this negotiation
> with little to no user input required.
> The analogy is roughly that of escalation-of-force in law enforcement,
> starting at a level of "polite requests".
>
> You can disagree, but I implore you: please don't stand in the way of
> those wanting to find consensus on scalable, flexible, technical solutions
> that encompass a wide range of network policies and enforcement needs.
>
> The main point is, I believe the end result will be mechanisms that allow
> you to deploy networks that meet your needs, and software that you can
> configure to bypass such controls, but that neither of those should ever be
> the default configurations.
>
> If the results allow you to do what you want/need, and also allow others
> to do what they want/need, everyone should be happy enough with the result.
>
> Can we at least agree on this as a desired goal for this work?
>
> Brian
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com