[Captive-portals] Remediation url for CAPPORT

Heng Liu <liucougar@google.com> Fri, 10 January 2020 06:46 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 5ED411200B3 for <captive-portals@ietfa.amsl.com>; Thu, 9 Jan 2020 22:46:09 -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 1y7BAtsOiX7G for <captive-portals@ietfa.amsl.com>; Thu, 9 Jan 2020 22:46:05 -0800 (PST)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 B4381120142 for <Captive-portals@ietf.org>; Thu, 9 Jan 2020 22:46:02 -0800 (PST)
Received: by mail-vs1-xe2b.google.com with SMTP id k188so623716vsc.8 for <Captive-portals@ietf.org>; Thu, 09 Jan 2020 22:46:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cQkvngbvaU8heYtHWOtiuaMQCbZvJ38f/aUYi+IDAik=; b=bY6m3/2OoBUQx67CvmwgMl+kJ+KM2XEAPpmI+jF6t7hb/8qd85c8Y9dkhp42rOrgWa tepHnr/M8a0WfpcCZQWmzvLzUUHxsR5YXhPBLB45f7ec9PyYH2LL0Vm2KksVPVPsvBZU 2enVFfwgLaAAMbR5qd3UfvdisSwO9bUcR7q+7owdxts1PtjMsdJjsahU7QLaCOfjhS5k JgPaYMMSQ0w38QE2lItxb/kS3cNVNGZtQ/dw8uoVzNoTVKmcC1TLMhiwImTGrNTUS6t8 asTdC9gJbkwkkSAzZspVsnwnNaa72WcxP6ljdxD9VrUPtW7iSQJNO9/dp2f93GYHxXOT hEwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cQkvngbvaU8heYtHWOtiuaMQCbZvJ38f/aUYi+IDAik=; b=UyW3zY7b7Wfy+MAMe2gnRY0sa6dHW9QGWZWZPzjuwLPoOeiRJFfBfAraZrpMmKtppE +SqKEDflDjje0Oifpon/8UWERvTDXY7BJBX4zRnw8710TWYnjwBbYjYhRIZDjcqMQaW/ hPLgnQIfkqP5MnT0o0HMCa3uPJ79F8U0V1GmIbKbZ8GG2uaXS11XZ7H3EMih7iJgwgmr Hyix/NYpOtrrcUCDw7804hkn9BEExu/dvb6yjdV+HsZAM9h1ZW4sNKqopcROjkCOjRSo LmBHAlTyYxpTO7aJjD7X/rMdb+foqX247mTQco2FgKBwJc+u/9S1VwyGqrVxY1pJhAgD tpyQ==
X-Gm-Message-State: APjAAAWAnZ8htY4G/P9Hc0Vta/BpWv6lSmcJoY+j9KrZ4sWvNzlhgZKR 6OGz33nb5aY6KjkZc7lri3QzG5hcbqVpcvJB7BSd/BO2oNE=
X-Google-Smtp-Source: APXvYqyXbGa4zq/O8GdCZGnNzZaTtrlCAPe/QlMxO6sy6c5eU0KSLlDPPyWV+PFj7rj0OIkoj7vJON/jSQ0urNo6MpY=
X-Received: by 2002:a67:7795:: with SMTP id s143mr861655vsc.227.1578638761319; Thu, 09 Jan 2020 22:46:01 -0800 (PST)
MIME-Version: 1.0
From: Heng Liu <liucougar@google.com>
Date: Thu, 09 Jan 2020 22:45:50 -0800
Message-ID: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com>
To: Captive-portals@ietf.org
Content-Type: multipart/alternative; boundary="000000000000993bea059bc37a0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/gH4EbMPztq4pazGu5X4I4752xJs>
Subject: [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: Fri, 10 Jan 2020 06:46:09 -0000

Hi all,
In some captive portals, it's possible to extend (or remediate) an existing
session without losing connectivity. This use case is covered in the
CAPPORT architecture draft:

4.2.  Conditions About to Expire

   This section describes a possible work-flow when access is about to
   expire.

   1.  Precondition: the API server has provided the User Equipment with
       a duration over which its access is valid

   2.  The User Equipment is communicating with the outside network

   3.  The User Equipment's UI indicates that the length of time left
       for its access has fallen below a threshold

   4.  The User Equipment visits the API again to validate the expiry
       time

   5.  If expiry is still imminent, the User Equipment prompts the user
       to access the web-portal URI again

Step 5 in the above section suggests UE visit the user-portal URI again.

However, not all CP provides a way to extend sessions. In order to provide
a positive signal that extending session is possible, what do you think if
an optional remediation-url field is introduced in the API JSON file please?

CP provider can set this to the same URL as the user-portal-url if they
want, or they can provide a different URL, If present, then in the Step 5
above, the remediation url will be used.

The presence of this url is a positive signal to the UE that extending a
session is possible in this captive portal.

Our user research in many markets on Captive Portals indicates that many
users dislike having their connection interrupted (e.g., in the middle of a
call, download, stream). For operators who are willing to offer a way to
extend without an interruption, this is an improvement to the user
experience.

This remediation-url is similar to the "subscription remediation" mechanism
outlined in Passpoint (Hotspot 2.0) Release 2:

In the Passpoint Release 2.0 Spec, page 71 "8.1.3 Subscription remediation"
section:

For the purposes of this document, the term “remediation” refers broadly to
the process of fixing a problem in the subscriber’s subscription; this
definition includes provisioning updated credentials to a mobile device,
updating the PerProviderSubscription MO on a mobile device or performing
some online function to update the subscription (i.e., no new
credentials/data are provisioned to the mobile device).

On page 72:

There are two classes of remediation: machine and user remediation:
• Machine remediation means the problem(s) with the subscription can be
remediated
without any user intervention.
• User remediation means the problem(s) with the subscription requires user
intervention.

On the same page 72, in section "8.1.4 Subscription management web
content", it states a web page could get more info from a user if "user
remediation" is needed.

regards
Dr. Heng Liu