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> Thu, 02 May 2024 17:59 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 855E9C14F68B for <dnsop@ietfa.amsl.com>; Thu, 2 May 2024 10:59:18 -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.249, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 U4SmL3sA_af5 for <dnsop@ietfa.amsl.com>; Thu, 2 May 2024 10:59:14 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.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 EFE0BC14F5F1 for <dnsop@ietf.org>; Thu, 2 May 2024 10:59:13 -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 CCC6CE1E76; Thu, 2 May 2024 17:59:13 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id B7020148D43; Thu, 2 May 2024 17:59:13 +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-189191-1713786135-470.1362913-9-0@icann.org>
References: <RT-Ticket-1362913@icann.org> <rt-5.0.3-225992-1713566832-1739.1362913-9-0@icann.org> <647558F8-2FEF-4418-AE1C-3BDC3B22A89B@nohats.ca> <1cb4663f-9502-47db-a099-ce5147bb733e@desec.io> <94ea3a71-6c1c-10af-a71f-7cee34e8d0d4@nohats.ca> <F21226BA-266A-4BF8-AD17-0D908B10AC54@nist.gov> <rt-5.0.3-189191-1713786135-470.1362913-9-0@icann.org>
Message-ID: <rt-5.0.3-1375868-1714672753-112.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: fneves@registro.br, scott.rose@nist.gov, peter@desec.io, drafts-expert-review-comment@iana.org, nils@desec.io, dnsop@ietf.org, oli.schacher@switch.ch, q@as207960.net, christian@elmerot.se, daniel.salzman@nic.cz, paul@nohats.ca
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 02 May 2024 17:59:13 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_yI9t6awBIPfxknMs5ZP1uVOKag>
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: Thu, 02 May 2024 17:59:18 -0000

Hi all,

Following up on this; does the group agree that "_dnssec" is OK?

Thank you.

Best regards,

David Dong
IANA Services Sr. Specialist

On Mon Apr 22 11:42:15 2024, scott.rose@nist.gov wrote:
> On 20 Apr 2024, at 19:38, Paul Wouters wrote:
> 
> > On Sat, 20 Apr 2024, Peter Thomassen wrote:
> >
> >> The authors certainly don't insist, but we'd need to pick a suitable
> >> replacement for the "_signal" label.
> >>
> >> John proposed "_dnssec-signal" elsewhere in this thread.
> >>
> >> The authors would like to note that adding "_dnssec-" eats up 8 more
> >> bytes, increasing chances that bootstrapping will fail due to the
> >> _dsboot.<domain-name>._dnssec-signal.<nsname> length limitation.
> >> Other than this (unnecessary?) use case narrowing, this choice seems
> >> fine.
> >>
> >> That said, does this choice address your concerns?
> >
> > It would, but I would also be okay if it is just _dnssec.
> >
> 
> If the concern is that the label is too generic, “_dnssec” might be
> too generic as well. If it is to be more precise, go with _ds-boot or
> something more specific to the use case. I don’t have an
> implementation in the mix, so it this isn’t a strong opinion.   If the
> group agrees _dnssec is fine, then I am fine with it too.
> 
> Scott
> 
> =====================================
> Scott Rose
> NIST/CTL/WND
> scott.rose@nist.gov
> ph: 301-975-8439
> GoogleVoice: 571-249-3671
> =====================================

v2.31.3 | Report a Bug | By Email | System Status