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

Paul Vixie <paul@redbarn.org> Sat, 20 March 2021 04:09 UTC

Return-Path: <paul@redbarn.org>
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 DD3E13A1973 for <add@ietfa.amsl.com>; Fri, 19 Mar 2021 21:09:33 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 Ulgy9a84eg5c for <add@ietfa.amsl.com>; Fri, 19 Mar 2021 21:09:32 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D69D3A1972 for <add@ietf.org>; Fri, 19 Mar 2021 21:09:32 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c0b:d988:3630:9c71] (unknown [IPv6:2001:559:8000:c9:1c0b:d988:3630:9c71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 434427599A; Sat, 20 Mar 2021 04:09:29 +0000 (UTC)
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: ADD Mailing list <add@ietf.org>
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>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <cb2fdd3c-1454-7daa-4fb8-b7b78a79ec39@redbarn.org>
Date: Fri, 19 Mar 2021 21:09:27 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.47
MIME-Version: 1.0
In-Reply-To: <CAHbrMsDuks_CekecsONR2USBk+TCyDy3xzdndbak2p8gsJnReQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Fjdq5chfqQkcxB28-MdnXHTtI6E>
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: Sat, 20 Mar 2021 04:09:34 -0000


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.

> That is a challenge, but it is not my
> principal concern.  My main concern is that when we move from encoding
> what the network offers to what it "allows", we are discussing the IETF
> blessing certain Terms of Service as technical standards.

not at all -- not even a little. the internet is a network of networks,
and the networks are considered by the core to be autonomous. a protocol
by which the network operator expresses policy (not terms) would aid in
interoperability.

* * *

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.

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, so i suggested a way to
signal the policy (TXT records under the IN-ADDR.ARPA tree) which could
be considered authoritative in any case, and could also be DNSSEC signed.

now your principle concern has changed. it seems that this concern could
have been stated earlier, in a brace with the others. could you supply a
complete list of your concerns, such that if addressed, you would not
object? because without that you run the risk of bad optics ("moving the
goalposts") and the suspicion that your objections aren't resolvable.

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>