|
Hi, Sorry, I had sent these comments sometime back, a few are still valid. Could you please take care of these? Thanks, Subash From:
"Tirupachur Comerica, Subash" <subash.tirupachurcomerica@xxxxxxxxxxxxx> Hi, I was reviewing this AD and found a few discrepancy needing clarifications, couple of them may just be editorial in nature. Appreciate your response on this, thanks. Thanks, Subash Section 1.2 Captive Network and Captive Portal are used interchangeably, so do we define captive portal or network or both? – [Pending] Section 2.3 At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. – [Pending] - However, in draft-ietf-capport-api, section 5: API State Structure, only "captive" (boolean): is mandatory whereas "user-portal-url" (string): is optional. One of these two drafts
may need an update for consistency. Section 2.6 Component Diagram Although the Provisioning Service, API Server, and Web Portal Server functions are shown as discrete blocks, they could of course be combined into a single element. – [Pending] - Here may be we can add the [Captive Portal Enforcement] as well, for eg: API Server, Web Portal Server and Enforcement can co-exist on a single WiFi Access-Point using ACLs.
Also there is a feeble reference to this co-location in Section 3.4.1 Section 3 Captive Portal Signal Is Enforcement Device defined anywhere else? Is it same as Captive Portal Enforcement(I guess so) Or does it coordinate with it? – [Resolved, Please ignore] From:
Captive-portals <captive-portals-bounces@xxxxxxxx> on behalf of Bob Harold <rharolde@xxxxxxxxx> I am curious why section 3.4 does not consider the MAC Address as a possible identifier? -- Bob Harold On Mon, May 11, 2020 at 12:56 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
