Re: [dnssd] Host instructions with no address… / Host Description Instruction without Service Description Instruction?

Esko Dijk <esko.dijk@iotconsultancy.nl> Fri, 19 August 2022 08:22 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
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 9A760C14F730 for <dnssd@ietfa.amsl.com>; Fri, 19 Aug 2022 01:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=iotconsultancy.nl
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 SUTtZW8NE7GS for <dnssd@ietfa.amsl.com>; Fri, 19 Aug 2022 01:22:08 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130131.outbound.protection.outlook.com [40.107.13.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6917CC1524C3 for <dnssd@ietf.org>; Fri, 19 Aug 2022 01:22:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ocfjccfhg89FO2YbBxIL9txwRVzYs38LMlTClHaYcXHS7Q9RQZ+RTS0gBsZ+i031y/YzVYgDJzoCPKoEhN7ETBUV856/xtVLcMwJlXLI0OvM9jB0+3Tv2P9yAcIBjZkgV9zWM4fHZPnCpUPC9SQwXuVrZL8w/2YRyYwbvZSPtuuBP/4kDD0Clx5pH/dz2nfnlXjRZLDUPKmlFZqOO3QOOcjN3DPXrRZ6HEd0gNsK9fijTpz1Wr4qyZ9SSB42VmL/iUick8zpO988cbh7TNRwheMtZKcZ027nrjkKZepBf2ZWyn0DtWsiNHA8zzlkB4hQi8EG0DyK3ds9v30HIGebAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zEII3ZcjibB/VYvX5bo6yYuBblvPBHtH8i93I5EHSo0=; b=Q4Gdl4U4ntpOWWXbQK4QY84gkxb2lL1sih4BLeIP+iY1TbpRPzrzkxSLP8N7nIdtUTQdSnO0iRglX6fGBxfiGPgA9TtK09e1mrntnzwaBpzkIduNPr4Iig1E4hDQjITuD/WrpYPDeWVtSapOzb7jO8LsckMiF8L9qJsaNcoXwSiqBYyRyMNR+DrGddhMAzWE5C5gFBcHLZgIEuCTrsEf/m/1eBZGwNXYISJqjsKVQ/HHVN8Ds2Nf7qfUmMPzq8a5QnY8x9e0uqTL6zT7BvQMuI6yUxi5rELsxHyb5rpN5HOhSfX4lumHMgvGL9pVqtvMs0wZU/l1MQEo/T00emsI0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zEII3ZcjibB/VYvX5bo6yYuBblvPBHtH8i93I5EHSo0=; b=QLoeQQLPmJlDM9QIyXS2rky8/HDjp3W1cM28Se3V74rawzD89U/owDrEzy25qLgWxxM2jsuoqouuv16LvLaXB2Az1ZrPR4lIZQJlx2TzfZu4ZHP/ztpy2Qh3iL5SSWXVOZr5+agtTPXF8MvYOuawj5fw0Ry7NX+I+flkwh4uoFM=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by DB6P190MB0150.EURP190.PROD.OUTLOOK.COM (2603:10a6:4:89::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.17; Fri, 19 Aug 2022 08:22:02 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::241f:347b:f324:f7a5]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::241f:347b:f324:f7a5%3]) with mapi id 15.20.5546.018; Fri, 19 Aug 2022 08:22:02 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Abtin Keshavarzian <abtink@google.com>, Ted Lemon <mellon@fugue.com>
CC: DNSSD <dnssd@ietf.org>
Thread-Topic: [dnssd] Host instructions with no address… / Host Description Instruction without Service Description Instruction?
Thread-Index: AQHYs6TCB3v3F37ES0Ssw8GHynx5gQ==
Date: Fri, 19 Aug 2022 08:22:02 +0000
Message-ID: <DU0P190MB197897F6B1643F95D24E20E7FD6C9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <CACce4dR1p_FiqTB-2MB08fq6EopU3DDxBWX5MBRQUtP4M8zc6w@mail.gmail.com> <85E5D771-AC8A-4D07-8465-D8DBC489A70D@fugue.com> <DU0P190MB19787758E77379260F121AE4FD6D9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1=62KKbyeUVd8oV3OpbanpZUwKQnZajfXJ10g6FO4e2QQ@mail.gmail.com> <DU0P190MB1978FC61C9109465B1D12E3EFD6D9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1nOkoJ-F169cQf9HxJ5Sey4im9Nd7LL-x3vhdj958UZMQ@mail.gmail.com> <CACce4dRx547ftJLfM2zZPpXMwC7xf0Ca5dwM+9smN+-HEV8jZw@mail.gmail.com>
In-Reply-To: <CACce4dRx547ftJLfM2zZPpXMwC7xf0Ca5dwM+9smN+-HEV8jZw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 90f1d86f-fdc5-4b0d-13f8-08da81bbe4af
x-ms-traffictypediagnostic: DB6P190MB0150:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: S7CRKpUPEmUfmjRK4xv9Pda0MLVjMP0L7Id/slHHe5+Gv95sbiOhZmtkkzUMI5xJ+qefT2QNQ6nbFPHmC8Ey/8il/T0447JINj/Do6aUq82AHGfRmVgDiNYKagsPyIeZtcPcOTy46/J3aeryL7SZrWpXOv1W7MUVUZRIFWGAtUlS2uTSdDVuq8HOnNjsX8fd3B6KhyfeUluO21lUlpI1ZW+KVVxvA3V5OzGqYsLoSa9CDUWoMLVfcyBZKUHOrtS5QV6O9y/YSq02v0+um2uZkvrP/zKb6SjKzAmgxM0v0iUTWJaeC7DRw3L6gCoT39Vr9WADatxW0kU2l8Hi2iVf7MH4tGuKUblBU3ZLx71HcS42/K9K7QkxZuBN0usEipSTCc74Y6o6Rl4eMaLQxJ1uprbfVHrcOlj2c5OEcAC+z8LtC9GGMwiiKYCrhfF7042xR/QpeJANsHLfpF5CPBE1TJwy2j9jIZ9gFLUlfAWdWiHnVFSfuW86FLfGPV+LbAtsWcq3+CmhXrn5JXg8gQ0TZQP7KFBfvvG0wO+yJCFN5Za53OeMkYnW3R/SyUFZTsz3F5nsT0ujuDXiltdQ/fGH827UFGCyihHgqFiWpN+pPGQzcujUfrwb3VN4Ufbs1B8MeuJzMa8dZyydhIjkJI3vOoa2lbYXDa4gwpf1y7Eq5QfyzFkda2xLpKZqol9L0KNlUFLzZr66e8ylruoKlqIGZSmgRO+WSX9aVOa5SKbj4/Eq3r1kehcVC6uHUfa7JV5SADracIH9Viww5/lGkvq9iZHyd0XPZCWk8Zfz0QeuszE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(136003)(366004)(346002)(376002)(396003)(39830400003)(9686003)(53546011)(2906002)(71200400001)(186003)(33656002)(478600001)(83380400001)(966005)(55016003)(7696005)(6506007)(41300700001)(86362001)(122000001)(316002)(38070700005)(166002)(38100700002)(76116006)(66446008)(8936002)(52536014)(110136005)(5660300002)(44832011)(30864003)(4326008)(64756008)(66476007)(66556008)(66946007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: dfauY14bqa2l2zgdsYomh07iDHVlXE9LtVR+iV+VJgwpcuwIn/E9w9RfsCGhH2O9zbX4hQD/fX7KPtP4ZGw89QNLVzP0JcM+ABxW2eDM2ZUoalba7B/owe2RcPyAuiX8EAuH1qGWN3mmcyp/jBtu6zMjvxS4yP1xn4tVQAvTZB/jSikIfRqHdkPWPcZkFB9bM+FrPvY8a2BcNYM8ymqyRcEiy5OTcqmW/9ybnL2qDRXMx9P0oxwu+wewAcef1R1AjHlB48zan5Se2lKFC8FkZ4C2rZy1jvDsEUotP5qTM4sBw68T1Lxk8NFbqXD5NnFs2Pr9gix+sxM3VVFe/1u/QaKJ+XelVEswzn2CRdU9Hw+Ic2yot7fVbGqXFGdinKjdWL40Jx8c+F4l06F//XZlmeeX14OKTOAelc11VeZg6iyILOVKRf2Rai/tDUGA7x+GzaTVn39TMaVFO7iYHGOQ7mKqJoAIR8bdn9WjcpvsSfbs/gu06cJyTpc3/Mxo0MkTkubYhriX/1fV86w94u3MHiE9iyLILqkaTvb9kCnUHaRPGQhM6QQnw+fOsdkStu8/KlKAuH9KCH0vMaIDC+A+zgplnMLmcOOmrkhUF6tuUs7MqVh9+rP0F5BfhD4RpD0d37LfwNnlRLor9tG5A05k+3Y9esULMtjhNo9r2Kq92+tTbf7Dwek8UqjHByu/EBMwoRgWYfDsLmCVIzhgMC6Ndcox6Bn1bqj2c9H4W4pnrThWJ6YYG/5kayoXpAFYW429Tz80ABRaXR7AP6QVYtZTsz5WUi/TRh1ws9WECNtm/eT0+l8gYYPKsd5QPG9okxwFyzh6yzAo4iSiKABJye82VRsyQTfOyvl499W3RXq4PJK0JMrD7dbgzK1fjQ2v3HqecExBpZF0riuLKIpTu7llO6njn64XLwgo75LzmC+YXH/Y0wcI+1cHyjJef5APpPzI7+SJ5dXaFAvkwK11ULdZ3aR4pQmBAvsjquPFiM/nNauibThbyD1R2p5CpFwivYK7Tojmeu28tRkABTDLpfq21DGfu08QtpMwKjeuCp0QAktYC0OerY18xxRfuyCY1mD35stJKvThEZNoOKMyzJE7UAKuTdA/WLR+0UbSlrwoM9QcUFGZ/Vt+nVEdyCUniT6dU2yc8zxz3SSmWgz6unrcE1IAkTTozAd7oqL/QQABkXm/9+WbK4AP+oodYaY4LftG8cbcK/UCWmO7EA7uCrC/VobUzIx3skIVsfzx1WXbeXI6PjgmT/JOHmv/tiKRG3c9QU8ugMwJzMy8Hz0tiTYG1aOCUVQrORafgeA4jC5H4NUotT7i5Iu8YyO1nlihIPutRMWHbaeJkb5PHa6R1C/FHaT57Rg4DqCBBqbh8QH/Ve713KQGUPtS/3xCxVwd+wur5kyiHZ6+ORsr6M3LXe5lcXhkg2WKK0CjdKeSIF7DnbUrIo15f8ptlZeccY+p8ZjRJC9guBimzwknrKydm939SKoTxIrbcHH1peMn5m8kjG1zvffJmwjvTiRKkQYQ4xBugd6G0jv0xzjnfibhqI5/iSYn3SHmoHgnqmWcwsKX4Lnouz3DIK1lE4zhsg9Ks5Ab7ZSgKdrzefjXo4FR/lLaKUtCYKbPOAdt8liK5Io51eVK5jh/v7dJsdhOW36+fm9JhgEva+zbIDNh6lPsqwzklA==
Content-Type: multipart/alternative; boundary="_000_DU0P190MB197897F6B1643F95D24E20E7FD6C9DU0P190MB1978EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 90f1d86f-fdc5-4b0d-13f8-08da81bbe4af
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2022 08:22:02.1268 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QoYXKqzt4BPSsJt/xSYktDNVITxj2Qg7VcdYqCfnDkz9ikeQJKXegVn9+eyj7rmGqAsIxyH2Fseyqnh4AZsdvmfMDOBYKKxD13u7eeW0U9A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0150
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/CTzijRcC4PRmUWoB--7rFgoLOPs>
Subject: Re: [dnssd] Host instructions with no address… / Host Description Instruction without Service Description Instruction?
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, 19 Aug 2022 08:22:13 -0000

Agree with Abtin here, we can keep the requirement on >=1 A/AAAA records in the Host Description Instruction.
Implementations can be kept as is.

The other discussion that I referenced in this thread is separate from the above topic (see also my WGLC review of yesterday).

That’s the issue that 2.2.5.5.1. says you can send *only* a Host Description Instruction and that is valid. This statement contracts 2.3.1.3. which says you cannot have a Host Description Instruction without the Service Description Instruction.
I’m okay here to keep whatever behavior the server implementations are currently doing and not change that, only I don’t know which behavior that is of the two options … depending on what it is, either 2.2.5.5.1 or 2.3.1.3 text needs to be updated.
@Abtin maybe you can indicate what the OpenThread implementation allows here?

Regards
Esko

From: Abtin Keshavarzian <abtink@google.com>
Sent: Thursday, August 18, 2022 21:27
To: Ted Lemon <mellon@fugue.com>
Cc: Esko Dijk <esko.dijk@iotconsultancy.nl>; DNSSD <dnssd@ietf.org>
Subject: Re: [dnssd] Host instructions with no address…


Thanks guys!

On num of A/AAA RRs:

- I think requiring one or more addresses when adding a host sounds good.
- When removing a host it may be redundant to include any addresses (but harmless).
- The text can be relaxed to "if lease is zero, allow zero or more, otherwise require one of more A/AAA RRs"
- I checked, OpenThread implementation related to this:
  - The client will include addresses during host removal
  - But server implementation allows zero address (only) when lease is zero.
- But as Ted mentioned we can use "dummy address hack" in all cases.

I think either way is fine. I slightly lean towards keeping it as is (require one or more A/AAA in all cases to keep it simple).

-------

On Host Description:

I think it is valid to have an SRP update message with only Host Description.

It is useful when updating (adding/removing) host addresses (without changing previously registered services).

In 2.3.2 the requirement is:
- Zero or more Service Discovery Instructions
- For every Service Discovery we should have a corresponding Service Description (and vice versa).
- And exactly one Host Description

I think may be the 5th bullet in 2.3.1.3 describing "Host Description" is adding complication (different interpretations)

"
   there is a Service Instance Name Instruction in the SRP Update for
   which the SRV RR that is added points to the hostname being
   updated by this update
"

I think the requirement is more clearly stated in 2.3.2:

"
   There MUST be exactly one Host Description Instruction. Every Service Description
   Instruction must have that Host Description Instruction as the target of its SRV
   record.
"

We have a similar statement in 2.3.1.2 (6th bullet about SRV RR in "Service Description Ins.").

So it may be ok to remove the 5th bullet in 2.3.1.3 to avoid confusion.

Thoughts?

----

On mechanism in 2.2.5.5.1:

I think it is valid and useful to have a "Host Description Ins" only with lease zero to remove host and all previously registered services.

- After a device reset/crash it may not know its past state and services it registered.
- And it can remove the host to start with a clean slate (I think matter code examples may already use this).

Thanks,
Abtin.


On Thu, Aug 18, 2022 at 10:35 AM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
I'm a bit concerned that making this change now would be fairly destabilizing. It might be better to write an update to the SRP draft, rather than address this here. That way we can write some code to test it out without delaying the WGLC. I don't want to just keep doing WGLCs forever.  The downside to this is that a server conforming to the current draft but not the update would reject an update of this type, but in this case the client is no worse off than it would have been if we just didn't do this at all, and in practice SRP servers are easy to update, so I'm not too worried about it.

On Thu, Aug 18, 2022 at 9:37 AM Esko Dijk <esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>> wrote:
If the question is “do we need Method 2 of 2.2.5.5.1?” then I would say yes – the code would be simpler when supporting this method than the code needed for not supporting this method.

If we the question is “do we need Method 2 to work also without including any Service Description Instruction?” then I don’t have a strong opinion. If we say “No” then: A requestor that forgot (for some reason) all of its prior registered services and now wants to deregister these can just include these both

  *   Host Description Instruction – lease-time = 0
  *   Service Description Instruction – (by definition also has lease-time = 0)

     *   Has 1 "Delete all RRsets from a name" instruction to delete a service with some arbitrary name in it (which may exist, or may not exist)
That’s easy enough to do.

If we say “No” then also Method 2 in section 2.2.5.5.1 needs to be clarified more (see also my WGLC review).
If we say “Yes” then 2.3.1.3. last bullet needs to be made optional i.e. removed but this may have implications for implementations that I can’t oversee.

Regards
Esko


From: Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>>
Sent: Thursday, August 18, 2022 15:13
To: Esko Dijk <esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>>
Cc: Abtin Keshavarzian <abtink@google.com<mailto:abtink@google.com>>; DNSSD <dnssd@ietf.org<mailto:dnssd@ietf.org>>
Subject: Re: [dnssd] Host instructions with no address…

That's probably the right approach. Thanks for thinking it through. The next question is, do we care enough about this to require this complexity? I'm not sure what my code would do if it got an update with a delete for an IP address and a valid KEY. Actually the dummy IP address hack would work for adding a host with no addresses as well. Anyway, the question is, do we need this? I don't actually know of a situation where I'd be tempted to use it—it just occurred to me that it was a gap.

On Thu, Aug 18, 2022 at 4:59 AM Esko Dijk <esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>> wrote:
Hi,

Tend to agree with Ted’s proposal – but details are not fully clear yet to me. So this would mean


  1.  When registering a host and service(s), the Host Description Instruction requires >=1 address records (as currently defined in the draft)
  2.  When deregistering a host and all its services due to the IP address becoming invalid, the client needs to use one of the methods of 2.2.5.5.1.  Removing all published services. I assume it wants to keep the key-lease on its name.

     *   Method 1: repeat the previous SRP Update with Lease time=0 – is the SRP client allowed to do this with the (now) invalid IP address? Presumably yes because the lease-time=0 is meant to remove that registration.
If an IP address would not be present at all, it would not be a valid Host Description Instruction. What if the client didn’t preserve its ‘old’ invalid IP address – can it use a dummy one in this case?
     *   Method 2: only delete the host record, SRP Registrar will automatically delete all associated service instances. So this is a Host Description Instruction only with lease-time=0.
However, per 2.3.1.3 a valid Host Description Instruction requires a “Service Instance Name Instruction” to be present and it’s not clear to me what is intended here. Probably “Service Description Instruction” is meant.
So it should be a Service Description Instruction to only delete (not add) records for some random name of the client’s choosing?  Since for Method 2 here the assumption is that the client didn’t maintain state of its registered services.

For method 2, it appears to me that a Service Description Instruction would not actually be needed – it’s just a “dummy delete” operation (effectively NOP) to satisfy the criteria for a valid Host Description Instruction which cannot exist on its own in an SRP Update.

Regards
Esko

From: dnssd <dnssd-bounces@ietf.org<mailto:dnssd-bounces@ietf.org>> On Behalf Of Ted Lemon
Sent: Friday, August 5, 2022 21:22
To: Abtin Keshavarzian <abtink@google.com<mailto:abtink@google.com>>
Cc: DNSSD <dnssd@ietf.org<mailto:dnssd@ietf.org>>
Subject: Re: [dnssd] Host instructions with no address…

Yeah, I’m sure we could make zero addresses work, but it would be fairly complicated, and I don’t think it adds value.
Sent from my iPad

On Aug 5, 2022, at 3:18 PM, Abtin Keshavarzian <abtink@google.com<mailto:abtink@google.com>> wrote:

Hi Ted,

> I think it would still probably be worthwhile to change the language about non-global addresses as I’ve suggested, though.

I agree. This sounds good to me.

> Actually, there’s a huge problem with this: if there are no A or AAAA records, there’s no way to tell that a host instruction is a host instruction, since all it contains is a key record. We’d have to pattern match on the name, which seems fraught.

I think there may be a way to figure this out without using a pattern match on the name (which I agree does not sound good).

A host description must include exactly one "Delete all RRsets from a name".
We can also have "Delete all RRsets from a name" for Service Description Instructions. But Service Description Instructions must have a corresponding Service Discovery Instruction (a PTR record) with the same service instance name. So we can use this to tell them arpat.

> So, apologies for raising this so late in the game, but what I’m proposing is to change the first bit of text to:
>>  zero or more "Add to an RRset" RRs of type A and/or AAAA

I can see the benefits in both cases (allowing zero or requiring at least one).  I slightly lean towards requiring one address.
I think practically we can always have an address on host (we can use link-local or in thread use-case mesh-local if there are no other addresses).

Abtin.

On Fri, Aug 5, 2022 at 10:09 AM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
> On Aug 5, 2022, at 9:47 AM, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
>
> One issue I just noticed that maybe we should take care of in last call is that currently the document says:
>
>> An instruction is a Host Description Instruction if, for the appropriate hostname, it contains […] one or more "Add to an RRset" RRs of type A and/or AAAA, […

Actually, there’s a huge problem with this: if there are no A or AAAA records, there’s no way to tell that a host instruction is a host instruction, since all it contains is a key record. We’d have to pattern match on the name, which seems fraught.

Since we already have a way to delete the host addresses and all its services but leave the KEY record, perhaps that’s the right approach to this. Effectively this would mean that it’s not valid to add a host and services without providing any address records, which seems to make sense.

I think it would still probably be worthwhile to change the language about non-global addresses as I’ve suggested, though.

_______________________________________________
dnssd mailing list
dnssd@ietf.org<mailto:dnssd@ietf.org>
https://www.ietf.org/mailman/listinfo/dnssd