From nobody Wed Jan 6 04:28:17 2021 Return-Path: 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 A1BEB3A045E for ; Wed, 6 Jan 2021 04:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 aWWwK9c1_kxC for ; Wed, 6 Jan 2021 04:28:14 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 906673A046A for ; Wed, 6 Jan 2021 04:28:14 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id j1so1481092pld.3 for ; Wed, 06 Jan 2021 04:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QomYGfXWc9pq2W1Q0Ar24+JTVEFcwO0mu2IUBAe+c88=; b=Oqfxr5FD6f/2KQglwA8gsxR5XapzJ7CUy3h6SXKVvHjy16Py2WN7joev3kqOldLok7 NwknTCvxPBa+iSf2TueDUy9O/BSo39dPZtSqj6lJzD7l4wXb/sqvQ8/UDexD066KRNIt 7mdGVS6cFuYt5hoeO0mit9fOz/fm21HY2Dc56PuUENHJZZGpKcLu5dI8SDRsI+1AM4Z3 fTk7IdWKKvKDfcbXOT2YNHvo08BiCF++QN2uY7cvmnp3MW0J8kx8fhbO+WuGA0ebwg/q zZEjYM1Sifb6QZgYT4XXHfThpp75CbO/yaw8XmBuiANSkGBhW7yVA4CbIoFZ0/VNpa0J 3lqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QomYGfXWc9pq2W1Q0Ar24+JTVEFcwO0mu2IUBAe+c88=; b=mlu3ar/duxsOOovLLjHkGNa1czqC+92g4guTDL5bgrBh5+d7AlD9vgisEzjhyW+ozg npMHulKM65ZF7YN7IyC4sNGCTsiumlJNViLS0n22z12K3NUMBZFaxGG06Q4cKiB1Oahw zhmvKNH0kZ6YmaUYhRg1wolUqkdicjv4Tpw0YX/iYJBS58v9cVs5zAvolIWnVrYKit2O Eqs7l24pMHbi2BIwUnfxjxZ9s2fFL6PyIQqzRyEAE/YvqiDX+EGVFIeJopDyY+414RM0 BpONK3jS07vmujb9jUAh5odjzUWQo3LRy28IWhHtMxtE/IcH6ublyWYBbt2yn90b+wyM o7Rg== X-Gm-Message-State: AOAM533PD7+A76vrt19QCS6y4fwH0FLKI9IsdcrauLVxneACwcPofE3s bBy4fegjG/9V8FkiAZX7L4on6GoMar1ILnrMuIojnD1x2KU= X-Google-Smtp-Source: ABdhPJwKh6CO464I5XywD5iKBtfnvOq7AtGeL8IhoPYlWSzls+UhTo4JpCxrEKuFb9z49RFG7vjVwwy9OlWaWf4D9DU= X-Received: by 2002:a17:902:c215:b029:da:b079:b9a3 with SMTP id 21-20020a170902c215b02900dab079b9a3mr3915685pll.67.1609936093855; Wed, 06 Jan 2021 04:28:13 -0800 (PST) MIME-Version: 1.0 From: David Schinazi Date: Wed, 6 Jan 2021 13:28:02 +0100 Message-ID: To: DNSSD , Barbara Stark Content-Type: multipart/alternative; boundary="000000000000fc43cc05b83a74d8" Archived-At: Subject: [dnssd] Should DNSSD meet at IETF 110? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:28:16 -0000 --000000000000fc43cc05b83a74d8 Content-Type: text/plain; charset="UTF-8" Hi DNSSD enthusiasts, Happy New Year 2021! Are there DNSSD topics that you would like to discuss at IETF 110 (early March 2021, virtual)? If yes, please share them here. In particular, the chairs would like to see discussion of those topics on the list to justify scheduling an in-virtual-person meeting. The deadline for requesting a meeting is 1/22, so please start these discussions ASAP so the chairs can make a determination before then. Thanks, David for the chairs --000000000000fc43cc05b83a74d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi DNSSD enthusiasts,

Happy New Year 20= 21!

Are there DNSSD topics that you would like to = discuss at IETF 110 (early March 2021, virtual)? If yes, please share them = here. In particular, the chairs would like to see discussion of those topic= s on the list to justify scheduling an in-virtual-person meeting. The deadl= ine for requesting a meeting is 1/22, so please start these discussions ASA= P so the chairs can make a determination before then.

<= div>Thanks,
David for the chairs
--000000000000fc43cc05b83a74d8-- From nobody Wed Jan 6 04:36:36 2021 Return-Path: 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 8A8563A0688 for ; Wed, 6 Jan 2021 04:36:34 -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, RCVD_IN_DNSWL_BLOCKED=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.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 CrCoYp49QlNS for ; Wed, 6 Jan 2021 04:36:33 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 5E5863A0FD5 for ; Wed, 6 Jan 2021 04:36:10 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id r9so2555859ioo.7 for ; Wed, 06 Jan 2021 04:36:10 -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=pRK5oeA+zqySR1h/Ya8NzzhVfdsdaRQJdxfu5lbxCkQ=; b=KMStYbiz2jfux2ERXYFE0OBvEf9suhJZWlUhbmii4F7dwgT9m+5PjlcD4bLq2gqqbM Ga7RLl1Uy5rJUiUrFBf11G0i9wZGBL3zRFpHnthJA6d9bM6YCk5xsCKPL5ujO8Bcjavb y8LjWZONmVrRWmNr/CE9l0ROu/nHETlBBaxx8c/nGuGcx8d7a7YqnE4Sa1DwFDOBCcxh l1X8goiu3PJ2+9yatlnyAGm08+NVS+/Lf5MdTCWbo3cOEj9bwLoWK5/IjC0KQfgFZlI3 Sp8CG0LjEJBApYAF5U5ICgFyd1S+gswG7gynqPNvOifqpDjQS+IWlSn851y2QDb6S5gK xu8g== 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=pRK5oeA+zqySR1h/Ya8NzzhVfdsdaRQJdxfu5lbxCkQ=; b=qMfG8iGMHtUEn4VxKfMl785E6DADO9PIGr6SvVqo8zOtL9wFrInZNm5q2d2RX9Agtl qvu4jGbE63YTnhkfWqcEzsr2/Z+U91xDFoGemzD+/rkJ6YwRfQrsxJfU8C7YddrKLCqI B836p5bUdMBEaJ0lI2L5SXJgzhSjGqoZHOpuOoXgVh4CwYoTA2oWYpg7KwYvX+chem4m 9/412VRRz0Q89wnb+cRko2ZJWqhVmDJUkJ2xQlJt9ul3cA58V1vE8IJxBgM0h2bkDxyc lTCvkS1DgJZlkAYjiaQnK+SlwnnMllE9EKY8kpGD0GlnvEN3+tW/sN/bZQiWNH3vf+xQ jhEw== X-Gm-Message-State: AOAM5330xzBqfDaccVefuJwX9gPSfTD0+L5s9gE6Vm+gvEkg64oMXIOZ BT6JXJ6yAmSqdMJHi09AM87a0w== X-Google-Smtp-Source: ABdhPJxfB9vhSk58NZjBZvh7/wf86a7H/UKfxR3vjv8NRJFgGUlym6ZCSQPcYNI9Y4MmZZBp+hu19A== X-Received: by 2002:a05:6602:45c:: with SMTP id e28mr2646437iov.196.1609936569667; Wed, 06 Jan 2021 04:36:09 -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 d5sm1939649ilf.33.2021.01.06.04.36.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 04:36:09 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_51F02A31-0008-42B4-95BA-7BB00D68C83D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Wed, 6 Jan 2021 07:36:06 -0500 In-Reply-To: Cc: DNSSD , Barbara Stark To: David Schinazi References: X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: Subject: Re: [dnssd] Should DNSSD meet at IETF 110? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:36:35 -0000 --Apple-Mail=_51F02A31-0008-42B4-95BA-7BB00D68C83D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 7:28 AM, David Schinazi = wrote: > Are there DNSSD topics that you would like to discuss at IETF 110 = (early March 2021, virtual)? If yes, please share them here. In = particular, the chairs would like to see discussion of those topics on = the list to justify scheduling an in-virtual-person meeting. The = deadline for requesting a meeting is 1/22, so please start these = discussions ASAP so the chairs can make a determination before then. Yes, please. I think you=E2=80=99ve been seeing discussion of the srp = draft on the mailing list. We also need to discuss the advertising proxy = draft, and hopefully adopt it. We will also be talking about an = autonomous replication solution for SRP, which should be ready to = discuss in March. It might be good to do anotther DNSSD+Homenet meeting, = because then we could talk about the related work going on with stub = networks. --Apple-Mail=_51F02A31-0008-42B4-95BA-7BB00D68C83D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 7:28 AM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
Are there DNSSD topics that you would = like to discuss at IETF 110 (early March 2021, virtual)? If yes, please = share them here. In particular, the chairs would like to see discussion = of those topics on the list to justify scheduling an in-virtual-person = meeting. The deadline for requesting a meeting is 1/22, so please start = these discussions ASAP so the chairs can make a determination before = then.

Yes, please. I = think you=E2=80=99ve been seeing discussion of the srp draft on the = mailing list. We also need to discuss the advertising proxy draft, and = hopefully adopt it. We will also be talking about an autonomous = replication solution for SRP, which should be ready to discuss in March. = It might be good to do anotther DNSSD+Homenet meeting, because then we = could talk about the related work going on with stub = networks.


= --Apple-Mail=_51F02A31-0008-42B4-95BA-7BB00D68C83D-- From nobody Thu Jan 7 08:02:56 2021 Return-Path: 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 9C03C3A124F for ; Thu, 7 Jan 2021 08:02:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mHuL_pESbkrc for ; Thu, 7 Jan 2021 08:02:49 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 3736B3A1243 for ; Thu, 7 Jan 2021 08:02:48 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id 22so5819642qkf.9 for ; Thu, 07 Jan 2021 08:02:48 -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=y9m7N5VE6BN6EZUMPVOzcxiDjEc8g0GxV11pFzlXadA=; b=uBYSFFcSGwpZ7JL8OY/pzh1SI3WrelMtXEJFMEYBBd8S5KK05qlE7aIAFwWOb2usCj kXhjZQlAdOuUm9RIx//I3RaLBBjqeASZKUMYraqQ6tEa2cyvjpKP6M/HLfae87UPQWos 0AE6BS7yxjNfsOVHoJmRDFghDXM1SVCTJgtZ6MKOTWmA0ILzdOu97tdAap9PLcqievEW 9W1Z93wlXryNoJGENVgRgNOKzfMpArQqwY618zyBW0UJji82SnF90GaX5hzoxJaib8+L AqVx/pnRrbc00PfhhgK62XdrD1n1LlRX5sMiETKGblFIGjagSYaYR3+JJPcRq3LRdBHc GGLQ== 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=y9m7N5VE6BN6EZUMPVOzcxiDjEc8g0GxV11pFzlXadA=; b=oVlYbJxxW2JMasBk8qMKAiLS3ORwA96sXo6dzjYDG0P3wUrytVHBT1Cc/prKuFRgsw /32U+ijK64i9Tes6I1ynJkh7JHQbLOG6ZUvni7BdpFHQzF2cfvGvQ3YzGjP2byjXpNRr tv6B5jy4/zEXgmHgqiOiHoDUsN/WjTUZwNvXa7P4KWsEcanmUPpPsj9v/8nIDyIxesjE 9H1S9+RfniL8nodANrF9BkxNWxm4VDyA2IjR/C05yQe8eRQFfYtJ9iRoz71FLyGLg3vP NUvZ8DY2sbWSS0a9LQeMZlCCQC5MbBkiD2Fb3GlcQzesPJhV5THQomk/x38MqWYJs9Qz uzsA== X-Gm-Message-State: AOAM531+vpjMfF9dwIqCbbBcQROCij07TRqTGuBPXvfcceWJGmK6rljD q4HPKXySOAs625kx2PagVg9GNw== X-Google-Smtp-Source: ABdhPJyWEvy35TY8SJuxIZgPihCkt0ZnGlo51JpS96ikMsxvDjZx7d3smjbqtizeA81bShY++uH4Tg== X-Received: by 2002:ae9:e219:: with SMTP id c25mr9445592qkc.443.1610035367948; Thu, 07 Jan 2021 08:02:47 -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 a9sm3259892qkk.39.2021.01.07.08.02.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 08:02:47 -0800 (PST) From: Ted Lemon Message-Id: <2BAE79F3-ED93-4B32-A82C-545063970286@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB12DAE1-3B77-41B9-8A47-C7AC9A1B1B5A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Thu, 7 Jan 2021 11:02:45 -0500 In-Reply-To: Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun To: Kangping Dong References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:02:53 -0000 --Apple-Mail=_AB12DAE1-3B77-41B9-8A47-C7AC9A1B1B5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 19, 2020, at 10:34 AM, Kangping Dong wrote: >=20 > Sorry, another question :) >=20 > In section 2.3.1. Validation of Adds = , we have: >=20 > SRP Updates consist of a set of instructions that together add or = remove one or more services.=20 > Each instruction consists either of a single add, a single delete, or = a delete optionally followed by an add.=20 > When an instruction contains a delete and an add, the delete MUST = precede the add. >=20 > What is the use case of the "single add"? To my understanding, the = "delete + add" pattern is > for resetting the service to our current SRP update. So the "single = add" pattern is for updating > the existing service, for example, adding one more AAAA RR, right? The PTR add can just be an add, because there=E2=80=99s a 1:1 match = between a service name PTR record and the service instance name that is = its target. But this text is indeed confusing, so I=E2=80=99ve updated = it: Each instruction consists some combination of delete updates and add updates. = When an instruction contains a delete and an add, the delete MUST precede the add. > I think, for most SRP clients, it will be more convenient for them to = track all IP Addresses and > always update with the whole IP addresses list rather than depending = on this "update" model > and register the addresses separately. The server, I think can also be = simplified. Thoughts? Indeed, the single add doesn=E2=80=99t make sense=E2=80=94the client has = no way of knowing if there may be stale data present on the name. > Another issue with this sentence is that, the Service & Host = Description Invalidation requires: > exactly one "Delete all RRsets from a name" RR, > Seems disallowing the "single add" pattern?=20 That=E2=80=99s right. The model of having the client partially update = its data wouldn=E2=80=99t be consistent with the fact that SRP updates = are essentially blind updates. So yes, the client always has to send all = the data for any instruction, and that means we need a delete for every = Host instruction, and a delete for every Service Description = instruction. This isn=E2=80=99t needed for the Service Discovery = instruction because there can only be one PTR record on a particular = service type pointing to a particular service instance name=E2=80=94if = it=E2=80=99s there, there=E2=80=99s no need to delete it before adding = it. --Apple-Mail=_AB12DAE1-3B77-41B9-8A47-C7AC9A1B1B5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 19, 2020, at 10:34 AM, Kangping Dong <wgtdkp@google.com> = wrote:

Sorry, another question :)

In section 2.3.1. Validation of Adds, we = have:

 SRP = Updates consist of a set of instructions that together add or remove one or more = services. 
Each = instruction consists either of a single add, a single delete, or a = delete optionally followed by an = add. 
When an = instruction contains a delete and an add, the delete MUST precede the = add.

What is the use case of the "single add"? To my = understanding,  the "delete + add" pattern is
for resetting the service to our current SRP update. So the = "single add" pattern is for updating
the = existing service, for example, adding one more AAAA RR, = right?

The PTR = add can just be an add, because there=E2=80=99s a 1:1 match between a = service name PTR record and the service instance name that is its = target. But this text is indeed confusing, so I=E2=80=99ve updated = it:

        =     Each instruction
   consists some = combination of delete updates and add updates. When an instruction = contains a delete and an add, the
   delete MUST precede = the add.

I = think, for most SRP clients, it will be more convenient for them to = track all IP Addresses and
always update with the = whole IP addresses list rather than depending on this "update" = model
and register the addresses separately. The = server, I think can also be simplified. = Thoughts?

Indeed, = the single add doesn=E2=80=99t make sense=E2=80=94the client has no way = of knowing if there may be stale data present on the name.

Another issue with this = sentence is that, the Service & Host Description Invalidation = requires:
exactly = one "Delete all RRsets from a name" RR,
Seems disallowing the "single add" = pattern? 

That=E2=80=99s right. The model of having the = client partially update its data wouldn=E2=80=99t be consistent with the = fact that SRP updates are essentially blind updates. So yes, the client = always has to send all the data for any instruction, and that means we = need a delete for every Host instruction, and a delete for every Service = Description instruction. This isn=E2=80=99t needed for the Service = Discovery instruction because there can only be one PTR record on a = particular service type pointing to a particular service instance = name=E2=80=94if it=E2=80=99s there, there=E2=80=99s no need to delete it = before adding it.

= --Apple-Mail=_AB12DAE1-3B77-41B9-8A47-C7AC9A1B1B5A-- From nobody Thu Jan 7 08:06:40 2021 Return-Path: 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 A5DA93A1224 for ; Thu, 7 Jan 2021 08:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 y4P6F7JNlD5q for ; Thu, 7 Jan 2021 08:06:38 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 2C33C3A0F48 for ; Thu, 7 Jan 2021 08:06:38 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id b9so4554686qtr.2 for ; Thu, 07 Jan 2021 08:06:38 -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=ewHykgbX4jYszAFd9Ju6SFx6PD7EZfLpBnqlKesWxso=; b=o/G/BgCDemp+KE2hQm0yLwpY1jThOZM03QXCa+FIwMY7dgT0PniNwuAT75ygoJ5oUz YrJQTZ7hPVdn0BsWlVLvTSxud/DEzxDWJ6tHrXHJxlGgkSTnkDrFjrl+Kiv3m7RRS7xI vKvguUlDOH9be4mZiK9GQUMJbUtwYOzLoBsmzvQCdg2INKNBLdHdMzTgmU0OhkMOFdQC NWtskcnGU7hcgShKHhsqdxwSxcIOIilWmWoFEXlfsZibPeQIZzYTXqrcQJFs0z+xcBFF FCtQRnu+I8oQIGFPkPu3bJsvMknJVEwZA0vuu21dmEW9EiUgBPY0PxhIBfxtedvEg6cz zHSg== 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=ewHykgbX4jYszAFd9Ju6SFx6PD7EZfLpBnqlKesWxso=; b=CcLS/00fdRyXQgKtXPajXDbRw+iiBomOTsJd5JHEjAWhNI2JIWyLcHxTG13ByG1LWP ZQ/4seVeYZEjXLpFUCLob/SZd2hDmbOHuC4BKTS7xmoJsqL7hv+1NoQtM5G3D19VyXTE WL2vdVzp6FBhlYWuNEAz6ZAHdDC9xVxifD9LBxvL0KSZHMaKTKjoyIHBc7K0o9xR1u5u nj79nbG+wWDintvidSn8VwS+jlkWYetCThjIDPi7rSBD9wErpeJOeoxJmdRcCIKbWxqh N0YGd19DKhhAQBon2iIiR2z90dLzOJHVA+ejXDK4ecgRuqMdgE8UBLuEpCh0qs2rFF4X wtrw== X-Gm-Message-State: AOAM530IuNGFZku4y+q1AVOod9G1p2Dit5x36EFVJdqCq/v0Y+fGPjcm /hK2c7CGpYbMfIZpcPg5iFkpHQ== X-Google-Smtp-Source: ABdhPJwb/6x985V/02Vo7oY17SnDDOdrrQmKFGSwQW4GEYIsvdwgHyH5uDxhDoSnwLRuPs6/8CB4zA== X-Received: by 2002:ac8:5806:: with SMTP id g6mr9066261qtg.292.1610035597146; Thu, 07 Jan 2021 08:06:37 -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 y16sm3236534qki.132.2021.01.07.08.06.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 08:06:36 -0800 (PST) From: Ted Lemon Message-Id: <8E71F1AF-345F-4A91-B380-F3513073856A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F7A3737-9AD6-4389-8ED7-073D380FD70A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Thu, 7 Jan 2021 11:06:34 -0500 In-Reply-To: Cc: Abtin Keshavarzian , Kangping Dong , DNSSD , Rongli Sun To: Jonathan Hui References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:06:40 -0000 --Apple-Mail=_2F7A3737-9AD6-4389-8ED7-073D380FD70A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Dec 19, 2020, at 11:07 AM, Jonathan Hui wrote: > I agree on checking for the KEY RR. It looks like the current text already specifies this. --Apple-Mail=_2F7A3737-9AD6-4389-8ED7-073D380FD70A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Dec 19, 2020, at 11:07 AM, Jonathan Hui <jonhui@google.com> wrote:
I agree on checking for the KEY RR.

It looks like the current text already specifies this.

--Apple-Mail=_2F7A3737-9AD6-4389-8ED7-073D380FD70A-- From nobody Thu Jan 7 08:07:34 2021 Return-Path: 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 DC9A73A0EFA for ; Thu, 7 Jan 2021 08:07:32 -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, RCVD_IN_DNSWL_BLOCKED=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.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 CbRom8OMGzLG for ; Thu, 7 Jan 2021 08:07:31 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 C17593A1240 for ; Thu, 7 Jan 2021 08:07:31 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id b64so5803580qkc.12 for ; Thu, 07 Jan 2021 08:07:31 -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=RAdM6t21oZXAHhPYX3oSrjnJyk3/HCm4vz5uH5JD++A=; b=GvYGozX14zrh3vEO01GrU2ZmGAn5I3y1pwBLpUIs1ZvLiDegDGdlfveeecrgQneFhR 20/sgw3C3Xulhzb0kMKLGqmKJQ9Su2eLXD7KuOg5KLVF6DGK/9lwga/eGkCp1BCV/xvi MBcQYolWCu9J1SOZ0oQ0WlPCUHhXC7UXBshrbfbZy878ynAGO3G2Wp23SBa4ivq5hLDn /UxWuqcuRVGPkVpwiiLFLU6Horz89yVquALqHPBOkabE7Pa6VJpAhmrDGdJKSgjEGIQn kVzNGJGZrao1JBejeKbqjokEtl4+6Omu1i/N/BUpbwCe6HVfg5eAQE5eonIsZ2R4v+79 MmMg== 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=RAdM6t21oZXAHhPYX3oSrjnJyk3/HCm4vz5uH5JD++A=; b=BCSUFygx2Duf0usiZ8nB1eQzJVdhiQ0PsdtZ+0PN6pmHOceAR7L7pW1P53uttHKtnU am7YH2QfVCpBpaEbqRMuW163JAf4TzSDc4kaRmVgRB8ZVsWQLvX5Or98ydnySvXcxfzY 4AxNJjH3ppE6PIZFll11z9tfa1L6owLjJ+zstcBByDi4KirmJ9pVSkgFI7yp6kLvCNir ZwGiB66KfHC3PxkBSQrQQ1trbM4JP5ccxMLGTEK00J5k8+KAbUY4xKPgxkOrC7TWmBlG c/kDRiiHQEzYE0n6TKnNmj8JJB0daswn6Q3xUzpwRbcpLkAuM4ZZCbqPmZz63t77canm BJDQ== X-Gm-Message-State: AOAM533gjc+tuPbbHD1E6W4A8Hcyci73BWyX/VthkbEcXf2BDIXLP3J+ NfZv1GHwpU8esUzUChHpZ3uq8g== X-Google-Smtp-Source: ABdhPJzqx5zUK2dju5zz71d5l4GMirND6zLqA8W2dUrByY1/sfgey2ps+c/CN8nPZUl0HEjcSh37Gw== X-Received: by 2002:a37:82c5:: with SMTP id e188mr9886319qkd.141.1610035650923; Thu, 07 Jan 2021 08:07:30 -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 y16sm3236534qki.132.2021.01.07.08.07.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 08:07:30 -0800 (PST) From: Ted Lemon Message-Id: <7B42EB99-8C91-4261-A1B6-6A095E149150@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_883BE186-B70B-4F5E-9E84-80344DE505FF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Thu, 7 Jan 2021 11:07:29 -0500 In-Reply-To: Cc: Kangping Dong , Abtin Keshavarzian , DNSSD , Rongli Sun To: Jonathan Hui References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:07:33 -0000 --Apple-Mail=_883BE186-B70B-4F5E-9E84-80344DE505FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 19, 2020, at 11:14 AM, Jonathan Hui wrote: > So I guess the question is whether we can/should mandate this future = going forward in SRP? What if an LPR protocol server wants to do an SRP add? Is there a = strong reason to add this limitation? I don=E2=80=99t think it makes = much difference. --Apple-Mail=_883BE186-B70B-4F5E-9E84-80344DE505FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 19, 2020, at 11:14 AM, Jonathan Hui <jonhui@google.com> = wrote:
So I guess the question is = whether we can/should mandate this future going forward in = SRP?

What if an LPR = protocol server wants to do an SRP add?  Is there a strong reason = to add this limitation? I don=E2=80=99t think it makes much = difference.


= --Apple-Mail=_883BE186-B70B-4F5E-9E84-80344DE505FF-- From nobody Thu Jan 7 08:49:43 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6333A1287; Thu, 7 Jan 2021 08:49:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <161003817838.17510.13375060697300861293@ietfa.amsl.com> Date: Thu, 07 Jan 2021 08:49:38 -0800 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-08.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:49:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-srp-08.txt Pages : 30 Date : 2021-01-07 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: 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 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 7 08:53:03 2021 Return-Path: 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 ; 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 ; 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 ; Thu, 7 Jan 2021 08:52:59 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id z3so4636977qtw.9 for ; 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 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, 7 Jan 2021 11:52:56 -0500 In-Reply-To: Cc: Abtin Keshavarzian , DNSSD , Jonathan Hui , Rongli Sun To: Kangping Dong References: <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com> <87BDE0DB-9FB0-4BB2-872D-6D045897FCBD@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:53:02 -0000 --Apple-Mail=_2CB34A00-1234-4BE2-85C0-8257D36E84E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 19, 2020, at 10:11 AM, Kangping Dong wrote: > I have some questions when reading the related sections: >=20 > 1. in 2.2.5.5.2. Removing some published services = , we have: > The second alternative is to send a normal SRP update, but as in the = first alternative,=20 > including a Service Discovery Instruction and a Service Description = that delete the service being removed. > Should the "delete" be "replace"?=20 Delete is a type of DNS update. There is no =E2=80=9Creplace=E2=80=9D 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 = , we have: > zero or more "Add to an RRset" TXT RRs, > =20 > 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=E2=80=99s relatively unusual, but we have to support it=E2=80=94SRP = 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=E2=80=99ve 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/ = There is also an HTML version available at: 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=3Ddraft-ietf-dnssd-srp-08 = --Apple-Mail=_2CB34A00-1234-4BE2-85C0-8257D36E84E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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, 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 = =E2=80=9Creplace=E2=80=9D 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, 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=E2=80= =99s relatively unusual, but we have to support it=E2=80=94SRP 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
<= br class=3D"">
I=E2=80=99ve submitted an update that contains = new text to address the delete/replace concern.


= --Apple-Mail=_2CB34A00-1234-4BE2-85C0-8257D36E84E5-- From nobody Sun Jan 10 19:57:06 2021 Return-Path: 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 ADB2A3A1532 for ; Sun, 10 Jan 2021 19:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.972 X-Spam-Level: X-Spam-Status: No, score=-16.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HEBLBvDaVMrC for ; Sun, 10 Jan 2021 19:57:03 -0800 (PST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 4A92B3A1530 for ; Sun, 10 Jan 2021 19:57:03 -0800 (PST) Received: by mail-yb1-xb2a.google.com with SMTP id d37so15639295ybi.4 for ; Sun, 10 Jan 2021 19:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Du766rlykuj/ZNEe1H8AlcURmv6mZi+8XMzF4Hrj5sI=; b=nft9n/NJu0yyTL/vHQIltiI8kfd5NFBnmJUq8/7Cyz1hDCx1BRPaohQvvFBczx6kSA mxj2zVnWeNF317hWw28vVH01bxY55hZdJhrjtudFFOSnr/Y6Dilm5qfnccxe+p8OdyZJ IQ8LmevwBfMWeZ9Q7vGc+CUwfJ4fx5bJGktpmMrsgzmaWsp+qP3IAYloHuwhNtxOkAIB WkprhB0WdPchC+0S4do5K1ERlOXcWrkaANleis0lFnF3GKIyWMCewYd3Fx6Z6RRhJETC Pt+rb0EcGSeXk3fQe4h/r9rA1+Tbe197QQb2yq37tKDrdTLze2puo+XiEBb0MzFsZuvO Yn9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Du766rlykuj/ZNEe1H8AlcURmv6mZi+8XMzF4Hrj5sI=; b=hKZ4kjkAbL5rprJU1eOgzXas16q1zgKMtx2jEjNdsUUXDZ8h+BSG2kreS57kaTaPIn dnQ6Vv2yKGTqIn72LnzaDDiqLeLNmA3axwBw0kesoOlz2JPo6U6KL8xhJa64NySSzfL1 0pHKBxXoW9M2RlmSqx8BEqkn33VYfFo3R/zNoNnTOJM4ebxcWcxwT5ZJFNkRIjjXhM01 Ny1NfP+c6vXM2VcHyQKlInwjWgkk9jR4rPUSP9f6LfuHSmgx8tY+X81fWR2YQkbuGDao 2ApXvl/bXQt+j/1RwOr3Pm/9m6IxgkE7VeQ1RZW0TAROpwRWsfLiXXZHhYdVge9karbL dCyA== X-Gm-Message-State: AOAM5306k9c80T9pSiGJxhbL5VfPkw/SqXCA3x8nqdqqq6Z9/X1hZnKn ukiv50WwiPUk0MgjHTnl+ADBlwD/SDiCrMN3/fvOJ3pw2hBTO0/h X-Google-Smtp-Source: ABdhPJzAEcx8jS9Q0SC7kmtbcsrjR3B++jRC7dE5GthZ0sWxA7AKKKAUSCpHjjkkSVRiF1JWUyynApVkX3sAGSXihIM= X-Received: by 2002:a25:d753:: with SMTP id o80mr20401111ybg.169.1610337422050; Sun, 10 Jan 2021 19:57:02 -0800 (PST) MIME-Version: 1.0 From: Kangping Dong Date: Mon, 11 Jan 2021 11:56:25 +0800 Message-ID: To: DNSSD , Jonathan Hui , Abtin Keshavarzian , Rongli Sun , Simon Lin , Ted Lemon Content-Type: multipart/alternative; boundary="00000000000002fd2e05b897e6ce" Archived-At: Subject: [dnssd] SRP - supports subtype 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 03:57:05 -0000 --00000000000002fd2e05b897e6ce Content-Type: text/plain; charset="UTF-8" Hi, Seems project CHIP needs support of "subtype": > > Three subtypes for CHIP Commissioning Discovery are defined: > > 1. > > Sddd (eight-bit short discriminator, encoded as a three-digit decimal > number in ASCII (UTF-8) text, with leading zeroes as necessary) > 2. > > Ldddd (twelve-bit long discriminator, encoded as a four-digit decimal > number in ASCII (UTF-8) text, with leading zeroes as necessary) > 3. > > Vddd (optional vendor id, encoded as a variable-length decimal number > in ASCII (UTF-8) text, without leading zeroes) > > (Please search "subtype" in this doc to find the source But current SRP spec seems not supporting multiple PTRs (Service Discovery Instructions): > An SRP Update MUST include at zero or more Service Discovery > Instructions, the same number of Service Description Instructions, > and exactly one Host Description Instruction. > > (https://tools.ietf.org/html/draft-ietf-dnssd-srp-08#section-2.3.2 I think multiple Service Discovery Instructions need to be allowed for a single Service Description Instruction, if we want to support subtype. Thoughts? BRs, Kangping --00000000000002fd2e05b897e6ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Seems project CHIP needs support of "subtype":<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Three subtypes for CHIP Commissioning Discov= ery are defined:

  1. Sddd (eight-bit sh= ort discriminator, encoded as a three-digit decimal number in ASCII (UTF-8)= text, with leading zeroes as necessary)

  2. Ldddd (twelve-bit long discriminator, encoded as a f= our-digit decimal number in ASCII (UTF-8) text, with leading zeroes as nece= ssary)

  3. Vddd (optio= nal vendor id, encoded as a variable-length decimal number in ASCII (UTF-8)= text, without leading zeroes)

(Please= search "subtype" in this doc=C2=A0to find the source

But curren= t SRP spec seems not supporting multiple PTRs (Service Discovery Instructio= ns):
An SRP Update MUST include at zero or =
more Service Discovery
   Instructions, the same number of Service Description Instructions,
   and exactly one Host Description Instruction.
(https://tools.ietf.org/html/draft-ietf-dnssd-srp-08#section-2.3.2

I think multiple Service Discovery Instructions need t= o be allowed for a single Service Description Instruction, if we want to su= pport subtype. Thoughts?

BRs,
Kangping
=C2=A0
--00000000000002fd2e05b897e6ce-- From nobody Mon Jan 11 05:45:40 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF173A0C85; Mon, 11 Jan 2021 05:45:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <161037273908.924.10416839618981268404@ietfa.amsl.com> Date: Mon, 11 Jan 2021 05:45:39 -0800 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-09.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 13:45:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-srp-09.txt Pages : 30 Date : 2021-01-11 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: 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-09.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 05:47:29 2021 Return-Path: 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 7F2773A0C93 for ; Mon, 11 Jan 2021 05:47:28 -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 566H2siG9cKY for ; Mon, 11 Jan 2021 05:47:24 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 0AC453A0ABB for ; Mon, 11 Jan 2021 05:47:23 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id e22so17314344iom.5 for ; Mon, 11 Jan 2021 05:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=uFtCetbpiM7hPO9CzT8EaRJLXXCyKImcbSv+umTP/NY=; b=YGwROJW55OncutM9MEt/Pd4PV6yXaT+4UUdyNhS+G6J3R2CcpyI4VRqBqhb3bZtxdG 9c4FV787D54YjwWwiE62FMjxJeVTErC7mcsotNJSEG3N5TpcVbP4G3V35UQxIkGgUM23 xLHyabiI80BYUx9ryFEBMJf1Y5epVXnVzCDQSlqgh/eGy8ZLPSHPzCqRbdsy1hgMbQHD qt7KcgoDY5Lsf2iDwZdRr4QgVO+sRWFW9h+6tP/f+nf+LOGlbJYaldsQiK/5SVkxBlIV lh02AeAQaDm40J2QKVzEiiX7vr1qOKHdEBzOIfRNdAzZnK2hZOopwNjdw70rRI0iYqwG VQ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=uFtCetbpiM7hPO9CzT8EaRJLXXCyKImcbSv+umTP/NY=; b=rPx3CnBPMZB8DAU/9Ariqt1N9K6+K4CgyE+ETQfYPeziSRbe4vHapqoSU9g9siL+yg ABybXg4Ykz2heDmT/gKa/5JOcmTag42bb5c3Ewa9ptA4OnA1nXdt4QDIUlMsiqaezJAo waomeCFY7Ot0BJGsHMhNgvkkLywjskZ5wgLZSqt5/EHV+H0JdrCDH93wCxLZRNBloyen SSdzlq1cN5iCsWX/htVSgVWU1n+s7JroJ3lUl12chFHX6OhYLVBGKQjv+Hzel/T8hAKO cZmvtEhDxlAt4MtJ1djHs3U/81PH6ZQfZjBOkchfHKOegvy+0vaN3lVuL5f7eOWJtVGr lfVw== X-Gm-Message-State: AOAM5303Ghkb+Qzxqae1RLZUNkvwfvbTxJ8XGNgE+/wVbq9xoCaLliJQ /vQNzPXayEue1RJvGwDPREATRPT1ypqi+w== X-Google-Smtp-Source: ABdhPJzFuO7g+wTMAmucEGnjKK8scghyjxmwFy4N3dGSH1xl+FQa5b8NCdQ2U7nW93tHGgfEUJ+ixQ== X-Received: by 2002:a05:6638:3a3:: with SMTP id z3mr14111360jap.67.1610372842868; Mon, 11 Jan 2021 05:47:22 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id w17sm10869437iom.7.2021.01.11.05.47.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 05:47:22 -0800 (PST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_3703A454-8CE0-4987-B504-ABD07C931080" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Mon, 11 Jan 2021 08:47:19 -0500 References: <161037273908.924.10416839618981268404@ietfa.amsl.com> To: dnssd@ietf.org In-Reply-To: <161037273908.924.10416839618981268404@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 13:47:29 -0000 --Apple-Mail=_3703A454-8CE0-4987-B504-ABD07C931080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 11, 2021, at 8:45 AM, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ = >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-09.html = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-srp-09 = I believe this update fixes the Valid SRP Update Requirements section of = the document to allow for service subtypes. --Apple-Mail=_3703A454-8CE0-4987-B504-ABD07C931080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 11, 2021, at 8:45 AM, internet-drafts@ietf.org wrote:
I believe this = update fixes the Valid SRP Update Requirements section of the document = to allow for service subtypes.

= --Apple-Mail=_3703A454-8CE0-4987-B504-ABD07C931080-- From nobody Thu Jan 14 22:03:55 2021 Return-Path: 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 29BCB3A0CEE for ; Thu, 14 Jan 2021 22:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.973 X-Spam-Level: X-Spam-Status: No, score=-16.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hiYVvFQa5rpW for ; Thu, 14 Jan 2021 22:03:51 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 C733F3A0CEB for ; Thu, 14 Jan 2021 22:03:51 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id z1so4068254ybr.4 for ; Thu, 14 Jan 2021 22:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=U89/QQObtVP5ae+AhjNp0LMgrdcgjC8dZnNjy5DMGhg=; b=NpNWU7LCbwrttqqwAp7sHCtZAnJhekfdz0UJCuiTCqgjS30fFRUqKRV9ZSBlyiZupM 2wBvWkpYcSKDf8Xvhkh2OJSmVd7aefOP0ey3hQ+DKgtqZNr4BoiR5oMuKrnHTRqfm8cF btSb4thxT6IzWDgbGM9E6gGM9Y+ny7H85gHqltGocMAGcXsklFSoEfVWOtuxK86YNwn0 iR+WNhiME5FJHfe08Klf9uCmAyJ0UIc/jL1Iv6e8nBjNZJgAsfGItBMw5yYiD1AgO8hi uO+RZCqY33RuQou+e5NQK1pmOQKRoJZMkfQoc7cRjwV5X80a54XUO6rGBtlqKMU7ZimF ji1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U89/QQObtVP5ae+AhjNp0LMgrdcgjC8dZnNjy5DMGhg=; b=bYreK8VrD1/TRdk1s4Ovb5OK6hMM9k4jG+nMRVEspehuQleKag38EV7D625bSMNNt8 OTMh32H782mZ3fVjudUgLM9YiTP7BY1hiAywD67bSF92bmVGJl4xh4uUaViGPcnhrthd 0BthvGoTiwnHugOOK5fYFHqieasnJ7KRpUElL0srLBMvLIYFSBGUILuZ2VETswdprw9T cB90Irqb9QT7p88FCG4sOWl5m13et5xLSzs6dpzkiixZ38mYoag4CilTxxv485sXxws1 /4PCl+IIDLpeCnl6EEY2e2+fVTTiA2fWV3tHBy4VXoay75EK5dvQ5uMFv5ZAq+ZQiG4H snqQ== X-Gm-Message-State: AOAM532fW2IjRQ1iCf4Dio5RqFoCXPrEFWWfwW0kEZhRiSRsevPeYeqL zOyiv/JeXLWQayQavGJlUrWd7qjfkFTohRakE+mmeOrUs5TRnaAM X-Google-Smtp-Source: ABdhPJwZq7gWCXbehqYWKQBLWXSM+p0lijADlCCjpBvAmJgUzUWKUxhgiEs5SEYisgbGFHGb+Ekc3NxGRhd1BiUX4AM= X-Received: by 2002:a25:e048:: with SMTP id x69mr16024558ybg.353.1610690630407; Thu, 14 Jan 2021 22:03:50 -0800 (PST) MIME-Version: 1.0 From: Kangping Dong Date: Fri, 15 Jan 2021 14:03:14 +0800 Message-ID: To: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Ted Lemon , Yakun Xu Content-Type: multipart/alternative; boundary="000000000000deda6505b8ea22ce" Archived-At: Subject: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 06:03:54 -0000 --000000000000deda6505b8ea22ce Content-Type: text/plain; charset="UTF-8" Hi DNSSD enthusiasts, For Service Registration Protocol (SRP), when a SRP server receives a registration with names that have already been taken by another client, it responds with a YXDOMAIN error code to indicate name conflicts. When the client receives such a response, it typically will re-generate a new host or service instance name and re-register with the new name. The problem is that a typical SRP update will include one Host Description Instruction and one (or more) Service Description Instructions (zero Service Description Instruction is allowed but it is more common that the client registers the host with some service instances). Name conflicts can happen on both Host Description instruction and Service Description Instruction, but there is no description of how to tell the client which instruction includes the conflict (or both include conflicts). Currently, the client needs to re-new both host name and service instance name or re-new a single name and starts a trial-and-error process until it finally succeeds. One solution is, the server/registry responds with the *Instruction(s)* which has name conflicts. For the client, it should check the RRs in the response to get the conflicting name if a YXDOMAIN response code is received. To Reduce data transported between the server & client, the server may just include one RR, but not the entire *Instruction*, that contains the conflicting name. Thoughts? BRs, Kangping --000000000000deda6505b8ea22ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi DNSSD enthusiasts,

For Service Regis= tration Protocol (SRP), when a SRP server receives a registration with name= s
that have already been taken by another client, it responds=C2= =A0with a YXDOMAIN error code to indicate
name conflicts. When th= e client receives such a response, it typically will re-generate a new host= or
service instance name and re-register with the new name.

The problem is that a typical SRP update will include = one Host Description Instruction and one (or more)
Service Descri= ption Instructions (zero Service Description Instruction is allowed but it = is more common
that the client registers the host with some servi= ce instances). Name conflicts can happen on both Host
Description= =C2=A0instruction and Service Description Instruction, but there is no desc= ription of how to tell the
client which instruction includes the = conflict (or both include conflicts). Currently, the client needs to re-new=
both host name and service instance name or re-new a single name= and starts a trial-and-error process
until it finally succeeds.<= /div>

One solution is, the server/registry responds with= the Instruction(s)=C2=A0which has name conflicts. For the
client, it should check the RRs in the response to get the conflicting nam= e if a YXDOMAIN response
code is received. To Reduce data transpo= rted between the server & client, the server may just include
one RR, but not the entire=C2=A0Instruction, that contains the conf= licting name.

Thoughts?

<= br>
BRs,
Kangping

--000000000000deda6505b8ea22ce-- From nobody Fri Jan 15 06:30:09 2021 Return-Path: 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 9FBAC3A09AC for ; Fri, 15 Jan 2021 06:30:07 -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, MIME_QP_LONG_LINE=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.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 2jSelFwn3210 for ; Fri, 15 Jan 2021 06:30:05 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 6D7323A096C for ; Fri, 15 Jan 2021 06:30:05 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id c14so6105104qtn.0 for ; Fri, 15 Jan 2021 06:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=PQj3th/kB1G55svuEKZ130DRxjeA22Vvhfud6ys99IM=; b=1MuE60DRAEZjo8ypEqrD7SHT7y4VwslI/nUGcAT1xXHNK9HYV8930qtzlGtkVHlPpV JvIWPlJ0WRJHnFS1rhuNAmThxjR+gnqXCCEuDIjL7EG/FK7/zknF5r/iaS8k0IN7YNGt Vd+QDsc71+z9v/MoH0Pz8H0FJ/4meSIyNZdld3I5xHvBDe01WA5DaU6DnWfND3rCNHzC 1h5l8oC7xsdPo6FEa1V9pnymGoo02UN92+diSqqmVgORmNUJ/E450JWdImeuZlklLwb4 bCcdfkwFJzPvEtQdR8jDCqrK1BffDrORY4Lf9sSm9hussN7Z8B3ipmIDcXwsgccrYaaF fBuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=PQj3th/kB1G55svuEKZ130DRxjeA22Vvhfud6ys99IM=; b=Em0Mm8bRnXYAXfdVcM4okxDb8NW0nOi+ymzsnUB7CCDX11mN7GZqrAIlNgAItlzwIE mExiWSFWiPy12KBrszjMv/0cwZycLtJFgzNR/61jJyail5pgrDmPkKJPVE3rPc7N8R9X mJz6dW/bFAJgHCVKvco5KTjLON7dyexrqWNCiIgzRiaqWCizaDt6OYPB03TNfiUxgSYv V2ZP4m0dHUfpYPz+pbzsuefbTeKPczY+qyJQVAzG+M9xE2OxYopKQKGwW3H3iVJN6596 p6hDVo1RrK6iR4oNnDmclh2f3koqUwedNKSPrs9K3HghsTzgVfqZL6dwzYVeZaM3olH/ OZFw== X-Gm-Message-State: AOAM530yzHbtcDuOWKGGiRboBPJaeH1bhYfmbas14yADDd4n+J9dI8hq RgzWG4wBIaHpcPvFzM7YdmVh+A== X-Google-Smtp-Source: ABdhPJzBYXLrqJP2kXyvkDq8ppatn2QFxf/c0e9Q6SelrSRFwldAqSuOiMdi9iPOsr23Id4RaIz4Dw== X-Received: by 2002:ac8:454e:: with SMTP id z14mr11672011qtn.120.1610721004436; Fri, 15 Jan 2021 06:30:04 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h25sm5114667qkh.122.2021.01.15.06.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Jan 2021 06:30:03 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-257EFF3B-7760-4809-9484-CFC232E1D94F Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 15 Jan 2021 09:30:02 -0500 Message-Id: <30F1E517-3A0E-4BCF-B2F9-DE3346570B9B@fugue.com> References: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu In-Reply-To: To: Kangping Dong X-Mailer: iPhone Mail (18E118) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 14:30:08 -0000 --Apple-Mail-257EFF3B-7760-4809-9484-CFC232E1D94F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How about including an additional section on the response that includes the c= onflicted names and rrtypes with zero length data? Or just pointing to the r= oot? > On Jan 15, 2021, at 01:03, Kangping Dong wrote: >=20 > =EF=BB=BF > Hi DNSSD enthusiasts, >=20 > For Service Registration Protocol (SRP), when a SRP server receives a regi= stration with names > that have already been taken by another client, it responds with a YXDOMAI= N error code to indicate > name conflicts. When the client receives such a response, it typically wil= l re-generate a new host or > service instance name and re-register with the new name. >=20 > The problem is that a typical SRP update will include one Host Description= Instruction and one (or more) > Service Description Instructions (zero Service Description Instruction is a= llowed but it is more common > that the client registers the host with some service instances). Name conf= licts can happen on both Host > Description instruction and Service Description Instruction, but there is n= o description of how to tell the > client which instruction includes the conflict (or both include conflicts)= . Currently, the client needs to re-new > both host name and service instance name or re-new a single name and start= s a trial-and-error process > until it finally succeeds. >=20 > One solution is, the server/registry responds with the Instruction(s) whic= h has name conflicts. For the > client, it should check the RRs in the response to get the conflicting nam= e if a YXDOMAIN response > code is received. To Reduce data transported between the server & client, t= he server may just include > one RR, but not the entire Instruction, that contains the conflicting name= . >=20 > Thoughts? >=20 >=20 > BRs, > Kangping >=20 --Apple-Mail-257EFF3B-7760-4809-9484-CFC232E1D94F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How about including an add= itional section on the response that includes the conflicted names and rrtyp= es with zero length data? Or just pointing to the root?

On Jan 15, 2021, at 01:03, Kangping Dong <= ;wgtdkp@google.com> wrote:

=EF=BB=BF
Hi DNSSD enthusiasts,
<= br>
For Service Registration Protocol (SRP), when a SRP server rec= eives a registration with names
that have already been taken by an= other client, it responds with a YXDOMAIN error code to indicate
<= div>name conflicts. When the client receives such a response, it typically w= ill re-generate a new host or
service instance name and re-registe= r with the new name.

The problem is that a typical S= RP update will include one Host Description Instruction and one (or more)
Service Description Instructions (zero Service Description Instructi= on is allowed but it is more common
that the client registers the h= ost with some service instances). Name conflicts can happen on both Host
Description instruction and Service Description Instruction, but= there is no description of how to tell the
client which instructi= on includes the conflict (or both include conflicts). Currently, the client n= eeds to re-new
both host name and service instance name or re-new a= single name and starts a trial-and-error process
until it finally= succeeds.

One solution is, the server/registry res= ponds with the Instruction(s) which has name conflicts. For the<= /div>
client, it should check the RRs in the response to get the conflic= ting name if a YXDOMAIN response
code is received. To Reduce data t= ransported between the server & client, the server may just include
one RR, but not the entire Instruction, that contains the c= onflicting name.

Thoughts?


BRs,
Kangping

= --Apple-Mail-257EFF3B-7760-4809-9484-CFC232E1D94F-- From nobody Sun Jan 17 19:46:12 2021 Return-Path: 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 146823A0CCD for ; Sun, 17 Jan 2021 19:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.972 X-Spam-Level: X-Spam-Status: No, score=-16.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QkXKpyfLF-By for ; Sun, 17 Jan 2021 19:46:09 -0800 (PST) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 A91433A0CCC for ; Sun, 17 Jan 2021 19:46:09 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id x78so6944322ybe.11 for ; Sun, 17 Jan 2021 19:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qv8FM04rIen8XFTSpAU9DArzPvzI1baM1LrKMmqqKh4=; b=c4vvK9zT7dMx403Py8C5hQoVRafdLKSpmZcyZv8gAi+gFhV+wcdW1BcWb7NS5xoj+I +x5TeVP05CLYXmWG/W1cWl3sT8EvQmIpdr6JcJqzlBUZcTsxauzni2+FrqvtX7iw9KL9 SmzbgTdEw/IhElquPTRZOd35Ej76q7mtB3EQIUmV9UVHp6uhZ1298+XAIXQMswBmaLyw Fx1YKA2owKfM+z04gNLg9nwgMwLc5UoKVmzsdSZfmyNpPC1LcEAyS6zDQZ+3/5qLVDEp q5oQ1qjsi2qxf3JfS01xBOIbdqssO1Lj99/ejMVzgm3N4hURX/2dGxwdAo6HefOtVaEq rKMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qv8FM04rIen8XFTSpAU9DArzPvzI1baM1LrKMmqqKh4=; b=oiK45N5Csz8GJYg6qiP1M6e9hFL8KHSfDIVEcTQ2N4yBrLsvww6LX+Dzen6GpxQd5g l3dmWCMA5r4dF81o7JYRejOfVy7/EmeNyulpEkxojIZ2CWqXWpHkHQtkUiwEVPA7kMFV OjIHhKDgFjGx+h2rt8e0Eu+QMEtiP4m4LJ6ZZPjO0DhwUNwnyX08v/yUiUhnRqrAvH5v kzfFNW1hrW3yaFeRt9JtHhaSmoZGVC2W56Z/78vrnTTY8VWIOq5Di6rfCs8o9nGde1w2 RDDt92Fpnzkshs15zELfft3Y9r2fTN1Y+O8XzlfnplzYLo3HhBqAbQJD9ciLPuPsQ2be frfw== X-Gm-Message-State: AOAM531hc09jk3SKGsiu3CEKpMKNgRG/uH1MULHELMUF2KxFgTGcnMnX oTayJwb/p4cKIQFB21xV+FhHBnwvA7UTF1W+clik3g== X-Google-Smtp-Source: ABdhPJzh7ObZFFdKHZS7aaJvtS90MA+Jk6EKP88PsqR+LVe+L6mjEh/KZFFfN6N+e2OlLWRpv+szVYfeJg/7JXrxyUI= X-Received: by 2002:a25:2fd7:: with SMTP id v206mr34262183ybv.420.1610941568519; Sun, 17 Jan 2021 19:46:08 -0800 (PST) MIME-Version: 1.0 References: <30F1E517-3A0E-4BCF-B2F9-DE3346570B9B@fugue.com> In-Reply-To: <30F1E517-3A0E-4BCF-B2F9-DE3346570B9B@fugue.com> From: Kangping Dong Date: Mon, 18 Jan 2021 11:45:32 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu Content-Type: multipart/alternative; boundary="000000000000f2966805b9248ff5" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 03:46:11 -0000 --000000000000f2966805b9248ff5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should we use one RR with ANY type (and zero rdata) for one conflicted name? Because the conflict applies to all RRs of this name. Or just pointing to the root? > Sorry, I am not following. Do you mean including exactly the original RR that has name conflict? BRs, Kangping On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon wrote: > How about including an additional section on the response that includes > the conflicted names and rrtypes with zero length data? Or just pointing = to > the root? > > On Jan 15, 2021, at 01:03, Kangping Dong wrote: > > =EF=BB=BF > Hi DNSSD enthusiasts, > > For Service Registration Protocol (SRP), when a SRP server receives a > registration with names > that have already been taken by another client, it responds with a > YXDOMAIN error code to indicate > name conflicts. When the client receives such a response, it typically > will re-generate a new host or > service instance name and re-register with the new name. > > The problem is that a typical SRP update will include one Host Descriptio= n > Instruction and one (or more) > Service Description Instructions (zero Service Description Instruction is > allowed but it is more common > that the client registers the host with some service instances). Name > conflicts can happen on both Host > Description instruction and Service Description Instruction, but there is > no description of how to tell the > client which instruction includes the conflict (or both include > conflicts). Currently, the client needs to re-new > both host name and service instance name or re-new a single name and > starts a trial-and-error process > until it finally succeeds. > > One solution is, the server/registry responds with the *Instruction(s)* w= hich > has name conflicts. For the > client, it should check the RRs in the response to get the conflicting > name if a YXDOMAIN response > code is received. To Reduce data transported between the server & client, > the server may just include > one RR, but not the entire *Instruction*, that contains the conflicting > name. > > Thoughts? > > > BRs, > Kangping > > --000000000000f2966805b9248ff5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should we use one RR with ANY type (and zero rdata) for on= e conflicted name? Because=C2=A0the conflict applies to all RRs of this nam= e.

Or just = pointing to the root?
Sorry, I am not following. Do yo= u mean including exactly the original RR that has name conflict?
=

BRs,
Kangping

On Fri, Jan 15, = 2021 at 10:30 PM Ted Lemon <mellon@f= ugue.com> wrote:
How about including an additiona= l section on the response that includes the conflicted names and rrtypes wi= th zero length data? Or just pointing to the root?
On Jan 15, 2021, at 01:03, Kangping Dong <wgtdkp@google.com&= gt; wrote:

=EF=BB=BF
Hi DNSSD enthusiasts,

For= Service Registration Protocol (SRP), when a SRP server receives a registra= tion with names
that have already been taken by another client, i= t responds=C2=A0with a YXDOMAIN error code to indicate
name confl= icts. When the client receives such a response, it typically will re-genera= te a new host or
service instance name and re-register with the n= ew name.

The problem is that a typical SRP update = will include one Host Description Instruction and one (or more)
S= ervice Description Instructions (zero Service Description Instruction is al= lowed but it is more common
that the client registers the host wi= th some service instances). Name conflicts can happen on both Host
Description=C2=A0instruction and Service Description Instruction, but the= re is no description of how to tell the
client which instruction = includes the conflict (or both include conflicts). Currently, the client ne= eds to re-new
both host name and service instance name or re-new = a single name and starts a trial-and-error process
until it final= ly succeeds.

One solution is, the server/registry = responds with the Instruction(s)=C2=A0which has name conflicts. For = the
client, it should check the RRs in the response to get the co= nflicting name if a YXDOMAIN response
code is received. To Reduce= data transported between the server & client, the server may just incl= ude
one RR, but not the entire=C2=A0Instruction, that cont= ains the conflicting name.

Thoughts?

BRs,
Kangping

--000000000000f2966805b9248ff5-- From nobody Sun Jan 17 20:08:18 2021 Return-Path: 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 5235A3A0CE0 for ; Sun, 17 Jan 2021 20:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, RCVD_IN_DNSWL_BLOCKED=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 N9M8-fCmlhtY for ; Sun, 17 Jan 2021 20:08:15 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 58DEC3A0CDF for ; Sun, 17 Jan 2021 20:08:15 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id d11so6943227qvo.11 for ; Sun, 17 Jan 2021 20:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=teXAE/8Vp2h69PNTgIlliF+w8yhCE7bgyBbiRO44LRY=; b=NPWeB+2HyuZweG0S5Puntvhz51jltxPSmBVrejRdWqel07Msbzj86PlwM1FMoszPQn pOGyvPAUT1Ipgb40PJteCA/K7TpIcpmCxtnwhSho4Nkbxlv34JSKuovoSLnn/P7PDs0b eZDQE6DX6cSrtYXP/E4erflIYViXsDs6tLO1uKhy1lgxuZWYIh6iR0dkEUWzVmJfedFw ia8OPWspp0c6/MB/kkYB7ccK+TEbb/g3k1tcEeSR7Txk/vayG7X3C6QkMPiVKHjKFHI1 yUGzaFJ369T7HFgNuc6ACnYjxSDqTQgJFp1qOLsJjPsbBUch6BavF1XWeOhABWkLZRc8 wDKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=teXAE/8Vp2h69PNTgIlliF+w8yhCE7bgyBbiRO44LRY=; b=nSzRLqaQIRq7ExDeB5mwAf5M2tRaozZN1oTP+FKy7EDL3ppk3ye18z+UsymunpmASt FgkJgWGmRo52nmVZV7XBDy0IyLHIWU54xRZVu7Fco8rjfjS06Ee5OPh8ke3IZPZu64bi CKzx5npGS3tNYUq2ASQpMXV1o/6StxWIe3Qcv35mlfjT51OXPW+RYZffBI2dy9q5rwga EX/8TUQTU2RBoqHx6QIf/vuduXgdfptSP3QqViyD7TDndjDm+FH2QG1ww8sFwhXILjgU ZmjGiqCB2Dx2IEVIbGN4KWys1tXLObWKp++sxPIPy46XaBaMCgDR25DAHqrpsPRNCTs8 rNQA== X-Gm-Message-State: AOAM5328lTUFAWdhukjmtt4IoFYT06xjuRVgaGK/kErooJjVf3cvLyOF WXm46IWU8QlUcFAaJ5ni9L1UMQ== X-Google-Smtp-Source: ABdhPJw3sgeZiPsDo1F9d3qbMuVf35yEzmmk9K/d4c32boh8GDjvrVi4RPbuCNWIYomrlOOLVu46gw== X-Received: by 2002:a0c:e351:: with SMTP id a17mr22799653qvm.46.1610942894139; Sun, 17 Jan 2021 20:08:14 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 17sm10085748qtu.23.2021.01.17.20.08.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Jan 2021 20:08:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-1520E959-47FA-42AD-A2EB-237B6407B447 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 17 Jan 2021 23:08:12 -0500 Message-Id: References: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu In-Reply-To: To: Kangping Dong X-Mailer: iPhone Mail (18E118) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 04:08:17 -0000 --Apple-Mail-1520E959-47FA-42AD-A2EB-237B6407B447 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The ptr or srv record, yes. I don=E2=80=99t think any is allowed outside of t= he question section.=20 > On Jan 17, 2021, at 22:46, Kangping Dong wrote: >=20 > =EF=BB=BF > Should we use one RR with ANY type (and zero rdata) for one conflicted nam= e? Because the conflict applies to all RRs of this name. >=20 >> Or just pointing to the root? > Sorry, I am not following. Do you mean including exactly the original RR t= hat has name conflict? >=20 >=20 > BRs, > Kangping >=20 >> On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon wrote: >> How about including an additional section on the response that includes t= he conflicted names and rrtypes with zero length data? Or just pointing to t= he root? >>=20 >>>> On Jan 15, 2021, at 01:03, Kangping Dong wrote: >>>>=20 >>> =EF=BB=BF >>> Hi DNSSD enthusiasts, >>>=20 >>> For Service Registration Protocol (SRP), when a SRP server receives a re= gistration with names >>> that have already been taken by another client, it responds with a YXDOM= AIN error code to indicate >>> name conflicts. When the client receives such a response, it typically w= ill re-generate a new host or >>> service instance name and re-register with the new name. >>>=20 >>> The problem is that a typical SRP update will include one Host Descripti= on Instruction and one (or more) >>> Service Description Instructions (zero Service Description Instruction i= s allowed but it is more common >>> that the client registers the host with some service instances). Name co= nflicts can happen on both Host >>> Description instruction and Service Description Instruction, but there i= s no description of how to tell the >>> client which instruction includes the conflict (or both include conflict= s). Currently, the client needs to re-new >>> both host name and service instance name or re-new a single name and sta= rts a trial-and-error process >>> until it finally succeeds. >>>=20 >>> One solution is, the server/registry responds with the Instruction(s) wh= ich has name conflicts. For the >>> client, it should check the RRs in the response to get the conflicting n= ame if a YXDOMAIN response >>> code is received. To Reduce data transported between the server & client= , the server may just include >>> one RR, but not the entire Instruction, that contains the conflicting na= me. >>>=20 >>> Thoughts? >>>=20 >>>=20 >>> BRs, >>> Kangping >>>=20 --Apple-Mail-1520E959-47FA-42AD-A2EB-237B6407B447 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The ptr or srv record, yes= . I don=E2=80=99t think any is allowed outside of the question section. = ;

On Jan 17, 2021, at 22= :46, Kangping Dong <wgtdkp@google.com> wrote:

=EF=BB=BF
Shoul= d we use one RR with ANY type (and zero rdata) for one conflicted name? Beca= use the conflict applies to all RRs of this name.

Or just pointing to the root?
<= /blockquote>
Sorry, I am not following. Do you mean including exactly th= e original RR that has name conflict?


BRs,
Kangping

On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon <= ;mellon@fugue.com> wrote:
How about including an additional section on the response that inc= ludes the conflicted names and rrtypes with zero length data? Or just pointi= ng to the root?

On Jan 1= 5, 2021, at 01:03, Kangping Dong <wgtdkp@google.com> wrote:

<= blockquote type=3D"cite">
=EF=BB=BF
Hi DNSSD= enthusiasts,

For Service Registration Protocol (SRP), wh= en a SRP server receives a registration with names
that have alrea= dy been taken by another client, it responds with a YXDOMAIN error code= to indicate
name conflicts. When the client receives such a respo= nse, it typically will re-generate a new host or
service instance n= ame and re-register with the new name.

The problem i= s that a typical SRP update will include one Host Description Instruction an= d one (or more)
Service Description Instructions (zero Service Des= cription Instruction is allowed but it is more common
that the cli= ent registers the host with some service instances). Name conflicts can happ= en on both Host
Description instruction and Service Descripti= on Instruction, but there is no description of how to tell the
cli= ent which instruction includes the conflict (or both include conflicts). Cur= rently, the client needs to re-new
both host name and service inst= ance name or re-new a single name and starts a trial-and-error process
=
until it finally succeeds.

One solution is, th= e server/registry responds with the Instruction(s) which has nam= e conflicts. For the
client, it should check the RRs in the respon= se to get the conflicting name if a YXDOMAIN response
code is rece= ived. To Reduce data transported between the server & client, the server= may just include
one RR, but not the entire Instruction, that contains the conflicting name.

Thoughts?


BRs,
Kangping
= --Apple-Mail-1520E959-47FA-42AD-A2EB-237B6407B447-- From nobody Sun Jan 17 23:06:15 2021 Return-Path: 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 EBF443A10DA for ; Sun, 17 Jan 2021 23:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.972 X-Spam-Level: X-Spam-Status: No, score=-16.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 BHrTZ0XsbIak for ; Sun, 17 Jan 2021 23:06:11 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 5D9383A10D8 for ; Sun, 17 Jan 2021 23:06:11 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id r32so2013717ybd.5 for ; Sun, 17 Jan 2021 23:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LzOpR3ntFfSIS7gSVdzbZ5+XA12Blb7OdE5PebO+nuY=; b=offnxcWGcAGnIh0BqSKwmg6qpEXoDJvjo59Zktmi6NZu/eMIcyjQTn6hiMzPhK6v7c XbNqwtYFBr2WS/VvUh6wxkkUzhKNl6EHkjVB5aczYGk94mgGVCR4DrVGC3pIejLPGSCr gVtw/SDc9h8g0o1g8auzz7oNpZcUkl1FCuCw3MwTmYF+AJ24FziEMFA6N5kOWzXr8VrJ YBi0yMwwBm4lN9jfLNhG/zfj6TjUFPxTqVu4JeNX9n0i5sbKoRwFqOi+yOg0TMdp1Rj1 cxsu2DX3fZD7P7WVf1rRWdpU7WXptlukEVH64tioqPFOGw2iKsa876AuL0K1xdpX+LsC 4ziA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LzOpR3ntFfSIS7gSVdzbZ5+XA12Blb7OdE5PebO+nuY=; b=ZK5NITQQMPkxEJsGHAE537aKrQH1YuJtG8MUlLVdjU2KqnucJBzroaPwJfIy0rKfQ2 O3/9qVnnsM3aPETrBM6qXgLIpzDVsDoFA2OAwaaprpzF1JAryCL7WKD+m/5LHXrD/Lxz fa0NBh6dWm+zUfcJBZmHnzO5Qjsqory6EL4J+6ZEwHR0PogjYj1OSi85U/G423apcHk8 yRtSUF4lFN9TPXgta1k/gss7Of4DkELnu9NHOjvr0ZKkut6iJflZ/IUpJ1u/vwmFWH6l QgGLIyq+vSZzOqcon8rCi8FziE2hwC4lxFHEnkD0WuilPzZeGJyqgRaDm8r4tz/DoHib NgHA== X-Gm-Message-State: AOAM530k7fCV49lsG68Esfzs9axAaygSazCrBM8k39l48v0/tygOoVkP dUw/gzpSyTI2pwHLTXxZP1QDv4Xh2SCo+2ocKYljvw== X-Google-Smtp-Source: ABdhPJyE+E6K8m7IwhMbDIKsdLU3LzaKYQpdIvBbVoTdSVum1awDDl6ASPmQH8XX5WsBfj7+opUiW59ayg5RbPOkxoE= X-Received: by 2002:a25:dbc4:: with SMTP id g187mr36762706ybf.489.1610953570131; Sun, 17 Jan 2021 23:06:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kangping Dong Date: Mon, 18 Jan 2021 15:05:33 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu Content-Type: multipart/alternative; boundary="0000000000004cac4105b9275bdc" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 07:06:13 -0000 --0000000000004cac4105b9275bdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, then I think both zero rdata and original rdata work for me. BRs, Kangping On Mon, Jan 18, 2021 at 12:08 PM Ted Lemon wrote: > The ptr or srv record, yes. I don=E2=80=99t think any is allowed outside = of the > question section. > > On Jan 17, 2021, at 22:46, Kangping Dong wrote: > > =EF=BB=BF > Should we use one RR with ANY type (and zero rdata) for one conflicted > name? Because the conflict applies to all RRs of this name. > > Or just pointing to the root? >> > Sorry, I am not following. Do you mean including exactly the original RR > that has name conflict? > > > BRs, > Kangping > > On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon wrote: > >> How about including an additional section on the response that includes >> the conflicted names and rrtypes with zero length data? Or just pointing= to >> the root? >> >> On Jan 15, 2021, at 01:03, Kangping Dong wrote: >> >> =EF=BB=BF >> Hi DNSSD enthusiasts, >> >> For Service Registration Protocol (SRP), when a SRP server receives a >> registration with names >> that have already been taken by another client, it responds with a >> YXDOMAIN error code to indicate >> name conflicts. When the client receives such a response, it typically >> will re-generate a new host or >> service instance name and re-register with the new name. >> >> The problem is that a typical SRP update will include one Host >> Description Instruction and one (or more) >> Service Description Instructions (zero Service Description Instruction i= s >> allowed but it is more common >> that the client registers the host with some service instances). Name >> conflicts can happen on both Host >> Description instruction and Service Description Instruction, but there i= s >> no description of how to tell the >> client which instruction includes the conflict (or both include >> conflicts). Currently, the client needs to re-new >> both host name and service instance name or re-new a single name and >> starts a trial-and-error process >> until it finally succeeds. >> >> One solution is, the server/registry responds with the *Instruction(s)* = which >> has name conflicts. For the >> client, it should check the RRs in the response to get the conflicting >> name if a YXDOMAIN response >> code is received. To Reduce data transported between the server & client= , >> the server may just include >> one RR, but not the entire *Instruction*, that contains the conflicting >> name. >> >> Thoughts? >> >> >> BRs, >> Kangping >> >> --0000000000004cac4105b9275bdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, then I think both zero rdata and original rdata wo= rk for me.

BRs,
Kangping

On Mon, Jan 18, = 2021 at 12:08 PM Ted Lemon <mellon@f= ugue.com> wrote:
The ptr or srv record, yes. I do= n=E2=80=99t think any is allowed outside of the question section.=C2=A0

On Jan 17, 2021, at 22:46,= Kangping Dong <w= gtdkp@google.com> wrote:

=EF=BB=BF
Should we use one RR w= ith ANY type (and zero rdata) for one conflicted name? Because=C2=A0the con= flict applies to all RRs of this name.

Or just pointing to the root?
<= div>Sorry, I am not following. Do you mean including exactly the original R= R that has name conflict?


BRs,
Kangping

On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon <mellon@fugue.com> wro= te:
How about including an additional section on the res= ponse that includes the conflicted names and rrtypes with zero length data?= Or just pointing to the root?

On Jan 15, 2021, at 01:03, Kangping Dong <wgtdkp@google.com> wrote:

=
=EF=BB=BFHi DNSSD enthusiasts,

For Service Registrat= ion Protocol (SRP), when a SRP server receives a registration with names
that have already been taken by another client, it responds=C2=A0wi= th a YXDOMAIN error code to indicate
name conflicts. When the cli= ent receives such a response, it typically will re-generate a new host or
service instance name and re-register with the new name.

The problem is that a typical SRP update will include one H= ost Description Instruction and one (or more)
Service Description= Instructions (zero Service Description Instruction is allowed but it is mo= re common
that the client registers the host with some service in= stances). Name conflicts can happen on both Host
Description=C2= =A0instruction and Service Description Instruction, but there is no descrip= tion of how to tell the
client which instruction includes the con= flict (or both include conflicts). Currently, the client needs to re-new
both host name and service instance name or re-new a single name an= d starts a trial-and-error process
until it finally succeeds.

One solution is, the server/registry responds with th= e Instruction(s)=C2=A0which has name conflicts. For the
cl= ient, it should check the RRs in the response to get the conflicting name i= f a YXDOMAIN response
code is received. To Reduce data transporte= d between the server & client, the server may just include
on= e RR, but not the entire=C2=A0Instruction, that contains the conflic= ting name.

Thoughts?


=
BRs,
Kangping

--0000000000004cac4105b9275bdc-- From nobody Mon Jan 18 06:21:55 2021 Return-Path: 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 865253A136F for ; Mon, 18 Jan 2021 06:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 egGi6fVDE_Cc for ; Mon, 18 Jan 2021 06:21:51 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 979573A136B for ; Mon, 18 Jan 2021 06:21:51 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id a13so7544442qvv.0 for ; Mon, 18 Jan 2021 06:21:51 -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=3h9vkuCu5I4xxm5YdzMmb6V98iNUMJ2+aifuUPzzYYc=; b=O9Tb3LBLWQkx33BUbjxw/8l8HGrMrKLU7eGx0fHq/OwxDX7+E6vOoXE/EOMe1FKpSP gqE8e31feWeiCQ2g7Gnp1/Gflis8PqD8aEmmhyNwoo+LwI/9bLmLm9jrimfCviP6bCFq lWbCJS0vnBBa+OIzI3iQYqsQ/7QueGjj5z8vRx0+HGJFqicCyEq3UCcJkEknKKAWV0wa vWQDPA7UmrxMxh5ssVSW71QWwm7qPWfThI2Twb4TjQTt4IX2Fkvw+yFY5qR6oHv76VV8 2uNq96pFGll3eKaScG2CSRJgEAtzDfyJRDNwAoIXTWyR1MK3l4fkKRAaDik/4EnWvyZ2 sx2w== 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=3h9vkuCu5I4xxm5YdzMmb6V98iNUMJ2+aifuUPzzYYc=; b=QCzAo75NJw+VOX/IEp2hTLH1uuxbPg7n+FpfPM/cTC0xg5EuQttfj4+hz95IoMlL/u dFOY0hBdAid3ppdpstxnt0FMb9wI8bk1FpFQdX9RzBEsuxB9G+6ysz8tpy03IlNNdvtV WBScMj7BIv+JNH+78/qjtUm96Cr/pcRlTKTRtBkL1A4Spb4mH10SNvkgbiE+JaAtCH+C t/w0q4IW2vhKY4eyPbrMXi2r6seqbYpSrsRuI+UdL+W3bstkxvS9EH3DVuGfNRiHxJy8 T/nKrlX6Rzpz9uZDqYDdftjWM6ZOkDtT4JmPp24DnCOd9Z0TFqQUPMVFkUMj7aCZo0My 8Hgw== X-Gm-Message-State: AOAM531+Jel+LTXYZXTMKcjW9o7hNsXWF72AGzkVJrApWUT7sTCwDL1P HxHDjQ+Ef63bpNGFz1Zk/x5fqw== X-Google-Smtp-Source: ABdhPJx5eqAk6x3veN4x5mttxAB8dgb+8jTa8KMkWeZMGI+uT7jXUbl5WMksoue89txQ/ZqOzQRVrQ== X-Received: by 2002:a0c:a525:: with SMTP id y34mr23985880qvy.37.1610979710521; Mon, 18 Jan 2021 06:21:50 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id i13sm10592290qkk.83.2021.01.18.06.21.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jan 2021 06:21:49 -0800 (PST) From: Ted Lemon Message-Id: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_750878D8-6D7E-4250-BD1B-E400004CFD78" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Mon, 18 Jan 2021 09:21:47 -0500 In-Reply-To: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu To: Kangping Dong References: X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 14:21:54 -0000 --Apple-Mail=_750878D8-6D7E-4250-BD1B-E400004CFD78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 18, 2021, at 2:05 AM, Kangping Dong wrote: > Thanks, then I think both zero rdata and original rdata work for me. Okay. I think it=E2=80=99s better if the response is syntactically valid = to a parser that doesn=E2=80=99t have special knowledge, so we = shouldn=E2=80=99t use zero-length rdata. We could encode some = information in the CLASS or TTL of the response, though. One thing that = occurs to me is that there=E2=80=99s a failure mode that can occur if = you are using an advertising proxy (as opposed to an authoritative = server) model: two different clients choose the same name at roughly the = same time, but their advertising proxies aren=E2=80=99t in = communication, so duplicate detection fails to detect the conflict = before a positive reply is sent to both. Later on, the conflict is noticed, and one or both of these devices gets = renamed. At this point we don=E2=80=99t have a way to communicate the = name change to the SRP client, because it=E2=80=99s not expecting = another reply. For SRP clients that make TCP connections to the server, = we could use some sort of subscription model to address this, but for = constrained clients (e.g. Thread accessories), that won=E2=80=99t work. = There are three ways to address this problem that have occurred to me: The next time the SRP client registers, we signal to it that it was = renamed, and give it its new name. The SRP client is then free to either = register another name, or accept the new name that it was given. The next time the client registers, we signal to it that there is a name = conflict, and it renames itself; the temporary new name is removed. The SRP server just carries on with the new name without notifying the = client. Right now, my advertising proxy implementation does (3). The reason is = that this produces the fewest name changes, and that seemed like a = desirable characteristic. I did this because the only simple alternative = that occurred to me at the time was (2), which would always result in = the client being renamed twice.=20 However, since we are now contemplating sending back conflict = information, (1) becomes possible=E2=80=94we can send back the name that = was rejected, and the new name, marking the rejected name with a TTL of = zero and the new name with a TTL that is nonzero. This gives the client = the option to choose a new name if there is a conflict. It doesn=E2=80=99t= have to choose a new name=E2=80=94it can do nothing. So now we have = full transparency, and the correct amount of efficiency. What do you think of these approaches? --Apple-Mail=_750878D8-6D7E-4250-BD1B-E400004CFD78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 18, 2021, at 2:05 AM, Kangping Dong <wgtdkp@google.com> = wrote:
Thanks, then = I think both zero rdata and original rdata work for me.

Okay. I think it=E2=80=99s better if the = response is syntactically valid to a parser that doesn=E2=80=99t have = special knowledge, so we shouldn=E2=80=99t use zero-length rdata. We = could encode some information in the CLASS or TTL of the response, = though. One thing that occurs to me is that there=E2=80=99s a failure = mode that can occur if you are using an advertising proxy (as opposed to = an authoritative server) model: two different clients choose the same = name at roughly the same time, but their advertising proxies aren=E2=80=99= t in communication, so duplicate detection fails to detect the conflict = before a positive reply is sent to both.

Later on, the conflict is noticed, and = one or both of these devices gets renamed. At this point we don=E2=80=99t = have a way to communicate the name change to the SRP client, because = it=E2=80=99s not expecting another reply. For SRP clients that make TCP = connections to the server, we could use some sort of subscription model = to address this, but for constrained clients (e.g. Thread accessories), = that won=E2=80=99t work. There are three ways to address this problem = that have occurred to me:

  1. The next time = the SRP client registers, we signal to it that it was renamed, and give = it its new name. The SRP client is then free to either register another = name, or accept the new name that it was given.
  2. The = next time the client registers, we signal to it that there is a name = conflict, and it renames itself; the temporary new name is = removed.
  3. The SRP server just carries on with the new = name without notifying the client.

Right now, my advertising proxy = implementation does (3). The reason is that this produces the fewest = name changes, and that seemed like a desirable characteristic. I did = this because the only simple alternative that occurred to me at the time = was (2), which would always result in the client being renamed = twice. 

However, since we are now contemplating sending back conflict = information, (1) becomes possible=E2=80=94we can send back the name that = was rejected, and the new name, marking the rejected name with a TTL of = zero and the new name with a TTL that is nonzero. This gives the client = the option to choose a new name if there is a conflict. It doesn=E2=80=99t= have to choose a new name=E2=80=94it can do nothing. So now we have = full transparency, and the correct amount of efficiency.

What do you think of = these approaches?

= --Apple-Mail=_750878D8-6D7E-4250-BD1B-E400004CFD78-- From nobody Tue Jan 19 13:18:18 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB413A1783; Tue, 19 Jan 2021 13:18:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: bs7652@att.com, dnssd-chairs@ietf.org, dnssd@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161109109574.1044.6816971611225404342@ietfa.amsl.com> Date: Tue, 19 Jan 2021 13:18:15 -0800 Archived-At: Subject: [dnssd] dnssd - New Meeting Session Request for IETF 110 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 21:18:16 -0000 A new meeting session request has just been submitted by Barbara Stark, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Barbara Stark Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: dnsop dprive homenet quic tls babel intarea httpbis 6man v6ops Technology Overlap: mls core anima Key Participant Conflict: 6tisch rats roll lake People who must be present: Stephen Farrell Ted Lemon Eric Vyncke Barbara Stark David Schinazi Resources Requested: Special Requests: dnssd and homenet would like to do a single joint 2 hour meeting. We'll figure out how to divide the time. --------------------------------------------------------- From nobody Wed Jan 20 21:28:31 2021 Return-Path: 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 40BD43A0DC2 for ; Wed, 20 Jan 2021 21:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.971 X-Spam-Level: X-Spam-Status: No, score=-16.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7B5OF64irD7O for ; Wed, 20 Jan 2021 21:28:28 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 9190E3A0DD2 for ; Wed, 20 Jan 2021 21:28:28 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id f6so890619ybq.13 for ; Wed, 20 Jan 2021 21:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RG9keq2U3SSDhcGnQzRB3J1rGI5YvDMjK4SCKHRU43I=; b=Wsn+Cyay+HKiauVeYtCmq8/Z5JRvWPQ17OcvPxR0GckLlZqi9xiWeuzjuhYV0dKftm XGovx9B7QNwEhYHMjubk7PLWOgQ8FB8vDFuKVSYQ86p/Cr0P6XVz9mU/evaY2BoJyVFX HVR3+rdm83nrAr5+1RCcCNFViYznvVrmdIni8H7JrmEUhfxKmiF5nr9C9gIAPvkjf8dP AL8kzsEjYjP15cVH0jZjjA1pL+FfSDcgFuP9poHgA6dYDK/wC7liMUf2z64adWeFAHH9 DOJUK8xkwGQ5BihHQomADh9rI9xHya9e2+LJWuW6pZE2DL7Ya9TYbrDD/UErH8sJdfnK fQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RG9keq2U3SSDhcGnQzRB3J1rGI5YvDMjK4SCKHRU43I=; b=S7WkCIBNpXa3ECtSO/WmDRq7zqWmBMr7muTS1BeZueRg/tzHuX9MaQmh1Qqnsu7Bhv 7MEt8ROCFyVNiBHBoEK68H+20HNHX8RpEtkkfQdC3QfVWIrsB84ESWfCJMD94oy+jpBG hTn9+arF4eJNavEQUAAjHYIgvZKqwx+glRU6WcfWUmfkLE90mLluH0+HdyjxdbHefrGi teYzpFJkvN/dhs8/sC4/ZPbJCNwDG9OHUIOFkF7791ytvVdZIGC7GESsK0z1nHQa9LP9 wA+DtklzQ5SKh1PKg7/voyM66Qo/jTee+ciIKMDSTGNvvh1Fi/Ffn/bsuyaKzaNz/uUl oayA== X-Gm-Message-State: AOAM530sGPNpJK2KKxWzaww0tWkhFrWbYMrM5HGVkCuqqh/oRNg13wfj ln23ZPIPTUUMpzIy598Kyzy7RFhbZyARlARVeY4qTA== X-Google-Smtp-Source: ABdhPJy20TXvxuy+SrA5zON1hY629aUtRNeJ1sizL8csGRtg/12pkadtN86eiUEq5t+WShV1vKTBB3hhVRv6N+EuokE= X-Received: by 2002:a25:4c8a:: with SMTP id z132mr20268933yba.350.1611206907237; Wed, 20 Jan 2021 21:28:27 -0800 (PST) MIME-Version: 1.0 References: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> In-Reply-To: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> From: Kangping Dong Date: Thu, 21 Jan 2021 13:27:51 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , ronglisun-team@google.com, Yakun Xu Content-Type: multipart/alternative; boundary="0000000000005e0be405b9625787" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 05:28:30 -0000 --0000000000005e0be405b9625787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ted, Sorry for the late reply. Okay. I think it=E2=80=99s better if the response is syntactically valid to= a > parser that doesn=E2=80=99t have special knowledge, so we shouldn=E2=80= =99t use zero-length > rdata. > Agree. The next time the SRP client registers, we signal to it that it was > renamed, and give it its new name. The SRP client is then free to either > register another name, or accept the new name that it was given. Option (1) also looks good to me. But what are the RRs that should be included in the response? SRV RR for service instance name and AAAA/A RR for host name? BRs, Kangping On Mon, Jan 18, 2021 at 10:21 PM Ted Lemon wrote: > On Jan 18, 2021, at 2:05 AM, Kangping Dong wrote: > > Thanks, then I think both zero rdata and original rdata work for me. > > > Okay. I think it=E2=80=99s better if the response is syntactically valid = to a > parser that doesn=E2=80=99t have special knowledge, so we shouldn=E2=80= =99t use zero-length > rdata. We could encode some information in the CLASS or TTL of the > response, though. One thing that occurs to me is that there=E2=80=99s a f= ailure > mode that can occur if you are using an advertising proxy (as opposed to = an > authoritative server) model: two different clients choose the same name a= t > roughly the same time, but their advertising proxies aren=E2=80=99t in > communication, so duplicate detection fails to detect the conflict before= a > positive reply is sent to both. > > Later on, the conflict is noticed, and one or both of these devices gets > renamed. At this point we don=E2=80=99t have a way to communicate the nam= e change > to the SRP client, because it=E2=80=99s not expecting another reply. For = SRP > clients that make TCP connections to the server, we could use some sort o= f > subscription model to address this, but for constrained clients (e.g. > Thread accessories), that won=E2=80=99t work. There are three ways to add= ress this > problem that have occurred to me: > > > 1. The next time the SRP client registers, we signal to it that it was > renamed, and give it its new name. The SRP client is then free to eith= er > register another name, or accept the new name that it was given. > 2. The next time the client registers, we signal to it that there is a > name conflict, and it renames itself; the temporary new name is remove= d. > 3. The SRP server just carries on with the new name without notifying > the client. > > > Right now, my advertising proxy implementation does (3). The reason is > that this produces the fewest name changes, and that seemed like a > desirable characteristic. I did this because the only simple alternative > that occurred to me at the time was (2), which would always result in the > client being renamed twice. > > However, since we are now contemplating sending back conflict information= , > (1) becomes possible=E2=80=94we can send back the name that was rejected,= and the > new name, marking the rejected name with a TTL of zero and the new name > with a TTL that is nonzero. This gives the client the option to choose a > new name if there is a conflict. It doesn=E2=80=99t have to choose a new = name=E2=80=94it > can do nothing. So now we have full transparency, and the correct amount = of > efficiency. > > What do you think of these approaches? > > --0000000000005e0be405b9625787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

Sorry for the late reply.=C2=A0=

Okay= . I think it=E2=80=99s better if the response is syntactically valid to a p= arser that doesn=E2=80=99t have special knowledge, so we shouldn=E2=80=99t = use zero-length rdata.
Agree.

=C2=A0The next time the SRP c= lient registers, we signal to it that it was renamed, and give it its new n= ame. The SRP client is then free to either register another name, or accept= the new name that it was given.
Option (1) also looks goo= d to me. But what are the RRs that should be included in the response? SRV = RR for service instance name and AAAA/A RR for host name?


BRs,
Kangping

On Mon, Jan 18, 2021 at= 10:21 PM Ted Lemon <mellon@fugue.co= m> wrote:
On Jan 18, 2021, at 2:05 AM, Kan= gping Dong <wgtdk= p@google.com> wrote:
Thanks, then I think both= zero rdata and original rdata work for me.

Okay. I think it=E2=80=99s better if the response is syntactic= ally valid to a parser that doesn=E2=80=99t have special knowledge, so we s= houldn=E2=80=99t use zero-length rdata. We could encode some information in= the CLASS or TTL of the response, though. One thing that occurs to me is t= hat there=E2=80=99s a failure mode that can occur if you are using an adver= tising proxy (as opposed to an authoritative server) model: two different c= lients choose the same name at roughly the same time, but their advertising= proxies aren=E2=80=99t in communication, so duplicate detection fails to d= etect the conflict before a positive reply is sent to both.

<= /div>
Later on, the conflict is noticed, and one or both of these devic= es gets renamed. At this point we don=E2=80=99t have a way to communicate t= he name change to the SRP client, because it=E2=80=99s not expecting anothe= r reply. For SRP clients that make TCP connections to the server, we could = use some sort of subscription model to address this, but for constrained cl= ients (e.g. Thread accessories), that won=E2=80=99t work. There are three w= ays to address this problem that have occurred to me:

<= div>
  1. The next=C2=A0time the SRP client registers, we signal to it th= at it was renamed, and give it its new name. The SRP client is then free to= either register another name, or accept the new name that it was given.
  2. The next time the client registers, we signal to it that there is a n= ame conflict, and it renames itself; the temporary new name is removed.
  3. The SRP server just carries on with the new name without notifying the= client.

Right now, my advertising proxy= implementation does (3). The reason is that this produces the fewest name = changes, and that seemed like a desirable characteristic. I did this becaus= e the only simple alternative that occurred to me at the time was (2), whic= h would always result in the client being renamed twice.=C2=A0
However, since we are now contemplating sending back conflict = information, (1) becomes possible=E2=80=94we can send back the name that wa= s rejected, and the new name, marking the rejected name with a TTL of zero = and the new name with a TTL that is nonzero. This gives the client the opti= on to choose a new name if there is a conflict. It doesn=E2=80=99t have to = choose a new name=E2=80=94it can do nothing. So now we have full transparen= cy, and the correct amount of efficiency.

What do = you think of these approaches?

--0000000000005e0be405b9625787-- From nobody Thu Jan 21 08:11:23 2021 Return-Path: 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 33C223A125D for ; Thu, 21 Jan 2021 08:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 CKwR2JCWZBzZ for ; Thu, 21 Jan 2021 08:11:19 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 595633A1261 for ; Thu, 21 Jan 2021 08:11:19 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id e17so1899021qto.3 for ; Thu, 21 Jan 2021 08:11:19 -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=8WPExjCNQA5HAwXW3XT7up9FhAdSdHMPCO3UpKdl76c=; b=Ll1MamcUdyqUy7dApZKRlNrG0KIvrB6SWoIzR2L4YBVMiSTO0/Ixg+QvdYvdQ+FQW9 jL9hHq3oplCz/mFmtYy0UTEzSElXf9UUGXX9VgVd9MKwM+zV4SIv/bbrUjqAC9BmBqyL 3znL2MLjMveYCWERD4HvJ/OnNlEnjUTDnexpXimz2y9OW3r3h+cD8KwZEIXvdBgwGOY2 p5UvuxA8II4fXm1vceEcBRc4M/ElNJPacEzW3cemRQ78knff09fiPVvyhuTd0ul6CHdX Ml1TQgSqhInOM02m28IzmYXMFDsJDrsY2zEUy9Vx1/HAyymRNMlDmcAE80jpn3Qx0Bc8 bKAw== 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=8WPExjCNQA5HAwXW3XT7up9FhAdSdHMPCO3UpKdl76c=; b=S3AxoJOWQS9KfJtYtV+5Yjo9X4pVRbuAz1JOnqZ4VM6oyub3CObPAmVFUm4S3fKoWP T/aoOTCXKVmqfpFGRKpBdB3LEXZChqnUcyAiezLd2c92VKcqy42Wzc8NQtgtsR+hCwzB WilXizRgneRLpCTZp3+kj0WH1kwiqFI9z1g3PvLVVd2x2oX4GxuKCwQHy8eDDzV6f0r8 js8drCSgX5jFq5b+I8foYKG2Gj/tb0qJp2OsP8e1Vf2+KgY1aReewFxOSnbTjtWJMp9i ESeIjVZ5jlLUAphvbUHtAMolv33iN0GkHgWLSEO7TsCWpA1sAEqzIF1krQbv4cVs1Ojh 2cYA== X-Gm-Message-State: AOAM5336NSkxVPVMSP8uvhUhG4OmPVAGgAQm2RltYkB30PDO2jDBYngA VT7yKrmZpM69Bl6Vj61s+p/7Qw== X-Google-Smtp-Source: ABdhPJykXJx4dO2jJm+GMzXH6L0NHNHki0MXHuoir/1AkJaKUYS5/SRmSvKfkIWOG8NzI8EQojbCOQ== X-Received: by 2002:ac8:4b75:: with SMTP id g21mr322982qts.334.1611245478297; Thu, 21 Jan 2021 08:11:18 -0800 (PST) Received: from [192.168.4.75] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id n30sm1347447qte.34.2021.01.21.08.11.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2021 08:11:16 -0800 (PST) From: Ted Lemon Message-Id: <700C359B-B9D1-4A1E-A7B2-1ACA0AF224C5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1E0AFB90-A36A-4534-8DB0-41636D8E8EE3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Thu, 21 Jan 2021 11:11:14 -0500 In-Reply-To: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu To: Kangping Dong References: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 16:11:21 -0000 --Apple-Mail=_1E0AFB90-A36A-4534-8DB0-41636D8E8EE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 21, 2021, at 12:27 AM, Kangping Dong wrote: > Option (1) also looks good to me. But what are the RRs that should be = included in the response? SRV RR for service instance name and AAAA/A RR = for host name? Yes, I think that makes sense. These unambiguously indicate what type of = update failed. Which brings up the question of what RRtype to use for = renaming. CNAME? --Apple-Mail=_1E0AFB90-A36A-4534-8DB0-41636D8E8EE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 21, 2021, at 12:27 AM, Kangping Dong <wgtdkp@google.com> = wrote:
Option = (1) also looks good to me. But what are the RRs that should be included = in the response? SRV RR for service instance name and AAAA/A RR for host = name?

Yes, I think = that makes sense. These unambiguously indicate what type of update = failed. Which brings up the question of what RRtype to use for renaming. = CNAME?

= --Apple-Mail=_1E0AFB90-A36A-4534-8DB0-41636D8E8EE3-- From nobody Thu Jan 21 22:02:54 2021 Return-Path: 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 AA9D13A1108 for ; Thu, 21 Jan 2021 22:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.972 X-Spam-Level: X-Spam-Status: No, score=-16.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 N8is89FmKXLO for ; Thu, 21 Jan 2021 22:02:44 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 5DA2B3A1103 for ; Thu, 21 Jan 2021 22:02:44 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id y4so4457834ybn.3 for ; Thu, 21 Jan 2021 22:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O7Z2MwY6DKrWjL6VpnlRAxN3hQ6z+cI6c1ftCgBadn0=; b=RrKV18pdMVRhGVt2C1JG2gv6XenLPXC0yNPgcj2a1SCvLdCh+5eUYOBZ911EFN1ZkK 35OpsXVVCdn+TzsGAHf0drevgGoVIgcXAqYwPToUMAxxGxKRh2/xc2hF3z1RmRE5/Pcx I/3VIS8ocpu+A94GevBkXVHiLQESzJe54zXPH0ZCg5EkB9+MUuX6xxavO+v8irZY8rzY tTtE1o3Txtjay8EGdrRcWKFoGam3MPouolvpqfGbRAx7ZjMdo852yR41tM8b/xX8en+v 30KcTPQSOW3x/Sw8crSbur/9BbOA43CtgYzkvG82U0nO61Tr7WPkOchw9q29SFaNhyuG 8x7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O7Z2MwY6DKrWjL6VpnlRAxN3hQ6z+cI6c1ftCgBadn0=; b=F2hsmKcL8ycHBPFGr/t2kpYps02KNku0BMZ3VMWyn8mcuz8WVhTFITmj5pA2ynje0E fp68WBwnsEKZ+/9j9Ll8KGT/wZnxz+IUeRT1n/UdhBGdO/ruZM1sRW/IWOj17CJuqUbu 5WmVIiJoHJje/qlE5pum1c6Ky+Ab5H1+X1XUnODly2mEpKujPBB1Ruj9jZS763E606fY PAscFqettaftxq+Ubxb/6OZuMV/zrUqhOdqIfuMMKAI7TkG4l35FyTTYt4xQmynLfm1W 5sLIIJ3j5fmQZEpfAg7eG3XSrnXg2NYJSikH4zM4bwu1hmCIXMQyOXn4vi1+eblQuFrD iPFg== X-Gm-Message-State: AOAM532N7z8cqd7vMyFSklBokcO1gyZ/fyWlMxoNSRjVderXcmL2vXxP yr6k9aW9gD1ECsGp8NjKYzSr9bZKPf6lAzI3590YdA== X-Google-Smtp-Source: ABdhPJwDu8XGrZsYkqnjFpPQhL++WPL8XspmCaL5s6O0YiV/l9OOwkySsmHfETWniygMX6rc0Ry1fao4y+Zx4Df92gE= X-Received: by 2002:a25:4c8a:: with SMTP id z132mr4656634yba.350.1611295363087; Thu, 21 Jan 2021 22:02:43 -0800 (PST) MIME-Version: 1.0 References: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> <700C359B-B9D1-4A1E-A7B2-1ACA0AF224C5@fugue.com> In-Reply-To: <700C359B-B9D1-4A1E-A7B2-1ACA0AF224C5@fugue.com> From: Kangping Dong Date: Fri, 22 Jan 2021 14:02:07 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu , Rongli Sun , Simon Lin Content-Type: multipart/alternative; boundary="000000000000bf2c5705b976ef8e" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 06:02:53 -0000 --000000000000bf2c5705b976ef8e Content-Type: text/plain; charset="UTF-8" To make sure if I correctly understand how this works, let me explain how a SRP client will handle name conflicts: 1. If a name has already been registered on the SRP server or a name conflict error is returned by the Advertising Proxy: the SRP server responds with the RR that includes the conflicted name. If the client sees such records, it knows the conflicts on the SRP server and will retry with a new name. 2. If a name conflict is reported to the SRP server after the SRP update transaction has been committed: The next time the SRP client registers, the SRP server responds with a CNAME record which includes the new name. If the client sees such records, it knows the conflict on the multicast link and will accept the name or retry with another name. Am I correct about the workflow? On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon wrote: > On Jan 21, 2021, at 12:27 AM, Kangping Dong wrote: > > Option (1) also looks good to me. But what are the RRs that should be > included in the response? SRV RR for service instance name and AAAA/A RR > for host name? > > > Yes, I think that makes sense. These unambiguously indicate what type of > update failed. Which brings up the question of what RRtype to use for > renaming. CNAME? > > --000000000000bf2c5705b976ef8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To make sure if I correctly understand how this=C2=A0works= , let me explain=C2=A0how a SRP client will handle=C2=A0name conflicts:1. If a name has already been registered on the SRP server or a name confl= ict error is returned by the Advertising Proxy:
=C2=A0 =C2=A0 the= SRP server responds with the RR that includes the conflicted name. If the = client sees such records, it knows the conflicts
=C2=A0 =C2=A0on = the SRP server and will retry with a new name.
2. If a name confl= ict is reported to the SRP server after the SRP update transaction has been= committed:
=C2=A0 =C2=A0 The next time the SRP client registers,= the SRP server responds with=C2=A0a=C2=A0CNAME record which includes the n= ew name.
=C2=A0 =C2=A0 If the client sees such records, it knows = the conflict on the multicast link and will accept the name or retry=C2=A0w= ith another name.

Am I correct about the workflow?=


On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon <mellon@fugue.com> wro= te:
On Jan = 21, 2021, at 12:27 AM, Kangping Dong <wgtdkp@google.com> wrote:
Option (1) also looks good to me. But w= hat are the RRs that should be included in the response? SRV RR for service= instance name and AAAA/A RR for host name?

Yes, I think that makes sense. These unambiguously indicate what ty= pe of update failed. Which brings up the question of what RRtype to use for= renaming. CNAME?

--000000000000bf2c5705b976ef8e-- From nobody Fri Jan 22 06:52:45 2021 Return-Path: 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 3662E3A0C86 for ; Fri, 22 Jan 2021 06:52:44 -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 s0pDhsXqIB4e for ; Fri, 22 Jan 2021 06:52:42 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 52B4C3A0C7A for ; Fri, 22 Jan 2021 06:52:42 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id k193so5300377qke.6 for ; Fri, 22 Jan 2021 06:52:42 -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=AswXAxecAJOApKz6vjoQU0zi7hZ2AM9xIIDaLqyqMnM=; b=AAx4yNyh2CGeVy4WB86lvbsLr5rWz9tQNeuGHyBYWDftfXNlOPHH3r3Mp5d/crBZ/L yBrMkZYq+WhZ9WCkWhqk8+7wbq1TM9psmDxfIFdDUnKfXNI9B5rr77d/eQpNLbFe7iJT 88fcXCHwKkyzlGxQkkgyqDq1ocGyVS16IlNQcxXs+3D7n0tnNMU2YC5X1t3BOow33Bmu 0r934Lt8E1fl7zm8RQYN6R/7lCYxhzXURVtJHZqBmC/BRLWEkSIseR8jjJLmroEXEzaD 0fb2mj9XOBFJyJGfFP6dZUZfd/06S5zEhtUwTK4nZLx7QQs5kdrL/F8drPXhxonrIMpP Hm7w== 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=AswXAxecAJOApKz6vjoQU0zi7hZ2AM9xIIDaLqyqMnM=; b=WbWa5gAgLcWNIcLcYRcZn50msdv6jeGeA8LKakZowDiS98TaVBc57CKY3W4eG7mlVo Rgh/dQPAzCfV81bUHdqwGpe+iL8x43GKx/eJGn4IlF1qDa4WeuA8aLwHepAwJ+SzWVAy Er+TaILUpRBG3Ij3iAvVPhYL9hU+wOwXu4ad6WmT9K/y+RxXnQCKRpTqyWUYe48r51zU WJi1eGGo/mfUkz1TZYVDmBs3OLGxXZGlHqmJ0zSdApKUEvfJrpDp1N3pI/CJtsBa+zRJ xLIzP/+sfyjGmP6V8Bva/yPMXIH54q7gdaHjqYz/diZUzg1OdkoMyxYnBQv4ceI6Fqsh uWkw== X-Gm-Message-State: AOAM533UTKscx209X290h4AuzHo5dF8vh+ozRCYZsndsW6YJu5xDurNl kdwQ4Z60i3WQFGuOrE/nRaZnpA== X-Google-Smtp-Source: ABdhPJzwwYNhLGnQfGdvslRIjHFBO62TII7/8cFHaFHcoocaVzL6aQDm9madfbdCWZCxgJjfVfzcBw== X-Received: by 2002:a37:5a47:: with SMTP id o68mr220387qkb.423.1611327161203; Fri, 22 Jan 2021 06:52:41 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h22sm5645303qth.55.2021.01.22.06.52.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 06:52:40 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B60143F3-95F9-4B9C-87DD-142F4EFD9956" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Date: Fri, 22 Jan 2021 09:52:38 -0500 In-Reply-To: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu , Rongli Sun , Simon Lin To: Kangping Dong References: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> <700C359B-B9D1-4A1E-A7B2-1ACA0AF224C5@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 14:52:44 -0000 --Apple-Mail=_B60143F3-95F9-4B9C-87DD-142F4EFD9956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think that=E2=80=99s a good description of the solution, yes. > On Jan 22, 2021, at 1:02 AM, Kangping Dong wrote: >=20 > To make sure if I correctly understand how this works, let me explain = how a SRP client will handle name conflicts: > 1. If a name has already been registered on the SRP server or a name = conflict error is returned by the Advertising Proxy: > the SRP server responds with the RR that includes the conflicted = name. If the client sees such records, it knows the conflicts > on the SRP server and will retry with a new name. > 2. If a name conflict is reported to the SRP server after the SRP = update transaction has been committed: > The next time the SRP client registers, the SRP server responds = with a CNAME record which includes the new name. > If the client sees such records, it knows the conflict on the = multicast link and will accept the name or retry with another name. >=20 > Am I correct about the workflow? >=20 >=20 > On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon > wrote: > On Jan 21, 2021, at 12:27 AM, Kangping Dong > wrote: >> Option (1) also looks good to me. But what are the RRs that should be = included in the response? SRV RR for service instance name and AAAA/A RR = for host name? >=20 > Yes, I think that makes sense. These unambiguously indicate what type = of update failed. Which brings up the question of what RRtype to use for = renaming. CNAME? >=20 --Apple-Mail=_B60143F3-95F9-4B9C-87DD-142F4EFD9956 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think that=E2=80=99s a good description of the solution, yes.

On Jan 22, 2021, at 1:02 AM, Kangping Dong <wgtdkp@google.com> = wrote:

To make sure if I correctly understand how = this works, let me explain how a SRP client will = handle name conflicts:
1. If a name has already been = registered on the SRP server or a name conflict error is returned by the = Advertising Proxy:
    the SRP server = responds with the RR that includes the conflicted name. If the client = sees such records, it knows the conflicts
  =  on the SRP server and will retry with a new name.
2. If a name conflict is reported to the SRP server after the = SRP update transaction has been committed:
  =   The next time the SRP client registers, the SRP server responds = with a CNAME record which includes the new name.
    If the client sees such records, it knows the = conflict on the multicast link and will accept the name or = retry with another name.

Am I correct about the = workflow?


On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon <mellon@fugue.com> wrote:
On Jan 21, = 2021, at 12:27 AM, Kangping Dong <wgtdkp@google.com> wrote:
Option (1) also looks good to me. But what = are the RRs that should be included in the response? SRV RR for service = instance name and AAAA/A RR for host name?

Yes, I think that makes sense. These = unambiguously indicate what type of update failed. Which brings up the = question of what RRtype to use for renaming. CNAME?


= --Apple-Mail=_B60143F3-95F9-4B9C-87DD-142F4EFD9956-- From nobody Sat Jan 23 22:05:34 2021 Return-Path: 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 8ACE53A0CB8 for ; Sat, 23 Jan 2021 22:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.971 X-Spam-Level: X-Spam-Status: No, score=-16.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UEmeySkrTZKl for ; Sat, 23 Jan 2021 22:05:30 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 CEEE23A0CB5 for ; Sat, 23 Jan 2021 22:05:30 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id p185so9948634ybg.8 for ; Sat, 23 Jan 2021 22:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6KUAS9MSJredKwVzRtjcA3lYNUeJw40Y5VZOlp8jIbQ=; b=XLvCBRcMK93fEZ5bNsd2nZY3DtuptQAa7v8BklFhb4LbdL9rrTv0uV0oGXRRrRHR/2 H96lb/5VjUeNVdndsiM2Q5rGuaiAeSrpVQYzrRK7VjKlPUGiAZWx55V+x/07ERTLCeak jmkcHbWqbBapdc9tHGRbKQ7tLdQV3K1rawGYq7kfsW7e/+hFH1ESZIlpj2nq7ZylSBYL 5K+mzTKyQmsDb3wjtqh8GPvM5b7ihZYrPK1rD/7Si5csyPgCIqWpeZi0DySisZQdiVSy 9hnboZKHRISSrxwTccqM+iiddzj33GTfBeXmZ9VJDmk8UE0B7oRWCwcpxxaVkBbbFpfj yCgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6KUAS9MSJredKwVzRtjcA3lYNUeJw40Y5VZOlp8jIbQ=; b=PHNnXP+OeICbHO4fU91mHJQWet7G/Ee67f5MOTmryi5wid/4NIqFnomGBG0y80VfPj xuURlJkZQWqi7xu7Zgndye9FHSMJXBdMFT67nCVI+31dIYCVWRxiR4jC9ojOsMTBh9fD BPAdIePMLQf6JegOZmTdrFWgb6RTGfgaz5VGvIXs7nRnrHlfbe+z9DszXC+bslOT9NMS OZ7n+AwyXc7Q60N9Q024R2eKCCY61Bj1I7oLrOCZWPxWxwXjX4C7S7TdSC0/8iLQFYgj fYT+VC5M65vmKfknTKHBpaZl0QKYrwbr7P5z4iQ8Wp46fe1dxuukWcqym/edg9lES19I 7iDw== X-Gm-Message-State: AOAM530A+883+MthDofzS2bCV7GV4DNySc2io0fjYfjEkah7p6WhfAhH BKsFHY1DrIDz+zxh+oKTavp3Xl+KET3zz2KpOEh1Ew== X-Google-Smtp-Source: ABdhPJzIvRNQyPlZ4k+n56G/N5BtVg9kCERop9ZaN1GMX9GF0V4RhNFoaXR8ieZk9YQaej3aYFe8U44Wf/1lDHjNI8I= X-Received: by 2002:a25:c50a:: with SMTP id v10mr17108766ybe.276.1611468329484; Sat, 23 Jan 2021 22:05:29 -0800 (PST) MIME-Version: 1.0 References: <0A1488E9-BFB8-4E82-815B-EF1F2A40B35E@fugue.com> <700C359B-B9D1-4A1E-A7B2-1ACA0AF224C5@fugue.com> In-Reply-To: From: Kangping Dong Date: Sun, 24 Jan 2021 14:04:53 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu , Rongli Sun , Simon Lin Content-Type: multipart/alternative; boundary="0000000000005943cb05b99f35e3" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 06:05:33 -0000 --0000000000005943cb05b99f35e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable okay, the workflow almost works for me, just a small question. For case 2, when the Advertising Proxy detects a name conflict on the multicast link, it choses a new name and informs the SRP server the new name. Before the client refreshes its service registration, how should the SRP server/Border Router respond to a DNS query for the original name? I think the BR will reject the query with some error like *RESOURCE_NOT_FOUND* / *NAME_NOT_FOUND*, as the service has already been renamed but just the client hasn't been notified yet. right? On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon wrote: > I think that=E2=80=99s a good description of the solution, yes. > > On Jan 22, 2021, at 1:02 AM, Kangping Dong wrote: > > To make sure if I correctly understand how this works, let me explain how > a SRP client will handle name conflicts: > 1. If a name has already been registered on the SRP server or a name > conflict error is returned by the Advertising Proxy: > the SRP server responds with the RR that includes the conflicted name= . > If the client sees such records, it knows the conflicts > on the SRP server and will retry with a new name. > 2. If a name conflict is reported to the SRP server after the SRP update > transaction has been committed: > The next time the SRP client registers, the SRP server responds > with a CNAME record which includes the new name. > If the client sees such records, it knows the conflict on the > multicast link and will accept the name or retry with another name. > > Am I correct about the workflow? > > > On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon wrote: > >> On Jan 21, 2021, at 12:27 AM, Kangping Dong wrote: >> >> Option (1) also looks good to me. But what are the RRs that should be >> included in the response? SRV RR for service instance name and AAAA/A RR >> for host name? >> >> >> Yes, I think that makes sense. These unambiguously indicate what type of >> update failed. Which brings up the question of what RRtype to use for >> renaming. CNAME? >> >> > --0000000000005943cb05b99f35e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
okay, the workflow almost works for me, just a small quest= ion. For case 2, when the Advertising Proxy detects a name conflict on the = multicast=C2=A0link,
it choses a new name and informs the SRP server th= e new name. Before the client refreshes its service registration, how shoul= d the SRP server/Border Router
respond to a DNS query=C2=A0for th= e original name? I think the BR will reject the query=C2=A0with some error = like RESOURCE_NOT_FOUND / NAME_NOT_FOUND, as the
service has already b= een renamed but just the client hasn't been=C2=A0notified=C2=A0yet. rig= ht?

On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon <mellon@fugue.com> wrote:
= I think that=E2=80=99s a good description of the solution, yes.
On Jan 22, 2021, at 1:02 AM, Kangping Dong = <wgtdkp@google.co= m> wrote:

To make sure if I correctly= understand how this=C2=A0works, let me explain=C2=A0how a SRP client will = handle=C2=A0name conflicts:
1. If a name has already been registered on= the SRP server or a name conflict error is returned by the Advertising Pro= xy:
=C2=A0 =C2=A0 the SRP server responds with the RR that includ= es the conflicted name. If the client sees such records, it knows the confl= icts
=C2=A0 =C2=A0on the SRP server and will retry with a new nam= e.
2. If a name conflict is reported to the SRP server after the = SRP update transaction has been committed:
=C2=A0 =C2=A0 The next= time the SRP client registers, the SRP server responds with=C2=A0a=C2=A0CN= AME record which includes the new name.
=C2=A0 =C2=A0 If the clie= nt sees such records, it knows the conflict on the multicast link and will = accept the name or retry=C2=A0with another name.

A= m I correct about the workflow?


On Fri, Jan 22, 2021 at= 12:11 AM Ted Lemon <mellon@fugue.com> wrote:
On Jan 21, 2021, at 12:27 AM, Kangping Dong <wgtdkp@google.com&g= t; wrote:
Option (1= ) also looks good to me. But what are the RRs that should be included in th= e response? SRV RR for service instance name and AAAA/A RR for host name?

Yes, I think that makes sense. These = unambiguously indicate what type of update failed. Which brings up the ques= tion of what RRtype to use for renaming. CNAME?

<= /blockquote>

--0000000000005943cb05b99f35e3-- From nobody Sun Jan 24 07:59:03 2021 Return-Path: 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 CC7743A0DE1 for ; Sun, 24 Jan 2021 07:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, 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 dqkjNQlWMilA for ; Sun, 24 Jan 2021 07:59:00 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 EEB563A0DDF for ; Sun, 24 Jan 2021 07:58:59 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id l23so5429604qtq.13 for ; Sun, 24 Jan 2021 07:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=nh1ACxDuMEGvn61F/mu9BecSOIY3jngE1XS4MMM8kxc=; b=JpxtJ0kIMrCQzFJUaCnaDP8X/m4phV3uik//2gQq/1/xymjXlLiVKAe/aY/k1N17r9 gJf3mVXpXZa2Ptk0XNVEWiaHsoSBK2veaYPd6kSb8sRsHnY+Kpn2719bPoy4kY0UpA6z ZJXXpt+6NEAKIwzkktfRuCdqwgM4GpXXCt6HdCMKLo3kz0Rxtg4q9X2EXwqLwOosxtiy KZZvgMuhBPTZwNWUj0Z4OPtepbtkjpV+PeyoQTpv6tl8BtrHRBGy6JDxa7d6N//JHVwu K293iP+hqBk+ppN9MDaNDP7z0kY4js+t7ZuvoKFofV7fj7FAaYehMF1PALQw/MnAKoQZ errw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=nh1ACxDuMEGvn61F/mu9BecSOIY3jngE1XS4MMM8kxc=; b=ZHgeXKmxYeFHZSjXeO+JkICfJIivBApa0XpKn+P55qUvIh7rjjphEku1MhyZPMOxVH Iy0FFqh+Qx5GJsOQFYKJVv0iGbakBwOYZ0pZyKWB/m2KoCGQHGe2sZd+utLksm8Mg9EM +Jsa9XQ5bfemLxKE4rSyQwn0Fh7eu3B/PeSiDMplBaqx9ufLhaE9+DuOYW0DD9QBYhJE 5hzaK4scGhOqh9VWfTks2gfWSzk2ueaYpGh0PZzcwemjnTRogeVvyfecee7XSdWaopPr O/WCOiyO93Xhh88nvlEp4lBlaEEusZpdwN3T6W8EA9jxPgwfIj/IZrsOwk4rbujQ0bfe jNAw== X-Gm-Message-State: AOAM531vddMf+63oF5HLdkOHGIWvqJH3YS7zNKVd3RNCb4PDBEndhWJ8 LESCkifVPnNwtAwran5DszAjHX38RPCZCA== X-Google-Smtp-Source: ABdhPJztFmsLY92kWKuhxLfFmyzTLCeL+X61uUIkHhjgSgETwyfFDaNiXi26HfdCObme+uRl3UHnNg== X-Received: by 2002:ac8:1699:: with SMTP id r25mr3869039qtj.302.1611503938756; Sun, 24 Jan 2021 07:58:58 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 193sm4465359qko.5.2021.01.24.07.58.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Jan 2021 07:58:58 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6B542A17-346F-4E68-9234-8094B198251C Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 24 Jan 2021 10:58:56 -0500 Message-Id: References: Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu , Rongli Sun , Simon Lin In-Reply-To: To: Kangping Dong X-Mailer: iPhone Mail (18E118) Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 15:59:02 -0000 --Apple-Mail-6B542A17-346F-4E68-9234-8094B198251C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If there is a name conflict, it=E2=80=99s because the name is in use. This w= ill never happen if the srp server is an authoritative name server: in this c= ase there is only one source of truth. It will only happen if the underlying service is an unauthenticated distribu= ted service like mDNS. So in this case we rely on the definition of that ser= vice to say what will be done. I believe this is discussed in rfc 6762 for m= DNS.=20 > On Jan 24, 2021, at 01:05, Kangping Dong wrote: >=20 > =EF=BB=BF > okay, the workflow almost works for me, just a small question. For case 2,= when the Advertising Proxy detects a name conflict on the multicast link, > it choses a new name and informs the SRP server the new name. Before the c= lient refreshes its service registration, how should the SRP server/Border R= outer > respond to a DNS query for the original name? I think the BR will reject t= he query with some error like RESOURCE_NOT_FOUND / NAME_NOT_FOUND, as the > service has already been renamed but just the client hasn't been notified y= et. right? >=20 >> On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon wrote: >> I think that=E2=80=99s a good description of the solution, yes. >>=20 >>> On Jan 22, 2021, at 1:02 AM, Kangping Dong wrote: >>>=20 >>> To make sure if I correctly understand how this works, let me explain ho= w a SRP client will handle name conflicts: >>> 1. If a name has already been registered on the SRP server or a name con= flict error is returned by the Advertising Proxy: >>> the SRP server responds with the RR that includes the conflicted nam= e. If the client sees such records, it knows the conflicts >>> on the SRP server and will retry with a new name. >>> 2. If a name conflict is reported to the SRP server after the SRP update= transaction has been committed: >>> The next time the SRP client registers, the SRP server responds with= a CNAME record which includes the new name. >>> If the client sees such records, it knows the conflict on the multic= ast link and will accept the name or retry with another name. >>>=20 >>> Am I correct about the workflow? >>>=20 >>>=20 >>> On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon wrote: >>>>> On Jan 21, 2021, at 12:27 AM, Kangping Dong wrote:= >>>>> Option (1) also looks good to me. But what are the RRs that should be i= ncluded in the response? SRV RR for service instance name and AAAA/A RR for h= ost name? >>>>=20 >>>> Yes, I think that makes sense. These unambiguously indicate what type o= f update failed. Which brings up the question of what RRtype to use for rena= ming. CNAME? >>>>=20 >>=20 --Apple-Mail-6B542A17-346F-4E68-9234-8094B198251C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If there is a name conflic= t, it=E2=80=99s because the name is in use. This will never happen if the sr= p server is an authoritative name server: in this case there is only one sou= rce of truth.

It will only h= appen if the underlying service is an unauthenticated distributed service li= ke mDNS. So in this case we rely on the definition of that service to say wh= at will be done. I believe this is discussed in rfc 6762 for mDNS. 

On Jan 24, 2021, at 01:05, K= angping Dong <wgtdkp@google.com> wrote:

=EF=BB=BF
okay, the w= orkflow almost works for me, just a small question. For case 2, when the Adv= ertising Proxy detects a name conflict on the multicast link,
it ch= oses a new name and informs the SRP server the new name. Before the client r= efreshes its service registration, how should the SRP server/Border Router
respond to a DNS query for the original name? I think the BR w= ill reject the query with some error like RESOURCE_NOT_FOUND / NAME_NOT_FOUND= , as the
service has already been renamed but just the client hasn= 't been notified yet. right?

On Fri, Jan 22, 2021 at 10:52 PM T= ed Lemon <mellon@fugue.com> wr= ote:
I think that=E2=80=99s a good description of the= solution, yes.

On Jan 22, 2021, a= t 1:02 AM, Kangping Dong <wgtdkp@google.com> wrote:

To m= ake sure if I correctly understand how this works, let me explain = how a SRP client will handle name conflicts:
1. If a name has alrea= dy been registered on the SRP server or a name conflict error is returned by= the Advertising Proxy:
    the SRP server responds with= the RR that includes the conflicted name. If the client sees such records, i= t knows the conflicts
   on the SRP server and will retr= y with a new name.
2. If a name conflict is reported to the SRP se= rver after the SRP update transaction has been committed:
  &= nbsp; The next time the SRP client registers, the SRP server responds with&n= bsp;a CNAME record which includes the new name.
   = If the client sees such records, it knows the conflict on the multicast lin= k and will accept the name or retry with another name.

Am I correct about the workflow?


On Fri, Jan 22,= 2021 at 12:11 AM Ted Lemon <mellon@fugue.com> wrote:
On Jan 21, 2021, at 12:27 AM, Kangping Dong <= wgtdkp@google.com= > wrote:
Option (1) a= lso looks good to me. But what are the RRs that should be included in the re= sponse? SRV RR for service instance name and AAAA/A RR for host name?
<= /div>

Yes, I think that makes sense. These unambi= guously indicate what type of update failed. Which brings up the question of= what RRtype to use for renaming. CNAME?


= --Apple-Mail-6B542A17-346F-4E68-9234-8094B198251C-- From nobody Mon Jan 25 19:23:03 2021 Return-Path: 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 09A9A3A1B3E for ; Mon, 25 Jan 2021 19:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.074 X-Spam-Level: X-Spam-Status: No, score=-14.074 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XkMuGHUY16k7 for ; Mon, 25 Jan 2021 19:22:59 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 6B59C3A1B3D for ; Mon, 25 Jan 2021 19:22:59 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id v200so1062040ybe.1 for ; Mon, 25 Jan 2021 19:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fERK1qKLhRdB7uamJ5OeMECJuNBttv/5ged9BejTI+o=; b=IhUwymofaXgU1BCIiOj28mA5SfWb6lq+zGdtioxHjyz7R/IDxNZCpJkvK01F5+diYO xC4yGPEwZ939voU0NVvXkKk2sJGj6k7s6wO8xmAMmT7Bwayyygoc8HlKvcUtVGbUGPZX paN5pT5XEcKJD1XNIX0fk9mDFGzCZntB5heBqklr7gmasQwGByZRtPJgVy+eGcejv4ZN psYN92ITOC109VN9HNAw5Ma4i5Un2oQCBWaV/VMOIJMt/bOLxKVKJ1PyS3MdvxJC1Ejx hgkKy3CgHwfA53ezJT5mWqQLpBV3+GEK6242jMY5HYd821/sZCFhmR+tm38VKrxt9RVl WCxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fERK1qKLhRdB7uamJ5OeMECJuNBttv/5ged9BejTI+o=; b=K3Db0ItsI22+Dja2nq5xuPP7kdo+wKD8RUt0giyydFRg5KUuXGW4ta6vWNzBBFkJl3 s/DuUZO7bbiaHl8+1fbCRujdeFxHHJD5khlhWWsvyOaqGr/ZCYjsa+FPY+FRXtCy2Wj7 8DAYF3CT5yuZA/9fSi8A1u/UCrR/7Y79Mssq+H8V4g3gMSe1bfl1sW88oewzLmpRn2HL dLmcE8068axSWluoyZe96RydYaKpom0L+PNiLY4yH4ETugWQ/Dvg6HaUntK/In5MWjzQ B67ZFDz0lv5giM30Zel96A9Kc3F46wrRI51OyqiT3tCLSCj/o5dcB0TZHG8iCRQpiNjp vGoA== X-Gm-Message-State: AOAM531EE4hgKUr3TaWREgbo9eHNpoux4fygzi/a5IGwrJ9QJ8P+4KUI GcNijrVYeZeibcmsok8gEH4b19pD4vJiQNZGihn+cA== X-Google-Smtp-Source: ABdhPJxkm+uNa60zTkr4F/8Glg7PkwhlZj8+HFRIWTrhlomw8/mHGeavrZOfJMjg4gMqT+SLKgARCdDcDzLOLwn2G2M= X-Received: by 2002:a05:6902:6b0:: with SMTP id j16mr5086076ybt.169.1611631378330; Mon, 25 Jan 2021 19:22:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kangping Dong Date: Tue, 26 Jan 2021 11:22:22 +0800 Message-ID: To: Ted Lemon Cc: DNSSD , Jonathan Hui , Abtin Keshavarzian , Yakun Xu , Rongli Sun , Simon Lin Content-Type: multipart/alternative; boundary="000000000000d0e77c05b9c52b1b" Archived-At: Subject: Re: [dnssd] SRP: Name Conflicts Handling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 03:23:01 -0000 --000000000000d0e77c05b9c52b1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Makes sense, Thanks! On Sun, Jan 24, 2021 at 11:58 PM Ted Lemon wrote: > If there is a name conflict, it=E2=80=99s because the name is in use. Thi= s will > never happen if the srp server is an authoritative name server: in this > case there is only one source of truth. > > It will only happen if the underlying service is an unauthenticated > distributed service like mDNS. So in this case we rely on the definition = of > that service to say what will be done. I believe this is discussed in rfc > 6762 for mDNS. > > On Jan 24, 2021, at 01:05, Kangping Dong wrote: > > =EF=BB=BF > okay, the workflow almost works for me, just a small question. For case 2= , > when the Advertising Proxy detects a name conflict on the multicast link, > it choses a new name and informs the SRP server the new name. Before the > client refreshes its service registration, how should the SRP server/Bord= er > Router > respond to a DNS query for the original name? I think the BR will reject > the query with some error like *RESOURCE_NOT_FOUND* / *NAME_NOT_FOUND*, > as the > service has already been renamed but just the client hasn't > been notified yet. right? > > On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon wrote: > >> I think that=E2=80=99s a good description of the solution, yes. >> >> On Jan 22, 2021, at 1:02 AM, Kangping Dong wrote: >> >> To make sure if I correctly understand how this works, let me explain ho= w >> a SRP client will handle name conflicts: >> 1. If a name has already been registered on the SRP server or a name >> conflict error is returned by the Advertising Proxy: >> the SRP server responds with the RR that includes the conflicted >> name. If the client sees such records, it knows the conflicts >> on the SRP server and will retry with a new name. >> 2. If a name conflict is reported to the SRP server after the SRP update >> transaction has been committed: >> The next time the SRP client registers, the SRP server responds >> with a CNAME record which includes the new name. >> If the client sees such records, it knows the conflict on the >> multicast link and will accept the name or retry with another name. >> >> Am I correct about the workflow? >> >> >> On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon wrote: >> >>> On Jan 21, 2021, at 12:27 AM, Kangping Dong wrote: >>> >>> Option (1) also looks good to me. But what are the RRs that should be >>> included in the response? SRV RR for service instance name and AAAA/A R= R >>> for host name? >>> >>> >>> Yes, I think that makes sense. These unambiguously indicate what type o= f >>> update failed. Which brings up the question of what RRtype to use for >>> renaming. CNAME? >>> >>> >> --000000000000d0e77c05b9c52b1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Makes=C2=A0sense, Thanks!

On Sun, Jan 24, 2021 at 11:58 PM = Ted Lemon <mellon@fugue.com> = wrote:
If there is a name conflict, it=E2=80=99s becaus= e the name is in use. This will never happen if the srp server is an author= itative name server: in this case there is only one source of truth.
<= div dir=3D"ltr">
It will only happen if the under= lying service is an unauthenticated distributed service like mDNS. So in th= is case we rely on the definition of that service to say what will be done.= I believe this is discussed in rfc 6762 for mDNS.=C2=A0

On Jan 24, 2021, at 01:05, Kangping Dong = <wgtdkp@google.co= m> wrote:

=EF=BB=BF
okay, the workflow almost works for me= , just a small question. For case 2, when the Advertising Proxy detects a n= ame conflict on the multicast=C2=A0link,
it choses a new name and infor= ms the SRP server the new name. Before the client refreshes its service reg= istration, how should the SRP server/Border Router
respond to a D= NS query=C2=A0for the original name? I think the BR will reject the query= =C2=A0with some error like RESOURCE_NOT_FOUN= D / NAME_NOT_FOUND, as the
service has already been renamed but just the client hasn't been=C2=A0= notified=C2=A0yet. right?

On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon &= lt;mellon@fugue.com> wrote:
I think that=E2=80=99s a good description of the solution, yes.
=

To make sure if I correc= tly understand how this=C2=A0works, let me explain=C2=A0how a SRP client wi= ll handle=C2=A0name conflicts:
1. If a name has already been registered= on the SRP server or a name conflict error is returned by the Advertising = Proxy:
=C2=A0 =C2=A0 the SRP server responds with the RR that inc= ludes the conflicted name. If the client sees such records, it knows the co= nflicts
=C2=A0 =C2=A0on the SRP server and will retry with a new = name.
2. If a name conflict is reported to the SRP server after t= he SRP update transaction has been committed:
=C2=A0 =C2=A0 The n= ext time the SRP client registers, the SRP server responds with=C2=A0a=C2= =A0CNAME record which includes the new name.
=C2=A0 =C2=A0 If the= client sees such records, it knows the conflict on the multicast link and = will accept the name or retry=C2=A0with another name.

<= div>Am I correct about the workflow?



--000000000000d0e77c05b9c52b1b--