Re: [Captive-portals] Remediation url for CAPPORT
Remi NGUYEN VAN <reminv@google.com> Mon, 20 January 2020 03:30 UTC
Return-Path: <reminv@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 50A7C120026 for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 19:30:49 -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 yiOO1OeE56t6 for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5AC48120024 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id t8so26113280iln.4 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 19:30:45 -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=LcPnmaJFPkkpAY5FK9a/hXniFgp375rcE19I3GwdS5U=; b=NhRQskLEPZadPB+JugE8GJeWPNZJKTab2s0xa7R5ftoiGvcRNDvpPN5UpUDAXuVAwC wYkdn1/hDk7DhIIXEa0b3zDfVd8MohYeFwwNjIN83uhk1txP2mcEDLV22Eb2hAKag7B1 jGrpZm6Qf7hnvXsgOC2hSjlcCYznF/7YwDvNC6y1/NDjeyIPfXBg/iz36lxYVAaQMX6V rzicfGgk3p1FZkrsSUNaZYpcLSUyT1VX2S5slJ60cj0G4n7gqJhgxJY7AJwvir4vikNm +4FBM5S15yRmfJEZYqJo+xhPYRR853gwVZr9+gOhL8lxS8rFbeNp15PFeYl5E8JYInRQ NLFQ==
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=LcPnmaJFPkkpAY5FK9a/hXniFgp375rcE19I3GwdS5U=; b=rSX/hF+XNlVpUYjLA4bLxII4FNLB9E7sA69maUYbJo4U6xIuL4vpFYNqb/But3pdcv 5DEspNX6rI5CCL2rG38V3CKPoFp4sy4HSLj1VDG1f96EjJrvCzoZjHACdksn87xuG5Cx NiVMJqf+WVyFKpc/zwdhPK15BlvV6ed+FnFGLf9pS3RgmzwW2ISvlXeF4qBpSzPBDmQn gqkWzd/xz5JxBK2BiXYMCjFhq8pBb6m+8zX3fVDiyuOMD5SSKIDu3dM0PSudfiXTe29z CwbVozGgmIoSOloRc86KPz+Op0rFmyQ8uEgAVXVOaJd2Vxz2cJZaX/Q03dF37LwhwNo6 uHHw==
X-Gm-Message-State: APjAAAVhtwuD1mRD0bmk0NdnQiW1zcbp99r3aWaPNkcPdZ5vvMVTTC7j l/39j8nnWsXg5MUkAaF//rjk/S5GwyiiPgyKmO1g5A==
X-Google-Smtp-Source: APXvYqwvXTujlfg2PFABI/G3wmZeCSC+rm9bZfNQDRJdOnCp1SmDEd6wv3Vu7HyJcBVrtiVONgkvIy7rBJAvtyreHvU=
X-Received: by 2002:a92:8d8e:: with SMTP id w14mr8767742ill.187.1579491044421; Sun, 19 Jan 2020 19:30:44 -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> <CAKMty=JqBHb3fqrBy1yhrfxuJVMATP=HByD+bxRezKUN5WYqQA@mail.gmail.com> <CAAedzxpXPdUw+LpfLK15T1YRghSO973pHUaQZQara5GH1QYiPA@mail.gmail.com> <CAKxhTx_8Bik5HnCae4OtYv7Q0gtv7bmKY3PamQN4aGb=S0V7dw@mail.gmail.com> <40F3E8F6-AB27-4F7E-A751-B6C7FB985457@apple.com>
In-Reply-To: <40F3E8F6-AB27-4F7E-A751-B6C7FB985457@apple.com>
From: Remi NGUYEN VAN <reminv@google.com>
Date: Mon, 20 Jan 2020 12:30:33 +0900
Message-ID: <CAKxhTx8aJgLN2dSqKsf9WNWNLtm=UykmvjVizw5UfEu_vjQVzw@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: Erik Kline <ek@loon.com>, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>, Heng Liu <liucougar@google.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000a8244a059c89eaa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/1UUBD-eEMy9ZxcGAEQ-8Z-BvEh0>
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 03:30:49 -0000
I also thought "remediation-supported" was not ideal but could not come up with a better name. "can-extend-session" does sound clearer to me. Cheers, Remi On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly <tpauly= 40apple.com@dmarc.ietf.org> wrote: > I'm fine with adding the boolean to the main draft. I discussed this a bit > with Heng yesterday, and we discussed naming it something like > "can-extend-session". Thoughts on that name? > > Thanks, > Tommy > > On Jan 16, 2020, at 11:25 PM, Remi NGUYEN VAN < > reminv=40google.com@dmarc.ietf.org> wrote: > > As far as the Android implementation is concerned, I think it would be > nice to have capport API support in the next (android R) version; however > due to deadlines, it's going to be harder for me to change the attributes > read from the API very soon. > Following this discussion my current plan is to support an optional > "remediation-supported" boolean, and only prompt users to extend their > session shortly before it expires when it is set to true. Hopefully the > boolean can be added to the current draft or in a future, separate draft > considering that we seem to roughly agree on it, but if the group > eventually realizes that it wants to go in another direction, we'll update > behavior in subsequent releases. > > Does that make sense ? > > Cheers, > > Remi > > On Wed, Jan 15, 2020 at 9:30 AM Erik Kline <ek@loon.com> wrote: > >> If there's working group consensus to add it to the current API draft >> then definitely add it. Otherwise, probably a separate document that would >> need a call for wg adoption. >> >> Separately, and hopefully without starting a massive bikeshed, is there a >> more apt word than "remediation"? I think this specific word carries the >> connotation of "fixing an error" or "correcting damage" and it seems like >> the use here would be broader. But perhaps I'm completely mistaken. >> >> On Tue, 14 Jan 2020 at 16:21, Heng Liu <liucougar@google.com> wrote: >> >>> 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 >>>>> >>>>> >>>>> >>>> _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > >
- [Captive-portals] Remediation url for CAPPORT Heng Liu
- Re: [Captive-portals] Remediation url for CAPPORT Remi NGUYEN VAN
- Re: [Captive-portals] Remediation url for CAPPORT Erik Kline
- Re: [Captive-portals] Remediation url for CAPPORT Heng Liu
- Re: [Captive-portals] Remediation url for CAPPORT David Bird
- Re: [Captive-portals] Remediation url for CAPPORT Erik Kline
- Re: [Captive-portals] Remediation url for CAPPORT Tommy Pauly
- Re: [Captive-portals] Remediation url for CAPPORT Remi NGUYEN VAN
- Re: [Captive-portals] Remediation url for CAPPORT Tommy Pauly
- Re: [Captive-portals] Remediation url for CAPPORT Heng Liu
- Re: [Captive-portals] Remediation url for CAPPORT Erik Kline
- Re: [Captive-portals] Remediation url for CAPPORT Remi NGUYEN VAN
- Re: [Captive-portals] Remediation url for CAPPORT Tommy Pauly
- Re: [Captive-portals] Remediation url for CAPPORT Remi NGUYEN VAN
- Re: [Captive-portals] Remediation url for CAPPORT Lorenzo Colitti
- Re: [Captive-portals] Remediation url for CAPPORT Tommy Pauly
- Re: [Captive-portals] Remediation url for CAPPORT Michael Richardson
- Re: [Captive-portals] Remediation url for CAPPORT Martin Thomson
- Re: [Captive-portals] Remediation url for CAPPORT Martin J. Dürst
- Re: [Captive-portals] Remediation url for CAPPORT Dan Wing
- Re: [Captive-portals] Remediation url for CAPPORT Tommy Pauly