Re: [Captive-portals] Remediation url for CAPPORT

Heng Liu <liucougar@google.com> Wed, 15 January 2020 00:21 UTC

Return-Path: <liucougar@google.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B412006D for <captive-portals@ietfa.amsl.com>; Tue, 14 Jan 2020 16:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_voqdvPDEJI for <captive-portals@ietfa.amsl.com>; Tue, 14 Jan 2020 16:21:01 -0800 (PST)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D32120046 for <Captive-portals@ietf.org>; Tue, 14 Jan 2020 16:21:00 -0800 (PST)
Received: by mail-vk1-xa36.google.com with SMTP id d17so4196753vke.5 for <Captive-portals@ietf.org>; Tue, 14 Jan 2020 16:21:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8V7+/OcITgePiGgVE/tOmVZeYssJYC99mYCupWxcaiY=; b=myLL1Za8SbTWhNLRlNTLA9/wmNnRVYXAaHdYeHfrd+rGTqfJrTldLoVDPOdRM56LKr jypszfe3oxIR+xZtQu00kZWBlCCozMA4l7IpqYilrWYQp2uh66bo+ygfJn4XIYA/f1+E SSl13nPl/BL/QYhIstY397wZSRYza7hayDMRn87KLtMPTvcvJiM+vlq1xSHicqNqsn7e mX5Bc3RralI2l4RJKGbZkTgtawjDIhA/Ji/p6JTNbaHzKwg9J2HwbPl1AwVb6GmzcJgV HzD6GrELWYeJJWcFPGK0s2n0J3C206IttHCx1v0VQA3fKFz4S6e19jD7WkEtsBG65B7j kGoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8V7+/OcITgePiGgVE/tOmVZeYssJYC99mYCupWxcaiY=; b=kphpxr5sLGN3fRD+/P1BZcgfPiAMfyAIwNjUHAVEfi5N5Vk+cGFP0mANDHdpKuzagg uWR1c1dFfl5rtC7GGAxK3rMCui0gQ1+OwREXLyqWiC6bIAoN7FEsvKStw0yxRnX3QXB5 soSN7mJHpsghY0Yzkyt3PisCvHR8xNebKmyLbg1VjEN8hPyhX8vsPc68XCp8Hy5WQaHl 3Xb4xzR4RuYTVS6Ia8DX89emlzZu73zORpSyuOW/+D9LSWsJ0rBB+8Hkp90iZe32Blai cEBcQzZTu8xNSpvVSdkaQx72Zw0DB5pnMxw5u2Giiw0Z3CNw0wEjzPWnMw9ZpVHpAU5S DTaw==
X-Gm-Message-State: APjAAAXhWUusYXpklP3gl8uIX1GSM1SL7bRiTXaugtCHN+cJ5CmLD7Wn OAtl39eD9lMmaxQHhByhQJTLYy3cm0adh37YfuGWxQ==
X-Google-Smtp-Source: APXvYqx+9nsNSjrCvVlh840gbUZnRxnPRfmfo5L9J0cX+FpgvfqToQpmuU7hvzGgLY7hnm4JG0+9OJx4tHGt8Hrf9hE=
X-Received: by 2002:a1f:7c0c:: with SMTP id x12mr12342419vkc.41.1579047659723; Tue, 14 Jan 2020 16:20:59 -0800 (PST)
MIME-Version: 1.0
References: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com> <CAKxhTx_uaZVFs4VhM+nro61XxTjPtwZ+pZ_gsJtNQXiNHtf2vQ@mail.gmail.com> <CAMGpriX1ct9y53HZ2FtbK00TfVm3uNRFMwYQW0Wb_18XoXjFJw@mail.gmail.com> <CAKMty=KhYr4XfJWzXeBiod1oiyG-qVp7-ANKJaZF1-_nPZhrTw@mail.gmail.com> <CAAedzxocTUhQ-z+_Cpz8PhG=o3CR4aZHOGddngiEjZ1HZChP1A@mail.gmail.com> <D00FBAF2-3825-4435-8426-10C300E491F2@apple.com> <CAKxhTx9g3WrKM=BP2fifv08CVcMrZvhuvnZjapb3ugN=WX1fhg@mail.gmail.com> <DBEFCCF8-0677-490F-A305-14C880B3DC7A@apple.com>
In-Reply-To: <DBEFCCF8-0677-490F-A305-14C880B3DC7A@apple.com>
From: Heng Liu <liucougar@google.com>
Date: Tue, 14 Jan 2020 16:20:48 -0800
Message-ID: <CAKMty=JqBHb3fqrBy1yhrfxuJVMATP=HByD+bxRezKUN5WYqQA@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: Remi NGUYEN VAN <reminv=40google.com@dmarc.ietf.org>, Erik Kline <ek@loon.com>, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7f259059c22aef1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/juv_LX__gUDGygkwtL9aeIe6q5c>
Subject: Re: [Captive-portals] Remediation url for CAPPORT
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 00:21:03 -0000

It seems most are comfortable with adding a remediation-capable boolean,
which is simpler than another url while also making it explicit on whether
remediation is provided or not, so UE could display different notifications.

Anyone have any objections on adding this boolean please?

If not, what's the next step on moving this forward please?

Thanks,
Heng

On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly <tpauly@apple.com> wrote:

> Any captive portal that is newly adopting the CAPPORT API will hopefully
> be testing the setup in the new model, and will have to think about which
> URLs to map to different user experiences.
>
> A page that only says "you're logged in!", and has no way of adding more
> time, etc, is in my opinion a relatively useless page. If we provide a
> separate URL for remediation, it would seem to encourage such a design. Not
> including this would hopefully urge the portal design to a cleaner model.
>
> I do think the boolean is nice for highlighting to the captive portal
> deployer that they should think about remediation. I'd be more ok with that
> model, although it could also be an extension as we gain experience in
> deployment.
>
> Thanks,
> Tommy
>
> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN <
> reminv=40google.com@dmarc.ietf.org> wrote:
>
> If we show prompts to the user shortly before the session expires, we'd
> like to make sure that we can redirect them to some page where they can fix
> the problem, instead of landing on a page saying "you're logged in". The
> user-portal-url would work fine with a remediation-supported boolean for
> that purpose; having a separate URL gives additional flexibility to the
> access point operator, but from the point of view of the client I think
> both are fine.
>
> Cheers,
>
> Remi
>
>
> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly <tpauly=
> 40apple.com@dmarc.ietf.org> wrote:
>
>> I have a similar initial reaction to Erik's. Adding another URL that
>> effectively is just another user portal, but meant to be used at certain
>> times, adds a lot of complexity. I'm certainly not ruling out adding such a
>> key as need arises, but I'd hesitate to make it part of the initial set.
>>
>> Particularly, if we start seeing the "venue URL" be the main landing page
>> we redirect people to once they're logged it, it kind of makes sense to let
>> the user portal be the status/remediation/payment page.
>>
>> Tommy
>>
>> On Jan 13, 2020, at 4:06 PM, Erik Kline <ek@loon.com> wrote:
>>
>>
>>
>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.ietf@gmail.com> wrote:
>>>
>>>> Why should this different from the user-portal-url?  It seems to me
>>>> that either the user-portal-url would remediation UI elements or it
>>>> wouldn't.
>>>>
>>> Some CP vendors want to specify a different URL specifically tailored
>>> for remediation of a session. By providing a 3rd URL, we can accommodate
>>> this use case.
>>>
>>
>> If the remediation URL is available but the user (somehow) navigates to
>> the user-portal-url, what do they see?
>>
>>
>>>
>>>> With this 3rd URL, if the bytes/time does expire should the OS try to
>>>> launch an interaction the remediation URL and then fallback to the user URL
>>>> if it failed to load?  In which case, why not just leave all interaction
>>>> with the user-portal-url?
>>>>
>>> if a remediation URL is present, and if it fails to load for whatever
>>> reason, no need to fallback to user portal URL: CP vendor should make sure
>>> the remediation URL is working properly (this is similar to user-portal url
>>> should work properly, if not, there is no other way for user to clear a CP)
>>>
>>
>> I guess I'm just trying to be mindful of one person's flexibility is
>> another person's complexity.  I think this just doubles the number of URLs
>> that the CP vendor needs to make sure function correctly.
>>
>> If the vendor doesn't implement a means to extend your session without
>>>> completely shutting everything down and forcing to the user to restart the
>>>> interaction flow anew, I could see that an OS would not want to bother the
>>>> user with an interaction where they couldn't actually do anything useful.
>>>> But that might suggest a boolean capability, rather than a new URL
>>>> (remediation-supported={true|false})?
>>>>
>>> A boolean field could also be a positive signal to notify UE that
>>> remediation is possible, but this would prevent CP vendors from using
>>> different URLs for remediation.
>>>
>>> (As mentioned in the initial thread, this URL approach is also taken by
>>> the Passpoint release 2.0 spec to signal remediation process.)
>>>
>>> regards,
>>> Heng
>>> _______________________________________________
>>> 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
>>
>>
>>
>