Subject: [Captive-portals] I-D Action: draft-ietf-capport-architecture-03.txt

From: [email-masked]
Date: Thu, 27 Dec 2018 09:32:13 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Captive Portal Interaction WG of the IETF.

        Title           : CAPPORT Architecture
        Authors         : Kyle Larose
                          David Dolson
	Filename        : draft-ietf-capport-architecture-03.txt
	Pages           : 17
	Date            : 2018-12-27

Abstract:
   This document aims to document consensus on the CAPPORT architecture.
   DHCP or Router Advertisements, an optional signaling protocol, and an
   HTTP API are used to provide the solution.  The role of Provisioning
   Domains (PvDs) is described.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-capport-architecture-03
https://datatracker.ietf.org/doc/html/draft-ietf-capport-architecture-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kyle Larose <[email-masked]>
Date: Thu, 27 Dec 2018 12:34:26 -0500

This update is mostly a refresh until I can spend a bit more time on
it. Either way, it addresses some of the issues we raised in Montreal.

Changes
------------

Major Changes:
- Reduce the scope of the signaling protocol:
  - Changed many SHOULDs to MAYs
  - Clarified that the signal is a simple indication that traffic is restricted.
- Document that the signaling protocol does not provide mechanisms for
non-binary blocking.

Minor Changes:
 - Some small changes to the diagrams
 - Mention that the identity depends on the network attachment point
 - Fixed spelling/grammar mistakes
 - Fixed up some ambiguous phrasing
 - Changed an example workflow to when conditions are about to expire,
rather than when they have already expired.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, 27 Dec 2018 at 12:32
Subject: [Captive-portals] I-D Action: draft-ietf-capport-architecture-03.txt
To: <[email-masked]>
Cc: <[email-masked]>

Abstract:

_______________________________________________
Captive-portals mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: David Bird <[email-masked]>
Date: Thu, 27 Dec 2018 11:14:36 -0800

I, for one, think "Document that the signaling protocol does not provide
mechanisms for non-binary blocking." is where IETF tries to become a some
sort of legal authority...

Hypothetically, what if a non-free captive portal network is legally
requires to *allow* certain resources for free (in the walled garden, so to
speak), but to comply with the IETF spec, networks indicate *nothing*
available (except the captive portal)... Networks *can already* enforce
captivity based on destination... limiting signaling only makes it
impossible to be transparent about it!!

At this point, I think you might as well remove the entire signaling
section... It reads like propaganda against signaling as a concept.. then
later has a entire section on the Nuisance factor of signaling, where it is
suggested "it may be possible for any user on the Internet to send
signals"... Hmm..

The section titled  "Risk of Nuisance Captive Portal" should really be
talking about networks that USE the API and have NO network integration
(e.g. Captive by API only, not by any network enforcement function).

Happy Holidays!

Cheers,
David

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Dec 2018 14:03:05 +1100

Thanks for doing this Kyle.

I see one issue that might be closed.  And a couple that appear to be blocked on discussion.  But this looks close.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Dec 2018 14:16:08 +1100

no hats...

> sort of legal authority...

The IETF describes what consenting protocol participants can do.  So, I'm fairly sure that legal authority has no bearing on this.  However, your point remains a good one.

There are relatively few places where you will find that blocking a per-destination basis doesn't happen at all.  No two networks are the same, and many apply policies that affect how your packets are passed.

Maybe it's a shortcoming in the draft, but recognizing that the intent is to provide an indication of whether access meets common expectations for network access should help.
 
> suggested "it may be possible for any user on the Internet to send

Personally, I'm comfortable with what is there as a set of requirements.  They aren't that negatively phrased, just narrowly scoped.  I think that a more narrowly targeted version of your ICMP draft would have met these requirements, as would several of the other things we've considered.  I might concede - as some have argued - that the resulting value is so greatly diminished as to not make it worthwhile, but that's the essence of the debate.

> (e.g. Captive by API only, not by any network enforcement function).

Opened https://github.com/capport-wg/architecture/issues/24

Thanks,
Martin

---

From: Nicolas Mailhot <[email-masked]>
Date: Mon, 31 Dec 2018 14:47:10 +0100

Le lundi 31 décembre 2018 à 14:16 +1100, Martin Thomson a écrit :
> The IETF describes what consenting protocol participants can do.  So,
> I'm fairly sure that legal authority has no bearing on
> this.  However, your point remains a good one.

Let's be honest and cut the crap.

Binary blocking does not exist. No one with an ounce of technical know-
how will ever implement such a thing.

A plane/train portal will provide free access to the train/plane live
location map, a school will provide free access to the school library
website and class schedules, a corp will provide free access to the
corp internal webapps, an internet cofee will provide free access to
its commercial portal with remaining time counter, parental controls
will provide free access to Disney comics, and so on. Tech stuff
documentation, including portal documentation, is online by defaut
nowadays. Even lightbulbs and toasters can have their own webpage.
Pretenting a network equipment will not in 2018 is utter dishonest
technical bullshit. That's not consensus at work that's capture by
special interests.

Normalising binary blocking is as idiotic as normalising that home
doors have no locks because some ultra marginal rural neighborhoods can
afford not to lock their doors (Guess what? They buy doors with locks
like everyone else. They just choose not to use them. And even when
they do not lock their main door they *will* lock the shed containing
dangerous sharp instruments in presence of small children).

When the IETF tries to pretend, that the default is different from the
one any last year IT student will naturally implement, it is taking a
political not technical stance. It is sabotaging its own standards. It
is discrediting itself as a neutral technical authority.

-- 
Nicolas Mailhot

---

From: David Bird <[email-masked]>
Date: Mon, 31 Dec 2018 17:44:23 -0800

Imagine if other network notifications were binary ... "You have no route
to at least one host, but not telling you which one."

I have to agree; the signaling section - without even specifying any real
solution - is only trying to limit any future work .. and not for any
technical reasons, at least not on the network infrastructure side.

I think there are maybe two motivating factors for those pushing the binary
agenda:
- A misguided attempt at enforcing net neutrality - when, in fact, a binary
signaling protocol doesn't solve (or prevent) any net neutrality issues, it
only makes them less transparent (to the network device and user)
- A misguided attempt at limiting the signaling protocol because it is just
easier on the user device side to think binary - when, in fact, nothing is
preventing the UE from treating the "full-disclosure" notification as
something binary (until the device software can think beyond the binary
captive portal)