IETF Logo Mail Archive

[DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

David Dong via RT <drafts-expert-review-comment@iana.org> Fri, 19 April 2024 22:47 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A995AC151092 for <dnsop@ietfa.amsl.com>; Fri, 19 Apr 2024 15:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level:
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 weoVHIf2z-yM for <dnsop@ietfa.amsl.com>; Fri, 19 Apr 2024 15:47:12 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (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 64284C14F61E for <dnsop@ietf.org>; Fri, 19 Apr 2024 15:47:12 -0700 (PDT)
Received: from request6.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 3C096E16DD; Fri, 19 Apr 2024 22:47:12 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id 372216AEA4; Fri, 19 Apr 2024 22:47:12 +0000 (UTC)
RT-Owner: david.dong
From: David Dong via RT <drafts-expert-review-comment@iana.org>
Reply-To: drafts-expert-review-comment@iana.org
In-Reply-To: <rt-5.0.3-120814-1712971453-1671.1362913-9-0@icann.org>
References: <RT-Ticket-1362913@icann.org> <rt-5.0.3-94165-1712946300-1756.1362913-9-0@icann.org> <rt-5.0.3-94735-1712946676-1212.1362913-9-0@icann.org> <d0b9a6fc-9764-0232-22d0-f693b2c4623e@nohats.ca> <68dc75b3-afa3-4c46-9ddd-5440e9b85446@desec.io> <rt-5.0.3-120814-1712971453-1671.1362913-9-0@icann.org>
Message-ID: <rt-5.0.3-225992-1713566832-1739.1362913-9-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1362913
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: david.dong@iana.org
CC: paul@nohats.ca, nils@desec.io, peter@desec.io, dnsop@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Fri, 19 Apr 2024 22:47:12 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oUEPoulTtS5wwfB2Fj2liXcT0no>
Subject: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2024 22:47:16 -0000

Hi Paul,

Just a ping on this; thank you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Sat Apr 13 01:24:13 2024, peter@desec.io wrote:
> Hi Paul,
> 
> On 4/12/24 22:36, Paul Wouters wrote:
> > However, I would urge the authors/WG to pick a less generic and more
> > specific name than "_signal", such as "_dnssec-bootstrap". Especially
> > because there is also the well known "Signal" message client. Also,
> > in case of future different signaling, the current name might become
> > confusing.
> 
> The signaling record names actually have two underscore labels, and
> look like (taking nohats.ca as an example)
> 
> _dsboot.nohats.ca._signal.ns2.foobar.fi.
> 
> The specific type of signal is already indicated by the first label.
> Other signaling use cases would use a different first label. (draft-
> thomassen-dnsop-mske has an example.)
> 
> The _signal label generically indicates that ns2.foobar.fi likes to
> signal something about nohats.ca. Its presence is needed to allow
> separating the object from the source without ambiguity.
> 
> We could change _signal to something else, but not to _dnssec-
> bootstrap as that's not generic. Suggestions are welcome.
> 
> 
> I'd like to add some considerations:
> 
> - The spec has quite a few production implementations (see Section 8),
> and changing them would come with significant costs.
> 
> - I don't think the _signal label is in use for the Signal messenger.
> Even in case it's used in the future, a collision (in terms of prefix
> labels + rdtype) seems unlikely.
> 
> As there would be significant costs, but no tangible benefit, perhaps
> we should not do this.
> 
> 
> Further context: The structure of the signaling name is the result of
> the DNSOP Interim [1]. Details on rejected alternatives can be found
> in [2].
> 
> [1]: "Open Issue 3" in https://datatracker.ietf.org/meeting/interim-
> 2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-
> authenticated-dnssec-bootstrapping-00.pdf
> [2]:
> https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/
> 
> Thanks,
> Peter

v2.23.0 | Report a Bug | By Email