On Sun, 7 Jun 2020 at 20:03, Erik Kline <ek.i...@gmail.com> wrote: > > Tommy is correct. I think the architecture document should add a > qualifying subclause to clarify that requirement (2) only applies "if > captive portal enforcement may be active on the given network" or > something. > > The model supports, for example, the very experiment we ran on the > IETF 106 network [106EXP]. In that experiment we handed out an API > URI via 7710/7710bis mechanisms to an API that told the client it was > /not/ captive but that a venue-info-url was available (which led to a > service that redirected clients to the agenda page, IIRC). > > [106EXP] https://tickets.meeting.ietf.org/wiki/CAPPORT
Indeed, this inconsistency was brought up earlier (https://mailarchive.ietf.org/arch/msg/captive-portals/FfPC0M6Plmflg5G92uylDn2stH4/). There's an issue (https://github.com/capport-wg/architecture/issues/71) opened against the architecture regarding it. Let's fix it there by making it optional. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
