Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 11:02:45 -0500

On Dec 19, 2020, at 10:34 AM, Kangping Dong <[email-masked]> wrote:
> 
> Sorry, another question :)
> 
> In section 2.3.1. Validation of Adds <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-validation-of-adds>, we have:
> 
>  SRP Updates consist of a set of instructions that together add or remove one or more services. 
> Each instruction consists either of a single add, a single delete, or a delete optionally followed by an add. 
> When an instruction contains a delete and an add, the delete MUST precede the add.
> 
> What is the use case of the "single add"? To my understanding,  the "delete + add" pattern is
> for resetting the service to our current SRP update. So the "single add" pattern is for updating
> the existing service, for example, adding one more AAAA RR, right?

The PTR add can just be an add, because there’s a 1:1 match between a service name PTR record and the service instance name that is its target. But this text is indeed confusing, so I’ve updated it:

            Each instruction
	    consists some combination of delete updates and add updates. When an instruction contains a delete and an add, the
	    delete MUST precede the add.

> I think, for most SRP clients, it will be more convenient for them to track all IP Addresses and
> always update with the whole IP addresses list rather than depending on this "update" model
> and register the addresses separately. The server, I think can also be simplified. Thoughts?

Indeed, the single add doesn’t make sense—the client has no way of knowing if there may be stale data present on the name.

> Another issue with this sentence is that, the Service & Host Description Invalidation requires:
> exactly one "Delete all RRsets from a name" RR,
> Seems disallowing the "single add" pattern? 

That’s right. The model of having the client partially update its data wouldn’t be consistent with the fact that SRP updates are essentially blind updates. So yes, the client always has to send all the data for any instruction, and that means we need a delete for every Host instruction, and a delete for every Service Description instruction. This isn’t needed for the Service Discovery instruction because there can only be one PTR record on a particular service type pointing to a particular service instance name—if it’s there, there’s no need to delete it before adding it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 11:06:34 -0500

On Dec 19, 2020, at 11:07 AM, Jonathan Hui <[email-masked]> wrote:
> I agree on checking for the KEY RR.

It looks like the current text already specifies this.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 11:07:29 -0500

On Dec 19, 2020, at 11:14 AM, Jonathan Hui <[email-masked]> wrote:
> So I guess the question is whether we can/should mandate this future going forward in SRP?

What if an LPR protocol server wants to do an SRP add?  Is there a strong reason to add this limitation? I don’t think it makes much difference.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Jan 2021 11:52:56 -0500

On Dec 19, 2020, at 10:11 AM, Kangping Dong <[email-masked]> wrote:
> I have some questions when reading the related sections:
> 
> 1. in 2.2.5.5.2. Removing some published services <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#section-2.2.5.5.2>, we have:
> The second alternative is to send a normal SRP update, but as in the first alternative, 
> including a Service Discovery Instruction and a Service Description that delete the service being removed.
> Should the "delete" be "replace"? 

Delete is a type of DNS update. There is no “replace” in a DNS update. If you want to replace an RR on a name, you first delete the current version, and then add the new version. I have updated the text to make this clear.

> 2. What's the use case of supporting multiple TXT RRs?
> in section 2.3.1.2. Service Description Instruction <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-service-description-instruc>, we have:
> zero or more "Add to an RRset" TXT RRs,
>  
> Are there real use cases that we need more than one TXT RRs? What is the expected behavior
> for the advertising proxy to publish this service with multiple TXT RRs? (I think DNS-SD requires
> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated to form a new TXT RR?
> If there is no such use case, should we require a single TXT RR? It will be easier to implement on both
> client and server side and consistent with DNS-SD. thoughts?

It’s relatively unusual, but we have to support it—SRP is not just for IoT use cases, where I agree that multiple TXT records are unlikely. See https://tools.ietf.org/html/rfc6763#section-6.8

I’ve submitted an update that contains new text to address the delete/replace concern.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ <https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-08.html <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-08.html>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-08>