Hi, Linda Dunbar raised the following comment during the OPSDIR review of the capport-api draft:
What improvement does the proposed API have over today's existing communication between clients and Captive Server(s)? Captive servers have been deployed everywhere, like airport or restaurants trying to access free WIFI. What problems does the existing method have to justify this newly proposed APIs? The CAPPORT architecture document seems to be decidedly silent on why it exists and what problem is being solved. It seems that there was an ID covering some of the this (https://tools.ietf.org/html/draft-nottingham-capport-problem-01), but it doesn't look like that document progressed. It feels like it would have been beneficial if some of the information in that problem statement draft was captured or referenced from this architecture document in some way (e.g. in a Problem Description section, or in an appendix). Regards, Rob > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Robert Wilton via > Datatracker > Sent: 11 June 2020 10:57 > To: The IESG <i...@ietf.org> > Cc: captive-portals@ietf.org; capport-cha...@ietf.org; draft-ietf-capport- > architect...@ietf.org; m...@lowentropy.net > Subject: Robert Wilton's No Objection on draft-ietf-capport-architecture- > 08: (with COMMENT) > > Robert Wilton has entered the following ballot position for > draft-ietf-capport-architecture-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found this document easy to read, but have a few comments. > > I support the 3rd bullet of Ben's discuss. > > I was surprised by the diagram in section 2.6, since it seems to imply > that the > Provisioning Service kicks everything off, but I would have expected the > User > equipment to initiate the flow, which is articulated in the first step of > section 4.1. Hence, I think that the diagram could be more clear if it > also > showed the initial request from the client (as per the first step in 4.1). > > Finally, I note that this document makes no mention of OAM considerations. > Having some text covering these aspects would probably be beneficial. > > _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
