Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)

Ted Lemon <mellon@fugue.com> Wed, 05 July 2023 15:03 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113C2C151701 for <dnssd@ietfa.amsl.com>; Wed, 5 Jul 2023 08:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20221208.gappssmtp.com
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 2AZgYLv00u-j for <dnssd@ietfa.amsl.com>; Wed, 5 Jul 2023 08:03:51 -0700 (PDT)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4618AC15108D for <dnssd@ietf.org>; Wed, 5 Jul 2023 08:03:51 -0700 (PDT)
Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-634a3682c25so51499806d6.3 for <dnssd@ietf.org>; Wed, 05 Jul 2023 08:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20221208.gappssmtp.com; s=20221208; t=1688569430; x=1691161430; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Hx9uj3PdHzSwSk+tmXPmkwarb101fVQoCeAdcuS8xqU=; b=nU59e6WAYzl5Zh4ESBcirWaAQR3OD072IoCjPZO/T/ErNPpaoXdvttaJhRIMFWDQWb WqCYHXOmHAwU4LDFUyN1x4SGrw73S9ARNtmLBYYFm3BPbrlBC/3KhqseLWoGgpqmv2mE AAWUvGPCC8G/GjRwJW7EtruPTD49WcAxXnLDJAtraeeDlcaLHhRXhJlDMKppSy+9/1II 7XC1ZTR3Tve0XaV7/52xgN5fqRENEEqPL3aMU52WRBV90QW4UALCLTzrJi5LXq6MEnyq 69VqKELyOQY7NtRUpl4YAWYGZ3HoaPL3hqxJO0ZPdFgbFN1YYrucJ1XbDLNMqqIkVDe4 v2hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688569430; x=1691161430; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hx9uj3PdHzSwSk+tmXPmkwarb101fVQoCeAdcuS8xqU=; b=M4V6wdO7Q4+PZNEMR0r+3LtF+tDS7/++p7XR2EZJVE5kZpuA9YI2VSgtiEWCUQVfMm AJEOlwJQOgObOWLycKqNzqMQ2I0idBrB5UqsLyCLsXds4Ufk/259nXH7P/uuVK1/d8gD IwQXnYUSxBp6lOn8tkNQmZmFMR6oXTFZTT3E8NVi9k8BBuIZIYgibbA8BISXHzOA8UJ0 6llS7ORwm+IXb8vNQ3LWhN9IcNfXvKHDNN9/ZIUC/7S+eIKCx0jyb0HPFGpqshw7aRWX LMBRRYNvcNsxd5DHR8ADQfl5IyFq5cnmXR5yO5y4RKYE9eTqBHELsJPl6SotePLG0ew3 AN0A==
X-Gm-Message-State: ABy/qLZoxruQRAGtqT70Iwmqa480jZsPwihohEEBwQ6T9FNoTH+nDVoS IS94STtWyLeTlMdpPVtnpZKTh+kwT5VcuUOqx9GLWqb0WKBhNZoV1lU=
X-Google-Smtp-Source: APBJJlHEYZnUJAxFtAHEOQ03lhiNZCCcY9EjppVnuOyTMdun01G45W51q+HI4MBHLSTRO4ct59OPsHACPgpoBxlITN4=
X-Received: by 2002:a05:6214:2aa3:b0:631:eb39:b7a6 with SMTP id js3-20020a0562142aa300b00631eb39b7a6mr18936052qvb.33.1688569430216; Wed, 05 Jul 2023 08:03:50 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB1978200A6FCB7259C8B3B0C5FD2EA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1knidoVUHDFvd+6BW2msCVkjRfRi3COxpHpZKtjGFZFOQ@mail.gmail.com> <DU0P190MB1978076949E643E64EDC73E7FD2FA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978076949E643E64EDC73E7FD2FA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 05 Jul 2023 11:03:39 -0400
Message-ID: <CAPt1N1mi+6ma=MyEofp_gzRF9So1=EhKnXiqwwr8gAPxK=ecyA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000112c4305ffbeb5f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/EE-QICFWcGalycP99LdblwFwbOo>
Subject: Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2023 15:03:52 -0000

Op wo 5 jul 2023 om 03:06 schreef Esko Dijk <esko.dijk@iotconsultancy.nl>

> The “why” is maybe not so relevant – if something is optional in a spec to
> NOT do, implementers will jump on it by NOT doing the thing. They even
> don’t implement RECOMMENDED functions in my experience ;-)
>
> For the testers, it means they have to test for the possible variants and
> need to know what to test against.  Right now as specified there’s 3 cases
> possible: 1) return KEY ; 2) return RCODE=0; 3) return RCODE=5 .
>

Okay, that makes sense. This is a pretty late clarification. Chairs, do you
object to me including this in the forthcoming update?

>