On Thu, 2019-05-02 at 22:35 +0200, michal.lowas-rzechonek@xxxxxxxxxxx wrote: > Hi Inga, > > On 05/02, Stotland, Inga wrote: > Device UUID is associated with a mesh-based application and, as such, > is immutable. > > However, the same application (or we can call it device) can be > simultaneously provisioned on different mesh networks (e.g., home and > office networks), which means that it needs to be represented as a > unique mesh node and its configuration has to be stored in unique > distinct location. Hence the need for a unique node ID that is not > based on device UUID. > 3.10.3 says that: > > "(...) each node shall be assigned a 128-bit UUID known as the Device > UUID. Device manufacturers shall follow the standard UUID format as > defined in [RFC4122] and generation procedure to ensure the > uniqueness > of each Device UUID" > > So I think the UUID is assigned to *nodes*, not *applications* > controlling them? I don't think it's legal to create two different > nodes with the same UUID. > You are correct, a device UUID is a node attribute, not application's. I am not sure whether it's truly "illegal" to have nodes with the same UUIDs from a remote Provisioner perspective (since it has no control over the UUID value in the unpovisioned device beacon and I am not aware of any error code that a Provisioner can send indicating a name collision). However, from a local node node perspective, you are absolutely correct: UUIDs should be unique. So, Join() method will have to check if a directory name with the supplied UUID value already exists and, if so, fail with "AlreadyExists" error. The mesh-api.txt doc should be updated accordingly. Also, if the directory name contains the uuid value, then we probably don't need the duplicate value in the JSON file since it can be derived from the directory name. > To cover the use case you mentioned, I think the application would > need > to keep track of two UUIDs, and Attach() itself to both - which is > certainly possible. > > regards >
