[Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-09: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-capport-architecture-09: 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-architecture/ -- COMMENT: -- After further discussion, I see that draft-09 does indeed address my Discuss - the user-portal-url is optional in practice, just something the api design has to cover. I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1. After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). In the API doc it is called a "user portal." It would be great to unify the terminology across the documents as a whole. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-09: (with DISCUSS and COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-capport-architecture-09: 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-architecture/ -- DISCUSS: -- AFAICT this Discuss still applies to draft-09. Sec 2.3 says: At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. But in section 5 of capport-api, user-portal-url is an optional field. Both a capport-api author and a WG chair agreed that the architecture doc should be fixed, so I'm moving the DISCUSS here. -- COMMENT: -- I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1. After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). In the API doc it is called a "user portal." It would be great to unify the terminology across the documents as a whole. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)
Any of the proposed options are satisfactory. Thanks. On Tue, Jun 9, 2020 at 4:56 AM Kyle Larose wrote: > Hi Martin, > > Thanks again. I'll reply to the comment section with comments from the > earlier review for consistency. > > Inline. > > On Mon, 8 Jun 2020 at 11:07, Martin Duke via Datatracker > wrote: > > > > Martin Duke has entered the following ballot position for > > draft-ietf-capport-architecture-08: Discuss > > > > > > > -- > > DISCUSS: > > -- > > > > Sec 2.3 says: > > At minimum, the API MUST provide: (1) the state of captivity and (2) a > URI for > > the Captive Portal Server. > > > > But in section 5 of capport-api, user-portal-url is an optional field. > > > > Both a capport-api author and a WG chair agreed that the architecture doc > > should be fixed, so I'm moving the DISCUSS here. > > > > I agree. We need to fix this in the architecture. Two suggestions were > proposed in the discussion on the API document. > > - Require that the API be *able* to provide the URI > - Qualify the requirement to indicate when the URI is required (e.g. > when captive portal enforcement may be active). > > I think I prefer the first option, since it's simpler. Does anyone > else have some input on this? > > > > > -- > > COMMENT: > > -- > > > > I found the terminology around “Captive Portal API server” and “Captive > Portal > > Server” to be a little confusing, as these are similar terms. The latter > also > > doesn’t get its own discussion in Section 2 and is confusingly called > the “web > > portal server” in Figure 1. > > The Captive Portal API Server is the server hosting the Captive Portal > API. The Captive Portal Server is the server hosting the page(s) used > to communicate with the user visually via some form of client. > > I think, given your comments in the API review, and of the other > working group members who commented there, that we should use Tommy's > suggestion of "User Portal" in place of Captive Portal Server. That > should hopefully remove any confusion caused by the similarity between > the two terms. > > > > > After Figure 1, this seems to be consistently called the “web portal” > (sec 2.6 > > and 4). In the API doc it is called a "user portal." It would be great > to unify > > the terminology across the documents as a whole. > > > > I agree. That's a mistake; the document should be consistent. We'll fix > that up. > > > > > > > Thanks! > > Kyle > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)
Thanks! On Mon, Jun 8, 2020 at 8:50 AM Tommy Pauly wrote: > Hi Martin, > > Thanks for the updated review. I’ve incorporated these comments in our > GitHub: > > > https://github.com/capport-wg/api/commit/daeba897a1d50229b86f6ec23a026aaa725bf672 > > Thanks, > Tommy > > On Jun 8, 2020, at 8:08 AM, Martin Duke via Datatracker > wrote: > > Martin Duke 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: > -- > > This document is clearly written. Thanks. > > I am also confused by this sentence at the end of section 4.1 about failed > authentication: “It may still be possible for the user to access the > network by > being redirected to a web portal.” > > I suggest “...access the network by redirecting a clear text webpage to a > web > portal.” I was a bit confused by the original wording. > > As I said in the architecture review, the term for the user portal keeps > changing. Over there it’s called a “Captive Portal Server” and a “web > portal > server”. Here it’s a “user-portal.” The authors of the two docs should get > together and agree on a term. > > One nit: > s/extenal/external > > > > > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Thanks Kyle. I had to move this to a DISCUSS based on the inconsistent requirements with -api, but it sounds like this is about to be resolved. On Mon, Jun 8, 2020 at 5:05 AM Kyle Larose wrote: > Hi Martin, > > Thanks for the review! > > Responses inline > > On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker > wrote: > > > > Martin Duke has entered the following ballot position for > > draft-ietf-capport-architecture-08: No Objection > > > > > > > -- > > COMMENT: > > -- > > > > I found the terminology around “Captive Portal API server” and “Captive > Portal > > Server” to be a little confusing, as these are similar terms. The latter > also > > doesn’t get its own discussion in Section 2 and is confusingly called > the “web > > portal server” in Figure 1. > > > > > The Captive Portal API Server is the server hosting the Captive Portal > API. The Captive Portal Server is the server hosting the page(s) used > to communicate with the user visually via some form of client. > > I think, given your comments in the API review, and of the other > working group members who commented there, that we should use Tommy's > suggestion of "User Portal" in place of Captive Portal Server. That > should hopefully remove any confusion caused by the similarity between > the two terms. > > > After Figure 1, this seems to be consistently called the “web portal” > (sec 2.6 > > and 4). It would be great to unify the terminology across the document > as a > > whole. > > > > I agree. That's a mistake; the document should be consistent. We'll fix > that up. > > Thanks! > > Kyle > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's No Objection on draft-ietf-capport-api-07: (with COMMENT)
Martin Duke 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: -- This document is clearly written. Thanks. I am also confused by this sentence at the end of section 4.1 about failed authentication: “It may still be possible for the user to access the network by being redirected to a web portal.” I suggest “...access the network by redirecting a clear text webpage to a web portal.” I was a bit confused by the original wording. As I said in the architecture review, the term for the user portal keeps changing. Over there it’s called a “Captive Portal Server” and a “web portal server”. Here it’s a “user-portal.” The authors of the two docs should get together and agree on a term. One nit: s/extenal/external ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-capport-architecture-08: 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-architecture/ -- DISCUSS: -- Sec 2.3 says: At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. But in section 5 of capport-api, user-portal-url is an optional field. Both a capport-api author and a WG chair agreed that the architecture doc should be fixed, so I'm moving the DISCUSS here. -- COMMENT: -- I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1. After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). In the API doc it is called a "user portal." It would be great to unify the terminology across the documents as a whole. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)
On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly wrote: > > > I believe in this case the architecture document needs to change, or > clarify that this MUST refers to that the mechanism needs to be *able* to > communicate such a URI, not that such a URI must always be communicated. > > The group has discussed this several times, and I believe the API doc > reflects the consensus: while we aren’t tackling solutions for captive > portals that don’t involve User Portal pages (future solutions using a more > OS-driven experience and perhaps built in payment, etc), we want to allow > the API JSON to be usable in those new models. Not all captive networks > will necessarily use this kind of URI in the future, and there’s no need to > make the registry lock that in as mandatory. Very well, I’d like to hear from one of the chairs, but if confirmed I’m happy to move my DISCUSS to -architecture. > > > > > I am also confused by this sentence at the end of section 4.1 about > failed > > authentication: “It may still be possible for the user to access the > network by > > being redirected to a web portal.” > > > > Who is doing the redirecting here? If authentication has failed, how is > this > > redirect authenticated and secure against theft of credentials? > > This is referring to the fact that the old HTTP redirect of a clear text > webpage may still happen on a network. Even networks that support the API > will need to handle legacy clients. This is only about redirecting > unrelated pages to the user portal, and is orthogonal to the authenticity > of the API server. > > > Thank you for the clarification. I will move this bit to a COMMENT and suggest “...access the network by redirecting a clear text webpage to a web portal.” > > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)
Martin Duke 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: -- Unless I am misinterpreting the language here, there is a disconnect between this document and the architecture document. Sec 2.3 of -architecture says: At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. But in section 5 user-portal-url is an optional field. Is -architecture actually levying a requirement on the api spec, or the api server? I am also confused by this sentence at the end of section 4.1 about failed authentication: “It may still be possible for the user to access the network by being redirected to a web portal.” Who is doing the redirecting here? If authentication has failed, how is this redirect authenticated and secure against theft of credentials? -- COMMENT: -- This document is otherwise clearly written. Thanks. As I said in the architecture review, the term for the user portal keeps changing. Over there it’s called a “Captive Portal Server” and a “web portal server”. Here it’s a “user-portal.” One nit: s/extenal/external ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-capport-architecture-08: 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-architecture/ -- COMMENT: -- I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1. After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). It would be great to unify the terminology across the document as a whole. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
