[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt



Lorenzo Colitti <[email protected]> wrote:
    > Over the years on this list we have seen many use-cases come
    > through, I recall:

    > - A school/library network that allows most of the Internet,
    > but captures and redirects for certain networks / sites
    > - A network allows all sorts of protocols - IMAP, HTTPS, for
    > example - but not others - like HTTP, SMTP - and want to
    > redirect / signal portal

    > - A network that allows all Internet traffic, but just at a
    > low QoS tier. No "captive" portal, but a portal is yet
    > available for upgrading tier
    > - Any network that allows a large walled garden, or even a
    > *very large* garden, but otherwise has a captive portal

    > - A network that will 99.99% of the time allow all traffic,
    > but will (perhaps because of virus detection) interrupts
    > sessions into captive state [technically, this is a "boolean"
    > use-case, but one where polling would just be huge noise]

    lc> I don't see why you would want to signal any of these to the UE,
    lc> because they're not really actionable. Even if the UE distinguishes

Not actionable by an UE.
Might other things care?

Is it useful for diagnostics?
(Why doesn't webrtc work here?)

    lc> between these categories, application developers are likely not going
    lc> to want to do so and in the main are going to do whatever the UE
    lc> decides to do. As Martin says, the human using the UE might be
    lc> interested (e.g., in the upgrading case), but that's not hard to do by

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature