SRP Client Lease Interval and Key Lease Interval

[OlivierGre]

After a Thread commissioning, I'm using SRP to advertize the presence of the Thread device. It is working fine.
Can you please explain me the respective roles of Lease Interval and Key Lease Interval ? What will happen at the end of this durations?

Is it possible to use them to stop the SRP service after X seconds?

Thank you

[jwhui]

The lease specifies how long the DNS-SD PTR, SRV, A, AAAA, and TXT records will remain valid. This helps ensure that the service information is no longer discoverable within a reasonable amount of time after the device publishing the information disconnects from the network.

The key lease specifies how long the KEY record will remain valid, which allows the device to retain its claim on the name for much longer than the lease interval even when it is disconnected from the network.

Note that the SRP registrar can override the lease and key lease values requested by the SRP client. See otSrpServerSetLeaseConfig() to configure the bounds on the SRP registrar.

You can find more information about the lease and key lease in draft-ietf-dnssd-srp.

[OlivierGre]

Thank you Abtin, that clearly helps.

I can tell you more about what I'm doing:
My demo is about NFC Commissioning:
I have an OTBR, an Android phone acting as the Commissioner (running our own app) and a Thread device that I want to add to the Thread network.
The Thread device has an NFC tag. This is not a basic tag but a tag connected to the MCU via I2C. The tag contains the same information as what you put in a QRCode.
To initiate the commissioning, the user put the smartphone on the NFC Tag. The smartphone reads the tag content and gets the EUI64 and the PSKd. NFC communication is also used at that time to initiate the otJoinerStart() action on the Thread device.
Once the commissioning done, the Thread device uses SRP to advertize its IP address. The smartphone scan "_ipps._tcp" services, finds the one with the expected EUI64 ("ot-host-0123456789ABCDEF", "ot-service-0123456789ABCDEF") and can then communicate with it. For the moment I use UDP.

Our goal is to show this commissioning so when this is done, we reset the Thread device. Credentials have not been kept in non volatile memory so it starts disconnected from Thread network and we can do the demo again.

My problem is with SRP service peristance. If I try a new commissioning, previous SRP service is still there. This is sometimes a problem because the Thread device may receive a new IPV6 address. Once the commissioning done, SRP service will get updated with the new IPV6 address but it is too late because the smartphone has already seen the old IP address.

That's why I wanted a SRP service with a short duration.

I'm going to try the following strategy: Once the commissining done and the device discovery (via SRP) done, the smartphone and the Thread device will echange a message. The Thread device will then call otSrpClientRemoveHostAndServices() (with removeKeyLease = true and sendUnregToServer = true) so that the SRP Service get stopped.

Your comments and suggestions are very welcome.
Thanks for your help
Regards

[jwhui]

If this is purely for demo purposes, I would think that setting the lease values to something small would be fine. While that would cause the device to refresh its lease more frequently, that should not be much of an issue for a demo.

[abtink]

I'm going to try the following strategy: Once the commissining done and the device discovery (via SRP) done, the smartphone and the Thread device will echange a message. The Thread device will then call otSrpClientRemoveHostAndServices() (with removeKeyLease = true and sendUnregToServer = true) so that the SRP Service get stopped.

Yes. I think this can work. You can register a callback in SRP client to get notified on changes (so to tell when remove was done and updated on server) and then continue to next step (reset the device, etc).

[jwhui]

I'm going to try the following strategy: Once the commissining done and the device discovery (via SRP) done, the smartphone and the Thread device will echange a message. The Thread device will then call otSrpClientRemoveHostAndServices() (with removeKeyLease = true and sendUnregToServer = true) so that the SRP Service get stopped.

Yes. I think this can work. You can register a callback in SRP client to get notified on changes (so to tell when remove was done and updated on server) and then continue to next step (reset the device, etc).

The only downside with this approach I see is if that message does not get through for whatever reason (maybe because the device was factory-reset too early), then the symptom will be unaddressed.

[OlivierGre]

Ok thank you @jwhui and @abtink for your messages.

Is it possible to stop a SRP service that has not been started during the current run? I mean: Let's say that the Thread device has started a SRP service and then been rebooted without stopping the service. Can I stop the SRP service afterward? Is it possible to use otSrpClientRemoveHostAndServices() to stop a service not started during the current session?

[OlivierGre]

I'm thinking to another solution:
I can manage to get the host name and the service instance name to be different every times.
The host name would still contain the EUI64 (ex: "ot-host-0123456789ABCDEF") but the service instance name would contain a random number known by the Thread device and by the Android phone (ex: "ot-service-AABBCCDD"). This random number would change every times so the smartphone will specifically search this service instance name and will ignore services with other number (remaining from previous demos).

By this way, I don't have to bother anymore with SRP service persistance.
What do you think?

[jwhui]

All names are protected with the same key record. So you would need to use a different name with a different key (which occurs after a factory reset).

[OlivierGre]

ok, thank you

[OlivierGre]

The discussion is now difficult to follow because of the nested messages. So I'm copying my last message here:

Ok thank you @jwhui and @abtink for your messages.

Is it possible to stop a SRP service that has not been started during the current run? I mean: Let's say that the Thread device has started a SRP service and then been rebooted without stopping the service. Can I stop the SRP service afterward? Is it possible to use otSrpClientRemoveHostAndServices() to stop a service not started during the current session?

[jwhui]

Yes, the documentation for otSrpClientRemoveHostAndServices() states:

The aSendUnregToServer determines the behavior when the host info is not yet registered with the server. If aSendUnregToServer is set to false (which is the default/expected value) then the SRP client will immediately remove the host info and services without sending an update message to server (no need to update the server if nothing is yet registered with it). If aSendUnregToServer is set to true then the SRP client will send an update message to the server. Note that if the host info is registered then the value of aSendUnregToServer does not matter and the SRP client will always send an update message to server requesting removal of all info.

One situation where aSendUnregToServer can be useful is on a device reset/reboot, caller may want to remove any previously registered services with the server. In this case, caller can otSrpClientSetHostName() and then request otSrpClientRemoveHostAndServices() with aSendUnregToServer as true.

[OlivierGre]

Thank you!