Subject: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 05 Jun 2020 22:49:48 -0700

Martin Duke has entered the following ballot position for
draft-ietf-capport-architecture-08: 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-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found the terminology around “Captive Portal API server” and “Captive Portal
Server” to be a little confusing, as these are similar terms. The latter also
doesn’t get its own discussion in Section 2 and is confusingly called the “web
portal server” in Figure 1.

After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
and 4). It would be great to unify the terminology across the document as a
whole.

---

From: Kyle Larose <[email-masked]>
Date: Mon, 8 Jun 2020 08:05:06 -0400

Hi Martin,

Thanks for the review!

Responses inline

The Captive Portal API Server is the server hosting the Captive Portal
API. The Captive Portal Server is the server hosting the page(s) used
to communicate with the user visually via some form of client.

I think, given your comments in the API review, and of the other
working group members who commented there, that we should use Tommy's
suggestion of "User Portal" in place of Captive Portal Server. That
should hopefully remove any confusion caused by the similarity between
the two terms.

> and 4). It would be great to unify the terminology across the document as a

I agree. That's a mistake; the document should be consistent. We'll fix that up.

Thanks!

Kyle

---

From: Martin Duke <[email-masked]>
Date: Mon, 8 Jun 2020 08:10:44 -0700

Thanks Kyle. I had to move this to a DISCUSS based on the
inconsistent requirements with -api, but it sounds like this is about to be
resolved.