Hi Rob, Thanks for the review!
Responses inline. You can also see updates in our working copy here: https://capport-wg.github.io/api/draft-ietf-capport-api.html > On Jun 11, 2020, at 4:17 AM, Robert Wilton via Datatracker <nore...@ietf.org> > wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-capport-api-07: 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-api/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > I found this document straight forward and easy to read. > > Linda's comment in the Opsdir review is interesting. I would have expected > the > CAPPORT architecture document to discuss/reference the problem being solved, > but it seems to be mostly silent on this. I will redirect Linda's comment to > the CAPPORT architecture. > > In section 5. "API State Structure", it does not state whether a connection > could be both time and data limited. My reading of the spec is that this > would > be allowed, assuming that is the case, the current text is fine. Correct, there is no requirement that time and data limits are mutually exclusive. > > 6. Example Interaction > > Upon receiving this information the client will use this information > direct the user to the the web portal (as specified by the user- > portal-url value) to enable access to the external network. Once the > user satisfies the requirements for extenal network access, the > client SHOULD query the API server again to verify that it is no > longer captive. > > Nit: information direct => information to direct Fixed on latest working copy. > > 7. Security Considerations > > I'm slightly concerned about the third paragraph in the security > considerations. Ideally I would like a solution that doesn't require humans > to > potentially spot potentially dubious spoofed domain names. But I can > appreciate that is probably out of scope here. This has been removed and reworded in our working copy, from addressing Ben’s comments. > > 7.1. Privacy Considerations > > Possibly worth adding a comment about the necessity to keep personal > information secure. In addition, should there be any comments about GDPR > like > constraints (if they apply)? This section has also be reworded slightly to make this more clear. I’m not sure if there’s anything we can state for GDPR or similar constraints here. I think that would mainly apply to what is shown in the user portal, not the API interaction. Best, Tommy > > Thanks, > Rob > > > _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
