Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly <[e-mail]>]

Hi Martin,

Thanks for the updated review. I’ve incorporated these comments in our GitHub:

https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672 <https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672>

Thanks,
Tommy

> On Jun 8, 2020, at 8:08 AM, Martin Duke via Datatracker <[e-mail]> wrote:
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-api-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document is clearly written. Thanks.
> 
> I am also confused by this sentence at the end of section 4.1 about failed
> authentication: “It may still be possible for the user to access the network by
> being redirected to a web portal.”
> 
> I suggest “...access the network by redirecting a clear text webpage to a web
> portal.”  I was a bit confused by the original wording.
> 
> As I said in the architecture review, the term for the user portal keeps
> changing. Over there it’s called a “Captive Portal Server” and a “web portal
> server”. Here it’s a “user-portal.” The authors of the two docs should get
> together and agree on a term.
> 
> One nit:
> s/extenal/external
> 
> 
>