[Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

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.

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

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.

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)?

Thanks,
Rob