Clarify relationship of discovery to lifecycle

[mmccool]

We should more clearly state (and perhaps show with diagrams) how discovery and directory services relate to the lifecycle stated in Architecture. For example, when does a device become "active", how does onboarding take place, is a device "discoverable" immediately after registration, etc.

[mmccool]

Also, devices may not be "active" even if they are registered in the directory, e.g. if they are sleeping. This is different from them being operational. They may be operational (eg onboarded, registered) but sleeping or powered down, and hence not "active". In this case what does the directory do?

[zolkis]

Discovery is like a service, it defines its identification, addressing and its configuration/onboarding for the service.
That is a service lifecycle and usually maps to configuration in device lifecycle (i.e. in operational state).
However, it is also possible that in a WoT-only deployment that maps to the bootstrapping device state.

Also, please do make a clear difference between discovery FOR onboarding (protocol specific) and discovery in operational state (which WoT Discovery is, discovering Things and their services).

I think what really needs to be done is defining configuration sequences for discovery, and then it will be the job of implementations to map that to various protocols and the device lifecycles defined by these.

[mmccool]

So right now discovery has its own lifecycle, and is unrelated to onboarding. Anyway, directories just maintain lists of TDs, and those TDs may or may not point to already "onboarded" or active/accessible Things.

In the long run I think we DO need to clarify this but perhaps the clarification can take place in the Architecture document, in a future discovery 2.0 document, or in a future separate deliverable defining an onboarding process. We can also leave it unspecified, which is better than saying something wrong or misleading.

For the record I am fine with leaving onboarding as unspecified in the Discovery document itself, and talking about it (if at all) in Architecture.

[mmccool]

I've marked as "Resolve by PR" since I think that if we do add anything to the spec, if should probably be informative. We don't have time to spec and test a normative onboarding process, and it's also out of scope for what discovery should be doing. So at most we will be adding some informative text saying how discovery "fits in" to the lifecycle.

[mmccool]

Propose deferring to Discovery 2.0, when we can also figure out how onboarding fits in better.