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 q‎ueries, 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