Hi Tommy! Thanks for publishing this update to address my discusses and comments. I’ve cleared my ballot.
Regards, Roman From: Tommy Pauly <tpa...@apple.com> Sent: Thursday, June 18, 2020 11:11 PM To: Roman Danyliw <r...@cert.org> Cc: The IESG <i...@ietf.org>; draft-ietf-capport-...@ietf.org; capport-cha...@ietf.org; captive-portals@ietf.org; Martin Thomson <m...@lowentropy.net> Subject: Re: Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT) Hi Roman, I’ve published the working copy as the -08 version of the draft: https://datatracker.ietf.org/doc/html/draft-ietf-capport-api Please take a look, and update your evaluation if it looks good! Best, Tommy On Jun 11, 2020, at 12:14 PM, Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> wrote: Hi Tommy! The proposed edits in the working copy look good and address all of my discuss and comments. Thanks for making the changes. Regards, Roman From: Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>> Sent: Wednesday, June 10, 2020 2:09 PM To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-capport-...@ietf.org<mailto:draft-ietf-capport-...@ietf.org>; capport-cha...@ietf.org<mailto:capport-cha...@ietf.org>; captive-portals@ietf.org<mailto:captive-portals@ietf.org>; Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT) Hi Roman, Thanks for your comments! I’ve updated our working copy with this commit: https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896 The full editor’s copy can be viewed here: https://capport-wg.github.io/api/draft-ietf-capport-api.html On Jun 9, 2020, at 7:51 PM, Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-capport-api-07: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- “Discuss discuss”. Section 4 says “The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].” There is also various guidance on verifying the API server identity and access to revocation and time resources. However, the way I read the definition of the “Captive Portal API Server” per Section 2 and per Figure 1 of draft-ietf-capport-architecture, the API server is logically different than the service at the user-portal-url URL (i.e., Web Portal Server in the architecture). Section 7.1 helpfully points out “Information passed between a client and a Captive Portal system may include a user's personal information, such as a full name and credit card details. Therefore, it is important that Captive Portal API Servers do not allow access to the Captive Portal API over unencrypted sessions.” The first sentence is makes sense, but the second, while true, doesn’t follow the first for me. PII and credit card information would be the kind of input you would provide to the _Web Portal Server_ not the Captive Portal API (of course both are part of the overall Captive Portal system). This has been updated to: Information passed between a client and the user-facing web portal may include a user's personal information, such as a full name and credit card details. Therefore, it is important that both the user-facing web portal and the API server that points a client to the web portal are only accessed over encrypted connections. I feel there is missing guidance roughly on the order of the user-portal-url “provides the URL of a web portal _that MUST be accessed over TLS_ with which a user can interact.” (and the venue-info-url SHOULD use TLS too). Good point. This was implicit in some of our text, but needed to be stated: - "user-portal-url" (string): provides the URL of a web portal that MUST be accessed over TLS with which a user can interact. - "venue-info-url" (string): provides the URL of a webpage or site that SHOULD be accessed over TLS on which the operator of the network has information that it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally providing pointers to other resources. Would it be out of scope for this document to place restrictions on what the API is capable of pointing to? If not here, then where? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for describing the protocol interaction within the reference architecture of draft-ietf-capport-architecture. ** Ben points to a few places to tighten up the TLS mechanics (e.g., referencing BCP195, non-OCSP stapling revocation) which I won't repeat here. These are important. Indeed. Please see responses to Ben’s comments. ** Are there any retry behavior to specify for the client? Say the client tries to the visit the API URL and the server returns an HTTP 500 error? Or, the API server doesn’t respond at all? I’ve added this text to clarify: Client behavior for issuing requests for updated JSON content is implementation-specific, and can be based on user interaction or the indications of seconds and bytes remaining in a given session. If at any point the client does not receive valid JSON content from the API server, either due to an error or due to receiving no response, the client SHOULD continue to apply the most recent valid content it had received; or, if no content had been received previously, proceed to interact with the captive network as if the API capabilities were not present. ** Editorial Nits -- Section 4.1. Typo. s/mechnism/mechanisms/ -- Section 6. Typo. s/the the/the/ -- Section 6. Typo. s/extenal/external/ Thanks! Fixed all of these. Best, Tommy
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
