Re: [DNSOP] [Ext] Re: New draft for consideration:

Olli Vanhoja <olli@zeit.co> Sun, 24 March 2019 13:52 UTC

Return-Path: <olli@zeit.co>
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 90BF8127AC2 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 06:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 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, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zeit-co.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 AuJJuDKvsO_1 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 06:52:47 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 D58A312788C for <dnsop@ietf.org>; Sun, 24 Mar 2019 06:52:46 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id q66so5581140ljq.7 for <dnsop@ietf.org>; Sun, 24 Mar 2019 06:52:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zeit-co.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BGfa4T0Q0sGV0TxpbsQgQ/akVSbPWwwbqc4I49SPTLU=; b=fVJG9FSu59R8nrYnZqqcmEgvsm4NQVFpah9Y6o9/Y+Zjrny8TtumYLsRynTiFjq2RF 1hOR03PDu2plc1dUAQxmcElKGp9QTGOegpwtuUcxdWOs8/35Rp2HEQP2chZ7OG78h2ea f4vwc5sm6SYzJHhCgnSIeZVYe0fO9sklAv+z+SMWQQ90wdy9kG6fHWYPx9KNN4v2ftmF 4+liGOpS/eeXjSPKrZDG2T18JpO2AI7DwTwOhkUP84WxfjCpYO0kT2C6405LgJWNSC89 fJ71u4QlEFrxDpR7+TfiXR00RengC/GUutBcjrQKEariusAwm6+4UJyH6oAXB+FgXXqh Si/w==
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=BGfa4T0Q0sGV0TxpbsQgQ/akVSbPWwwbqc4I49SPTLU=; b=WpUFya7rojKc2MN+I8txkp4GRV4zSTpQlXNkgqNZEv9O3Ltq7UVoyHJPP1zgDlLkax roPqbQzFZHQrbGj2IE39FuhkjjSqjJeaKn3WkxbwqEYSlpybJ4U0xMzHvgAm/jdqCCbU eOesIBpsSM0OG4Ruc8WbCd0ZNT8UucPjKy+oowxWW1zkiDMfel1z3xUxUxEBP05RU0yV ANGfpwca/dcC5oWZttfDEC15e4KENMzv5KO2QfES4zGnlmfSQeXtWdmSRpfgJKblMPGa 7YRY2YLP2JuJE00pfcnSIgcKtFuq1U36Uv0sGikrTJsEZH6P38YcGbt8RDU1bK+oTc/h g9iA==
X-Gm-Message-State: APjAAAUDIzgselFOZfEncUGhfIe0OPqrzvV6hDo4vH+dFNBApgiK00cB 7IVHypvzDuB+ulJVyfvau3IKQ+wANtikhcSkmdV/jQ==
X-Google-Smtp-Source: APXvYqw2vUnWEkoK8xDuyVaGwwv23aVE7Qj6im6oIYA34k7CJVfzkqOacOlh4z22/QjQgy3Mu14GTEoKDhRNvrxLq3w=
X-Received: by 2002:a2e:8e8e:: with SMTP id z14mr10230420ljk.86.1553435565019; Sun, 24 Mar 2019 06:52:45 -0700 (PDT)
MIME-Version: 1.0
References: <E2267015-0A5F-4D6E-85F0-3FA93348CA79@icann.org> <20190324101805.GA22597@server.ds9a.nl> <6893EFA4-F413-4C11-828A-13E942AA345C@icann.org> <CAHw9_iJEmfY36RU3z80uTdPXQ0EKRnd2Gn=YJphZiFM1K0d8fw@mail.gmail.com>
In-Reply-To: <CAHw9_iJEmfY36RU3z80uTdPXQ0EKRnd2Gn=YJphZiFM1K0d8fw@mail.gmail.com>
From: Olli Vanhoja <olli@zeit.co>
Date: Sun, 24 Mar 2019 14:52:33 +0100
Message-ID: <CABrJZ5FOvBjq08jsgESXPNtwBWVx4M6bOdXOPVwRasfmdTkMuw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>, bert hubert <bert.hubert@powerdns.com>
Content-Type: multipart/alternative; boundary="00000000000008ec750584d76705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/56W2DaKMhVi_glIRSTPC00eihvk>
Subject: Re: [DNSOP] [Ext] Re: New draft for consideration:
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: Sun, 24 Mar 2019 13:52:49 -0000

I don't like it either because DAO is a well known acronym for Data Access
Object.

On Sun, Mar 24, 2019 at 12:49 PM Warren Kumari <warren@kumari.net> wrote:

>
>
> On Sun, Mar 24, 2019 at 11:46 AM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> On Mar 24, 2019, at 11:18 AM, bert hubert <bert.hubert@powerdns.com>
>> wrote:
>> > It may be good to add a note that "DoH is the protocol as defined in
>> > [RFC8484]. The operation of this protocol by browser vendors and cloud
>> > providers is frequently also called 'DoH'. DoH-the-protocol is
>> > therefore frequently conflated with DoH being used to perform
>> > DNS lookups in a different fashion than configured by the network
>> settings
>> > (see DaT and DaO)."
>>
>> A much better outcome would be that people who are saying DoH when they
>> mean DaT or DaO would use the new terms. That is, this is a forward-looking
>> document because we're making up new terms.
>>
>
> <no hats>
> This is likely to be an annoying comment, but I don't really like the DaO
> "acronym", simply because I'm not sure how people will pronounce it -- I
> could see people mishearing "DaO" as "DoH", or the other way round --
> unfortunately I don't have a better suggestion. Is it just me who has this
> issue?
>
> </no hats>
> W
>
>
>
>>
>> > Secondly, I understand the technical need for the wording of the
>> definition
>> > of DaO.  But I had to read this all a few times before I understood that
>> > 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
>> > definitions should be easy to understand because otherwise they don't
>> > function.
>>
>> I fully agree; proposed changes to this wording are quite welcome. It's a
>> new term, after all.
>>
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application makes the choice for
>> the
>> > user".
>>
>> The split here is more "someone changes from traditional without the user
>> knowing, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>> > I'm willing to write text once we have discussed this a bit.
>>
>> Thanks!
>>
>> --Paul Hoffman
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>