Re: [dnssd] Progressing with multi-qtypes

Esko Dijk <esko.dijk@iotconsultancy.nl> Mon, 29 April 2024 20:40 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 6B33AC180B4F for <dnssd@ietfa.amsl.com>; Mon, 29 Apr 2024 13:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 p9yaKuNetcxL for <dnssd@ietfa.amsl.com>; Mon, 29 Apr 2024 13:40:29 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2117.outbound.protection.outlook.com [40.107.21.117]) (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 6FE58C1840E7 for <dnssd@ietf.org>; Mon, 29 Apr 2024 13:40:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mIlsZ0Dsxfhkc8SW4KhPzG3hPXRHyEvGAt4O8Z39HOZMKaffDn0NYfGRjI9iPNJ+20x27Qvla5ilWg7AZ+i69Iwfj+9g7e94bFmHw8gJqHiOGSwNDWelePMrMQLsAvgQY8s1n3zQVyyIoLFOcrWH7K8H43NvpncbHzEsD7ze1FY3NSnFUdPCxFIcRvJRO0/4hqBr+R/Ju7BZU2tli0cdHwAodGo/uq1QOp2dLBUJy/P9SMl5pwXaIIqwKjjLgBH4GMeCXVW7IxGubUUn/r6MDy9m3U4lhpNgkTvyjvR5jSZxOryPg3t0P1K9UugYTJhMeUxdoPdhzqzIsDfjgE6IMA==
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=3xD/z57D12e5P+yy3zqJpEPY5HzDAmDs1k0ybb3o8Ik=; b=ZXEoyuGB1c71Qiuj344f+T+vMY5F+TyymRgEJ5n/0QPygUjTcX7Gv7Q+0e4XIhhUuP961dmINeAiqC1Kc946Z1lwOYlFMgp6Kedgebnl6QiPG+txwUV3/tzw602sfm+ovuNw378/UlRVuEgcWww34W9hvaYk/6vSAmWIJe1qJnZflm804hdT+VWyVvUnP4ZBTCv387pFo6rgA1GXXnXzqaNmeMXzuj3UZhH/M4fUVUVFDeMKRWufGLzm16rKzN/QS+wA4i0HBPpIx/LxtWQLEmGthIcGM53wedm4fp2OUihn6InjFdpXGAAfHx7OwUBDYeCju9BG7+73BE653zBYaw==
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=3xD/z57D12e5P+yy3zqJpEPY5HzDAmDs1k0ybb3o8Ik=; b=kRhyR8DZ643kKMPeaWx6NN0+nLDHK3U+qZOq4mvfb+O/JPYjKohGlK/izOT6oSZISRjbYLqscDeLU7jJ+aL1AmGH9TPHQNo9ByArE7gy5pgOHf8ygsAbq+xUugV8d/hCumABonHEVmB+Z7CU2T2WR+a327RtkYVSP8g4rl7kr48=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by AS8P190MB2006.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:528::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7519.35; Mon, 29 Apr 2024 20:40:25 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1f4d:554c:ad1:5fb7]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1f4d:554c:ad1:5fb7%6]) with mapi id 15.20.7519.031; Mon, 29 Apr 2024 20:40:25 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: David Schinazi <dschinazi.ietf@gmail.com>, Ted Lemon <mellon@fugue.com>, Ray Bellis <ray@bellis.me.uk>
CC: dnssd <dnssd@ietf.org>
Thread-Topic: [dnssd] Progressing with multi-qtypes
Thread-Index: AQHamh5+bgpPWuRkVkemHfHU3WY9N7F/O+MAgAA80oCAADnwgA==
Date: Mon, 29 Apr 2024 20:40:24 +0000
Message-ID: <DU0P190MB197899449A62158B2816C0BFFD1B2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <39876154-aea3-44ca-9250-6ab0d78e1ec1@bellis.me.uk> <CAPt1N1mcEqz5W2c8DgA+JQ-gk6=fGfHfHRvHQKShBC0VG1LiAg@mail.gmail.com> <CAPDSy+6E33e2E3G3A4y9QFNAaLH--Wg3r0b1X2U2NSczmWT6eg@mail.gmail.com>
In-Reply-To: <CAPDSy+6E33e2E3G3A4y9QFNAaLH--Wg3r0b1X2U2NSczmWT6eg@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-traffictypediagnostic: DU0P190MB1978:EE_|AS8P190MB2006:EE_
x-ms-office365-filtering-correlation-id: 5432a070-9b12-4b46-1af8-08dc688c98ee
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0; ARA:13230031|1800799015|376005|366007|38070700009;
x-microsoft-antispam-message-info: tvLaDT7fj/hkXXDSbWxqMRBSCAPt4hyQH8Xy+8HbEGTOuPBOTbAoefhTWYXrvNedwU7CD+Q2e/8o0Hxg+gpPTvDMmpX1pF4l2ImIDtduYtXbnWizIZy+G1ZACN8XEn9lnrM6dFcIUig4dADhIek9K5UJJfYAY06ohxN8eXTpOr7F5sSp8tYf7GRY6TCLMuyLI24GLlcwQEZu9M87HxzgAyauL0iMcM32oH5yv751tO4Qn/z6+kt3Gq9p9dCu1LNds7ReJojS8rdjMrnhI0lDqPrcDGfgg21hcgAI/bNyVjtj61xYzprJUy9mtbp1G0olw3vMZyezQBMaOUiUIngW+usKcVhKlKJCF/L0GIx+MFtttdHFupevVlFHqUXKI9TD1ncb5B2+GamAecGHLRM0IZY3kuEL948R6nkqG0lBwMTkAietofHIBZ7mbKFLd34ZJM06jsFv3pXyE6MPxv3HH3CQ6fTOL0bFw0ZF05l+XlalDKLIX81z11XH9PCYVgciL5WSCIzOVdO98fPLA704KBe9C4S8CRWIi44fA9d3Gi4yK1V74/W7G7B0DIZy4xetZ+ic/JgijgtkL4piZLi10nb3auyu2uDgXQfp4LnPP8yMSY41taBRyY01fUdtrVsBuWNEdilBxxkriooVz9vfFevL8L2i06UN/VFX0ArJp/fpTOL6xE16EvRHAX33uChpemBXyVlj/5HEYcM+G9VMa9vCh5teS9tIbYyS2pqF1q8t/MQkiNE7xZdzGIWIIXXJkNR8tplQ8Zf5MGHyGKh1Z3ua2CEx5NSg82AITS5SFNs+YhoT31yRt9vZ3NE0mqFrPW6fbDC+wbjn45UeQ/eq3opwHKyQSe9Ilg88Uc8mic+EskZC7MalMyFPrmbUwK7LIYxBuPsHL0mZDeuYlJzH3ivSlv+61fHTKcZ8zxw1eom6ihE3UrTYBI+EAT2qDfRwjg4VEEXYp//F0OrJI/RDvQeuZmlsr3mz5SXSy1OS8TdHbENlAe2xS+jm+ml3uAT/5skm2KZ3rsZ+n6hwvJe/9l9sE+50VGDTMJzU30N1ydd0bAPrPAxgYp1Hhr4OSktHSmQwedqRRxUztYoJR+G4aOqxjkkJxqKkGagMW3wPf8exM3y5wdhyNx2WyNvl3yQplnGuxZwaWYnWU9rO1NFtlxGHCDW7uNWlkXeh55IXnLZacvna5ot8gKTaDER2PmQSn59oNEm9aDB8vDcF3BTYR1OSKIzmtVGjrTD3nqAEiWf8lxHd2zORYx0DEz1RLl3OPIy50hE5BEPt2T1zRMOqXIJmfXw0C+EV5raNMOOLC+0knzQvskbMwba38iNkZXdpjNeggiarNx5EvjLfWZFCCw==
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:(13230031)(1800799015)(376005)(366007)(38070700009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: yRNBUiQno+m0554csvv32ZbKMJJceI6N6N1MMMMs/yuaykImO2rXihE9VaE2G6VRhUN3+zp+WKku2ISpGyS6lJri63Wc2SI53T3+lJh0SUmD15mjAydnhFVx7HuTWgnte8Ur7dg+89qz2rD04f3A3zx9eVw/0EnB9Vx8YZub6f2DhNRNoBjR+19yotffFYEOTUkfzEGMAil2Y4k3CvTw3VESKrp43X2FRGf7fscKnQWNUWKWgcnLyhDDy1ylT1SWlHHzsBu34wx2WG1Gb53AkhKFwZ0cwtvaVpSAnhLV2M88r0kYLYE28IqgMmIycshVOTpLyjCC75XRb86iSv51ZQd8xC/pCrEKvOBP4DRcA1s7byCgVtRHFyUrlxT6xy5FBP1nVR7DLC6vWsasUd6M4r2gsA9Atg3TuLVUqjoFfuka7L0pd+XcqqhxdH5/GNWZuDY6tgGxUcAHr4YbyOOTlPUIsEmVcn5UEQCFeaYHRBkCu/SBZ1OSKruGCmS4kayq5m1+6NITce9NoLt8vVbRXixHbvT7KxoH71+pjguXAtYlzgO6gFe21wB/OiwWv71HlIJo6xDkTi0kG2YaSYFLnJ7nI+2ooSiADvkkbI7JiZc6RblgyZ5HPkuX+58g8Omfi6bqjfCFpbvul72MNnejEjLb5TRJwFRqNdQcwLFsArAM2Z1bMWreRBIbQ6KR4gvj9c4r/hwxrbFpTf9KEyVwL3MyZ7pysGl1Bk/hRCkXrdmDnDtBYqJ/BgKvaIV+HdsLsc+9HdZzvVgOKH1G2jqgj/8M/zsVbpfPvC9BaEK6nplGvcsWiWWv4cb8+AzWl/BocvpP4NsvJ9XG9OqbrbwPGITb25o2FzswdzHSDjGQJOjYfItIpydtUfnHO6iXjIEAPYpGQAhtKiij/lJHauvlavyO8B+nOr/+i79o5EgBcqIkaEleY9RE19W6hplEMMm4BqjR4RmCFU62sDqDbg2ZPLrvxiVBI51xHllrmgc3JHhBBNjy12fAq2q67majFBV+2drs+yYfhIBwnFMd+FWPu7VVmoaoC4jVja5i5CR0828OYgyBS9B8T6Z5PUYzRbKMoBFWqihiXpLMZnYFfncOYilMYpBKkKrLF0bhlVqLCAtrpwdXzeAMTAnohBM6xiqTFDqvks8RzW2+BJW32TtkqngUGSs2C+x5O8ZyQwjeFeVG5VOL9P0pa1iiRtqLPVmKN42DtosKC4QTyVGTS706hDVP2U892pFN/eGPJx9xhN6fTbX20IjCxFN67yHfklKkgJDjnaKK7d6fMbtUt7rdVqhK3fnhlmEgS7Uwk9g6CUrR7WwVQ16RLKnbgxmJrUgS0z0RWdGLnWHEOd3Vfrxr9oKWDjhED7qHupiwN2Bk7cWfI4/nwAZBEQO7iwuIs+GF/4NDTtvk1Ey/aS+ZUo1oriDzLkWROgOI3A0nFfwN3duY+wPpfbvZZVgpkC7cu2HLY83hCei4R2Y4lUHd7yoTvDX6tFt8gUygSxbRal+lwRm8EiFuXspWp5+rMvtz6I0GD5Wgt2w6B32p8XhoXyeb4DYiEGW8fTiqf0a5hauRoWmKcg2xpp/mriK/FC3nPBUjHXdHqHXpWjJD607ImpZm8BLhgmhAqv7LPUV8b6ODlhYkFUEkSp4JYxMVvXCyJpGznpgrcnGiDR6JCoNh8QqahA==
Content-Type: multipart/alternative; boundary="_000_DU0P190MB197899449A62158B2816C0BFFD1B2DU0P190MB1978EURP_"
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: 5432a070-9b12-4b46-1af8-08dc688c98ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2024 20:40:25.0017 (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: 5h5xkJBzOcqjrckfGO/G9vTeozInHt5wRa6QtjJLMzgsY/+J6QQfADuhnoFFhh5q0rFHLlAud9DHiPM6FCapx+fX79A3cT7x9Jd7TTxJZSI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB2006
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/mZNvcmStTXM9Tk-Mjdwmaw-hC2c>
Subject: Re: [dnssd] Progressing with multi-qtypes
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: Mon, 29 Apr 2024 20:40:34 -0000

Agree with the proposed changes.

About David’s comment:

> the server is allowed to only handle some of them if it is resource constrained

I see the point. But the present draft also has the requirement “MUST attempt to return all specified RR types except where that would result in truncation”. This seems more strict than the “SHOULD” requirement that is quoted.
If the intention is that a “MUST attempt” is at equal level to a “SHOULD”, then it’s compatible, but it’s too fuzzy for my taste. So: can be clarified in whatever way we intended this to be.

Considering the situation of a resource constrained server that only has a few RR types for a given (query) name – there may be no need for this server to ignore any of the QTYPES in the request.
Suppose that for example the client asks for 300 QTYPES, really a lot, but the server stores only 4 RR types for the name. In that case the server can just keep iterating over the 300 QTYPES in the request and only add the 4 records that it recognizes by type. Its response Multi-QTYPE option would be small, and no resources are spent on the server side apart from storing the request packet which I assume it can do anyway (otherwise it wouldn’t have received the packet in the first place.)
So the only resource spent here by the server is some iteration and comparison time in memory, which should be really fast on any platform nowadays. No extra memory allocation is needed.

If the server is resource constrained and also stores many different RR types per name, then it’s another story, but in this case it would be rather unlikely to have this hosted on a resource constrained server I think.  But even so, such a server could still perform the truncation as already described in the current -00 draft. (when it’s not able to complete the “SHOULD” or “MUST attempt” part discussed above.)

So what I’m trying to say with many words is that if we remove QTCOUNT, no special provisions for a “resource constrained server” are needed in addition to what we already have in -00 – only some clarification or language harmonization of this SHOULD-behavior is needed.

Esko

From: dnssd <dnssd-bounces@ietf.org> On Behalf Of David Schinazi
Sent: Monday, April 29, 2024 18:59
To: Ted Lemon <mellon@fugue.com>
Cc: Ray Bellis <ray@bellis.me.uk>; dnssd <dnssd@ietf.org>
Subject: Re: [dnssd] Progressing with multi-qtypes

[ Speaking as individual contributor ]

+1 to removing the QTD bit in favor of two option codes

+1 to removing the type number limit entirely. Since the server handling of these is a SHOULD, the server is allowed to only handle some of them if it is resource constrained. We already have the server send the list of types it handled in the response option, so we could just say that the server MAY ignore some of the requested types, but in that case it MUST NOT include them in the response options?

David

On Mon, Apr 29, 2024 at 6:21 AM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:
I think I may have already argued for some of these points, but I think I was a bystander for the multi-option versus QTD question. I do agree with the approach you've stated—just burn two option codes. We have plenty. I'm sure someone will curse our memory 2000 years from now, but how else will we be remembered if we don't do this?

I may have been one of the people who argued for getting rid of QTCOUNT, and I still think that's right—it's redundant, and if we send it, we have to validate it. That seems like needless complexity.

As for the limit on the number of qtypes, I also don't see the need for that. There will no doubt be practical limits; the most likely of these is simply that there aren't actually that many rrtypes that will likely be represented on any given name. So I'm not sure what an explicit limit here accomplishes. At the very least we should articulate a reason for the limit if we impose one.

On Mon, Apr 29, 2024 at 6:17 AM Ray Bellis <ray@bellis.me.uk<mailto:ray@bellis.me.uk>> wrote:
With apologies for the delay (caused by other travel since the Brisbane
meeting) the proposal during the session there was to:

- remove the QTD bit and use a pair of EDNS option codes instead
   (one for queries, and another for responses).

- remove the QTCOUNT field

- either impose a fixed limit on the number of additional QTYPES (in the
   range of 3 - 8?) or remove the limit altogether.

We need to get formal WG consensus on these points so please send your
thoughts to the list...

thanks

Ray

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