Priority list of URLs for Rendezvous server

[kraney]

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.

[trbehera]

The protocol allows us to mention multiple rendezvous service URL that gets embedded in the device during 'Device Initialization - DI' process. As long as the device can navigate to the given rendezvous URL (an accessible hostname), the device should be able to complete the TO process. It is true that we would have to standardize the on-premise rendezvous URL.