| Hi David, You mention in one of your emails that you'd expect there to be many "broken PvD" deployments, which would either necessitate ignoring PvD and using legacy mechanisms, or else having the user face a broken portal. My impression is that if client-side deployments fail closed—that is, if there is a PvD advertised, but it does not work well, then we treat the network as broken. If this client behavior is consistent from the start of deployment, then I would think that deployments would notice very quickly if they are broken. The fundamental part of the PvD being advertised is in the RAs—if our DHCP or RAs are broken on a network, we generally are going to be broken anyhow. As far as where the API resides, I appreciate your explanation of the various complexities. My initial take is this: - Where a PvD is being served is up to the deployment, and determined by the entity that is providing the RAs. To that end, the server that hosts the API for extended PvD information may be very different for enterprise/carrier scenarios than in captive portals for coffee shops. - For the initial take for Captive Portals, I would co-locate the "PvD API" server with the "Captive API" and "Captive Web Server". Presumably, the device that was previously doing the HTTP redirects would be able to do the similar coordination of making sure the PvD ID that is given out to clients matches the PvD API server (which is the same as the "Captive Web Server"). For the captive use-case, I see the integration of PvDs as an incremental step: 1. Today, we join a network, always do a probe, which may get redirected to a captive web server 2. With RFC 7710, we would join a network and do the same as (1), unless the captive URL is given in the DHCP/RA and we just make a connection directly. 3. With the Captive API draft, we can interact with the portal other than just showing a webpage; but this may still be bootstrapped by 7710 if not using another mechanism 4. With PvDs, the mechanism in 7710 is generalized to support APIs other than just captive, and can indicate that no captive portal or other extended info is present; and the PvD API in this form is just a more generic version of the captive API that allows us to use the same mechanism for other network properties that aren't specifically captive (like enterprise network extended info, or walled gardens) Getting into the arms race of people avoiding the captive probes: if someone doesn't want to interact with the client OS's captive portal system, they can and likely will not change anything and just keep redirecting pages. Hopefully if a better solution becomes prevalent enough in the future, client OS's will be able to just ignore and reject any network that redirects traffic, and the only supported captive portals would be ones that interact in specified ways and advertise themselves as captive networks. In order to get to this point, there certainly needs to be a carrot to incentivize adoption. My goal with the more flexible interaction supported by PvD is that we will allow the networks to provide a better user experience to people joining their networks, and integrate with client OS's to streamline the joining process (notification of the network being available, who owns it, how to accept and how to pay), the maintenance process (being able to integrate time left or bytes left on the network into the system UI), and what is allowed or not on the network. Thanks, Tommy
|