Re: [dnssd] Review of draft-ietf-dnssd-srp-05

[Ted Lemon <[e-mail]>]

Thank you for the comments, Manuel!

> /------------- Typos --------------/
> Page 9, first paragraph:
> "This key pair MUST be unique to the device" is repeated twice.
> "+" symbol appears twice.

What I get for manually applying a diff—thanks for catching it! :)

> Page 12, second paragraph:
> "Instrructions"

Got it.

> /------------- Doubts -------------/
> Page 9, section 2.4.1.1 Service Behavior:
> "the key MAY be overwritten as a result of a full reset of the device (e.g., a "factory reset")"
> 
> What happens then?

Good question. I’ve clarified:

When the device changes ownership, it may be appropriate to erase the old key and install a new one. Therefore the key MAY be overwritten as a result of a full reset of the device (e.g., a "factory reset”)

> 
> Page 10, section 2.4.2 Removing published services:
> "To remove a service registration, the client retransmits its most recent update..." 
> "However, in some cases a client may not have retained sufficient state to know that some service instance is pointing to a host that it is removing."
> 
> Then, how is it able to retransmit an update of something that no longer knows? 

The notion is that an SRP update with just the host information, and with a lease time of zero, will remove all services advertised by that host, even if the SRP client doesn’t enumerate them in the update.

I’ve re-written the text in this paragraph as follows:

SRP clients are normally expected to remove all service instances when removing a host.  However, in some cases a SRP client may not have retained sufficient state to know that some service instance is pointing to a host that it is removing.  An SRP server can assume that all service instances pointing to a host entry that's being removed are no longer valid.  Therefore, SRP servers MAY remove all service instances pointing to a host when a host is removed, even if the SRP client doesn't remove them explicitly.

> Page 15, section 2.6.2. Sleep Proxy:
> This feature conditions the location of SRP Server, right?
> If we thought in a Border Router, it would only be useful for external traffic going through BR, but not for traffic initiated in the mesh network. 
> Maybe I have misunderstood it.

Bear in mind that SRP is a general protocol specification, and stub routers, like the Thread border router, are individual use cases. I don’t think there’s any value in implementing sleep proxy service for a Thread border router—Thread already has its own way of handling sleepy end devices.

> Regarding the protocol used, I don't see a clear drawback to not allow using UDP for the constrained devices. If the DNS service allows it, I believe that this new protocol should support it too.

I also think it makes sense to use UDP for SRP registrations.

Anyway, thanks for the comments, I will be updating the draft to address your and Esko’s comments, as well as Jonathan’s comments that followed my previous update, shortly. :)