Hi Martin, Thanks again. I'll reply to the comment section with comments from the earlier review for consistency.
Inline. On Mon, 8 Jun 2020 at 11:07, Martin Duke via Datatracker <nore...@ietf.org> wrote: > > Martin Duke has entered the following ballot position for > draft-ietf-capport-architecture-08: Discuss > > > ---------------------------------------------------------------------- > 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. > 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? > > ---------------------------------------------------------------------- > 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). In the API doc it is called a "user portal." It would be great to > unify > 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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
