Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

Ted Lemon <mellon@fugue.com> Fri, 21 October 2022 08:04 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12367C1524BC for <homenet@ietfa.amsl.com>; Fri, 21 Oct 2022 01:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwyXAT_i6HrU for <homenet@ietfa.amsl.com>; Fri, 21 Oct 2022 01:04:42 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63548C1524BB for <homenet@ietf.org>; Fri, 21 Oct 2022 01:04:42 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id a18so1600473qko.0 for <homenet@ietf.org>; Fri, 21 Oct 2022 01:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/fDD8yCGEers9Tgi4jVCsrpSgdsyYcxxNBlVdhm83os=; b=Ni1MtkDP1kdk/cSOdEQqKz/ENiFSJQNdpLCk32k7PviLEskh2/fykp672vvKHRvZ+2 2ZZDcKksMUDZqR6FO6lOFNOhYyXiu7TqCs0cZeveP4Yi+k9YmaFQP3jvMAGcT44ZKDZb 9z/q88yQDn1huHRykS7xAXMmncaBs+F84CSfbvZFEfbel5bmAMHMWN96ZQ39Pe++RUEl n4a+Yvkfbl0IyUZaeAI9c/TmAsQiDq3CvjyDhz2XqxC9h1sqnRg88h/jwbDuQHcLJLmE M+UF5sS+e20syftxkABb6DmI2JrpaN29qY40KT36ZP2YSdTHLJ6L0094qFqkh2AhRstJ XknQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/fDD8yCGEers9Tgi4jVCsrpSgdsyYcxxNBlVdhm83os=; b=LcimW0M9cQRVe1sF4PdVa5OeFaL13wzjtiJbFSzvfkQ6wQdub8JgTf3A5qmLz8WA+U Me7JdLRpfotFEVembcAzzIlsn3VOXp3wj0YxK7mNTf3guXqoiyvTjldJxmE6Ux7tBy82 j1XJXeDeKZP4U8IcxIFQKHrH0aDxKrmWB4CFUo2uQBwhyuXxuEqyDSeRbrwOXYFpJI9j tlyh+99E5NJqPNof7QNL3Fw/g/cn8pmAY1Le7ATdPaqWhj+0VSd3bF3rFehNrF+fcaSl LxeXElrt1krMWeIS7b08Ft3LB/klMI0tsa0pEcz11l6JDzFoL/tRCazFYwv+bjnX50M8 TVVQ==
X-Gm-Message-State: ACrzQf2boW0tw+lMpHLwtt18wFXEgyoLEpgRcy2pUY/AmF8nfsxDmmIG UV4hB4HCJj9zz+EPeSS0MwN0DXdgrHkMsITW4MqJBg==
X-Google-Smtp-Source: AMsMyM5XkU7k7zI8R7Gx2yPZdFPaqrht19MgfQCrp734kcYC4QPZvHZNSEoF9Uu2uuQEtW8utXfXYEnPtviD+YhWoys=
X-Received: by 2002:a05:620a:46a0:b0:6ee:afc7:d9dc with SMTP id bq32-20020a05620a46a000b006eeafc7d9dcmr12093311qkb.189.1666339480790; Fri, 21 Oct 2022 01:04:40 -0700 (PDT)
MIME-Version: 1.0
References: <166626634180.56070.1120340716182021442@ietfa.amsl.com>
In-Reply-To: <166626634180.56070.1120340716182021442@ietfa.amsl.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 21 Oct 2022 04:04:04 -0400
Message-ID: <CAPt1N1k2MAfXuWwBc9x8ooq6qGdUpSOSLkfSzB1YsjkQX--4fw@mail.gmail.com>
To: Lars Eggert <lars@eggert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-homenet-naming-architecture-dhc-options@ietf.org, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
Content-Type: multipart/alternative; boundary="000000000000d3fb0d05eb86e424"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/S7hKnJat0hg2ziVHhQLBbL0h-Ow>
Subject: Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2022 08:04:43 -0000

On Thu, Oct 20, 2022 at 7:45 AM Lars Eggert via Datatracker <
noreply@ietf.org> wrote:

> I agree with the Discusses and Comments on this document - this simply
> isn't
> implementable as described.
>

I have no opinion on this per sé, but...


> My main reason for abstaining is something else though. This document has
> been
> worked on for almost ten years. While in the beginning, we might have
> expected
> or at least hoped that a solution in the shape that this document tries to
> describe would see adoption, it's become very clear that dynamic DNS
> services
> as described in Section 4 have won out here. These services are far from
> perfect, but at least some of the limitations in Section 4 have been
> addressed,
> and others are arguably a feature and not a limitation.


I'm deeply frustrated by this response. I think it's good to pay attention
to whether there could be market pressure for a given protocol, but when
the market has solved a related problem badly, this doesn't seem like a
good reason to say no to an actual solution to the problem. If you think
the document isn't any good, ask the authors to fix it, and don't publish
it until they do.

What the market has produced is a way for a user to subscribe to a service
that lets them keep a single domain name current with their external IP
address. It doesn't let them populate a DNS zone that they control with
arbitrary records. There exists no solution to that problem in the market
other than setting up your own DNS server and getting a delegation through
a registrar (which many of us who participate in the IETF do) or paying
somebody like godaddy to do it for you (which is mostly what non-experts
do).

Making it easier seems like a good thing. That's what this document
proposes to do. If it does it badly, or the wrong way, then you should be
able to criticize it on that basis. Not on the basis that, for a
substantial monthly fee, I can maintain the association between a single
name not of my choosing and the very-much-not-stable single IPv4 address
that my ISP provides to me.