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

Martin Duke via Datatracker <noreply@ietf.org> Tue, 05 March 2024 17:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E46DEC14F69E; Tue, 5 Mar 2024 09:54:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsawg-mud-iot-dns-considerations@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, henk.birkholz@sit.fraunhofer.de, henk.birkholz@sit.fraunhofer.de
X-Test-IDTracker: no
X-IETF-IDTracker: 12.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <170966125692.33301.9731640824995434163@ietfa.amsl.com>
Date: Tue, 05 Mar 2024 09:54:16 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/_-6Rosd-brRf1ukaS5IT_KPBzYo>
Subject: [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
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: Tue, 05 Mar 2024 17:54:17 -0000

Martin Duke has entered the following ballot position for
draft-ietf-opsawg-mud-iot-dns-considerations-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(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!