[core] Requiring mDNS participation for a node to be discoverable

Carsten Bormann <cabo@tzi.org> Wed, 21 February 2024 08:03 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A70C14F6EC for <core@ietfa.amsl.com>; Wed, 21 Feb 2024 00:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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
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 f-SJQ9OY3yjp for <core@ietfa.amsl.com>; Wed, 21 Feb 2024 00:03:28 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4BBB2C14F6BA for <core@ietf.org>; Wed, 21 Feb 2024 00:03:26 -0800 (PST)
Received: from smtpclient.apple (p548dcbf2.dip0.t-ipconnect.de [84.141.203.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4TfpgH66dGzDCgf; Wed, 21 Feb 2024 09:03:23 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Wed, 21 Feb 2024 09:03:12 +0100
Message-Id: <3EB788AE-F999-4B11-9F58-D330226C37A4@tzi.org>
To: core@ietf.org
X-Mailer: Apple Mail (2.3774.400.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/1wCGflhT5VpVBYxiVhsAWd9rjQM>
Subject: [core] Requiring mDNS participation for a node to be discoverable
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2024 08:03:31 -0000

The perennial discussion about link-local names has been newly revived over in the HTTPBIS WG list.

The newest contribution
<https://www.w3.org/mid/CAPDSy+7h3SSeKyA2CUazyWWsUi6+xhn2i91zNW1uz4NhgOGkug@mail.gmail.com>
proposes a best current practice (BCP) that essentially requires a node to run mDNS so that others are able to find it (IP address and which link it is on).

It seems to me this discussion is of interest to the constrained devices community.

Grüße, Carsten