On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:

> We've had a number of discussions in the captive portals group about
> fixing RFC 7710.
>

Fixing or make RFC7710 more useful ?


>
> Erik and I would like to propose a plan for that work.  We would keep
> this to addressing the issues that we have identified thus far.
> Namely:
>
> 1. The purpose of the URI is not well defined.  We would reference the
> capport architecture and API documents for that.  The group would need
> to decide between:
>   a. point to the API
>   b. point to a login page
>
>
Our (or at least my thought) was in the beginning,
just send the device to the location of the portal, as I hate having
connections intercepted.
Then the USER could just see that page and decide what to do.

Now you are taking that basic idea forward to allow a handshake between
device and portal ; this is good
Happy to help with that anything that allows [semi/fully]-automated sign-on
is great.

2. There isn't a clear way to signal that there is no captive portal
> in the network.  It has been suggested that we use a special URL -
> e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could
> privilege the empty string, but that doesn't have as clear a signal of
> intent.
>
> This seems to be a standard problem in DHCP i.e. there is no way to issue
a denial or list available options


> 3. RFC 7710 states that the URL SHOULD use an address literal.  This
> works at odds with the idea of using HTTPS.


If there is a better way then this is the reason to do an RFC7710-bis,
the items above only need to CITE RFC7711, and there could be more than one
API proposed/documented.


>
>
Is there anyone who is willing to take on this work?  We aim to start
> and complete this work in <1 meeting cycle, starting in London.
>
> This is a great goal, willing to review


> For the authors of RFC 7710, let us know if you have any concerns.
>

not really, thanks for pushing the idea forward.

Olafur
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Reply via email to