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 <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> 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> > Sent: Wednesday, June 10, 2020 2:09 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, > > 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 > <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 > <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/ > <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
