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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 11 Jun 2020 02:57:09 -0700

Robert Wilton 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 this document easy to read, but have a few comments.

I support the 3rd bullet of Ben's discuss.

I was surprised by the diagram in section 2.6, since it seems to imply that the
Provisioning Service kicks everything off, but I would have expected the User
equipment to initiate the flow, which is articulated in the first step of
section 4.1.  Hence, I think that the diagram could be more clear if it also
showed the initial request from the client (as per the first step in 4.1).

Finally, I note that this document makes no mention of OAM considerations. 
Having some text covering these aspects would probably be beneficial.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 11 Jun 2020 11:24:24 +0000

Hi,

Linda Dunbar raised the following comment during the OPSDIR review of the capport-api draft:

What improvement does the proposed API have over today's existing communication between clients and  Captive Server(s)? Captive servers have been deployed everywhere, like airport or restaurants trying to access free WIFI. What problems does the existing method have to justify this newly proposed APIs?

The CAPPORT architecture document seems to be decidedly silent on why it exists and what problem is being solved.  It seems that there was an ID covering some of the this (https://tools.ietf.org/html/draft-nottingham-capport-problem-01), but it doesn't look like that document progressed.  It feels like it would have been beneficial if some of the information in that problem statement draft was captured or referenced from this architecture document in some way (e.g. in a Problem Description section, or in an appendix).

Regards,
Rob

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Robert Wilton via
> Datatracker
> Sent: 11 June 2020 10:57
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-capport-
> [email-masked]; [email-masked]
> Subject: Robert Wilton's No Objection on draft-ietf-capport-architecture-
> 08: (with COMMENT)
>

---

From: Kyle Larose <[email-masked]>
Date: Sat, 13 Jun 2020 09:23:43 -0400

Hi Robert,

Thanks for the review. Responses inline.

E.g. something like a "Join Network" request? I think that's
reasonable. It's possible that the URI flows to the User Equipment
unsolicited, but I don't think adding the request to the diagram
precludes that.

> Having some text covering these aspects would probably be beneficial.

I don't object to mentioning it, but I'm not sure it's within the
scope of the WG to expand much more beyond that. Perhaps one of the
chairs could comment?

Thanks!

Kyle

---

From: Kyle Larose <[email-masked]>
Date: Sat, 13 Jun 2020 09:37:28 -0400

Hi Rob,

Response inline.

> The CAPPORT architecture document seems to be decidedly silent on why it exists and what problem is being solved.  It seems that there was an ID covering some of the this (https://tools.ietf.org/ht…

We referenced that document in earlier versions of the draft. However,
since it didn't seem like it would be published any time soon, we
removed our reference to it. In doing so, we also decided not to
include any of its text to reduce document churn.

Martin, given that we're likely to make a non-trivial number of
changes to the document based on the recent review feedback, do you
think it's worth adding a few points discussing the problems faced by
existing captive portal implementations?

> > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

Thanks,

Kyle