IETF Logo Mail Archive

[DNSOP] Re: [Ext] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

Joe Abley <jabley@strandkip.nl> Tue, 06 May 2025 06:16 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BEA06253322C for <dnsop@mail2.ietf.org>; Mon, 5 May 2025 23:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VeLcagqYNQS for <dnsop@mail2.ietf.org>; Mon, 5 May 2025 23:16:36 -0700 (PDT)
Received: from outbound.qs.icloud.com (p-east3-cluster5-host11-snip4-10.eps.apple.com [57.103.86.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 28C922533220 for <dnsop@ietf.org>; Mon, 5 May 2025 23:16:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; bh=K021yceoOjuzf/VldIocNsQRJLhznjHQSP92p6Sa1Yg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=l+G1xMY7GhuLlPSb2dM2xjukgsEGSTkh5SDZxUW8zHJ6xvAwf/0MH2dNQcf3aYr5E hGdNRheCUyip2i5DqsKAyQF47uIOp6FqigOM4fbBgqAg3iZb3q03bi8H+TPbP8ffzN tXz1/ZEog+vuupuqTk4BKvZBHfQaD+yfqKyCTyrUj89qQ5dP0vvQE3haXNWBW8NSSp AqL8UAfOpcFlcXzdZiGL+eBD1fnS+TlmrviMuneNUuOzfteozAjOcBPvZUdL8ApUtW f/X5fQLOQMzphd+R0A0j5DnLdxsHkX+1XZkqhSluS4IRGbFQLgyndfGZC4yTh2lv5C CqrFS8VX2U8FA==
Received: from smtpclient.apple (qs-asmtp-me-k8s.p00.prod.me.com [17.57.155.37]) by outbound.qs.icloud.com (Postfix) with ESMTPSA id 418CD18001B1; Tue, 6 May 2025 06:16:33 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <7acd4998-b8dc-43ec-86a2-325270a629a3@isc.org>
Date: Tue, 06 May 2025 08:16:20 +0200
Message-Id: <03C093D5-0C28-4420-A743-80D441638E5E@strandkip.nl>
References: <7acd4998-b8dc-43ec-86a2-325270a629a3@isc.org>
To: Petr Špaček <pspacek@isc.org>
X-Mailer: iPhone Mail (22E252)
X-Proofpoint-GUID: 58tXHsmLfQvankgZb_AL0tNMELd2QAVU
X-Proofpoint-ORIG-GUID: 58tXHsmLfQvankgZb_AL0tNMELd2QAVU
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-05-06_03,2025-05-05_01,2025-02-21_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 adultscore=0 phishscore=0 mlxscore=0 clxscore=1030 malwarescore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2505060058
Message-ID-Hash: 2O4CEQHA26RX5JYNNWC2H23IHBSFBAFK
X-Message-ID-Hash: 2O4CEQHA26RX5JYNNWC2H23IHBSFBAFK
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Hoffman <paul.hoffman@icann.org>, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>, Roy Arends <roy@dnss.ec>, Philip Homburg <pch-dnsop-6@u-1.phicoh.com>, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZD0bn7VCTnL4N2w8EPkLEvMpSdk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On 6 May 2025, at 07:49, Petr Špaček <pspacek@isc.org> wrote:

> IMHO point #1 is not applicable because that's what we are discussing just now. Saying 'it's different because we did not reached conclusion yet' seems kinda moot point.


I think we are discussing whether the IETF would achieve anything useful by writing about .INTERNAL as part of an adoption call which is why I waved my hands about policy (in a topic that includes ICANN, SSAC, the IETF and the root zone it seems inevitable for hands to wave about policy.)

However, if were talking about whether or not an insecure delegation for INTERNAL should be installed in the root zone, then

I if we imagined that has happened, there would be no technical differences of the differences would be minor (they will all exist as insecure delegations but perhaps to different servers).

If you were talking about how a private namespace under INTERNAL might look to one of its intended clients, I think for most clients they all look the same without an insecure delegation but that it is possible to imagine scenarios where not having a public insecure delegation for INTERNAL might make it look different.


Joe

v2.31.3 | Report a Bug | By Email | System Status