Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

Ted Lemon <mellon@fugue.com> Thu, 07 January 2021 16:53 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 CBA643A102E for <dnssd@ietfa.amsl.com>; Thu, 7 Jan 2021 08:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Reybo4e9TZ3F for <dnssd@ietfa.amsl.com>; Thu, 7 Jan 2021 08:53:00 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC33A0FE7 for <dnssd@ietf.org>; Thu, 7 Jan 2021 08:52:59 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id z3so4636977qtw.9 for <dnssd@ietf.org>; Thu, 07 Jan 2021 08:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lvW/jnkquO6UtU2kjLuybA3lLbn1GYih2z9ZY1LJsbI=; b=F8BWm/+ZvXmCqvCUOeNK5YDQASHMn8NorUwETnaPOlkDryVVbFj5a8pTSvr3U15MdN t0ygF/RX6R2f1Kp5acSGi9sYz3n/zE69VUS36Igm5+/0pMHSoRqwKHSnHXBG24/TDFsx nElv442xyOje5NqWRqTulhCDvcCAtK1DQDH4g4FisRTMcVQ7rHbrWIa4Wwj8yaQudW+8 A1dwfjnoYop6OlIFkKzUAGAV6gsZVx4riJZrW+gmTX/Y4g6odY1KcLu726sfkMETF9An XbG1W/4M3KOoZbAiuI5i6Dycgu0p9pltkxDlULa0uCar3oSprTt31cDeFUm7O35amo6i hhUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lvW/jnkquO6UtU2kjLuybA3lLbn1GYih2z9ZY1LJsbI=; b=lJfPlVmUsJsgeLXRHOZF5nIMKdtN/t/+m487nCf1zGFIK6v0aWabc2AgO9bvYdrsf+ R/beQSYsxlluIVH7rALs7xS4dm771xYGGd2UhasDL3ehkTHdevM4vP3ZjMXW+xAurXTI AhAcJv2QZHpuk1XHGupir0Izv0lAJR+RTZ2EphC5U1ylXUnXVP6iMf6mEpDUTaskJEad Pd0WJvxDpT2M0ZtfvhJ2h9WKIbc3saGIzB5l99VT90Hwm+GsO0TfB+WhTfVzkVqW8Ebb Eop1sDvVvAkif/MJvLAGYn459MEkwvlJn7tNs8dj8AnQE9boK5DRxYEp4l4tjN0WIej2 aNUg==
X-Gm-Message-State: AOAM531lJ0iQkpMWn2CpbbpmH+P9QQwNXHgZwjD6c2G9QRdllW3r2Viz D1t9tYUyoJsnw1d0I3OOT3eMtQ==
X-Google-Smtp-Source: ABdhPJxgQxriTr3bfH47Xx5IOK4H1ljXDocuDni1H5rmBdCuv4bJZ2zBMrVynu4mWSsJYy/75FXa6g==
X-Received: by 2002:ac8:5296:: with SMTP id s22mr9223984qtn.343.1610038378861; Thu, 07 Jan 2021 08:52:58 -0800 (PST)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o30sm2982399qtd.24.2021.01.07.08.52.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 08:52:58 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <515D8853-DEFD-4DD6-9A61-7D27C4F3ED21@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2CB34A00-1234-4BE2-85C0-8257D36E84E5"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\))
Date: Thu, 07 Jan 2021 11:52:56 -0500
In-Reply-To: <CAJ5Rr7ZmVWRp8H1Kg2QVXFJKnrUK09J2iPHsVTDvSxFioAznUQ@mail.gmail.com>
Cc: Abtin Keshavarzian <abtink@google.com>, DNSSD <dnssd@ietf.org>, Jonathan Hui <jonhui@google.com>, Rongli Sun <rongli@google.com>
To: Kangping Dong <wgtdkp@google.com>
References: <CACce4dTbWCVwBityepJpb5FF4Rv43+DUev_0Ka+rVT9exZrJzA@mail.gmail.com> <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <CACce4dQZ708aaMdvmwhEurHDSdFAvLbzwpDWz=viig_2cX75Dw@mail.gmail.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <CAJ5Rr7bDSMv1uPDPXppG9e4OUEU7oriK9tVKD20=P3Kgb2q=0g@mail.gmail.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <CAJ5Rr7Yw33y2k=wo-ZXzFNP77=bucRcr2LxJxf+98e5oqK+fsw@mail.gmail.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <CACce4dToa2+FiYgzp5AvZjO7-UfHy5VSSZ4ED+PkHMVPBZTQAA@mail.gmail.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> <CAJ5Rr7ZmVWRp8H1Kg2QVXFJKnrUK09J2iPHsVTDvSxFioAznUQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/yxE-rTTBAJSeQ6KRugp2eIZYzzk>
Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 07 Jan 2021 16:53:02 -0000

On Dec 19, 2020, at 10:11 AM, Kangping Dong <wgtdkp@google.com> wrote:
> I have some questions when reading the related sections:
> 
> 1. in 2.2.5.5.2. Removing some published services <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#section-2.2.5.5.2>, we have:
> The second alternative is to send a normal SRP update, but as in the first alternative, 
> including a Service Discovery Instruction and a Service Description that delete the service being removed.
> Should the "delete" be "replace"? 

Delete is a type of DNS update. There is no “replace” in a DNS update. If you want to replace an RR on a name, you first delete the current version, and then add the new version. I have updated the text to make this clear.

> 2. What's the use case of supporting multiple TXT RRs?
> in section 2.3.1.2. Service Description Instruction <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-service-description-instruc>, we have:
> zero or more "Add to an RRset" TXT RRs,
>  
> Are there real use cases that we need more than one TXT RRs? What is the expected behavior
> for the advertising proxy to publish this service with multiple TXT RRs? (I think DNS-SD requires
> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated to form a new TXT RR?
> If there is no such use case, should we require a single TXT RR? It will be easier to implement on both
> client and server side and consistent with DNS-SD. thoughts?

It’s relatively unusual, but we have to support it—SRP is not just for IoT use cases, where I agree that multiple TXT records are unlikely. See https://tools.ietf.org/html/rfc6763#section-6.8

I’ve submitted an update that contains new text to address the delete/replace concern.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ <https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-08.html <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-08.html>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-08>