Subject: [Captive-portals] IESG comments on charter-ietf-capport-00-03

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Nov 2015 12:09:10 -0500

capport denizens,

After yesterday's IESG telechat, the capport charter was approved
*pending edits*, and I'm holding it as I wait for responses to the
assorted comments in this final round of review.

See the comments here:
https://datatracker.ietf.org/doc/charter-ietf-capport/ballot/

Please review the comments ASAP, decide what edits, if any, are needed
to address the comments, and post a collective response to the IESG
list (one message responding to all the comments is fine).  I'll check
that, make the edits in the datatracker, and we can finalize the
approval of the charter.

Thanks,
Barry

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Nov 2015 15:11:01 -0800

How does this sound?

Alissa: editorial, just fix it
Spencer: maybe pass
Jari: important, just fix it
Benoit: maybe related, but we can let the WG decide
Joel: is right, but I don't know what to do about that.  I'd rather
have the goal and miss it due to ... physics ... than to not have it
at all.  I think that the notion that *secure* detection is possible
is a Hard problem.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 21 Nov 2015 01:33:29 +0200

I agree with all of Martin's proposed statements. Regarding the last 
comment (Joel's), the word "secure" in the draft charter applies to 
multiple mechanisms, some of which we may not be able to secure, and 
some that are possible to secure. So I'm fine with the text as it 
stands, even if securing everything may not be realistic.

Thanks,
	Yaron

On 11/21/2015 01:11 AM, Martin Thomson wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 30 Nov 2015 15:15:40 +0000

+1
Let¹s move on from charter and roll our sleeves up on the real (harder)
work. ;-)

Jason L

On 11/20/15, 6:33 PM, "Captive-portals on behalf of Yaron Sheffer"
<[email-masked] on behalf of [email-masked]>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Nov 2015 15:26:19 +0000

Doh.
I'd responded to this (on the plane back from RIPE in Bucharest), somehow
didn't hit "Reply All".

Here is how I'd proposed to address comments:
Some networks require interaction from users prior to authorizing network
access. Before that authorization is granted, network access might be
limited in some fashion. Frequently, this authorization process requires
human interaction, either to arrange for payment or to accept some legal
terms.
Currently, network providers use a number of interception techniques to
reach a human user (such as intercepting cleartext HTTP to force a redirect
to a web page of their choice), and these interceptions are
indistinguishable from man-in-the-middle attacks. As endpoints become
inherently more secure, existing interception techniques will become less
effective or will fail entirely. This will result in a poor user experience
as well as a lower rate of success for the Captive Portal operator.

The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of limited
environment,
- provide a URL to interact with the Captive Portal,
- allow endpoints to learn about the parameters of their confinement,
- interact with the Captive Portal to obtain information such as status and
remaining access time, and
- optionally, advertise a service whereby devices can enable or disable
access to the Internet without human interaction.
(RFC 7710 may be a full or partial solution to the first two bullets)

The working group may produce working documents to define taxonomy and to
survey existing portals and solutions. These might or might not be
published as RFCs, and might or might not be combined in some way.

Out of scope are "roaming" (federation of credentials), network selection,
or the on-boarding/provisioning of clients onto secure (or any alternate)
networks.
These are not really captive portals, and have largely been solved in other
ways.

Initially, the working group will focus on simplifying captive portal
interactions where a user is present. A secondary goal is to look at the
problem posed to or by devices that have little or no recourse to human
interaction.

Comments:
Comment from: Alissa.
The phrase "satisfy the requirements" is pretty ambiguous. I would
suggest either explaining what requirements are intended (e.g., "the
network operator's requirements for obtaining network access" or
something along those lines) or dropping the phrase altogether if the
point is really just to provide the URL.

Explanation;
I was meaning "satisfy the captive portal" - do whatever is needed to make
it happy (pay some $$$, accept AUP, etc), but this is not clear, not easy
to make it clear.

Resolution:
Dropping the phrase. Thank you.

Comment from :Jari
The phrase "unrestricted access" was not clear to me. Perhaps you meant
"Internet access".
Comment: Yeah, that works. Before a CP is satisfied it sometimes only gives
access to certain services / sites (e.g: United Airlines only gies you
access to their website until you pay them $$$) - "unrestricted access" was
supposed to mean, well, I guess, Internet access.
Resolution: Changed it to be "Internet access"

Comment from: Benoit
What's the relationship with draft-wkumari-dhc-capport-16?

Any value in mentioning it in the charter?
"Building on/Integrating/Improving/... (*) draft-wkumari-dhc-capport-16
(RFC editor queue), the WG will ..."

(*) depending on the answer to the first question

Comment:
I was uncomfortable suggesting this myself, because I'm obviously biased.
 draft-wkumari-dhc-capport-16 is in / has completed AUTH48 (will be  RFC
7710)

I think that it solves the first 2 bullets nicely (discovery / URL) in many
cases, but, again, I may be biased.
Resolution: " RFC 7710 may be a full or partial solution to the first two
bullets. " inserted.
I don't really like where it is / the wording, additional suggestions
welcome.

David Bird (in email - [TODO(WK): Find link when not on plane!]):
David suggested that we don't need to mention iPass / Boingo / etc by name,
and provided:
"Out of scope are "roaming" (federation of credentials), network selection,
or the on-boarding/provisioning of clients onto secure (or any alternate)
networks." as suggested text. I think that this works nicely. Any
objections?

-----

Sorry folk for not having managed to hit Reply All.
W