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

Re: [Captive-portals] Fixing RFC 7710

On Thu, Mar 1, 2018 at 10:58 PM, Martin Thomson <[email protected]> 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.

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

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.