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

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 08:06:22 -0700

Martin Duke has entered the following ballot position for
draft-ietf-capport-architecture-08: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sec 2.3  says:
At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for
the Captive Portal Server.

But in section 5 of capport-api, user-portal-url is an optional field.

Both a capport-api author and a WG chair agreed that the architecture doc
should be fixed, so I'm moving the DISCUSS here.

----------------------------------------------------------------------
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). In the API doc it is called a "user portal." It would be great to unify
the terminology across the documents as a whole.

---

From: Kyle Larose <[email-masked]>
Date: Tue, 9 Jun 2020 07:56:02 -0400

Hi Martin,

Thanks again. I'll reply to the comment section with comments from the
earlier review for consistency.

Inline.

I agree. We need to fix this in the architecture. Two suggestions were
proposed in the discussion on the API document.

- Require that the API be *able* to provide the URI
- Qualify the requirement to indicate when the URI is required (e.g.
when captive portal enforcement may be active).

I think I prefer the first option, since it's simpler. Does anyone
else have some input on this?

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.

> the terminology across the documents as a whole.

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

Thanks!

Kyle

---

From: Martin Duke <[email-masked]>
Date: Tue, 9 Jun 2020 08:40:41 -0700

Any of the proposed options are satisfactory. Thanks.