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

[Erik Kline <[e-mail]>]

Dave,

Eric Vyncke (or another principal author) should have a presentation slot
in Prague to re-introduce us all and restart some discussion.

(Sorry for the long delay in responding.)

On 24 June 2017 at 03:57, Dave Dolson <[e-mail]> wrote:

> [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:[e-mail]]
> *Sent:* Wednesday, June 14, 2017 9:36 AM
> *To:* Erik Kline
> *Cc:* Gunther Nitzsche; Mark Townsley; Heiko Folkerts; Martin Thomson;
> [e-mail]; 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>