The current specification seems to suggest that after the Active dataset is configured the BR will join/form the Thread network, but I am wondering if it's useful to have some sort of control over this operation? Maybe the application running the TBR would want to control when to form/join the Thread network.

[dhrishi]

          The current specification seems to suggest that after the Active dataset is configured the BR will join/form the Thread network, but I am wondering if it's useful to have some sort of control over this operation? Maybe the application running the TBR would want to control when to form/join the Thread network. 

Thoughts?

Originally posted by @marius-preda in #33872 (comment)

[dhrishi]

@wqx6 PTAL

[wqx6]

@dhrishi I think this should be a SPEC issue since @marius-preda suggest to have some sort of control over the activation operation.

[dhrishi]

Sure. Can you please file one. I will close this

[marchemi]

Indeed, the specification states "[10.38] If this command is invoked and the ActiveDatasetTimestamp attribute is null, the Thread Border Router SHALL configure and activate its active dataset using the ActiveDataset parameter."
I think we should not change this. Maybe I could suggest using SetPendingDataset to control the activation with the pending timer ?

[marius-preda]

Hi @marchemi , what is your concern with such a change? What would be the issue in introducing some sort of flag or option that allows the application to control if the Thread interface is started or not?

I have seen some scenarios like where the device is Border Router capable but the application or the user decides to not enable for now the this function. I am imagining some sort of flag that is by default enabled to behave like it is today but it gives some flexibility and control over the BR feature.