[DNSOP] Re: DNSOPCall for Adoption for draft-sheth-dns-integration

Wes Hardaker <wjhns1@hardakers.net> Thu, 12 June 2025 06:51 UTC

Return-Path: <wjhns1@hardakers.net>
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 9ACC73408914 for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 23:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 74E3oa1VhLEC for <dnsop@mail2.ietf.org>; Wed, 11 Jun 2025 23:51:50 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 EA198340890F for <dnsop@ietf.org>; Wed, 11 Jun 2025 23:51:49 -0700 (PDT)
Received: from localhost (178-196.icannmeeting.org [199.91.196.178]) by mail.hardakers.net (Postfix) with ESMTPA id E63582003B; Wed, 11 Jun 2025 23:51:47 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net E63582003B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1749711108; bh=J4RswCiEDht6SMeCPOGP+FNmMSAln0CsAMwUI1FtfAk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gHRrvEqPsrpCaBYpPlnieshhCf7v+HWxQ6XQOhtF7ye2jVVjkk210uS2zOFnPhdHd Oso5zuMw0k9G+d2xT+KvhuKqERs8ONyMyOGSKIWmZGc9PinikA9+7IKO7EfXi3Ae+W N5Ge9HVgV8kE+EnrygYIt+CuxwgpjfUZuAttqH8w=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ondřej Surý <ondrej@sury.org>
In-Reply-To: <9BEA9DC4-723F-4677-AACD-65CCBE6CF898@sury.org> ("Ondřej Surý"'s message of "Wed, 28 May 2025 14:37:40 +0200")
References: <9BEA9DC4-723F-4677-AACD-65CCBE6CF898@sury.org>
Date: Wed, 11 Jun 2025 23:51:45 -0700
Message-ID: <yblikl1sb9a.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: RZXJNSQJ5YKHWPDPG4ILT4ME2LJUTOA2
X-Message-ID-Hash: RZXJNSQJ5YKHWPDPG4ILT4ME2LJUTOA2
X-MailFrom: wjhns1@hardakers.net
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: dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: DNSOPCall for Adoption for draft-sheth-dns-integration
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EHIOddpjjmFfyymEVAJJ2CP5ehA>
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>

Ondřej Surý <ondrej@sury.org> writes:

> this starts a Call for Adoption for draft-sheth-dns-integration

I have read this document and believe it is a good starting point for a
document.  I have suggestions to make later about adding more concrete
statements and suggestions, but other than that I do consider the
concepts important.  If adopted, I'm certainly willing to help as I am
actively doing some research in this area that proves the points behind
the document.

I do think for it to be an effective IETF document we need to tailor it
toward the IETF audience more, and other documents in other realms can
think stronger about governance related issues.  Having said that, I
think describing what the IETF expects with respect to integrating
alternate name spaces along side the DNS is absolutely critical for the
IETF to produce a document about (beyond the special use list or
.internal or .alt, which are not "conflict" problems, and thus
different).  To date we only have the IAB document RFC2826 which
basically says "don't do this".  As we now have industries that
specifically are doing it anyway, it's probably time to produce a
document that says "ok, if you're going to ignore RFC2826 here are some
further suggestions".

I agree that there is no perfect place for this document to be housed,
and we need to work across the IETF community to get a strong document
published.  But I do think that DNSOP is likely the best of the choices
and thus support it's adoption here.

-- 
Wes Hardaker
USC/ISI