Re: [Captive-portals] thoughts on two documents

If by "temporary" you mean years or decades, then yes.

On Mon, Apr 24, 2017 at 1:09 AM, Dave Dolson <ddolson@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
>
>