Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

[resend with fewer recipients to avoid mailing list problems]

To echo David’s request,
> If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.

From: David Bird [mailto:dbird@google.com]
Sent: Wednesday, June 14, 2017 9:36 AM
To: Erik Kline
Cc: Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson; captive-portals@ietf.org; Livingood, Jason; Herzig, Willi; Warren Kumari; Dave Dolson
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

On Sun, Jun 11, 2017 at 11:17 PM, Erik Kline <ek@google.com<mailto:ek@google.com>> wrote:
I'm not sure we have enough input on whether 511 is useful or not.  There seemed to be some suggestion it would help, and some that it wouldn't.  Perhaps one question we could ask is whether it's harmful?  And if we agree it's not harmful, is it worth developing some recommendations for its use?

In of itself, I don't believe it is harmful. However, if vendors use it as a reason to continue to terminate TLS connection in order to deliver the 511, then perhaps it is a bit harmful - or at least misleading. As the world moves to TLS (and QUIC), I think the time for the 511 code has already passed, to some degree. That, combined with the fact you may still have browsers not handling that return code properly, I don't see the value for any vendor or venue to implement this.

As for the ICMP unreachable option, I certainly don't think it would be harmful (with the extra URL bits removed for now).  Is that something we wish to progress?

I will work on a new draft that is only the basics. The additional fields could always be add in their own draft as extensions.

Given that we're probably looking at a portal detection method based on entirely new work, it seems to me we're free to look at new things like utilizing the PVD detection scheme (DNS queries for "provisioning domain names", followed by other interaction still TBD).  Have the portal implementors reviewed this and given consideration as to whether its useful?  (I think of the discovery of the portal and subsequent interaction with it as 2 separate processes conducted, obviously, in serial.)

I believe there are several talking points here, as the PvD method seems to have several possible implementations.

I think requiring Ipv6 to configure Ipv4 is weird (I believe that was one proposed method to convey configuration)

Several points I made in the thread "Arguments against any Capport API" regarding a web service - detached from the NAS - controlling the UE/station I think are relevant.

If the authors of the PvD concept (re-)present their I-D to the mailing list, and stick around for discussion, that would be helpful.

Thoughts?

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals