Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

is no longer > captive.”. > > > > For us, the API saying the user is online but the enforcement device > still blocking them would be a major support headache, but could be caused > by a number of different scenarios. This sentence was key in making us seek > a robust solution to that

Re: [Captive-portals] Fwd: I-D Action: draft-ietf-capport-architecture-03.txt

I, for one, think "Document that the signaling protocol does not provide mechanisms for non-binary blocking." is where IETF tries to become a some sort of legal authority... Hypothetically, what if a non-free captive portal network is legally requires to *allow* certain resources for free (in the

Re: [Captive-portals] Signals from the network and ICMP

I, for one, disagree -- I believe the *risks* are that we: make network signaling optional, keep going down the road of trying to solve network enforcement at an Application layer, and ultimately just adding another way for Hotspots to be "broken". Just wanted to highlight a few comments made

Re: [Captive-portals] UE Identification

o IETF meetings. This definition will be a > lot simpler, and should make it clearer how to interact with the ICMP path. > > Thanks, > Tommy > > > On Dec 4, 2017, at 9:11 AM, David Bird <db...@google.com> wrote: > > I will also point out that the API is not only

Re: [Captive-portals] IETF 100: agenda and administrative items

A discussion of link layer based identifiers versus IP based > identifiers would be worth having. We might want to define the > general requirements, and then make explicit recommendations for what > to do when the enforcement point is on-link and when it's off-link. > > [3] In light o

Re: [Captive-portals] [adoption call] draft-larose-capport-architecture

I support adoption as well (as the draft rightly requires the ICMP I-D for notification) On Thu, Aug 31, 2017 at 10:15 AM, Kyle Larose wrote: > Likewise, as one of the authors, I support adoption. > > -Original Message- > From: Captive-portals

Re: [Captive-portals] Questions about PvD/API

to maintain this API/PvD association if they want to ever get notified. On Thu, Aug 31, 2017 at 5:54 AM, David Bird <db...@google.com> wrote: > Sending to list... > -- Forwarded message -- > From: "Martin Thomson" <martin.thom...@gmail.com> > Date:

Re: [Captive-portals] Questions about PvD/API

signal? something the nas is allowed to send to the ue, > but > > not icmp? > > > > > > Gr., Vincent > > > > > > > > Van: Captive-portals [captive-portals-boun...@ietf.org] namens Tommy > Pauly > > [tpa...

Re: [Captive-portals] Questions about PvD/API

were the > one that cited that argument in support of the ICMP solution.) > > As for several flows, I don't see what would stop an attacker from trying > to spoof several flows. > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird <db...@google.com> wrote: > >> You are

Re: [Captive-portals] Questions about PvD/API

network, things will be like networks that whitelist our probes today. Not > great, but still possible for the user to get through. My main goal in > these standards is to make it possible for a network to give the user a > good experience; not to make it impossible for the user to

Re: [Captive-portals] practicality of 511 HTTP status code

On Tue, Jun 27, 2017 at 8:55 AM, Julian Reschke wrote: > On 2017-06-27 16:56, Dave Dolson wrote: > >> Mark, thanks for the info about 511. >> >> But to the working group, I think this discussion about HTTP status codes >> is a distraction. >> >> I think the ICMP approach

[Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed

Can we get back on track and focus on our goal of improving the user experience of captive portals as they're commonly understood and currently deployed? ___ Captive-portals mailing list Captive-portals@ietf.org

Re: [Captive-portals] time-based walled gardens

I believe we both were referring more to the comment: "I don't like captive portals, I want them to die. " I know that wasn't your main point, but it is seems to be a feeling shared among some in this WG. On Tue, Apr 11, 2017 at 7:05 AM, Mikael Abrahamsson wrote: > On Tue, 11

Re: [Captive-portals] Arguments against (any) Capport "API"

ms actions in a broken browser of the UEs choosing (and doing). I think there are some user options to be had in there somewhere... On Fri, Apr 7, 2017 at 12:01 PM, David Bird <db...@google.com> wrote: > I am not claiming to have all the answers, or that this is an easy (or a >

Re: [Captive-portals] Arguments against (any) Capport "API"

In your example, you are doing (what I'm calling) Capport and Legacy at the same time. What would you do if Capport indicates YES (you have a portal), but Legacy says, NO (no portal)? Or wise versa? By adding Capport did we make anything easier? After you had a success, do you ever check again

Re: [Captive-portals] Arguments against (any) Capport "API"

Eduroam, at the end of the day, is not unlike Boingo or iPass. They went out and negotiated roaming contracts with hotspot providers, in this education organizations. Of course, part of that negotiation was the T acceptance/compliance. While this is a great example of an aggregate network and a

Re: [Captive-portals] Thinking of something related to captive portals for the ietf98 hackathon

Hi Kyle, I think that is a great idea! I had started to implement here: https://github.com/coova/coova-chilli/tree/capport-icmp What would be nice, in addition to the NAS changes, is to also demonstrate the client side ... either something like icmpd

Re: [Captive-portals] Fwd: Re: Tokyo

Sounds good. On Nov 3, 2015 2:04 PM, "mariko kobayashi" <a...@sfc.wide.ad.jp> wrote: > Thanks, I would like to have a short discussion. > I want some advices for my research topic, too. > How about around15:00 at the 5F Foyers? > > ao > > On 2015/11/03 13:11,

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach

pen WiFi, to prevent the sandbox browser from being used. However, if vendors do still use a sandboxed browser for HTTP CP-WEB, it will just encourage networks to use HTTPS, which is probably a good thing.) On Tue, Oct 6, 2015 at 5:53 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > &