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

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

Thanks Darshak and Tommy, this is really helpful. 

Some comments:

In 2. Workflow: Does it make sense to reorder 2) and 3)? It would seem 'Enforcement' should come before determining status (of said enforcement) and how to proceed. I would argue that the UE might as well try to use the network and wait for the network to respond (e.g. with Enforcement and/or routing notifications/errors. Indeed, the UE sorta already *did* this if it resolved DNS and checked certificate status of the API server hostname. 

In 3.1 URI of Captive Portal endpoint, I think we must go beyond making TLS a MUST --- we need to define how trust is handled. We must require the API client to validate the hostname, present that hostname to the user for acknowledgement. Or, are we explicitly saying that TLS is for privacy and not security? (e.g. that we really don't care what the server cert is... just that the cert is consistent for that location / domain?). Is the client expected to check revocation lists?

In 3.2, ' "permitted" (required, boolean): indicates whether or not the Captive Portal is open to the requesting host ' is confusing... does it mean the UE is subject to a captive portal?  I dislike how boolean this is! Why does it have to be all or nothing (especially if ICMP is providing enforcement notification?) 

Also in 3.2, I'm not sure about the time/data remaining info.. Is the expectation that the client keeps polling? (never goes idle on any network?) Is the expectation that the UE  will break connections after it sees this API expire timer or counter, or shall the (smart) UE wait until the network notification (ICMP) ?

I think it would be idea to keep ICMP focused on network notification and we can use the API more for validation and improving the security (and user interaction) of ICMP. 


On Sun, Feb 4, 2018 at 3:02 PM, <[email protected]> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Captive Portal Interaction WG of the IETF.

        Title           : Captive Portal API
        Authors         : Tommy Pauly
                          Darshak Thakore
        Filename        : draft-ietf-capport-api-00.txt
        Pages           : 6
        Date            : 2018-02-02

   This document describes an HTTP API that allows hosts to interact
   with a Captive Portal system.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

Captive-portals mailing list
[email protected]