Hi Roman, Thanks for your comments! I’ve updated our working copy with this commit:
https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896 <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 <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> > 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
