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 <nore...@ietf.org> > 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 > > >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
