Re: [dnssd] Second WGLC for draft-ietf-dnssd-srp

Ted Lemon <mellon@fugue.com> Tue, 23 August 2022 02:43 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 AFE95C14CE42 for <dnssd@ietfa.amsl.com>; Mon, 22 Aug 2022 19:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.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 HL5qbSS-olwr for <dnssd@ietfa.amsl.com>; Mon, 22 Aug 2022 19:42:58 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 8A4DAC14E514 for <dnssd@ietf.org>; Mon, 22 Aug 2022 19:42:58 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id j6so9348808qkl.10 for <dnssd@ietf.org>; Mon, 22 Aug 2022 19:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc; bh=wXsyNFK7qf9ax69HEseEeVhwi266a+jqHeCUbGaKAdg=; b=xRq0PsXh/vm9PE36u8Tv5xoYDs1NCVVfZG50VxR35sSpQs8FrTCRp2oP0oGtTJmjTM dctuPAvI5af/yAXsqvvLEJZBUAJYqQBSUMLA5AqK7dddQB/mRN1Kl95kY5aidRsTYzBa MYMuE8d/O7b1E0qL0pp52eVK1p21IGXCyOVYzu4UlrH8zg9EeihqtTvTOhYsTXKqE7fl 2XIzw9RVAQMJYJEoAufeFGKUQhE4GB+n72RZI8V1IXfTYEqbR0FQiSv3aZ+k9BSOxFv7 Wkq4/Nbsn+Fe2T6wLtlgFCKhcRoXMrWI9AUGNJ1Ivw8BrrJIB25EaHJzicjuchXMi46P i3bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc; bh=wXsyNFK7qf9ax69HEseEeVhwi266a+jqHeCUbGaKAdg=; b=iMe8X4Ryc9gva2UCIFeP6OaeOGI0sYlvvjy0dSPDiLyUeCQuZvGCwDIDji6NzU5BKN mir1titgY3bttpCVpmNVQe48ccwY3G6/WKgLKjp02SFthx1IUzV2q32xER6uX10GwnYH VTdTfFz+FZ8sh4uWuZiBBONJ81LshfXf+KG/8FCdHR/U5XODnSbYIFd/UlmZBLE3pm3C /odgnuAaLcn4IqK4cljtDuEYLTBeXcFM59ej328GNU8cepyMhNXwGJCQIhWXTcblcNI2 PANCWgZGtvJgtJsPb6t4YcGyjm9XWLUuT5T2VPNBcxdcgm7E//5NXsRT/eeLFzfK7Ycf 1Aow==
X-Gm-Message-State: ACgBeo3z9vNjzZgsTFlWrJnFgTlV/pGeFd1OhOoQEx9db6MIkCBw8rVh XBLSkTV1G0yBkGONnlgusc+RUQ==
X-Google-Smtp-Source: AA6agR6CfW6osDTdsqsZWPiRhIlGB+NN/DURfALVaClP6a2JDwsOWI+59pqs+5hbbpKUv0T2rdu0Yw==
X-Received: by 2002:a05:620a:2848:b0:6af:6c3f:7141 with SMTP id h8-20020a05620a284800b006af6c3f7141mr14603597qkp.548.1661222577264; Mon, 22 Aug 2022 19:42:57 -0700 (PDT)
Received: from smtpclient.apple ([2601:18b:300:3380:7551:1481:6815:9126]) by smtp.gmail.com with ESMTPSA id l8-20020a05620a28c800b006bbc3724affsm11567975qkp.45.2022.08.22.19.42.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 19:42:56 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F6CF190C-F38E-44B4-A9FD-350E154B5D05"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 22 Aug 2022 22:42:56 -0400
Message-Id: <DA2F7482-162D-47E0-A173-EB5ABE3D9CEF@fugue.com>
References: <4d5a01d8b5d4$bc7a8570$356f9050$@yahoo.com>
Cc: Nathan Dyck <nathan@nanoleaf.me>, Esko Dijk <esko.dijk@iotconsultancy.nl>, David Schinazi <dschinazi.ietf@gmail.com>, DNSSD <dnssd@ietf.org>
In-Reply-To: <4d5a01d8b5d4$bc7a8570$356f9050$@yahoo.com>
To: g_e_montenegro=40yahoo.com@dmarc.ietf.org
X-Mailer: iPad Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/T1D_s73n5wZCs4Jx6NQUu3e0Gvs>
Subject: Re: [dnssd] Second WGLC for 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: Tue, 23 Aug 2022 02:43:02 -0000

Thanks, Gabriel!

Pull request is here:

https://github.com/dnssd-wg/draft-ietf-dnssd-srp/pull/new/Gabriel-20220822-01

On Aug 21, 2022, at 11:11 PM, g_e_montenegro=40yahoo.com@dmarc.ietf.org wrote:
> Section 1, introduction.
>  
> DNS-SD is used without first defining it. Suggest this:
>  
> OLD:
> DNS-Based Service Discovery [RFC6763] is a component of Zero Configuration Networking
> NEW:
> DNS-Based Service Discovery [RFC6763] (DNS-SD) is a component of Zero Configuration Networking

The RFC editor would have dinged me for that too, but might as well fix it now. :)

> Section 2.1.1:
>  
> "Hosts that support SRP Updates using TLS use the "_dnssd‑srp‑tls._tcp.<zone>" SRV record instead."
>  
> Besides the TLS case, any clarification on updates for other DNS-over-foo cases such as for DTLS or QUIC or DNS-over-HTTPS? Privacy section already has references to DNS-over-TLS and DNS-over-DTLS, but nothing on DNS-over-QUIC (rfc9250) yet.

This is actually a really significant change, which I don’t think we should do in last call. If the working group is interested in working on this, I think we should just write a document that describes this. I don’t think you’re wrong, mind you. But e.g. the benefit of DNS-over-foo is fairly minimal for IoT devices, and for non-IoT devices there’s no additional privacy gained by any of the other protocols you’ve mentioned. This is not to say that we shouldn’t do it, just to say that it’s not urgent, and we should have a use case in mind. :)

> Section 8.1
>  
> OLD:
> IANA is requested, with the approval of IAB
> NEW:
> IANA is requested, with the approval of IAB (per https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/)

I don’t want to add this reference—it’s not an RFC. We didn’t do this for previous documents that took advantage of the registry, so I don’t think it’s necessary. Is there a reason you think this is newly necessary in this case?

>  References:
>  
> OLD:
> https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03
> NEW:
> https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-02.html
>  

Already done—thanks!