Subject: [dnssd] A bit more on subtypes in the SRP document

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2021 21:43:42 -0400

I've been doing the implementation for subtypes, and I think there needs to
be some additional clarifying text. It turns out to be really complicated
on various levels to support adding and removing individual subtypes. So I
would like to add text that restricts subtype updates roughly as follows:

Updates for service instances and their subtypes are considered as a whole:
deletes of individual subtypes are not permitted. An update of a service
instance replaces whatever subtypes may have previously been present with
the subtypes in the update.

The reason for this is that there's little utility to allowing edits. A
service presumably knows its subtypes, and so it's easier for the service
to update them atomically rather than trying to keep track of what was sent
previously. Allowing for editing of subtypes would make SRP replication
really, hard to get right.

I say this having embarked upon an implementation and then backing it out
because it was just spiraling.

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 13 Oct 2021 22:01:07 -0700

This makes sense to me. I was actually thinking through how one might
handle subtype edits in the context of SRP replication earlier today.
Requiring atomic updates will certainly simplify the implementation.

--
Jonathan Hui

On Wed, Oct 13, 2021 at 6:44 PM Ted Lemon <[email-masked]> wrote:

> I've been doing the implementation for subtypes, and I think there needs
> to be some additional clarifying text. It turns out to be really
> complicated on various levels to support adding and removing individual
> subtypes. So I would like to add text that restricts subtype updates
> roughly as follows:
>
> Updates for service instances and their subtypes are considered as a
> whole: deletes of individual subtypes are not permitted. An update of a
> service instance replaces whatever subtypes may have previously been
> present with the subtypes in the update.
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: Abtin Keshavarzian <[email-masked]>
Date: Thu, 14 Oct 2021 10:02:43 -0700

I fully agree.
Treating service instances and their subtypes as a whole makes sense to me
(helps simplify not only the SRP client implementation, but the replication
logic as well).
Abtin.

---

From: Kangping Dong <[email-masked]>
Date: Fri, 15 Oct 2021 11:29:29 +0800

Agree, though the OpenThread SRP server
<https://github.com/openthread/openthread/blob/main/src/core/net/srp_server.cpp>
is implemented to support updating individual subtypes :)

BRs,
kangping

On Fri, Oct 15, 2021 at 1:03 AM Abtin Keshavarzian <abtink=
[email-masked]> wrote:

> I fully agree.
> Treating service instances and their subtypes as a whole makes sense to
> me  (helps simplify not only the SRP client implementation, but the
> replication logic as well).
> Abtin.
>
>>> I say this having embarked upon an implementation and then backing it
>>> out because it was just spiraling.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Oct 2021 23:35:45 -0400

Yes, supporting it in the server isn't too bad until you start thinking
about how to do replication. Then it gets a bit painful, unless you just
get rid of the SRP trust model, which I would prefer not to do.

On Thu, Oct 14, 2021 at 11:30 PM Kangping Dong <[email-masked]> wrote:

>>>> I've been doing the implementation for subtypes, and I think there
>>>> needs to be some additional clarifying text. It turns out to be really