Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Fri, 25 Jul 2025 12:17:12 +0200
Message-Id: <106A502D-3B8D-4BCD-8096-44BC18C78BA2@strandkip.nl>
To: Working Group DNSOP <dnsop@ietf.org>
Message-ID-Hash: BU6L5DC444UXHJKOJJU4PX5GWHELPTXI
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_service_binding_mapping_for_service_levels?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/FZ4C9CCj_Is2kViIvz0DidkmHH4>

Hi Gautam!

Regarding draft-gakiwate-dnsop-svcb-sla-parameter:

At the mic just now in Madrid I asked what incentive a client had to ever ch=
oose background priority if there's a better performance option. Your answer=
 was that the use case here is when the application and the service are oper=
ated by the same people, like a weather forecasting service supplying data t=
o a weather forecast widget on a phone.

If the client and server are operated by the same people, you could just use=
 different names for the foreground and background traffic classes -- it's n=
ot obvious why you need to use a single name for both. You could use api-wid=
get.weather.example.com for the phone widget that operates in the background=
 and api-user.weather.example.com for use when an impatient user is asking t=
he application to do things, or something like that.

Something like what you are suggesting could of course be done, but I am not=
 sure why it's more useful than what we can already do. Is there an advantag=
e?

I would have asked this follow-up question at the mic but we were short on t=
ime, so I'm asking it here.


Joe=