I'm just learning this, so please pardon me if I have misunderstood something.
I'm attempting to understand the very first action of the onboarding from the device point of view - finding the rendezvous service.
If I have understood correctly, this service will be found based on a URL baked into the device identity at manufacturing time, during the DI protocol. By the time you know who has bought the device, at owner registration, it is too late to alter this setting.
I am attempting to address a use case where our end customers do not allow any kind of internet connection (like US Department of Defense,) and thus need an on-premise rendezvous server. The doc says on-premise is supported, and in some sense it seems to be, but there is a critical aspect here where it needs to be a customer specific on-premise rendezvous server, and that aspect seems not to be supported. "On-premise" means the customer's premises, not ours. And thus, the URL cannot be known until the device is sold.
My best guess at a way to reconcile this issue would be to allow a list of URLs, where the first one might be "https://intel-hosted-rendezvous-service.intel.com" and would be the common case, when on-premise is not required. The second could be something like "https://device-rendezvous/" - in other words, just a hostname not an FQDN. Then it becomes relatively simple for the customer to create a DNS entry within whatever their domain is, and the device will resolve it to their internal rendezvous server. I could use a hostname like this as the sole entry, but then ALL customers end up needing this DNS entry, rather than only the ones who have the strict requirements.
I'm just learning this, so please pardon me if I have misunderstood something.
I'm attempting to understand the very first action of the onboarding from the device point of view - finding the rendezvous service.
If I have understood correctly, this service will be found based on a URL baked into the device identity at manufacturing time, during the DI protocol. By the time you know who has bought the device, at owner registration, it is too late to alter this setting.
I am attempting to address a use case where our end customers do not allow any kind of internet connection (like US Department of Defense,) and thus need an on-premise rendezvous server. The doc says on-premise is supported, and in some sense it seems to be, but there is a critical aspect here where it needs to be a customer specific on-premise rendezvous server, and that aspect seems not to be supported. "On-premise" means the customer's premises, not ours. And thus, the URL cannot be known until the device is sold.
My best guess at a way to reconcile this issue would be to allow a list of URLs, where the first one might be "https://intel-hosted-rendezvous-service.intel.com" and would be the common case, when on-premise is not required. The second could be something like "https://device-rendezvous/" - in other words, just a hostname not an FQDN. Then it becomes relatively simple for the customer to create a DNS entry within whatever their domain is, and the device will resolve it to their internal rendezvous server. I could use a hostname like this as the sole entry, but then ALL customers end up needing this DNS entry, rather than only the ones who have the strict requirements.