[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Comment on Captive Portal Architecture



LLDP may not traverse any layer-2 device (actually should not). PvD (even in an IPv4-only environment) has obviously my preference ;-)

 

I thought that the ‘box’ in the draft where components, where component being an app, a container or a set of containers/boxes. Rather than making the diagram complex, I would prefer to make sure that it is understood what component means

 

Nice and useful cancelled meeting yesterday

 

-éric

 

From: Captive-portals <[email protected]> on behalf of Nasir Hafeez <[email protected]>
Date: Friday, 9 November 2018 at 13:20
To: "[email protected]" <[email protected]>
Subject: [Captive-portals] Comment on Captive Portal Architecture

 

As discussed in yesterday's IETF meeting, CAPPORT Architecture states that the CAPPORT web server signals allow/deny rules to Captive Portal Enforcement device. In reality, however, there may be intermediate devices like RADIUS servers or WiFi controllers that are doing that signaling, not the CAPPORT web server (and in the case of walled garden entries, the web portal is never involved). The architecture diagram and related sections of the document should perhaps be updated to show that.

 

Another option that occurred to me was using LLDP for capport signaling. Do you think there is any utility in pursuing this?


Regards,

 

Nasir Hafeez