Any of the proposed options are satisfactory. Thanks. On Tue, Jun 9, 2020 at 4:56 AM Kyle Larose <k...@agilicus.com> wrote:
> 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
