Lorenzo Colitti <lore...@google.com> wrote:
> If by "temporary" you mean years or decades, then yes.
It's one reason I would like standardized terminology so that, in the logs of
the device, one can see what kind of captive portal was avoided, and by what
test it was detected.
> On Mon, Apr 24, 2017 at 1:09 AM, Dave Dolson <ddol...@sandvine.com>
> wrote:
> Regarding the sacrificial queries, I would hope these are
> considered temporary measures to detect existing portals, not the
> preferred approach.
> David Dolson Sandvine
> From: Erik Kline Sent: Sunday, April 23, 2017 10:41 AM To: David
> Bird; Kyle Larose Cc: captive-portals@ietf.org Subject:
> [Captive-portals] thoughts on two documents
> All,
> I have the vague feeling that there might be some general agreement
> around the idea of having an ICMP unreachable code for captive portals
> (like an HTTP 511 code [https://tools.ietf.org/html/rfc6585#section-6]
> for ICMP :-), and it seems like there's no objection from captive
> portal implementers with respect to the basic functional elements
> captured in draft-larose-capport-architecture.
> Where I think some rough spots might lie for both of these is in
> their integration with as-yet-undecided new behaviour.
> To that point, I would like to take my co-chair hat off and ask the
> authors and the group for opinions of the following.
> [ draft-wkumari-capport-icmp-unreach ]
> There was some unresolved discussion about the contents of any
> included extension. I wonder if the extra payload parts might be
> removed (Dave Dolson's comment, I think?) and thereby simplify this
> version of the document. Given that Destination Unreachable is a TCP
> soft error (vis. RFC 5461) I'm not sure how much the proposed extra
> validation semantics are really adding.
> If the document simply said that receiving and authenticating an
> ICMP message with the capport code generically "MAY/SHOULD trigger the
> receiving node's captive portal handling subsystem", would that be
> something that folks might agree on?
> We'll need to run this whole thing by intarea and 6man as well, of
> course.
> And nothing stops us from proposing a mulit-part extension to be
> optionally included in a future document, once the captive portal
> interaction recommendations are more fully understood.
> [ draft-larose-capport-architecture ]
> I felt it was promising to hear some agreement about the functional
> elements of a captive portal system as documented.
> Given that the captive portal interaction process is still on-going
> work, would the document authors think it worth trying to advance the
> document with either (a) section 3 removed or (b) section 3 rewritten
> to describe broadly how most clients behave today? Even given the
> variety of clients I think it could be roughly captured (e.g. make a
> few sacrificial queries to trigger DNS/HTTP rewrites, keep trying until
> a sacrificial query produces an expected result while launching an
> HTTP-capable application, and so on).
> -Erik
> ___ Captive-portals
> mailing list Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
> ___ Captive-portals mailing
> list Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
