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

[David Bird <[e-mail]>]

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.

Cheers,
David




On Sun, Feb 4, 2018 at 3:02 PM, <[e-mail]> 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
>
> Abstract:
>    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:
> https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-capport-api-00
> https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-00
>
>
> 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:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>