Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

["Martin Thomson" <[e-mail]>]

Thanks for the review Lorenzo.

On Mon, Jul 22, 2019, at 11:17, Lorenzo Colitti wrote:
> 2. I'm surprised that the following text is present. It seems like we 
> should disallow IP literals for compatibility with IPv6. But perhaps 
> SHOULD is enough here.
> 
>  The URI SHOULD NOT contain an IP address literal. 

I tend to think that the core goal is that the URI contain a target identity that can be authenticated when accessed over HTTPS.

That generally means that IP literals aren't a good idea, but I wouldn't make this statement.  I would instead emphasize that this is an HTTPS URI.  Though I would not go into great detail on what that means, I would refer to RFC 7230.

> 3. The section that documents the link relation type should mention 
> what should happen if the portal is already open. Should the captive 
> portal add this header to probe responses even if the portal is already 
> open? if it does not, there is no way for a device to learn the API URL 
> if it connects to a portal, logs in, disconnects, and then reconnects, 
> because when it reconnects the portal will be open.

Good point.  I would be interested in hearing what the working group thinks of this.

To my understanding, this is a problem that exists today.  So we may decide not to worry about this particular problem, but just document it.  That would make this path less good than other options (like DHCP/RA), but I don't want to encourage networks to intercept EVERY request that passes.