IETF Logo Mail Archive

Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 March 2024 11:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A807C15108D; Wed, 27 Mar 2024 04:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 bD82zNiQzZda; Wed, 27 Mar 2024 04:53:08 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605B7C15108B; Wed, 27 Mar 2024 04:53:05 -0700 (PDT)
Received: from dyas.sandelman.ca (60-240-91-174.static.tpgi.com.au [60.240.91.174]) by relay.sandelman.ca (Postfix) with ESMTPS id AB0431F448; Wed, 27 Mar 2024 11:53:03 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="dkI4kQZO"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 07188A191C; Wed, 27 Mar 2024 22:53:01 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1711540381; bh=WUyL8PCEsLkSlsFJKogITK9dQQfsPf5DjJ3bSV93csQ=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=dkI4kQZO7BjwlzbW8WOLNH3kiokXRIVt+m+RfSKKEEfd0bjQUBDC4vZUTpADIuEAx t61PqPMq/Urvf0Az5lHyuXbjCIE6Y57kQe88kbmmDDge2zUuHIHBfssDuAnfvkx1+M vOgqcBbmghJWK+5eRwFDwhz7jLxfGp4EwarN//w3MFPLr6W/kUYvPI5tmIOopZK5N1 5xGRPIYUy8BM/x/Yu55zABMQUnHfHNaDdp943jthSRNeCtp/zjmuodOxOmsCfjfR9s xSScBfeN2dh4pA5x5dcmvVYGQR3qs07/Z165J8lyHwQOg9BSCB7AodKV+ewb0aUn6L ffWn4jPnLbCMg==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 04CB4A1918; Wed, 27 Mar 2024 22:53:01 +1100 (AEDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Martin Duke <martin.h.duke@gmail.com>
cc: The IESG <iesg@ietf.org>, opsawg@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org, mud@ietf.org
In-reply-to: <170966125692.33301.9731640824995434163@ietfa.amsl.com>
References: <170966125692.33301.9731640824995434163@ietfa.amsl.com>
Comments: In-reply-to Martin Duke via Datatracker <noreply@ietf.org> message dated "Tue, 05 Mar 2024 09:54:16 -0800."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 27 Mar 2024 22:53:01 +1100
Message-ID: <511281.1711540381@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/4tzMkA1Zj6Jh2Loa05K7eLRiRF4>
Subject: Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2024 11:53:12 -0000

Martin Duke via Datatracker <noreply@ietf.org> wrote:
    > (4.1) There's an editorial error here.

    > "An authoritative server might be tempted to provide an IP address literal
    > inside the protocol: there are two arguments (anti-patterns) for doing this."

    > I'm expecting two reasons someone might use an IP literal.

    > "The first is that it eliminates problems with firmware updates that might be
    > caused by lack of DNS..."

    > Yep, that tracks.

    > "The second reason to avoid a IP address literal in the URL is when an inhouse
    > content-distribution system is involved..."

    > But this is making the opposite point! It appears that this section is actually
    > presenting ONE (not two) reason to use IP literals, and then several reasons
    > that's a bad idea. So say that!

In my mind, an in-house CDN is a bunch of HTTP/FTP servers which just don't
have DNS names, because someone hacked the system together in an afternoon.
Let me think about how to rephrase that.  Or maybe it's really just two
examples of the same thing, and as you say, it's not two reasons, but two
kinds of one reason.

Or maybe I missed another reason to use literals.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.23.0 | Report a Bug | By Email