Check that Vendor Profile ID for a vendor is unique

[KrishnaIyer]

Summary

Check that VendorProfileID for profiles of a vendor is unique. Refs; TheThingsNetwork/lorawan-stack#5323

Why do we need this?

To make sure that we can query LoRaWAN device profiles with the (VendorID,VendorProfileID) tuple.

What is already there? What do you see now?

Currently, most device profiles don't have the VendorProfileID defined. For the few ones that are defined, the values are basically copy-pasted into multiple profiles.

What is missing? What do you want to see?

If VendorProfileID is defined, it must be a unique value for each profile of a given vendor.

How do you propose to implement this?

I guess you'd need to ask users. @Jaime-Trinidad: Let's do this as an example for The Things Products and The Things Industries devices.

Can you do this yourself and submit a Pull Request?

Can test.

[Jaime-Trinidad]

@KrishnaIyer I add a unique VendorProfileId in The Things Product and The Things Industries profile files as an example for this.
I can contact makers to add numbers or I can start adding to the profile files.

[KrishnaIyer]

@Jaime-Trinidad: Thanks. I also think we need validation to make sure that the values are unique for future profiles.

[Jaime-Trinidad]

@KrishnaIyer yes, the question vendorProfileId should be unique in each vendor profile or overall vendors. ex. tti-profile-868.yaml vendorProfileId: 868 and elsys-868.yaml vendorProfileId: 868 .
Here they can insert the same profileId different vendor. If they can't be repeated it will be difficult maybe it will be necessary to establish some rules about this, else if it doesn't matter because the vendor is different, only establish the rule that each profileId should be different.

[KrishnaIyer]

yes, the question vendorProfileId should be unique in each vendor profile or overall vendors.

It should be unique within each vendor.

[johanstokking]

I'll add validity checks in CI.

[NicolasMrad]

Any updates here?

[johanstokking]

We have two options here:

1. According to TR005, the profile ID can refer to a device profile and codec. So at least the combination of profile and codec must be unique. What we can do is declaring the numeric profile ID in the vendor's index file, referencing the region, profile and codec. This aligns with TR005, but has the downside that there are potentially many end devices using the same vendor profile ID, which makes onboarding challenging

2. We can stretch the interpretation of vendor profile ID to refer to a unique combination of vendor ID, device model ID, firmware version, hardware version and region. This way, we can uniquely reference the profile and codec. This may not be supported by all device makers though.

Technically, we can also do both. We can define generic profile IDs that can be reused, and we can use them for the primary key of the device repository.

References #527 (comment)

@adriansmares thoughts?

[adriansmares]

I think we should indeed go with a mixed approach - make this profile ID part of the vendor's index file, requiring it to reference the region+profile and codec if available. If available, the firmware / hardware versions may be added as well, in order to allow mapping back (vendor ID, vendor profile ID) to (band ID, brand ID, model ID, HW version, SW version).

[adriansmares]

Are there any changes with respect with the current specification or vendor usage here ? Do we know if people reusing the vendor profile ID in the wild already ?

[johanstokking]

No changes to the specification. The main gap is that VendorProfileID refers to a device profile and codec combination, while multiple different device models may use that combination and we would like to see a different ID for these different models. I do think we have enough leverage to convince device makers to interpret it this way, at least to a large extent.

As for usage of this ID in the wild, I haven't seen it yet.