[DNSOP] Re: Comments on "Service Binding Mapping for Service Levels"

Erik Nygren <erik+ietf@nygren.org> Fri, 25 July 2025 10:20 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3A9634AFF508 for <dnsop@mail2.ietf.org>; Fri, 25 Jul 2025 03:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level:
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.017, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btcjiR9-RZT5 for <dnsop@mail2.ietf.org>; Fri, 25 Jul 2025 03:20:54 -0700 (PDT)
Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 10B024AFF196 for <dnsop@ietf.org>; Fri, 25 Jul 2025 03:19:58 -0700 (PDT)
Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-32b553e33e6so15910001fa.2 for <dnsop@ietf.org>; Fri, 25 Jul 2025 03:19:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753438795; x=1754043595; h=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=6t+Uc4iEU88vspGKmckYIgZI11SfFQ8HBWknVR7P598=; b=oUbJMmfwS8AT6ZaItZlEN0V2/BsgtIubQVFYcNeQ3EYmycJ58dJAYX9K8J6m5WaUR9 73DB1qfkkjJriPoiHX5S8AMVRz3SdVtPIGht/Anydxj0MP1O/9BS/2xfVFhEzPbiOjEx YncIMs4tkUQMFWCALqUNH6RHlTXjLhNi1cRYnUPCJIs+aFHOJLUJnVTnEkMH6Yaf76GH QUyDqVDbb6BgqIYBZAMPV+o2RWwupcAA8GxkVOXfSf4+kQrcJgLX464Z67MxfI9HjPh5 LRN6zGqpaq5Mf7igKkXVn/SklubqCnJQYGZbOm4eFmi1+jCHXgnqHP5And59vsq+Vp+B 8mEQ==
X-Gm-Message-State: AOJu0YxIkOIcuGkCyp/Q8HhECFgY6jjlJ66a1y0hlxav4pphQ/38gsst 5Ks/DqQwbHBYWQsn0+bngfHFyUo1kc5tcJopz3xIm4HEz6ja9XtEGcgFQ8sOr2UsSfPy0DZrPOw e4Y4AXoqZid/SgwM3dnEl/nr0q+3jr6AR6Uf2/u8=
X-Gm-Gg: ASbGncvw0Dt7Uo6iBaQppfuU6L8VEzcvjv1xQ2YVMKLruDkK0vOvHquQDS3F2Bd9HeC GvMiIJBGchemrqPkKqhiFtT3KjNUUAT0Eyde7J+D5ZsFlTzYzy/Lmm8GMuHFYg0B2foVPLzRZ6a cU85REpJbvtAAZex9CQ87rYm01wjYXdMwzvb3rmMj8QGi8DYzgYMpFYyIsNIonQIbOIrW8KakRT qjoBXfv7VRvP8qbSLynXfDu5WN4rUmFMiYqhwk=
X-Google-Smtp-Source: AGHT+IFNSNtn7kgopKruR+UqoI3otvNt1SEt1+W7iat6PyS2EmBYC1YfpW0iFfC/+mNKDPdRP/hUSj4QFYiFkEgh/jI=
X-Received: by 2002:a2e:be0e:0:b0:32b:7413:503 with SMTP id 38308e7fff4ca-331ee719ecbmr4069971fa.16.1753438795193; Fri, 25 Jul 2025 03:19:55 -0700 (PDT)
MIME-Version: 1.0
References: <SA1PR15MB4370B576D2D88F883391CB74B3D32@SA1PR15MB4370.namprd15.prod.outlook.com>
In-Reply-To: <SA1PR15MB4370B576D2D88F883391CB74B3D32@SA1PR15MB4370.namprd15.prod.outlook.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 25 Jul 2025 12:19:43 +0200
X-Gm-Features: Ac12FXy3-bFZBpmRyaZCTN_thFfdXVJ5INy3Ep1du2oz0lyIzsiUOLrfhafWtYI
Message-ID: <CAKC-DJggUeEMNMXsSsG4DD1vksrvCeGwknXLGRPzrmBozPqZgg@mail.gmail.com>
To: DNSOP Working Group <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000085e2b5063abe48e0"
Message-ID-Hash: AR3VPV7SNHVURDET222VMZJKN7PEABAO
X-Message-ID-Hash: AR3VPV7SNHVURDET222VMZJKN7PEABAO
X-MailFrom: nygren@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Comments on "Service Binding Mapping for Service Levels"
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CdGXjY-wHm1QDcbt7PlP8Oj4ch8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

As another top-level comment on this draft:

For at least some operators, deploying safely will also require having a
way for clients to signal which SVCB record was used.  For example, load
reporting, debugging/diagnostics, and other operational use-cases would
need to know whether the background or interactive SVCB endpoint was used.

It would make sense to do this more generally rather than as part of this
specific draft.
Here was the backlog ticket from when SVCB was being authored where we
captured future-draft notes:

    https://github.com/MikeBishop/dns-alt-svc/issues/107
The privacy considerations were one of the biggest challenges here.  It's
also unclear which WG such a draft would go into?  (eg, http or maybe even
a future incarnation of happy.)  The top ideas had either been:  1) a
SVCB-Used request header that includes the used SVCB RR (the best solution
if we can be ok with the privacy properties); 2) introducing an identifier
tag SvcParam of at most N bits which then gets sent in a SVCB-Used header
(which would be no worse than what can be trivially done with IPv6
addresses as long as N<=64).

As to this draft, I wonder if having a bitmask of attributes (eg, with one
for "background") or list of tokens could be another approach we could take
that could make this more generally useful for cases other than just
background.

        Erik