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, 2022,

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 ti

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 provide

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

t's good to see >> > this turn into something concrete. >> > >> > On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote: >> > > Hello CAPPORT, >> > > >> > > I wanted to highlight an announcement we’ve made for the betas of iOS >>

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

, based 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, 2

[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 draft-ietf-capport-ap

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] Benjamin Kaduk's No Objection on draft-ietf-capport-api-07: (with COMMENT)

Hi Ben, Responses inline. I’ve updated the working copy here: https://capport-wg.github.io/api/draft-ietf-capport-api.html > On Jun 12, 2020, at 4:17 PM, Benjamin Kaduk wrote: > > Hi Tommy, > > Only a few things left to comment on, inline. > > On Wed, Jun 10, 2020 at 11

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 and

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 f

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 can

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 inta

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 8:

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 app

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 (https:

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: https://tools.ietf.org/

Re: [Captive-portals] WGLC ends for all drafts

The API draft is now similarly updated to incorporate the last issues opened during WGLC. Thanks, Tommy > On Mar 30, 2020, at 4:06 PM, Warren Kumari wrote: > > On Mon, Mar 30, 2020 at 4:14 AM Martin Thomson wrote: >> >> Thanks to everyone who reviewed and contributed to these drafts. That

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 > d

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 wo

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

I've put up a PR for the "can-extend-session" proposal here: https://github.com/capport-wg/api/pull/32 Please take a look and make suggestions for changes! Best, Tommy > On Jan 19, 2020, at 9:05 PM, Tommy Pauly > wrote: > > Lorenzo, my impression is that t

Re: [Captive-portals] Remediation url for CAPPORT

t;> >>> On Tue, 14 Jan 2020 at 16:21, Heng 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 i

Re: [Captive-portals] Remediation url for CAPPORT

ould display different notifications. > > Anyone have any objections on adding this boolean please? > > If not, what's the next step on moving this forward please? > > Thanks, > Heng > > On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly <mailto:tpa...@apple.com&

Re: [Captive-portals] Remediation url for CAPPORT

separate URL gives additional flexibility to the access > point operator, but from the point of view of the client I think both are > fine. > > Cheers, > > Remi > > > On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly > mailto:40apple@dmarc.ietf.org>> wrote: &

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. Part

Re: [Captive-portals] option 160 conflict

th a brief summary of the 160 polycom experience for > posterity. Sounds good. And do we just need to update the IANA Considerations to ask for 114? Best, Tommy > > On Thu, 2 Jan 2020 at 14:33, Warren Kumari <mailto:war...@kumari.net>> wrote: > On Thu, Jan 2, 2020 at 2:29 PM

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, a

Re: [Captive-portals] option 160 conflict

> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti > wrote: > >  >> On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), wrote: >> 1) It would not really remove the overlap for a long while (until all of the >> clients that used the "old" 160 Capport option are upgraded). So, devices >> will still n

Re: [Captive-portals] CAPPORT API with real Captive Portals and Linux Client: End-to-End demo

reply-all :-) > > On Mon, Oct 21, 2019 at 8:42 AM Tommy Pauly > mailto:40apple@dmarc.ietf.org>> wrote: > +1 to doing this at the hackathon, , and then (especially if there are > others who want to test as well), we can present the results to the WG. > > Do fol

Re: [Captive-portals] CAPPORT API with real Captive Portals and Linux Client: End-to-End demo

+1 to doing this at the hackathon, to also test interoperability with other implementations. I'd be happy to work on this with you at the hackathon on Sunday, and then (especially if there are others who want to test as well), we can present the results to the WG. Thanks, Tommy > On Oct 17, 20

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 a

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

In general, I think that the code on a client system that is intentionally interacting with a Captive Portal (for discovery, etc), will need to use the locally-provisioned DNS. That is probably Do53, but could be DoT/DoH in the future; it would, however, be expected to be under the control of th

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 Colitti

Re: [Captive-portals] (no subject)

+1 to getting a presentation from WBA; it would also be useful to get input and conversation during the meeting about the current working group documents! Best, Tommy > On Jul 7, 2019, at 12:32 PM, Erik Kline wrote: > > Thanks Brian. The capport agenda is currently unspecified. Would you lik

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 tha

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 sho

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 T

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 s

Re: [Captive-portals] Comments/Queries on draft-ietf-capport-api

ontent, a host sends an HTTPS GET >request: > > Thanks, > Subash > > From: on behalf of Tommy Pauly > Date: Monday, October 22, 2018 at 10:50 AM > To: "Tirupachur Comerica, Subash" > Cc: "draft-ietf-capport-...@ietf.org" , > "d.thak

Re: [Captive-portals] Comments/Queries on draft-ietf-capport-api

Hi Subash, Thanks for reading the document! To respond to the individual comments: 1. Access to the Internet is indeed an example, but it is among the most reliable ways to distinguish a "captive" network from a "non-captive" network. Captive networks often do also allow access to walled-garden

Re: [Captive-portals] Slimming down signalling text

Thanks for posting this, Kyle. I've added a review to your PR here: https://github.com/capport-wg/architecture/pull/16#pullrequestreview-139058967 Thanks, Tommy > On Jul 19, 2018, at 5:19 PM, Lorenzo Colitti > wrote: > > On Thu, Jul 19, 2018 at 4:50 PM Kyle Larose

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

hese decisions, as far as I can tell, are about improving use experience, rather than actually enforcing anything. The UE won't block traffic if it sees the API mark things as captive, etc; but it will be able to give the user better opportunities to interact with the portal. Tha

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

> On Jul 13, 2018, at 7:58 AM, David Bird > wrote: > > Hi Tommy, > > Thanks for the reply... See one follow-up inline. > > > On Mon, Jul 9, 2018 at 4:33 PM Tommy Pauly <mailto:tpa...@apple.com>> wrote: > Hi David, > > Thanks for the read-throu

[Captive-portals] New Version Notification for draft-pfister-capport-pvd-00.txt

. Best, Tommy > > > A new version of I-D, draft-pfister-capport-pvd-00.txt > has been successfully submitted by Tommy Pauly and posted to the > IETF repository. > > Name: draft-pfister-capport-pvd > Revision: 00 > Title:Using Provisioning

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

validating the network notifications. > > On Sun, Jul 1, 2018 at 10:35 AM <mailto:internet-dra...@ietf.org>> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Captive Portal Inter

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, but (assuming you are using the provided net

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 bette

Re: [Captive-portals] UE Identification

on, Dec 4, 2017 at 12:39 PM, David Bird <mailto:db...@google.com>> wrote: > Looking forward to it! > > > On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly <mailto:tpa...@apple.com>> wrote: > Darshak Thakore and I are now the editors of the API document, and will be

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 path

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 for

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 [mailto:captive-portals-boun...@ietf.org] On Behalf Of

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: captive-portals@ietf.org > Cc: martin.t

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 expected. > > David Dol

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

proposals to link the ICMP messages to the DHCP message somehow so that ICMP > is 'authenticated' against the original DHCP. Theses are solvable concerns, > not road blocks. > > > > On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <mailto:tpa...@apple.com>&g

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 ne

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

n a network, always do a probe, which redirects to captive > portal > > It wasn'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, T

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, i

Re: [Captive-portals] IETF 99 minutes

> On Aug 2, 2017, at 6:20 AM, Gunther Nitzsche 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: need to > notify non-http-80 > T

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

ave > > > 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> > Subject: Re: [Capt

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 can help solve the Capti

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

> On Jun 27, 2017, at 12:46 PM, Dave Dolson wrote: > > Eric, > Do I understand correctly from > https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5 > > > that the intenti

[Captive-portals] Proposals to discover Provisioning Domains (& Captive Portals)

read through and let us know your thoughts! Thanks, Tommy Pauly Apple ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals