Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt

Ben Schwartz <bemasc@google.com> Tue, 23 March 2021 02:31 UTC

Return-Path: <bemasc@google.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA73A1A73 for <add@ietfa.amsl.com>; Mon, 22 Mar 2021 19:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.699
X-Spam-Level:
X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AKbZGrmmNIJE for <add@ietfa.amsl.com>; Mon, 22 Mar 2021 19:31:39 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 391233A1A74 for <add@ietf.org>; Mon, 22 Mar 2021 19:31:39 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id m20-20020a7bcb940000b029010cab7e5a9fso12135290wmi.3 for <add@ietf.org>; Mon, 22 Mar 2021 19:31:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qApEC9sLOsE49WSIkGqBQBmTj1itIhdnSOizkKI1Mf8=; b=W9l5kCX0itceASe6916Pe67Ymh488526g/kpdo2SyLH8/Lmv7fkTS5t26mt65nce5R ul/Ut9xS2r+/titXohnQ5miE/4QIj2B+kQcpC29/PIlC8nvUxwPc4ZD7kVRXYdENkYGi DfO2ZYISC4O+flg0BrESTG1mibxMgKttVt3Xr88syXl+6UEpV72Qyd1EUIQUEBw9yN9n AnJ7woyWn0dBqpV6ODlLayNP/B+hggAZsriaLzp3iv7eDFpFYbFMQouMUP8+1evbzAhb CC5WF9kknztaAtK7lOAcakm1z/56Ns21IakFzyI7PTR2KREQpQfYzBZKuPYqvKPJsRDP P5cQ==
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=qApEC9sLOsE49WSIkGqBQBmTj1itIhdnSOizkKI1Mf8=; b=WNif5PQRYGBI/rO+fvlDHWKRvGULA1UcRBXGieqlybi1UUk098URTpIc1GdB0fK9td KHCKDbvtT0T4jueCjc0SVHuKICkoUOiN2C7jA/H3RoJgbFL/MLl+i21hdXi7Nvz1xFTZ 6Raw8dgpxbPyNj13GlDszUOGg0G8kJVGTjPcknp14qRR3hdWbQE2UgXvPnWizy93qNEX 0lNqrz+7WKgTSChX0i+1fyFirrY7GV8oKnBHkyEkffIQeQPVtQ5vWlV1tmi2j03UHB9F oV23L+klyfc8fzQcPQKSu9FDSXw4f2R/tGAlUKmvkLX8VWoe+cioeE5/yVE237hb74/5 ocpw==
X-Gm-Message-State: AOAM530Qx1NFP2lPulw6VnjoUy5NZSQipkdt/wG0RDLvjdeDVC5zCs3B S521w5rNwGWkxVro210ghPpbXeJwnvwvwQh/UyK7mQ==
X-Google-Smtp-Source: ABdhPJxVpIYz0k5ZPAGUx7xxNBVxUbUTXlA+W0WXZyJptMSxO3GUjKJGoBgxZPPAPcNCF9Yhnqa+YvQkmQcaMlo/rUw=
X-Received: by 2002:a1c:1f4a:: with SMTP id f71mr1067265wmf.101.1616466696060; Mon, 22 Mar 2021 19:31:36 -0700 (PDT)
MIME-Version: 1.0
References: <1c618bd9-e039-2dac-80f3-1f11b7b44bc4@cs.tcd.ie> <9486D9AE-047B-4046-AB8A-74E8AB0D83B5@nohats.ca> <20210315021312.ng5xgq23kkohvsgb@family.redbarn.org> <1191373191.33078.1615799543805@appsuite-gw1.open-xchange.com> <CAHbrMsDuks_CekecsONR2USBk+TCyDy3xzdndbak2p8gsJnReQ@mail.gmail.com> <cb2fdd3c-1454-7daa-4fb8-b7b78a79ec39@redbarn.org>
In-Reply-To: <cb2fdd3c-1454-7daa-4fb8-b7b78a79ec39@redbarn.org>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 22 Mar 2021 22:31:24 -0400
Message-ID: <CAHbrMsC7jaW8RWoO8szejOgVzOu0OcOd05RyBYw8HPpFw+Lxbg@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000003e0d8105be2afb9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/XLxQjepo1fCs6nQYbucX7gUIH1c>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-reddy-add-enterprise-split-dns-01.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 02:31:44 -0000

On Sat, Mar 20, 2021 at 12:09 AM Paul Vixie <paul@redbarn.org> wrote:

>
>
> Ben Schwartz wrote on 2021-03-15 08:09:
> > Many have raised the difficulty of establishing an identity for the
> > network and confirming that claims received by the client were produced
> > by the network operator.
>
> who? (the many) what? (did they say) and why not? (wouldn't we just use
> a signal pattern that only the network operator, and not every node on
> that network, could participate in?)
>
> i don't intend to be abrupt. but "many people are saying" is not an
> argument, and i don't think a non-argument should move the needle here.
>

Evidently I should have been clearer: I meant "many in this thread".  I
count at least three messages to that effect from different authors in this
thread.


> i hope you can clear something up for me, though. previously your
> principle concern was that RDNS policy was a small part of a larger
> puzzle, and you were reluctant to treat it independently. i answered
> that i wanted the same pony you did, but in the absence of anyone who
> wanted to work on the whole puzzle, we had to consider starting small
> with the small part of the puzzle we're facing.
>

I suppose this is in reference to
https://mailarchive.ietf.org/arch/msg/add/LAChEeAQa9_0zDEbPWhshYgEuGo/
I think I meant something quite similar to what I said earlier in this
thread: policy is a conversation between people, not machines, so the
logical place for it is in something more or less like a captive portal
ToS, where the user may contemplate all of the network's policies together.

In any event, the place for it is not in this working group.

you'd also said that there wasn't a way that the network operator could
> speak authoritatively and that a client might receive policy from some
> other node and would not know whom to trust


I just took a few minutes to re-read every message I've sent to this list
in the last two years.  I did not find anything matching this description.
Nonetheless, it's possible that I may have said something to this effect.

My current feeling, as I said earlier in this thread, is that this is a
significant challenge, but I do not mean to claim that it is impossible.