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.
On Mon, Jun 8, 2020 at 5:05 AM Kyle Larose <k...@agilicus.com> wrote: > Hi Martin, > > Thanks for the review! > > Responses inline > > On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker > <nore...@ietf.org> wrote: > > > > Martin Duke has entered the following ballot position for > > draft-ietf-capport-architecture-08: No Objection > > > > > > > ---------------------------------------------------------------------- > > 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. > > > > > 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. > > > 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. > > > > I agree. That's a mistake; the document should be consistent. We'll fix > that up. > > Thanks! > > Kyle >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
