Do please let us know if there are broadly applicable lessons/advice here.
Thanks!
On Tue, Jul 19, 2022 at 12:48 PM Tommy Pauly wrote:
> 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
On Tue, Sep 1, 2020 at 9:49 AM David Dolson wrote:
> How do such devices obtain IP addresses?
>
>
In IPv4, this would be NAT. The first host to connect would probably pass
the captive portal for all other devices, but only because of the
HTTP-intercept technique. No clients would see the API
definitely be in
this set.
On Mon, Aug 31, 2020 at 10:43 PM Martin Thomson wrote:
> These cases, along with the very common case of a router that is
> on-premises and sits between an ISP and a local network, were discussed,
> but I don't recall ever reaching a conclusion.
>
> On Tue, Sep 1, 2
I fail to see how this is good for general purpose nodes/user devices.
This seems like another way to do the "self-DPI" work that was
shopping around for a home a little while ago. I mean, it all just
seems like something that in the end can be abused to limit client
behaviour, dressed up as
On Fri, Jul 3, 2020 at 1:27 PM Michael Schneider
wrote:
>
> Hi,
>
> I have read the documents about CAPPORT and as a Captive Portal vendor I find
> the current drafts very reasonable and well thought out. But a question came
> up when I was thinking about a dual stack user equipment. How does
On Sat, Jun 6, 2020 at 7:54 PM Martin Duke wrote:
>
>
>
> On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly wrote:
>>
>>
>>
>> I believe in this case the architecture document needs to change, or clarify
>> that this MUST refers to that the mechanism needs to be *able* to
>> communicate such a URI,
> -- Section 2.2 ==
> In "should not be provisioned", I would suggest to use the normative "SHOULD".
Good catch. Done.
> == NITS ==
>
> -- Abstract --
> Not all users of a captive portal are 'customers', they can be guests,
> students, employees, ... suggest to use 'users' (and even in the world
Tim,
Thanks for taking the time to read and comment. Replies inline below
and changes made at https://github.com/capport-wg/7710bis .
On Thu, May 14, 2020 at 7:30 AM Tim Chown via Datatracker
wrote:
>
> Reviewer: Tim Chown
> Review result: Has Nits
>
...
>
> General comments:
>
> The security
-05 uploaded, but I see now I need to do an -06 for the IANA comments.
On Wed, May 13, 2020 at 10:29 AM Erik Kline wrote:
>
> Forthwith!
>
> On Wed, May 13, 2020 at 9:29 AM Barry Leiba wrote:
> >
> > Erik, is there a revised I-D coming for this?
> >
> > Than
Forthwith!
On Wed, May 13, 2020 at 9:29 AM Barry Leiba wrote:
>
> Erik, is there a revised I-D coming for this?
>
> Thanks,
> Barry
>
> On Mon, May 11, 2020 at 1:09 AM Erik Kline wrote:
> >
> > Gah! Sorry, I didn't mean to imply that the conversation should b
Gah! Sorry, I didn't mean to imply that the conversation should be
moved there. Only pointing to text-in-progress for your review.
On Sun, May 10, 2020 at 10:08 PM Erik Kline wrote:
>
> For the record: trying to improve text over on
> https://github.com/capport-wg/7710bis/pull/31 .
&
with an IP address instead of the
> > > > hostname
> > > > of the API, and in that case the user should be extra cautious when this
> > > > happens.
> > > >
> > > > Regards,
> > > > Rifaat
> > > >
> > &g
t were, I would suggest a citation.
>
> On Mon, May 4, 2020, at 07:58, Erik Kline wrote:
> > Rifaat,
> >
> > Thanks for your reading of the document.
> >
> > The security section has a paragraph that begins:
> >
> > """
> > An attack
gt;
> Good to know it is already taken care of.
>
>
>
> Hi Erik,
>
> Thanks, but it would be very handy next to the TLV formats (-:
>
>
>
> Thanks,
>
> Subash
>
>
>
>
>
> *From: *Captive-portals on behalf of
> Erik Kline
> *Date: *
And the 255 byte URI limit is mentioned in section 2 (~3rd paragraph).
I guess if someone wants longer URIs they have to move to an IPv6-only
network. ;-)
On Mon, Apr 27, 2020 at 3:54 PM Martin Thomson wrote:
> Thanks for the input. Apparently great minds think alike as another
> reviewer
Barry,
Thanks for the prompt review.
On Thu, Apr 23, 2020 at 9:18 PM Barry Leiba wrote:
> Good work on this, folks: a nice improvement on 7710, and let’s hope for
> wider deployment. Some comments below; I think we should have a quick
> revised I-D before we go to last call, mostly because of
Fellow capport-ians,
https://datatracker.ietf.org/meeting/107/agenda.html
https://datatracker.ietf.org/meeting/107/agenda.txt
We are currently scheduled for a 1 hour session on Thursday at 17:40.
The agenda will mostly likely be similar to previous agendae
chair,
so it'd be nice to get this wrapped up.
On Wed, 12 Feb 2020 at 07:55, Warren Kumari wrote:
>
> Checking in to see if the sync occurred...
>
> W
>
> On Wed, Feb 5, 2020 at 1:08 PM Erik Kline wrote:
> >
> > Martin and I have a sync scheduled to talk
Martin and I have a sync scheduled to talk about this (among other things).
On Tue, Jan 28, 2020 at 2:18 PM Warren Kumari wrote:
> Dear CAPPORT Chairs,
>
> I believe that Captive-Portal Identification in DHCP / RA
> (draft-ietf-capport-rfc7710bis) has addressed all open comments, and
> would
All,
We're thinking of requesting a meeting slot, given that every time we
haven't requested one we've met anyway. By default I was going to request
a one hour slot. If folks think we need more time let me know.
Between now and then it'll be a good time to burn down the open github
issues and
;> key as need arises, but I'd hesitate to make it part of the initial set.
>>>
>>> Particularly, if we start seeing the "venue URL" be the main landing
>>> page we redirect people to once they're logged it, it kind of makes sense
>>> to let the user
On Mon, 13 Jan 2020 at 15:26, Heng Liu wrote:
> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline wrote:
>
>> Why should this different from the user-portal-url? It seems to me that
>> either the user-portal-url would remediation UI elements or it wouldn't.
>>
> Some
Why should this different from the user-portal-url? It seems to me that
either the user-portal-url would remediation UI elements or it wouldn't.
With this 3rd URL, if the bytes/time does expire should the OS try to
launch an interaction the remediation URL and then fallback to the user URL
if
sounds good. I'll patch that in and upload a -01.
On Fri, 10 Jan 2020 at 16:00, Warren Kumari wrote:
>
>
> On Fri, Jan 10, 2020 at 12:19 PM Tommy Pauly wrote:
> >
> >
> >
> > On Jan 2, 2020, at 6:24 PM, Erik Kline wrote:
> >
> > 111 or 114 pen
111 or 114 pending approval from Apple both seem fine to me.
I'll add an Appendix C with a brief summary of the 160 polycom experience
for posterity.
On Thu, 2 Jan 2020 at 14:33, Warren Kumari wrote:
> On Thu, Jan 2, 2020 at 2:29 PM Tommy Pauly wrote:
> >
> > One option we have is to use Code
I copied these minutes into the github repo. The slides we used are also
uploaded there as well:
https://github.com/capport-wg/wg-materials/tree/master/ietf106
___
Captive-portals mailing list
Captive-portals@ietf.org
On Sun, 17 Nov 2019 at 12:03, Michael Richardson wrote:
>
> Christopher Morrow wrote:
> > During setup at the IETF meeting this week in Singapore the noc folk
> > setup an experiment on the IETF wireless network, specifically on the
> > IETF SSID to test your shiny new DHCP
times?
>>
>> Thanks,
>> Tommy
>>
>> On Oct 29, 2019, at 3:47 PM, Erik Kline wrote:
>>
>> (let me try again with reply-all :-)
>>
>> On Mon, Oct 21, 2019 at 8:42 AM Tommy Pauly > 40apple@dmarc.ietf.org> wrote:
>>
>>
(let me try again with reply-all :-)
On Mon, Oct 21, 2019 at 8:42 AM Tommy Pauly 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 folks think we should attempt to get an informal
at all? The problem with is that it cannot be used
> once the portal is open, so if the device logs in, and then disconnects and
> reconnects, it doesn't work.
>
> On Wed, Sep 4, 2019 at 10:05 AM Erik Kline wrote:
>
>> Chair hat off, co-author hat on.
>>
>> We c
Chair hat off, co-author hat on.
We can certain craft some text to round out
https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4 when
the time comes. Certainly DHCP/RA would retain highest precedence.
RFC 7553 URI records would obviate the inevitable discussion about the
I forgot to forward this after uploading the -03.
This version has some more text about the link relation alternative.
-- Forwarded message -
From:
Date: Mon, 11 Mar 2019 at 14:09
Subject: New Version Notification for draft-ekwk-capport-rfc7710bis-02.txt
To: Erik Kline , Warren
> I will not be surprised if there is nothing that satisfies my needs
> and is still capable of dealing with portals.
Can you clarify what "dealing with" means here for you?
Automatically interacting with a portal? (e.g. clicking agreement
checkboxes, filling in email addresses or facebook
I propose that this time we'll just meet informally.
There are some administrative things we might bring up, but otherwise
leave it open for discussion.
-Erik
On Mon, 22 Oct 2018 at 14:53, Erik Kline wrote:
>
> All,
>
> We currently have a 1 hour slot scheduled on Thursday afte
The point about UDP was primarily that the key attribute is the ability to
receive an unsolicited packet, not that it was better than ICMP.
On Thu, 17 May 2018 at 17:10, Warren Kumari <war...@kumari.net> wrote:
> On Thu, May 17, 2018 at 10:00 AM Erik Kline <e...@google.com> wrote:
I was unable to make it to London, but I was able to watch the session
on Youtube. The ICMP discussion begins here:
https://www.youtube.com/watch?v=tavhoXNVcP8=1h12m5s
and carries on until Darshak's presentation starts at t=1h45m35s (a
good 30+ minutes).
My reading of that portion of the
; safe travels,
-Erik
-- proposed agenda --
CAPPORT Working Group
IETF 100
Singapore
2017-11-14
15:50-17:50 Tuesday Afternoon session II
Chairs: Erik Kline, Martin Thomson
Materials: https://github.com/capport-wg/wg-materials/tree/master/ietf100
Agenda (proposed)
Administrivia 5
s I'm not sure if this is necessarily a great
idea. But I'm also not sure I see another way by which this could
work for architectures where the enforcement point might not have
direct link layer knowledge of attached clients.
>> -Original Message-
>> From: Erik Kline [mai
> -Original Message-
> From: Erik Kline [mailto:e...@google.com]
> Sent: Friday, October 20, 2017 9:39 AM
> To: Dave Dolson
> Cc: Kyle Larose; captive-portals@ietf.org; David Bird
> Subject: Re: client identifying info between API and enforcement
>
> With t
I wanted to poll the group's thoughts on the usefulness of the
rfc6585#section-6 511 HTTP status code.
Has anybody tried to serve 511s to clients, and if so what were the results?
Might it be useful to serve an API endpoint (rather than the full-blown
HTML UI)?
I'm trying to get a sense of
On 10 April 2017 at 12:07, Mark Nottingham <m...@mnot.net> wrote:
>
> > On 10 Apr 2017, at 12:53 pm, Erik Kline <e...@google.com> wrote:
> >
> >
> >
> > On 8 April 2017 at 04:54, Michael Richardson <mcr+i...@sandelman.ca>
> wrote:
> &g
>
> I think the client should, ideally do:
>
> - Use the network for all connections (why ask permission when
> forgiveness is cheap).
>
Not gonna happen. Mobile clients do a ton of work to enable "make before
break". There is no such thing as forgiveness from users who can't get
Facebook
42 matches
Mail list logo
