Re: [dnssd] SRP: support of SRP message with zero service?

Kangping Dong <wgtdkp@google.com> Wed, 07 December 2022 11:48 UTC

Return-Path: <wgtdkp@google.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 94408C1526F8 for <dnssd@ietfa.amsl.com>; Wed, 7 Dec 2022 03:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.601
X-Spam-Level:
X-Spam-Status: No, score=-15.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.999, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiLzr_zCwO3T for <dnssd@ietfa.amsl.com>; Wed, 7 Dec 2022 03:48:34 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 32E6CC1526F1 for <dnssd@ietf.org>; Wed, 7 Dec 2022 03:48:34 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id h17so7725472ila.6 for <dnssd@ietf.org>; Wed, 07 Dec 2022 03:48:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UaNq3IOkv7axAesvxvvwE7U/lh+WeDtulfNFcnYNH2o=; b=OFxnPn7oyU7W5R9LxnROrq5R263NUCdDQW1/Rqv+sIPGH9J5rI+xcW6/HjyBh0jrWo MfNfqSKAgnFXnO6uCEWlWfm/qIN7yM7R+YogMCHFYf+UGTtufSTVBW2YXh8WepDq4KK9 GB2Xmz9CEhpmNm5v4BThN9CimnoA3k1NThjTSD1G4Hy/LjvJYaWnjKz+v7TQpXMOMN0A Uizou47XyvppdgyUcuHVvA7IRtzRfjSyo9ishKNVsv5aOyoMHk7efUQBv6hQbhmrNl0z Zz9M8gWE7raLCgzMzC0Y+DvWwJia4T6jgSb5i1kdvBy4xfAfTh6ajm44tyY7am9Hn7CL HElA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=UaNq3IOkv7axAesvxvvwE7U/lh+WeDtulfNFcnYNH2o=; b=P1dca7atLYqFHW86cKcjdmDIw+IUv8idQz83qG6fQmWiGv7uDuR3sf+dGHA1SZ2Oa/ WCk+lfF9SKavVuQPH+fxge8KNoqY/Au4i51xz9fhsKkU+FeFNvQF94TllWoufwzeysqZ /DdnTt+z0oJAFp/xr0sTrmbkkmbw/PaMWCB+qv/4/rvy8o41yA+6lhkd5cA2wGFMyTYL NJDVlysabHv0awqT3bOo4HaNfTLediBgeaNYMW5WHasuUL1DUjpjbEr9EBkW02IISMuu ba+51bvcAXzsjBl1O7TRykSigRugsdXjUmb6XpJwEfOcre1w+PU60OJA8EDGqG1Z0UP0 wM2g==
X-Gm-Message-State: ANoB5pkPJe2DOPIjsklDadCaeqQFKGd8i+vCkeiyYPIt7qYn7XWULsJO lMJB2uvJth3+ZgJpXl6jk9Xn2OrtaIZIwI2fU9dDOg==
X-Google-Smtp-Source: AA0mqf68ufScR7E+Ri/Q3eUAVlG+n5vYDmZlLij4650e52UXirOxQoLTVSBvrxH2jsBCCIJQPuI2mu88p/Gduu61bsk=
X-Received: by 2002:a92:ccca:0:b0:2ff:e796:926 with SMTP id u10-20020a92ccca000000b002ffe7960926mr33123852ilq.216.1670413713265; Wed, 07 Dec 2022 03:48:33 -0800 (PST)
MIME-Version: 1.0
References: <CAJ5Rr7ZTujqf3_CR-PY1Kdj1KTFAKQKcPbmZORXOxW+8TMquVw@mail.gmail.com> <CAPt1N1=aPfTpSdVbWTSBVi27SAr_uGwhuG03z6MNGRBdzZyqkg@mail.gmail.com> <DU0P190MB1978503FBF2F9F3853AFC3E6FD1A9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978503FBF2F9F3853AFC3E6FD1A9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Kangping Dong <wgtdkp@google.com>
Date: Wed, 07 Dec 2022 19:47:56 +0800
Message-ID: <CAJ5Rr7azeWtW0ujL6GBQ9QwWbX3Zi5Noroc4fLvcRAC9n5iOsg@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Ted Lemon <mellon@fugue.com>, Abtin Keshavarzian <abtink@google.com>, DNSSD <dnssd@ietf.org>, Jonathan Hui <jonhui@google.com>
Content-Type: multipart/alternative; boundary="000000000000024b0305ef3b80e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/hNZwWLGuTchZvElEC2VjXmqjzcI>
Subject: Re: [dnssd] SRP: support of SRP message with zero service?
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2022 11:48:35 -0000

> Why is it useful to have a hostname and address generally?  :)

If the client knows only the hostname and address, it doesn't know what
protocol should be used to communicate with the device, so it doesn't seem
to be useful to
know only the address. One use case in my mind is that a device may
register a well-known hostname, but didn't find a real case in local
constraint networks...

> I recall that we discussed that a device could temporarily not have a
particular service; and some expectation that in due time a service will
become available again.
> During this time the device wants to keep its name registered, to show
that it is still there and functional, and defend its name against
potential other devices taking that name.

*> *So one use case is deleting its service(s) but keeping the name
registered.


Will this encourage devices to always register their hostname even when
they don't provide any service? Do we have a link to that discussion? @Esko
Dijk <esko.dijk@iotconsultancy.nl>


BRs,

Kangping




On Wed, Dec 7, 2022 at 7:32 PM Esko Dijk <esko.dijk@iotconsultancy.nl>
wrote:

> I recall that we discussed that a device could temporarily not have a
> particular service; and some expectation that in due time a service will
> become available again.
>
> During this time the device wants to keep its name registered, to show
> that it is still there and functional, and defend its name against
> potential other devices taking that name.
>
>
>
> So one use case is deleting its service(s) but keeping the name registered.
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Ted Lemon <mellon@fugue.com>
> *Sent:* Wednesday, December 7, 2022 12:15
> *To:* Kangping Dong <wgtdkp@google.com>
> *Cc:* Abtin Keshavarzian <abtink@google.com>; DNSSD <dnssd@ietf.org>;
> Esko Dijk <esko.dijk@iotconsultancy.nl>; Jonathan Hui <jonhui@google.com>
> *Subject:* Re: SRP: support of SRP message with zero service?
>
>
>
> Why is it useful to have a hostname and address generally?  :)
>
>
>
> Op wo 7 dec. 2022 om 06:09 schreef Kangping Dong <wgtdkp@google.com>
>
> Hi,
>
>
>
> Regarding SRP registration, it's unclear if at least one "Service
> Description Instruction" is required in a SRP message when the host is not
> being deleted.
>
> If it's not required to register at least one service, what's the use case
> of registering only the host/address? Any examples? (It doesn't seem to be
> useful
>
> to advertise only the host name and addresses with the Advertising Proxy :)
>
>
>
> Thanks!
>
>
>
>
>
>
>
> BRs,
>
> Kangping
>
>