Re: [Captive-portals] Capport return of experience and... questions :(

Hi Xavier, Yes — I’ll follow up with you off-list to collect the right logs from your machine. Best, Tommy > On Jul 19, 2022, at 4:39 AM, Xavier BEAUDOUIN wrote: > > Hello, > > >> Le 19 juil. 2022 à 12:13, Martin Thomson > > a écrit : >> >> On Mon, Jul 18,

Re: [Captive-portals] [Technical Errata Reported] RFC8910 (6620)

> On Jun 23, 2021, at 8:42 AM, Michael Richardson wrote: > > > RFC Errata System wrote: >> - >> In RFC8908 the relevant Content-Type is defined as >> "application/captive+json" and not "application/capport+json". > > Wow, thank god for the summary, and even with it, I had to read four

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-09: (with DISCUSS and COMMENT)

Hi Martin, I think the DISCUSS indeed is resolved by the -09 version. The text now says: “At minimum, the API MUST provide the state of captivity. Further, the API MUST be able to provide a URI for the User Portal.” That is in line with what the API document provides. It is *able* to

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

on. Likely we’re hitting one of those, but it would be good to confirm which. > > Thanks for your efforts in getting this implemented! Thanks for implementing it too! Best, Tommy > > Steve > > > >> On 22 Jun 2020, at 22:30, Tommy Pauly wrote: >> >&

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

> On Jul 2, 2020, at 11:55 AM, Michael Richardson wrote: > > > Not really a CAPPORT protocol problem... but... > > Tommy Pauly wrote: >> One point I wanted to clarify: the iOS and macOS betas support for >> CAPPORT discovery and APIs still goes through the st

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

ed on how networks adopt it. Thanks, Tommy > >> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson wrote: >> >> Tommy, this is great! Thanks for all your work here, it's good to see this >> turn into something concrete. >> >>> On Tue, Jun 23, 2020, at 07

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

Hello CAPPORT, I wanted to highlight an announcement we’ve made for the betas of iOS and macOS released today: How to modernize your captive network The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Rob, Thanks for the example text for user consent, etc. I believe that at this point in how the CAPPORT API will be used, the main way that personal information is transmitted is in the web portal. The privacy text in -08 was updated from the -07 version to not imply that it is the API JSON

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

On Jun 15, 2020, at 9:15 AM, Tommy Pauly > wrote: > > Thanks all for the input. The text in our working copy now reads: > > The API server endpoint MUST be accessed over HTTP using an https URI > {{!RFC2818}}, and SHOULD use the default https port. > > (https://capport-wg

Re: [Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

On Jun 11, 2020, at 12:14 PM, Roman Danyliw wrote: > > Hi Tommy! > > The proposed edits in the working copy look good and address all of my > discuss and comments. Thanks for making the changes. > > Regards, > Roman > > From: Tommy Pauly > Sent: Wednesday,

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

Thanks all for the input. The text in our working copy now reads: The API server endpoint MUST be accessed over HTTP using an https URI {{!RFC2818}}, and SHOULD use the default https port. (https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker > wrote: > > Magnus Westerlund has entered the following ballot position for > draft-ietf-capport-api-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Rob, Thanks for the review! Responses inline. You can also see updates in our working copy here: https://capport-wg.github.io/api/draft-ietf-capport-api.html > On Jun 11, 2020, at 4:17 AM, Robert Wilton via Datatracker > wrote: > > Robert Wilton has entered the following ballot position

Re: [Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

Hi Roman, Thanks for your comments! I’ve updated our working copy with this commit: https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896 The full editor’s copy can be viewed here:

Re: [Captive-portals] Benjamin Kaduk's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Ben, Thanks as always for your detailed comments. I’ve updated our working copy with this commit: https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896 The full editor’s copy

Re: [Captive-portals] Murray Kucherawy's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Murray, Thanks for the review! Some comments inline. > On May 13, 2020, at 12:45 AM, Murray Kucherawy via Datatracker > wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-capport-api-07: No Objection > > When responding, please keep the subject line

Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Martin, Thanks for the updated review. I’ve incorporated these comments in our GitHub: https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672 Thanks, Tommy > On Jun 8, 2020, at

Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

Hi Martin, Thanks for the review. Responses inline. > On Jun 6, 2020, at 2:49 PM, Martin Duke via Datatracker > wrote: > Martin Duke has entered the following ballot position for > draft-ietf-capport-api-07: Discuss > > When responding, please keep the subject line intact and reply to all >

Re: [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Hi Rifaat, Your comments make it clear that the recommendation to make the API server name visible isn’t necessarily clear. I think it’s not a harmful thing to show, as a way to give troubleshooting information and transparency to the user, but it is not a security-critical point. It seems

Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-api-07

Hi Linda, Thanks for reviewing the document. For background on how the architecture defined by the CAPPORT WG is preferable to the non-standard mechanisms in deployment today, I’d like to point you to one of the documents referenced by the API document, draft-ietf-capport-architecture

Re: [Captive-portals] Genart last call review of draft-ietf-capport-api-07

Hi Brian, Thanks for the review! I’ve updated our working copy to fix the nits you mention: https://github.com/capport-wg/api/commit/a9d1dabf8b8b1e4275b98cc5d022d12bece97e70 > On May 3, 2020, at 9:29 PM, Brian Carpenter via Datatracker > wrote: > > Reviewer: Brian Carpenter > Review result:

Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07

> On Apr 27, 2020, at 7:21 AM, Barry Leiba wrote: > > Thanks for the reply, Dave, and I think we're OK to start last call on > the document after you post a revised I-D with the changes so far -- > most unresolved things are not at a blocking level. Just one thing > I'd like to push on before

Re: [Captive-portals] AD review of draft-ietf-capport-api-06

Hi Barry, Thanks for the review! Update made here: https://github.com/capport-wg/api/commit/27cd22fd8a8db696efb9772acd6c05d24a86c81d This has been posted as draft-ietf-capport-api-07:

Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

> On Mar 7, 2020, at 1:54 PM, ddol...@golden.net wrote: > > Regarding capport-api, in the section 4.1.1 Server Authentication, is this > advice different than the authentication done by any other HTTPS client? It > seems like this section should just be referencing another document (but I >

Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

Hi Kyle, Thanks for the review! I’ve made some editorial fixes in this commit: https://github.com/capport-wg/api/commit/fabc5994e3d7945140dd379a8b81a28b5b668bb4 > On Mar 14, 2020, at 9:21 AM, Kyle Larose > wrote: > > Hello, > > I support publication of capport-api. Thanks for all the hard

Re: [Captive-portals] IETF 107 Preliminary Agenda

> On Feb 21, 2020, at 3:58 PM, Erik Kline wrote: > > Fellow capport-ians, > > https://datatracker.ietf.org/meeting/107/agenda.html > > https://datatracker.ietf.org/meeting/107/agenda.txt >

Re: [Captive-portals] Remediation url for CAPPORT

Liu wrote: >>>> >>>> It seems most are comfortable with adding a remediation-capable boolean, >>>> which is simpler than another url while also making it explicit on whether >>>> remediation is provided or not, so UE could display different >&

Re: [Captive-portals] Remediation url for CAPPORT

I have a similar initial reaction to Erik's. Adding another URL that effectively is just another user portal, but meant to be used at certain times, adds a lot of complexity. I'm certainly not ruling out adding such a key as need arises, but I'd hesitate to make it part of the initial set.

Re: [Captive-portals] option 160 conflict

One option we have is to use Code 114, which was reserved for use by Apple as a "URL" option. That particular codepoint wasn't ever used, so it should be open to be reclaimed as a CAPPORT API URL. Since this is in the range below 128, it should be safer to use. Best, Tommy > On Dec 23, 2019,

Re: [Captive-portals] Discovering captive portal API URL via DNS?

> On Sep 3, 2019, at 4:44 PM, Lorenzo Colitti > wrote: > > All, > > During discussions with captive portal operators about implementing the > capport API, one of the stumbling blocks that keeps coming up is that the > captive portal operator does not always control the DHCP configuration

Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

To that end, any enforcement of other traffic (such as normal web page loading) will not be carrying any session identifier, so only signals that are already present in the packets, such as the IP address, are effectively useful here. Thanks, Tommy > On Jul 25, 2019, at 2:43 PM, Lorenzo

Re: [Captive-portals] quick poll: IETF 105 Montreal

I’m in favor of having a meeting (and I’ll be in Montreal); I think at this point we should work to get the documents ready to go. Our milestones for API, Architecture, and 7710bis are set to July 2019, so I’d encourage that we get those documents in shape to WGLC, and go through any issues

Re: [Captive-portals] Call for adoption draft-ekwk-capport-rfc7710bis

Agreed, this document is definitely an improvement and core to moving ahead the other working group items. I also support adoption! Best, Tommy > On Mar 28, 2019, at 7:00 PM, Kyle Larose wrote: > > We need to update the document to align with our proposed API, as well > as to address a few

Re: [Captive-portals] [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)

> On Mar 15, 2019, at 5:22 AM, Thomas Peterson wrote: > > (to those exclusively on the captive-portals list, this email follows on a > discussion around a presentation discussing implications of DNS over HTTP in > networks where captive portals are present) > > On 15/03/2019 11:26, Martin

Re: [Captive-portals] IETF 103 call for agenda items

That sounds good to me. We haven't revved the API docs, etc, but using the time to just review next steps and get some more work done on 7710bis would be good. Best, Tommy > On Oct 29, 2018, at 4:49 PM, Erik Kline wrote: > > I propose that this time we'll just meet informally. > > There are

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

> On Feb 5, 2018, at 4:54 PM, Martin Thomson wrote: > > On Tue, Feb 6, 2018 at 8:41 AM, David Bird wrote: >>> I have heard UE vendors express a strong desire to be able to know >>> about status before they attempt to use the network. >>> >> >> Hm,

Re: [Captive-portals] API access and .well-known

Hi Evert, I think that all three options that Martin provided implicitly support two different URLs ([API-URL] and [HTML-URL] for lack of a better term) that a client device could use. I agree that making things very explicit and clear is important. >> a. use .well-known and just provide

Re: [Captive-portals] UE Identification

atnot... > > On Mon, Dec 4, 2017 at 12:39 PM, David Bird <db...@google.com > <mailto:db...@google.com>> wrote: > Looking forward to it! > > > On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>

Re: [Captive-portals] UE Identification

Darshak Thakore and I are now the editors of the API document, and will be posting a new version of the document hopefully soon that addresses the discussions from the previous two IETF meetings. This definition will be a lot simpler, and should make it clearer how to interact with the ICMP

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

Hi Kyle, Dave, Thanks for updating the architecture document! It's nicely written, and serves as a very good summary of the state of our collective thoughts in the WG. I've just done a pass of a review of the document, and wanted to share my notes/thoughts with you and the rest of the group

Re: [Captive-portals] Capport at the hackathon

+1 I'll be there, and would love to work on CAPPORT stuff! Tommy > On Nov 2, 2017, at 7:29 AM, Kyle Larose wrote: > > I'll be participating. Hoping to see a bunch of people there. :) > > -Original Message- > From: Captive-portals

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

I support adoption as well! Thanks, Tommy > On Aug 30, 2017, at 7:20 PM, Dave Dolson wrote: > > As one of the authors, I support adoption. > > David Dolson > Sandvine > Original Message > From: Erik Kline > Sent: Wednesday, August 30, 2017 7:04 AM > To:

Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection

+1 to adopting this document as the basis for the captive API. Thanks, Tommy > On Aug 30, 2017, at 7:23 PM, Dave Dolson wrote: > > I support adopting the API document, expecting some changes to the details of > the API itself, which I believe the authors also said they

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

Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given

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

n't clear in your e-mail if RFC7710 can be used *without* providing a > URL, or is there a PvD specific DHCP option? > > Thanks, > David > > > On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>> wrote: > Hi David

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

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,

Re: [Captive-portals] IETF 99 minutes

> On Aug 2, 2017, at 6:20 AM, Gunther Nitzsche <gnitzs...@netcologne.de> wrote: > > Hi > > and thanks for the meeting minutes. > > I have two (no..three :) small comments on that: > There is an uncontradicted comment saying: > > > David Dolson: nee

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

d of provisioning? > > -Dave > > > From: David Bird [mailto:db...@google.com <mailto:db...@google.com>] > Sent: Monday, July 10, 2017 9:39 AM > To: Tommy Pauly > Cc: Dave Dolson; Eric Vyncke (evyncke); captive-portals@ietf.org > <mailto:captive-portals@ietf.org&

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

Hi Dave, > On Jul 10, 2017, at 8:54 AM, Dave Dolson wrote: > > At the last meeting, I think we heard, “PvDs can help solve this problem.” > (This seems to me to be true.) > Are the PvD authors backing away from this assertion? No, we’re definitely still saying that PvDs