Re: [Captive-portals] thoughts on two documents

Lorenzo Colitti <lorenzo@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 <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

    > _______________________________________________ Captive-portals mailing
    > list Captive-portals@ietf.org
    > https://www.ietf.org/mailman/listinfo/captive-portals

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Re: [Captive-portals] thoughts on two documents

Attachment: signature.asc