Re: [Captive-portals] Remediation url for CAPPORT

Dan Wing <danwing@gmail.com> Mon, 20 January 2020 15:06 UTC

Return-Path: <danwing@gmail.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 8358E12008C for <captive-portals@ietfa.amsl.com>; Mon, 20 Jan 2020 07:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Vap_RViTwJLQ for <captive-portals@ietfa.amsl.com>; Mon, 20 Jan 2020 07:06:02 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 1C66F12007A for <Captive-portals@ietf.org>; Mon, 20 Jan 2020 07:06:02 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id k25so15679407pgt.7 for <Captive-portals@ietf.org>; Mon, 20 Jan 2020 07:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pVDheCJm33ANC5FnwLuLsB6QtPR0yPcV8crRejdexzc=; b=eFTzKu6QS3p3RC7ShO9Yxn+BjVJt4Rj4ClqiA7MllS6yFSBDtooN9SYLQj56L/Exyj zB9joVIKeAUOM2zvPOqLmKsswb2yDadH6htkz61WKGR8Pwnw/kCC8pNezr0iN8WDJpTE n8xq7GxWPAwHZ7rI74No+x5t/cLxit9cLvCsCM846THoptunXnJH9jNtHh2s4j5iXIeg PWCXdkwmTpKG3BYJdTXU+3yX+aRt1gSRflymcQgcPggojFUvQKlCmvoi4x89feVNgf1A Fme8QxiecaFnBYoaFWfI5y3SAq+xV2U5aL6yrre0fQmBTTOTCBF2voXCDQurywvmxUdu AUoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pVDheCJm33ANC5FnwLuLsB6QtPR0yPcV8crRejdexzc=; b=VsMXh44E+oYiaFABfIPJgSnelh0+vnQBVbbFTvni3NlZQswRG60zXoBW4XFTA2OuTI cn4O8CAWJSgIOJirF9uzZrZ5NQPlKIn+XKzEPqco2dGMVv9zxSOhzb9JwpWx7y0T/1DK cInP3oWTctsTptsaizNp8CJ/En1bHzAvPkvwkFR+nHp4vDIdKIyKkI4VdO2JT4lfiITE WMEgynkBpMM6TgSvC+ijXr78bPhC6U8nZbbRbi99XoFW6mClFxuITF8SkaegBnWnDRyz X3ujQjDdHcQKUtJTG2eq10fm2JbxB/MYVgvxWnwMGA43P2BQKyUysQtkGFBbJcO7m9G9 RLNA==
X-Gm-Message-State: APjAAAVNJh7nnmwfvK495yOwu5DG3sRzugYPy1LyhlAozaSTD43Nt0O+ ugYDq2zMZ7ZKNFDLVzNgnQs=
X-Google-Smtp-Source: APXvYqw6Avm5u9Z0g44+hyjK1xanbNOSYXkIYduVg2LU3rALpbqyx1PyJhcIGjwXeoldKSAmr7t5sA==
X-Received: by 2002:a62:d407:: with SMTP id a7mr17316615pfh.242.1579532761439; Mon, 20 Jan 2020 07:06:01 -0800 (PST)
Received: from [192.168.1.53] (47-208-190-34.trckcmtc01.res.dyn.suddenlink.net. [47.208.190.34]) by smtp.gmail.com with ESMTPSA id p5sm38064827pga.69.2020.01.20.07.05.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 07:05:58 -0800 (PST)
From: Dan Wing <danwing@gmail.com>
Message-Id: <DEEF19AC-870E-4C8C-B629-CF297172F303@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFC2FD7E-1C4A-4545-8C38-F4E8C2F17A97"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 20 Jan 2020 07:05:56 -0800
In-Reply-To: <D00FBAF2-3825-4435-8426-10C300E491F2@apple.com>
Cc: ek@loon.com, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>, Heng Liu <liucougar=40google.com@dmarc.ietf.org>, Remi NGUYEN VAN <reminv=40google.com@dmarc.ietf.org>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
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>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/V5oljQUqaB0KHP86Ff47N0H5lzs>
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: Mon, 20 Jan 2020 15:06:07 -0000

To that point, the remediation URL only works if the client and the CP are in sync; that is, if the client wondered off to another network for a while (LTE, because of whatever reason) and then re-connected to WiFi, is the remediation URL supposed to be visited because the wall-clock time expired, or not visited because the time-on-network has not yet expired.  The CP may have abandoned that client, figuring it went away permanently when it disconnected from WiFi.

-d


> On Jan 13, 2020, at 5:02 PM, 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 <mailto:ek@loon.com>> wrote:
>> 
>> 
>> 
>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.ietf@gmail.com <mailto: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 <mailto:Captive-portals@ietf.org>
>> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
>> _______________________________________________
>> Captive-portals mailing list
>> Captive-portals@ietf.org <mailto:Captive-portals@ietf.org>
>> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals