IETF Logo Mail Archive

Re: [dnssd] SRP: how to remove all published services?

Ted Lemon <mellon@fugue.com> Fri, 15 September 2023 14:40 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899DC14CE5F for <dnssd@ietfa.amsl.com>; Fri, 15 Sep 2023 07:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPu-ZFIgU_vp for <dnssd@ietfa.amsl.com>; Fri, 15 Sep 2023 07:40:40 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37155C14F73F for <dnssd@ietf.org>; Fri, 15 Sep 2023 07:40:39 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-412989e3b7bso13747141cf.1 for <dnssd@ietf.org>; Fri, 15 Sep 2023 07:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1694788839; x=1695393639; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oRetVMQ4Qe8AyDkNAqDbQqH6aybZAh/mTrNA8LU5gso=; b=RKfsFbzC/HUgY/QK1Ai07HlPAEgHoqo1OxYq6gE1f0elbcmha9PsKbqsPfJfnBYneV aQPsW5h8NWrzKZSvsj8HErQzCbjxoO/izsyfAbqzYmYb5r+LPw0rP5s3Q6x1C6mqaIFF nnGCwYxBuAqFdmhszMyOtWcCpTrMXEe4coLs3/K0wJWZoBTlTD2caKqEWKyCC5AcTtGK Nt7ygFw4bKUz6leLPix/qP3/kN/5f/ENsWxzzHa2mg04hxQBSRK97OdLiMie6rPUn97t XYZXZAR5ipzgMnXQVc0OFqZu5Ig3ZdRYiZtGcMbquoeTUCwpRXygPu2NyDzWaZIjG26U CFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694788839; x=1695393639; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oRetVMQ4Qe8AyDkNAqDbQqH6aybZAh/mTrNA8LU5gso=; b=muZIEB8KpPqgPeEZk9C8UBUpo6tfSvJPt5GDKgNPDsFpYUWBa+Hozj6E0D5SOPwlg4 +/WZMgXrhj3Gpc0Cz5o2riv3RuqTksTPI1/fB4jTL+2jgrZH2wpxGi+JNHVb2qzDdn1u MnAE2EOrOyv+MeqB6sMmhT+IAalUCnptOzr9FGRvPucIYVSvcS4e/TyRs3N/3xTgJfth k5BoMdd5vXB/caGm2V8bJaiUtxtJgaNEPkCURfnALS22WDtYuElawONYQfvEgxci9Kw3 6VQFZBNdemtneS2syYQ7xzJ7k3/B2kJKUh2GO59b9J75VpvYGUmDg+kPisADOXnr7aCn nAiw==
X-Gm-Message-State: AOJu0YyfSRSLqTZRf/YT5KUzA7rIOrbEluiefPg3Spbp2XrWNGb0MOQp 9OFBuPpAKq2UOxEDR9Pso4hVCYyZPJeOU2x6Axc+V/D61reo9IZa1Jc=
X-Google-Smtp-Source: AGHT+IHSEeF3vyxsedPnWQp9P9so9pof61mJNipdxMxCZm4wZhmXE5F0Kibb2drZwxmUJTPePuqplZoTWmhNMle/ZDw=
X-Received: by 2002:a05:6214:5148:b0:656:2fa3:ecdd with SMTP id kh8-20020a056214514800b006562fa3ecddmr1964052qvb.57.1694788838745; Fri, 15 Sep 2023 07:40:38 -0700 (PDT)
MIME-Version: 1.0
References: <DU0P190MB1978B5A8AA3745770E94EEA5FDF6A@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAGwZUDtz86KtOvtxeACGSDP9dSCJdoKGWHQ_5imVwZYQDom4yQ@mail.gmail.com>
In-Reply-To: <CAGwZUDtz86KtOvtxeACGSDP9dSCJdoKGWHQ_5imVwZYQDom4yQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 15 Sep 2023 10:40:02 -0400
Message-ID: <CAPt1N1kjMmnVMkkE7hsbnzf-T79GKSrcL3_oC8X_Pm47_xvkbw@mail.gmail.com>
To: Jonathan Hui <jonhui=40google.com@dmarc.ietf.org>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>, "dnssd@ietf.org" <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3ff7e060566c618"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/27jzdWyS2k4mp5YeNVg4tBg1ZoQ>
Subject: Re: [dnssd] SRP: how to remove all published services?
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Sep 2023 14:40:42 -0000

Was the question more "what if the requestor sends a partial remove (host
plus not all services) with lease time zero?" I think the answer is that it
removes all the services, because the other services are pointing to the
host, and the host has to be removed; this means that any remaining
services pointing to that host are simply invalid. We could certainly add a
note clarifying this point, although it's a bit late in the process for
that.

On Fri, Sep 15, 2023 at 10:31 AM Jonathan Hui <jonhui=
40google.com@dmarc.ietf.org> wrote:

> Hi Esko,
>
> I believe this is addressed by the immediately following paragraphs in the
> same section? Specifically:
>
>    To support this, when removing services based on the lease time being
>    zero, an SRP registrar MUST remove all service instances pointing to
>    a host when a host is removed, even if the SRP requestor doesn't list
>    them explicitly.  If the key lease time is nonzero, the SRP registrar
>    MUST NOT delete the KEY records for these SRP requestors.
>
> So there is no need to list all the services that were previously
> registered.
>
> --
> Jonathan Hui
>
>
>
> On Fri, Sep 15, 2023 at 7:17 AM Esko Dijk <esko.dijk@iotconsultancy.nl>
> wrote:
>
>> A question - in 3.2.5.5.1., Removing all published services, we have:
>>
>>
>>
>>    To remove all the services registered to a particular host, the SRP
>> requestor retransmits its most recent update with an Update Lease option
>> that has a LEASE value of zero.
>>
>>
>>
>> I wonder how this exactly works in the following case. If I’ve registered
>> service A, and 10 minutes later registered service B in addition (without
>> mentioning A in the second SRP Update), then both services A and B are
>> actively registered.  Now I send the “most recent SRP Update” which has
>> only service B to the SRP registrar, with a LEASE value of zero.
>>
>> Wouldn’t it be that only service B is removed (lease set to 0) while
>> service A stays active?
>>
>>
>>
>> If so, we may need to clarify this text I think. Because it’s not always
>> the “most recent SRP Update” then.
>>
>> (If not so, I’m having trouble understanding how the LEASE value in the
>> SRP Update does apply to all currently registered services….)
>>
>>
>>
>> Esko
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>

v2.23.0 | Report a Bug | By Email