Hi Benjamin,
Thanks for the review. Responses inline below.
On Mon, 14 Sep 2020 at 19:38, Benjamin Kaduk via Datatracker
wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-capport-architecture-09: No Objection
>
> When responding, please keep the subject line in
Martin,
Thanks again for the review.
Responses inline below.
On Sun, 9 Aug 2020 at 02:05, Martin Duke via Datatracker
wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-09: No Objection
>
> -
I have only skimmed this, so it may not be appropriate, but I wonder if
this could be a starting point for the captive portal signal. Could this
address some of the concerns we had with ICMP?
-- Forwarded message -
From: Tom Herbert
Date: Fri, Jul 10, 2020 at 11:52 AM
Subject: [ts
Hi Ben,
On Sun, 21 Jun 2020 at 14:51, Benjamin Kaduk wrote:
>
> Hi Kyle,
>
> On Sun, Jun 14, 2020 at 12:13:30PM -0400, Kyle Larose wrote:
> > Inline again.
> >
> > Note: I've clipped sections I'm not responding to.
> >
> > On Fri, 12 Jun 20
Inline again.
Note: I've clipped sections I'm not responding to.
On Fri, 12 Jun 2020 at 20:50, Benjamin Kaduk wrote:
>
> Also inline.
>
> On Thu, Jun 11, 2020 at 09:12:34AM -0400, Kyle Larose wrote:
> > Hi Benjamin,
> >
> > >
> > >None of
t;
> -eric
>
> -----Original Message-
> From: Kyle Larose
> Date: Tuesday, 9 June 2020 at 14:43
> To: Eric Vyncke
> Cc: The IESG , "draft-ietf-capport-architect...@ietf.org"
> , "capport-cha...@ietf.org"
> , captive-portals , Martin
> Thomson
>
Hi Rob,
Response inline.
On Thu, 11 Jun 2020 at 07:24, Rob Wilton (rwilton) wrote:
>
> Hi,
>
> Linda Dunbar raised the following comment during the OPSDIR review of the
> capport-api draft:
>
> What improvement does the proposed API have over today's existing
> communication between clients an
Hi Robert,
Thanks for the review. Responses inline.
On Thu, 11 Jun 2020 at 05:57, Robert Wilton via Datatracker
wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
> ---
Hi Alvaro.
Thanks for the review. Responses inline.
On Tue, 9 Jun 2020 at 16:16, Alvaro Retana via Datatracker
wrote:
>
> Alvaro Retana has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
> -
Thanks Roman,
Responses inline
On Tue, 9 Jun 2020 at 17:26, Roman Danyliw via Datatracker
wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
> --
> COMME
Responses inline
On Tue, 9 Jun 2020 at 12:27, Michael Richardson wrote:
>
> Benjamin Kaduk via Datatracker wrote:
> > (3) Probably a "discuss discuss", but ... in Section 1 we have:
>
> >* Solutions SHOULD NOT require the forging of responses from DNS or
> > HTTP servers, or any
Hi Benjamin,
Thanks for the thorough review!
Responses inline
On Tue, 9 Jun 2020 at 01:30, Benjamin Kaduk via Datatracker
wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-capport-architecture-08: Discuss
>
> ---
Hi Éric,
Thanks for the review!
Responses inline.
On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker
wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
> ---
Hi Martin,
Thanks again. I'll reply to the comment section with comments from the
earlier review for consistency.
Inline.
On Mon, 8 Jun 2020 at 11:07, Martin Duke via Datatracker
wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-08: Discuss
>
Hi Murray,
Thanks for the review!
Responses inline.
On Sun, 7 Jun 2020 at 00:00, Murray Kucherawy via Datatracker
wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
On Sun, 7 Jun 2020 at 20:03, Erik Kline wrote:
>
> Tommy is correct. I think the architecture document should add a
> qualifying subclause to clarify that requirement (2) only applies "if
> captive portal enforcement may be active on the given network" or
> something.
>
> The model supports, for
Hi Martin,
Thanks for the review!
Responses inline
On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
>
Hi Joel,
Thanks for the review.
On Sat, 16 May 2020 at 18:35, Joel Halpern via Datatracker
wrote:
>
>
> Summary: This document is almost ready for publication as an Informational RFC
>
> Major issues:
> This document says it is Informational. It says it describes "a" capport
> archite
Hello,
Thanks for the quick feedback
On Mon, 11 May 2020 at 15:25, S Moonesamy wrote:
>
> I took a quick look at the draft. The third paragraph in the
> Introduction section states that the document standardizes an
> architecture for implementing captive portals. Does it meant that
> this dra
Hi Bob,
Thanks for the quick feedback.
> I am curious why section 3.4 does not consider the MAC Address as a possible
> identifier?
Its omission doesn't mean that the MAC Address is not a valid
identifier. One should evaluate it using the criteria provided in 3.2
and 3.3. When I wrote the skele
IETF.
Title : CAPPORT Architecture
Authors : Kyle Larose
David Dolson
Heng Liu
Filename: draft-ietf-capport-architecture-08.txt
Pages : 19
Date: 2020-05-11
Abstra
Hey Barry,
I'll upload one shortly. Sorry about the delay.
On Mon, 11 May 2020 at 09:18, Barry Leiba wrote:
> Can we get a revised I-D up on this now, so I can get the last call
> started? The last calls on the other two documents are ending this
> week.
>
> Martin, should I hold the telechat
Thanks for the feedback and PR Gurshabad!
I've replied to Martin's reply regarding the signal section.
As for the privacy considerations, it's probably a good idea. Did you
have some suggestions for content?
Thanks,
Kyle
On Mon, 23 Mar 2020 at 22:52, Gurshabad Grover wrote:
>
> On 3/5/20 12:2
Thanks Martin,
It's unfortunate that we weren't able to better expand on the signals
section, but if the section is confusing or misleading, we probably
should reduce it to something like you've suggested. I think that text
captures the essence of the signal. I'll submit an issue to change it.
On
Hello,
I support publication of capport-api. Thanks for all the hard work!
I have a bunch of minor comments:
Regarding Section 4.1.1:
> If the certificates do
> require the use of AIA, the captive network will need to allow client
> access to the host specified in the URI.
Should this b
Hello,
I support publication.
I do have a couple of minor comments. Section 1 mentions a future protocol
to be worked on by the IETF:
"
It is anticipated that the IETF will work on a more fully featured
protocol
at some point, to ease interaction with Captive Portals.
"
Section 2 mentions
I agree. I think this is a good way to show traction for the work we're
doing.
There's also the hackathon demo happy hour (
https://trac.ietf.org/trac/ietf/meeting/wiki/106hackdemo) where you could
have an opportunity to demo it to the wider community.
On Mon, 21 Oct 2019 at 11:42, Tommy Pauly
w
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Captive Portal Interaction WG of the IETF.
Title : CAPPORT Architecture
Authors : Kyle Larose
David Dolson
David,
On Wed, 27 Mar 2019 at 08:26, David Bird
wrote:
>
> This is assuming that DHCP and RA will be handing out unique URLs to UEs
> encoded with the necessary token identifying the UE.
>
At IETF 100 we discussed how the various components interacting with
the captive portal would be identifie
We need to update the document to align with our proposed API, as well
as to address a few shortcomings I believe we have discovered since it
was first published.
I support adoption.
On Wed, 27 Mar 2019 at 08:01, Martin Thomson wrote:
>
> Erik and Warren have helpfully provided this draft that u
Tommy and Darshak,
Thanks for the update. Changing host to client makes sense. I hadn't
considered the NTP case either; it's pretty important!
I've done a re-read of the document. It is still nice and simple. Good job!
I have some comments.
In section 3, the document outlines the steps of inter
On Thu, 27 Dec 2018 at 14:14, David Bird wrote:
>
> The section titled "Risk of Nuisance Captive Portal" should really be
> talking about networks that USE the API and have NO network integration (e.g.
> Captive by API only, not by any network enforcement function).
>
I think the nuisance capt
To:
Cc:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Captive Portal Interaction WG of the IETF.
Title : CAPPORT Architecture
Authors : Kyle Larose
David Dolson
Hi David,
[snip]
On 25 July 2018 at 08:59, David Bird
wrote:
> Hi Mark,
>
>
>> > What is concerning with the API and direction of the WG, is that we are
>> defining a new form of captivity … “self enforced”. Which will lead to the
>> UEs doing probing to “confirm” the API captivity matches the
As suggested at the capport group meeting, I have taken a stab at slimming
down the text related to signalling in the architecture draft. I have
submitted a pull request: https://github.com/capport-wg/architecture/pull/16
Please take a look at the pull request. Feel free to suggest anything else
e architectural.
>
> I still haven’t completely gone through the API draft you mention in II)
> below. I may come back to you on this for questions, inputs, if any.
>
>
>
> Thanks again for the quick turn-around.
>
>
>
> Thanks,
>
> Subash
>
>
>
>
r could also be the enforcement device.
However, those are design decisions for the protocol or deployment; I
wouldn't want to tie down the options in the architecture. As you've noted
it'd couple the functionality. This is certainly an option to consider
when we design the p
the packet.
>>
>> Cheers,
>> David
>>
>> See https://www.juniper.net/documentation/en_US/junos/
>> topics/concept/pcrf-pcef-ocs-interactions-understanding.html
>>
>> On Tue, Jun 26, 2018 at 5:40 PM Kyle Larose wrote:
>>
>>> During IETF
During IETF 101 hackathon I played around with a modification to the
architecture where a device adjacent to the user equipment ensures that it
is not spoofing the implicit identity used by the captive portal
deployment. This worked out pretty well.
So, the proposal is to create a second "enforcem
Thanks again Lorenzo for putting together the requirements and posting them
to the list. I'm planning on integrating them into the architecture
document in the next week.
Given the lively discussion held in response to your post, I think it's
worth re-posting the requirements, along with some edit
Are we going down the path of defining a generic solution to signalling at
the network layer with implications to upper layers of the stack? We have
ICMP for signalling, yes, but it sounds like we want to define some
properties for this signalling protocol which go beyond the wire-protocol
details
Hey everyone,
I've been trying to tackle the outstanding issues on the architecture draft.
I've focused on two so far:
* How to identify the user equipment
(https://github.com/capport-wg/architecture/issues/5)
* Making sure the API is secure
(https://github.com/capport-wg/arch
Issue number 5 (https://github.com/capport-wg/architecture/issues/5) against
the captive portal architecture raises the question of which portion of the
packet to use for capport enforcement. I have uploaded a change to the
architecture repo to attempt to address this issue:
https://github.com/
Hey everyone,
Issue #6 in the architecture draft
(https://github.com/capport-wg/architecture/issues/6)
was raised to point out that we should really mandate that the API be secure.
Basically, we want to make TLS a requirement, not a suggestion, so I've changed
the
wording around TLS to reflect
Hey everyone,
At IETF 100 in Singapore the capport working group discussed the ICMP option
for captive portals, and how to identify user equipment at the various
components of the architecture.
I've gone over the Etherpad
notes(https://etherpad.tools.ietf.org/p/notes-ietf-100-capport?useMonosp
, November 10, 2017 4:40 PM
To: David Bird
Cc: Tommy Pauly; Martin Thomson; Kyle Larose; captive-portals@ietf.org
Subject: Re: [Captive-portals] Capport at the hackathon
I am interested in participating in the hack-a-thon this weekend for
capport. I am in Philadelphia (UTC -5) so the timezone ma
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
Martin Thomson
Sent: Wednesday, November 01, 2017 8:04 PM
To: captive-portals@ietf.org
Subject: [Captive-portals] Capport at the
n extension for the case where
there are multiple IPs.
> -Original Message-
> From: Erik Kline [mailto:e...@google.com]
> Sent: Friday, October 27, 2017 4:16 AM
> To: Dave Dolson
> Cc: Kyle Larose; captive-portals@ietf.org; David Bird
> Subject: Re: client identifying info bet
nderstood by the
enforcement device?
-Original Message-
From: Erik Kline [mailto:e...@google.com]
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: captive-portals@ietf.org; David Bird
Subject: client identifying info between API and enforcement
Kyle, Dave, (D
s like NAT, here, or should we call that out of
scope? I'm thinking about my laptop behind some sort of portable router point
querying the status of the captive portal to which that portable router is
connected.
-Original Message-
From: Dave Dolson
Sent: Monday, October 16, 2017
Hey Erik, that repo is up to date. The only thing remaining is to rename the
draft. The repo also has some stuff related to the last ietf meeting. Do you
want it in the new repo as well?
-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of
Mart
I support adoption. I'd like to see it move to some conclusion.
-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of
Erik Kline
Sent: Wednesday, August 30, 2017 7:04 AM
To: captive-portals@ietf.org
Cc: martin.thom...@gmail.com
Subject: [Captive-p
Likewise, as one of the authors, I support adoption.
-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of
Dave Dolson
Sent: Wednesday, August 30, 2017 10:21 PM
To: Erik Kline; captive-portals@ietf.org
Cc: martin.thom...@gmail.com
Subject: Re: [Ca
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Friday, June 30, 2017 1:45 PM
To: Dave Dolson; Kyle Larose
Subject: New Version Notification for draft-larose-capport-architecture-01.txt
A new version of I-D, draft-larose-capport-architecture-01.txt
has been successfully submitt
I also agree that the only new component is the API server. We have extended
the responsibilities of the others, or maybe, to put it differently, tried to
solidify them (since as David pointed out, many devices were already doing many
of these things).
It looks like most of the discussion recen
I was sitting in a coffee shop on Saturday in Chicago, and decided to log in to
their wifi. It was a captive portal that basically said something like “Hey,
we’re giving you this service for free, because we’re [the coffee shop]
awesome!”. To log in I just needed to click a button to continue.
Hello everyone,
It was pointed out to me at the meeting yesterday that I hadn’t posted to the
capport mailing list the code and such that we worked on during the hackathon.
Since I encouraged people to continue hacking on it, I probably should. ☺
Here it is.
• Coova chilli: https://github.com/
Sent: Thursday, March 09, 2017 5:22 PM
To: Dave Dolson; Kyle Larose
Subject: New Version Notification for draft-larose-capport-architecture-00.txt
A new version of I-D, draft-larose-capport-architecture-00.txt
has been successfully submitted by Kyle Larose and posted to the IETF
re
ff in wireshark as a plugin? If so,
I can create a repo for you as well (though you can yourself if you want. :))
From: pro...@gmail.com [mailto:pro...@gmail.com] On Behalf Of Alexis La Goutte
Sent: Wednesday, March 08, 2017 12:58 AM
To: Martin Thomson
Cc: Kyle Larose; captive-portals@ietf.org; h
Hello everyone,
I've put up some ideas for hackathon projects related to captive portal on the
hackathon wiki
(https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=98hackathon)
* Champion(s)
o Kyle Larose klar...@sandvine.com
o Others welcome. :)
* Project(s)
o Finish u
Dolson
Sent: Thursday, February 23, 2017 9:27 AM
To: Erik Kline; David Bird
Cc: captive-portals@ietf.org; Kyle Larose; war...@kumari.net; Lorenzo Colitti
Subject: RE: [Captive-portals] Thinking of something related to captive portals
for the ietf98 hackathon
Erik,
I don’t think it is onerous.
But, the
Hey everyone,
I was thinking of doing something (anything) related to captive portals for the
ietf 98 hackathon. In particular,
https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 caught my
eye. I was wondering if anyone had thoughts on that, and whether there is
anything else th
62 matches
Mail list logo
