►
From YouTube: IETF102-CAPPORT-20180717-0930
Description
CAPPORT meeting session at IETF102
2018/07/17 0930
https://datatracker.ietf.org/meeting/102/proceedings/
C
E
F
A
G
D
I
D
I
Already
any
any
agenda,
bashing
I
think
actually
the
the
said
that
not
on
the
agenda
explicitly
is
7710
this,
but
there's
the
slide
after
this
is
about
that.
So
the
chairs
section
may
expand
from
administrivia
to
administrivia
plus
7710
bists
and
take
more
than
five
minutes
any
other
agenda
bashing,
carrying
forward
okey
doke.
I
So
after
way,
too
long
a
delay,
I
finally
got
a
zero
7710
Biss
uploaded
it's
missing
a
handful
of
citations.
I
need
to
find
one
for
content
negotiation,
but
it
clarifies
that
the
URI
that
we're
talking
about
in
77.
This
is
the
API
endpoint
says:
capture
portals
may
do
content
negotiation
depending
on
the
accepts
header
in
there.
If
they
don't
see
cat
port
or
whatever.
I
The
tell
me
you'll
have
to
remind
me
what
the
what
the
type
is:
application
can't
port
JSON
something
captive,
and
we
remove
the
recommendation
that
you
should
use
IP
address
literals
and
we
in
fact
invert
it.
You
should
not
use
IP
address.
Literals
and
I
tried
to
suggest
that
we
use
this.
U
RN,
IETF
params
kept
port
unrestricted
as
a
URI
thing
to
to
say
district
to.
Let
clients
know
that
they
can
just
not
bother
with
Internet
connectivity
checks
and
just
proceed
straight
to
getting
on
I.
I
Don't
know
if
this
is
useful,
but
it
seemed
like
a
way
to
short-circuit
or
to
indicate
that
you
could
short-circuit.
They
kept
a
portal
connectivity
checks.
There
was
the
question
of
where,
additionally,
this
might
be
made
available
in
discussions
with
one
captive
portal
vendor
last
week.
It
seemed
that
the
DHCP
on
link
infrastructure
was
not
always
under
their
control
in
a
substantial
portion
of
deployments.
I
Furthermore,
in
the
ones
they
did,
control
changing
DHCP
parameters
might
be
seen
as
exceptionally
risky,
and
so
they
asked
whether
the
capture
portal
API
could
be
made
blue
sheets
anybody.
You
know
thank
you,
so
they
asked
whether
the
capture
portal
API
could
be
available
via
some
means
other
than
DHCP
or
Ras,
given
that
they
wouldn't
be
able
to
I
asked
if
they
could
deploy
7710
URL
options
in
new
deployments,
and
they
said
yeah
yeah,
sure
sure,
okay,
but
it's
not
gonna
deal
with
the
existing
deployment
base,
so
most
likely
most
of
it.
I
So
could
we
do
something
else,
and
one
idea
that
came
up
was
in
the
redirect
HTTP
redirect
of
the
sacrificial
clear
text?
Could
there
be
an
HTTP
header
that
said
not
only
location,
:
redirect
destination
something
about
where
to
find
the
captive
API
portal?
Ed
point:
I,
don't
know
what
people
think
about
this.
This
is
not
in
7710
this,
but
I
do
think
we
should
talk
about
it.
I
can
and
fully
intend
to
send
something
to
the
mailing
list
about
this.
I
J
J
H
I
D
I
I
K
Now
it
is
alright
morning
everyone
so
I'll,
be
talking
about
the
captive
API
stuff,
I'm
Tommy
Pauly,
halfway
through
I
think
we're
gonna
switch
with
Tariq,
because
he
has
some
thoughts
out
on
what
you
just
mentioned
about
how
we
do
kind
of
the
URI
redirecting
how
we
handle
the
URL
problem.
But
before
that
I'll
give
a
summary
of
the
latest
updates
to
the
API
document.
K
You
can
do
it
if
you
want,
but
that
is
left
as
an
exercise
to
the
implementer
to
deal
with
if
they
want
to
go
down
that
road
and
they
should
just
use
stapling
and
we
discourage
certificates
that
require
a
ia,
and
we
also
more
clearly
specify
that,
if
there's
any
certificate
validation,
failure
that
the
ue
should
reject
and
ignore
any
of
the
information
that
it
gets
on
this
connection
and
essentially
treat
the
network
as
if
there
is
no
captive
portal
api
present.
That
does
not
mean
that
captive
portals
will
not
work.
D
B
K
B
K
Think
we
should
still
be
doing
the
validation
of
a
certificate
either
way
like
that's
a
good
thing
to
do.
The
my
assumption
here
is
I.
Don't
think
this
actually
stated
quite
like
that
in
the
document.
My
assumption
is
that
the
value
of
validating
this
is
that
the
user
at
some
point
can
recognize
that.
Oh,
this,
captive
portal,
at
least,
is
claiming
to
be
provided
by
Google
or
Starbucks
or
whatever
I.
Don't
know
if
we're
just
valid
like
if,
if
what
we're
validating
that,
indeed,
the
captive
portal
is
owned
by
evil
evil.
K
I
D
Yes,
so
Martin
Thompson,
I'm
making
notes
and
try
to
make
comments.
At
the
same
time,
the
the
text
in
the
document
and
your
text
here
I
think
mrs.,
mrs..
The
the
key
point
look
a
little
bit.
The
the
important
thing
here
is
that
we
have
a
long
sequence
of
interactions
and
yeah.
The
first
one
is
with
the
network,
and
we
kind
of
know
that
it's
with
the
network,
because
it's
DHCP
or
an
RA
or
something
along
those
lines
of
beyond
that
point,
where
we're
exposed
to
all
sorts
of
attacks
and
and
whatnot
and.
J
D
We
established
those
expectations
when
we
get
the
RA,
the
7710
URI,
and
from
that
point
onwards
we
want
to
make
sure
that
no
one
can
violate
those
expectations.
And
so
that
is
what
has
been
provided
here,
but
in
the
fact
that
we're,
following
all
the
standard,
best
practices
for
doing
HTTPS
and
we
like
the
confidentiality
and
we've
enacted.
M
You
know
like
reasoning
about
the
chain
of
network
events,
but
the
reason
that
we're
validating
the
the
name
is
because,
when
you
connect
to
a
given
network-
and
you
think
you're
connecting
to
the
Metropolitan
Transit
Wi-Fi,
you
want
to
see
that
it's,
the
user
needs
to
see
that
it
is
the
network
that
is
the
Metropolitan
Transit
Wi-Fi.
We.
K
K
That's
kind
of
the
direction
I
was
going
down
here.
I.
Do
think
that
we
do
need
to
clarify
what
point
that
Martin
made
of
the
linkage,
because
that's
kind
of
the
fundamental
thing
for
the
API,
linking
with
the
rest
of
the
architecture
but
right
presenting
something
to
the
user,
is
a
good
way
to
make
sure
that.
L
So
Warren
quarry
I'm
still
a
little
confused
when
I
go
to
the
Sheraton
and
get
on
the
SSID,
that's
called
Sheraton
guest.
What
actually
connects
me
is
something
called
room.
Links
like
they've
outsourced
that
to
room
links
so
I.
Don't
really
know
what
I'm
supposed
to
be
expecting
here
right,
like
Sheraton
room
links,
who's
these
people
yeah.
What
am
I
supposed
to
do
with
this
information
now.
I
This
this
URL
just
comes
from
like
an
entirely
untrusted
source
right
I
mean
we
can
say.
Oh
yeah,
like
from
the
point
on
where
we
get
this
URL,
which
is
basically
anyone
on
link,
can
can
send
it
to
us.
Then
yeah,
we're
gonna,
validate
that
I
mean
sure,
but
I
don't
think
you
know,
maybe
maybe
you
could
say
I,
don't
think
you
can
even
say
well,
let's
check
that
it
was
the
last
that
what
the
one
we
got
last
time,
because
this
stuff
is
that
as
Lauren
says
it's
out
sourced
all
over
the
place.
I
K
An
interesting
deployment
question,
because
this
is
not
the
same
as
the
pager
redirected
to
right,
so
you
could
even
have
the
pager
redirected
to
being
a
different
entity
than
the
one
that's
providing
the
API.
Maybe
the
one
that's
providing
the
API
is
closer
to
what
you
would
expect
and
they
outsource
the
redirect
page
or
it
could
be
completely
all
the
way.
I
I
N
Jeffrey
Stehr
I
think
the
point
is
not
whether
you
want
to
present
the
hostname
to
the
user
or
not.
The
thing
is
what
was
said
before.
That
I
would
disagree
with
you,
Lorenzo
that
when
you
connect
to
the
network,
you
sort
of
trust
the
configuration
information
that
you
get
from
you
from
your
network,
so
the
HTTP,
arrays
or
PVD.
You
somehow
get
that
URI.
That
tells
you
that
there
is
a
CAPTCHA
photo
API.
K
J
So
I
think
I'm
gonna,
address
I.
Think
the
point
that
you
made
like
if
you
make
the
API
host
the
host
and
the
same
as
that
one,
we
lose
probably
a
lot
of
actual
practical
deployment
scenarios.
I.
Think
because
the
thing
is,
it
is
very
possible
that
the
captive
portal,
API
URL,
may
be
hosted
by
some
other
entity
compared
to
the
one
that's
providing
the
user
page
and
not.
J
Be
the
same
host
and
second
point
is
even
if
let's
say
the
host
name
may
not
be
apparent
to
the
user.
So
if
the
user
connects
to
share
it
on
things
at
all,
it's
from
some
on
link
some
something
else.
That's
fine.
At
least
you
have
showed
it
to
the
user
right
and
then
let
the
user
ask
the
question
or
decide
decide
if
they
still
want
to
continue
or
not.
We
should
at
least
put
a
recommendation
of
saying
they
should
show
it
to
the
user.
D
We
don't
have
that
property
here,
because
essentially,
the
network
can
send
you
anything
and
it's
very,
very
easy
to
use
confusable,
x'
and
all
those
sorts
of
other
things
too,
to
basically
fish
in
this
way,
and
that's
not
necessarily
a
problem
in
this
case.
As
long
as
the
primary
properties
that
we're
looking
for
maintained,
however,
there
is,
there
is
still
some
value
in
having
this
continuity
and
till
I
saw
the
way,
because
you
have
the
ability
to
do
things
like
well.
D
Origin
and
not
feed
that
password
in
and
if
people
are
using
those
sorts
of
tools
as
they
should,
then
you
you
avoid
some
attacks.
The
problem
with
with
taking
TLS
out
of
a
link
at
any
point
in
this
process,
is
that
you
open
the
door
to
all
sorts
of
interesting
problems.
I,
don't
think
we
need
to
go
there
right.
K
And
that's
an
interesting
point:
you
bring
up
because
if
we
eventually
do
evolve,
the
captive
API
into
something
that
doesn't
just
require
user
interaction
on
a
repo
web
page
and
then
we
can
do
some
more
automatic
rejoining
of
things.
Then.
Yes,
certainly
the
fact
that
we're
validating
this
will
help
us
reuse.
Whatever
credentials
we
had
from
previous
sessions.
I,
don't.
I
So
what
deployment
scenario
do
we
have
where
the
the
party
operating
the
captive
portal
login
page
is
not
the
same
party
would
be
operating
the
API
server,
because
I
can
see
how
the
venue
page
is
not
going
to
be
the
same
page,
but
the
the
entity
that
is
making
you
captive
or
not
surely
should
be
the
same
entity.
That's
using
the
that's
powering
the
API.
No
yeah
tell
me
tell
me
more
you've
seen
all
of
David
Byrd's
presentations
on.
I
D
But
those
yeah
okay,
so
for
those
people
who
haven't
seen
those
presentations-
and
it
was
probably
a
few
meetings
ago-
he
showed
some
of
the
ways
in
which
these
network
architectures
are
built
up
behind
the
scenes.
So
you
just
see
a
Wi-Fi
access
point
and
something
happens
and
what
what
it
shows
is
that
you
have.
You
could
probably
find
that
one
in
its
IT
f99.
A
D
So
he's
the
concern
there
I
think,
is
that
people
who
build
the
overly
complicated
hotspots,
if
they
see
any
impediment
to
doing
these
api's,
then
they're
not
going
to
deploy
this
thing
and
we're
not
going
to
get
any
benefit
from
having
defined
these
things
in
those
networks
and
we're
already
at
the
point
where
this
is
not.
This
is
a
big
ask
for
these
guys
to
deploy,
and
you
see
the
picture
here-
the
portal
and
the
and
the
website
sometimes.
I
K
I
I
K
D
As
a
concrete
example,
I
go
to
the
Starbucks,
the
you
know,
mechanical
details
of
all
of
this
has
been
offloaded
to
some
other
provider,
and
so
that
provider
manages
all
of
the
plumbing,
but
they
send
you
to
a
portal
page
that
redirects
and
redirects
and
redirects
and
ultimately
lands.
You
want
a
page
that
has
the
Starbucks
origin
and
shows
all
of
the
nice
things
that
you
might
expect
to
see.
Underneath
the
covers.
D
I
M
Is
this
invisible
thing
in
the
middle
that
we're
talking
about
validating
and
if
that's
actually
invisible
than
what
you're
saying
is
the
you
know,
evil
dot.
Evil
can
ultimately
point
you
to
Starbucks
dot
with
E,
and
then
you
go
into
Starbucks
out
with,
and
you
think
you're
going
into
Starbucks,
but
whatever
registration
set
up
actually
happens
there.
It
gets
tied
by
your
at
your
end
point
to
evil
dot,
evil.
M
So,
the
next
time
you
go
to
evil
dot,
evil
you
end
up
connecting
there,
even
though
you
thought
you
were
authenticating
to
Starbucks,
that
with
E
right
and
so
whatever
the
user
is
going
to
see,
needs
to
be
visible.
Now,
I
agree
with
Lorenzo
that
these
things
should
be
the
same
thing
because
showing
the
user
two
different
names
is
on
top
of
the
SSID
is
confusing,
and
users
will
not
get
it.
So
if
the
goal
here
is
to
communicate
something
to
the
user,
these
things
should
be
tied
together.
Well,.
K
You
could
imagine
that
if
they
are
not,
then
you,
the
UI,
highlights
that
in
some
way
another
place
where
this
could
be
represented
to
the
user
not
to
go
too
far
off
track,
for
example,
in
the
list
of
what
Wi-Fi
you're
associated
to,
because
this
is
actually
potentially
a
longer
lived
thing
or
something
that's
happening
automatically.
So
essentially
your
captive
portal
SSID
could
be
annotated
with
you
know,
captive,
provided
by
this.
O
K
B
K
So
these
are
just
a
couple
questions
or
comments
that
have
come
up
from
the
list
when
we
got
some
reviews
of
the
document.
So
far,
one
of
the
things
that
I
think
needs
to
be
further
emphasized
in
the
document
as
it
stands
is
that
the
list
of
keys
and
information
currently
provided
by
the
JSON
API
is
not
exhaustive.
K
Some
of
the
comments
were
like.
Oh,
this
is
you
know,
a
fairly
naive
approach
of
saying.
Oh
yeah,
you
have
a
UI
portal.
You
have
the
potentially
remaining
time,
potentially
the
remaining
bytes
I
think
we
fully
recognize
that
at
this
point,
this
list,
especially
the
optional
values,
to
have
the
remaining
time
or
the
rating
bytes,
is
a
bit
of
a
strawman,
and
it
does
need
some
more
nuance
there
and
potentially
extensibility.
K
We
can
see
that
just
being
something
that
we
discuss
in
this
group
as
we
are
working
on
the
document
to
clarify
that,
but
we
probably
also
want
some
mechanism
by
which
people
can
extend
the
keys
that
they
are
putting
in
this
JSON
format.
So
I
don't
know
if
we
have
thoughts
about
the
appropriate
way
to
do
that.
K
K
I
K
K
K
Yes,
something
that
will
need
to
be
a
fix
that
comes
in
a
other
version
of
this
document.
Great
the
other
thing
that
came
up
I
think
based
on
David
Byrd's
comments.
Were
you
know
what
are
some
of
the
edge
cases?
What
are
the
failure
cases
here
so
just
to
review
I
think
how
the
document
and
the
API
stands
today.
K
If
everything
is
working
and
centrally
you
are
advertising
a
captive
API
on
a
network
that
is
truly
captive,
then
everything
is
hunky-dory.
We
have
a
pretty
good
user
experience.
We
are,
we
know
where
the
portal
is,
we
don't
have
to
deal
with
redirects.
We
can
make
sure
we
present
it
to
you
and
then
the
two
failure
cases
are
the
cases
in
which
maybe
someone's
advertising
and
captive
API
on
what
would
otherwise
not
be
considered
a
captive
Network.
This
is
an
interesting
question
that
was
brought
up.
K
You
could
imagine
this
potentially
being
a
good
thing
in
which
oh
yeah,
this
network
has
given
you
extra
portal
information
without
blocking
you.
Just
too
give
you
some
user
experience,
but
it's
also,
you
know
an
invasion
of
the
user
experience
without
potentially
adding
too
much
benefit.
We've
decided
is
this
a
harmful
thing?
Do
we
need
to
worry
about
this,
and
then
the
other
edge
case
is
that
someone
is
not
advertising
the
API
correctly
on
this
captive
Network
and
that's
essentially
what
we
have
today.
L
K
K
Well,
so
what
you
we
imagine
is
that
this
thing
is
governing
the
behavior
of
like
what
we
consider
to
be
like
the
captive
interaction
like
the
sheet
that
pops
up.
If
someone
goes
into
a
browser
and
just
tries
to
load
a
page,
they
may
still
get
redirected
or
get
the
other
behavior.
This
is
talking
about
what
is
governing
system
behavior,
so
maybe
it
does
to
lay
the
system
automatic
behavior,
Kyle.
O
K
Right
well,
especially,
if
you
aren't
actually
being
denied
access
to
your
traffic,
this
is
I.
I.
Think
the
the
thing
that
comes
out
of
this
is
we
maybe
shouldn't
you
know
disallow
you
from
joining
that
network,
like
we
should
make
sure
that
your
your
browser
traffic
can
still
go
through
if
it
can
right
that
we
don't
prevent
that
or.
O
O
I
I
K
I
K
K
Right
in
some
cases,
I
think
this
is
potentially
somewhat
useful
because
there
are
some
services
and,
let's
say
like
on
airplanes
in
which
I
want
that
that
landing
page
cuz
I
want
to
know
how
far
my
flight
is
along
and
all
this
other
cute
little
information,
but
maybe
I
am
already
allowed
to
use
the
network,
and
so
how
do
I
get
back
to
that
page,
etc,
etc.
So
this
solves
that
say.
It
also
provides.
I
L
This
does
also
feel
a
fair
bit
like
it
might
be
abused
that
every
time
I
join
the
network
from
now
on,
somebody's
gonna
pop
up
a
shiny
website
for
me
offering
I
mean
I,
guess
that
that
currently
is
kind
of
a
thing
that
kept
the
photos
do
anyway,
but
it
feels
like
this
might
make
it
easier
to
pop
up
I.
Did
you
know
that
we
now
dual
Aragon.
K
K
P
That's
true
everything
and
what
I
would
say
is
basically
the
same
thing
as
Lorenzo
said
you
ate
well
anyway.
The
refer
back
to
this
case,
but
displaying
an
URL,
could
also
be
a
frame
of
one
picture
by
one
pixel,
all
sorts
of
your
viewport
containing
of
style
JavaScript
or
whatever,
but
this
is
simply
gets
302
right
anyway,.
K
D
So
mountaintops
exist
in
response
to
Eric's
point
there.
The
fundamental
premise
of
the
web
is
that
you
can
do
that
safely.
I
mean
if
we
fail
with
that,
as
we
often
do
that's
on
us
as
those
people
who
provide
the
browser's,
but
there's
nothing
much
we
can
do
about
and
then
yeah
we've
already
established
the
fact
that
they
can
do
this
anyways.
Okay,
great.
J
So
I
should
check
or
give
elapsed
so
I
actually
had
some
text
also
that
was
supposed
to
publish
for
this,
but
I
wrote
the
text
I
didn't
like
it,
so
I
didn't,
publish
the
text,
but
I
think
I
want
what
I
want
to
try
to
do
was
just
kind
of
throw
it
out
for
discussion
and
see
what
people
think
about
it
and
then
we'll
see
if
that
makes
sense.
So
we
sort
of
had
a
discussion
about
this
at
the
last
idea
of
I.
J
Think
Tommy
brought
it
up
in
terms
of
what
should
77
10.2
right,
and
so
what
we
are
suggesting
here
is.
It
can
be
like
let
the
network
operator
choose
what
they
want
to
publish
in
77,
10
or
any
other
equivalent
mechanism
right,
it's
their
choice.
What
we
provide
here
is
if
they
are
already
advertising
a
captive
portal
URI
in
77
10,
then
we
already
have
the
user
URL
key.
J
That
will
point
to
the
user
portal
and
the
user
can
and
you
you
can
actually
find
that
if
they
want
to
advertise
the
user
portal,
then
we
register
in
the
API
document
are
maybe
in
the
architecture
somewhere.
We
registered
a
link
header
weight,
whatever
some
link
relation
we
can
figure
that
out
and
that
one
captive
API
whatever
right
and
that
one
points
to
the
captive
portal.
So
if
the
user
actually
gets
to,
if
the
you
HOV
just
goes
and
receives
an
actual
you
Hotel
URL
page,
it
can
still
look
at
a
link
header.
J
It
can
still
find
out.
There
is
an
captive
API
URL
there.
So
you
actually
have
kind
of
connection
both
ways
and
then
we
don't
have
benefit.
Is
we
don't
have
to
decide
if
you
want
what
we
want
to
do
with
7710,
we
may
still
want
to
fix
7710
for
other
reasons,
and
that's
fine,
but
at
least
with
this
we
like
we
just
give
a
suggestion
and
let
the
deployer
or
the
network
operator
choose.
J
L
Warren
Kumari:
let's
say
that
I
join
a
normal
network,
there's
no
captive
portal
and
I
connect
to
the
Internet's
and
a
browser
arm
for
a
while
and
then
eventually
I
stumble
across
evil
example
calm,
and
it
includes
one
of
these
links
saying
please
go
along
and
use
this
capture
photo
API
and
come
back
every
30
seconds
in
order
to
make
sure
that
you
still
have
you
know
time
remaining
and
now
for
the
next.
You
know
three
weeks
everywhere:
I
go
I'm,
happily
checking
in
and
telling
them
where
this.
J
Is
this
is
part
of
like
the
current
you
ease
when
you
try
to
when
you
get
redirect
to
a
captive
portal,
knowing
that
you
are
behind
a
captive
portal,
this
is
for
those
URLs
to
advertise
it
to
that.
Not
so
right
now
so,
right
now
in
the
uu
right,
how
do
you
actually,
whatever
mechanism
we
are
using
to
load
up
your
special,
you
know,
you're
doing
your
probing
and
whatever
mechanism
using
to
find
a
special
page
is
where
that
is
the
idea
that
supposed
to
provide
this,
the
URL
back.
I
So
I
so
I
would
I
would
suggest.
The
answer
to
Martin's
question
is
which
of
those
three
or
twos
I
would
suggest.
The
answer
is
only
the
first
one
and
the
first
one
is
essentially
the
the
same
tofu
model
at
the
the
DHB
URL
has.
If
someone
is
able
to
manipulate
your
on
link
traffic,
then
they
get
to
choose
what
you
do.
Yeah.
L
L
I
I
Till
the
end
of
time,
pretty
much
I
mean
the
know
from
an
implementation
perspective
as
well.
I
mean
the
sacrificial
probes
already
there
and
in
our
implementation
it
happens
to
be
an
entirely
different
component
from
the
one
that
actually
displays
the
login
page,
which
we
don't
display
unless
the
user
actually
interacts,
and
so
there
is
a
there's,
a
difference
in
terms
of
trust
model
there
as
well.
So.
Q
Eric
Kinnear
so
just
a
point
on
the
captive
probe.
If
you're
on
a
portal
that
then
later
becomes
captive
because
your
time
expired
or
something
like
that,
I
don't
think
we
can
guarantee
that
you
always
have
a
probe.
That's
going!
That
is
gonna
come
back,
so
you
may
hit
a
redirect
sometime
later
for
some
totally
legitimate
traffic.
A
J
J
I
J
I
The
trust
model
for
the
the
HTTP
redirect
is
different
from
from
DHCP
and
R
is
a
smart
tofu,
because
many
many
hops
off
link
might
enter
interact
with
whatnot.
We
would
have
to
have
some
guidance
for
this
link.
Relation
saying
that
browsers
were
not
really
supposed
to
do
anything
with
it,
except
pass
it
off
to
an
operating
system
component
for
subsequent
evaluation.
Yeah.
Is
that
that
kind
of
thing
that
happens.
H
B
D
I
understand
what
he's
saying,
I
think
what
Lorenz
I
was
saying
was
something
different,
which
is
that
you
make
a
request
with
an
expectation
to
be
receptive
to
receiving
one
of
these
things.
And
when
you,
when
you
are
receptive
to
one
of
these
things,
then
it
has
meaning
yeah
in
every
other
context.
So
here.
N
D
Just
look
at
this
and
go
link
relation
like
they
do
with
all
of
them
just
about,
and
that's
fine
I
think
that's
actually
a
property.
We
would
like
it
out
of
this,
which
is
that
unless
you're,
specifically
looking
for
this
information,
you're
not
going
to
do
anything
about
it,
I
think.
I
I
H
I
J
K
Just
the
the
conversation
about
having
a
very
like
the
specific
probe,
that
this
is
a
connection
in
which
I'm
trying
to
detect
a
captive
portal
and
I
only
want
that
response.
If
I'm
I
only
want
to
use
that
response,
if
I'm
doing
this,
it
makes
me
concerned
that
you
know,
if
we
add
the
definition
of
the
link
relation
and
someone
just
sees
the
definition
and
they
see
come
back
and
they
don't
read
that
part
of
the
document
that
yeah
they
could
end
up
doing
the
browser
not
at
the
system
level
yeah.
K
But
does
this
mean
that
if
we're
doing
our
captive
probe,
should
we
add
in
like
the
accept
header
for
cap,
the
captive
API
JSON,
like
essentially
like,
do
a
probe
for
the
API
as
a
next
step
thing
like
when
the
other
side
detects
that
are
like?
Oh,
this
is
apparently
what
you
want
to
get
redirected
to
it's.
This
I
think
why.
J
L
So
Warren
Kumari
I
mean
maybe,
but
the
thing
is
a
lot
at
the
moment.
A
lot
of
we'll
spend
a
lot
of
time,
trying
to
figure
out
what
the
captive
portal
probes
are
and
do
special
handling
for
them
with
whitelists
and
blacklists
and
things
if
you
now
include
a
thing
being
like
hey.
This
is
a
captive
portal
probe.
Then
they've
got
less
work
to
do
this
may
be
a
feature
or
about.
O
The
point
earlier
about
some
only
using
the
link
relation
if
we
think
that
we
may
have
lost
a
captive
portal
is
interesting,
because
it
means
that
you
know
we
use
the
link
relation.
It
comes
back
from
a
probe
and
then
any
other
time.
We
only
use
it.
If
we
had
previously
seen
one
from
a
probe.
We
could.
M
M
O
J
I
think
that
was
one
of
the
reasons
why
I
probably
didn't
even
put
the
push,
because,
as
I
started,
writing
it
I
mean
this.
Actually,
literally
apart
from
just
I,
guess,
registering
the
link
relation.
We
will
probably
have
to
have
a
huge
section
about
deployment
guidance
or
you
know
security
consideration,
some
things
somewhere
is
that
in
the
architecture
or
in
the
API
document,
I
don't
know
where
the
right
place
is.
If
we
do
decide
to
even
consider.
J
I
O
Updates
to
the
captive
portal
architecture
between
now
and
the
O
2
and
O
one
version,
alright.
So
first
I'm
going
to
summarize
changes,
I'm
going
to
talk
a
little
bit
about
the
signaling
protocol,
we've
introduced
and
then
just
finish
off
discussing
some
open
issues
and
questions
that
come
up.
Let's.
P
O
O
O
The
last
ITF
there's
a
bunch
of
debate
about
using
ICMP
to
signal
that
your
captive
and
I
correct
me
if
I'm
wrong,
but
we
decided
that
rather
than
try
to
solve
that
problem
in
the
architecture
document,
we
would
sort
of
just
describe
at
a
higher
level.
We
want
that
protocol
to
do
and
then
move
make
it
optional
so
that
we
could
actually
deploy
captive
corals
without
if
we
need
to
and
then
finally
move
any
specification
of
it
into
a
separate
document
so
moving
forward.
O
So
the
requirements
before
the
document
are
essentially
that
it's
not
easy
a
spoof,
so
you
can't
just
have
it
coming
from
randomly
on
the
internet
that
you
can
send
it
before
the
portal
closes
to
inform
the
user
that
there's
a
pending
expiry
that
and
those
are
sort
of
the
two
main
ones.
Another
one
is
that
there
was
I
hope,
I
didn't
misinterpret
you
Lorenzo.
O
There
was
minimal
information
in
the
message.
That
means
that
really
keep
it
simple,
just
give
enough
information
to
the
user
equipment
to
make
the
decision
it
needs
to
go
whether
or
not
is
captive,
whether
this
stuff's
going
to
expire,
etc.
I
added
some
requirements
around
being
able
to
identify
the
source
of
a
signal
in
order
to
validate
it
later.
It's
debatable
whether
that's
actually
necessary
and
I
think
I'm
going
to
discuss
that
a
bit
at
the
end
of
the
presentation.
O
I
mean
finally
I
added
a
requirement
about
it
not
needing
to
be
reliable
and
I
wanted
people
who
implement
the
protocol
to
be
aware
that
it's
not
TCP
signal
necessarily
it
could
be
something
like
ICMP
or
it
could
be
something
like
a
uep
packet
and
that
they
should
be
aware
that
I
just
get
lost,
and
you
know
if
the
user
you're
cooking
keeps
on
trying
to
connect,
keep
trying
to
send
a
message
if
just
yeah
be
smart
about
it.
I
They
would
do
that
as
often
as
they
are
able,
and
so
my
fear
was
that
we
would
be
forced
to
tie
the
expiration
date.
The
time
left
on
the
clock
at
to
actual
expiration
in
the
sense
that
we'd
have
to
run
a
probe
and
determine
that
we
were
actually
locked
in
again
before
we
would
have
honored
that
so
I
don't
know.
If
this
fear
is
justified
or
well,
could
we
do
something
to
mitigate
it?.
O
K
Polly
Apple,
so
for
the
expiry
bites
or
time
in
the
API,
my
thought
was
not
that
one
should
prompt
at
all.
But,
for
example
like
if
you
had
a
page
that
was
like.
Oh
here's,
your
network
settings,
you
can
have
essentially
say
the
network
said
you
have
this
much
time
left
here
is
a
link
to
the
portal.
If
you
want
to
of
your
own
volition,
click
on
it
and
if
you
say
oh
yeah,
that
30
seconds
is
bogus,
then
you
won't
do
it,
but
essentially
it's
I
paid
for
an
hour.
K
K
You
could
represent
it
in
the
same
way,
but
if
we
have
an
API
I'm,
not
sure
what
the
value
of
a
signalling
on
the
wire
is
before
a
portal
code,
because
like
how
long
before
a
portal
closure
should
that
come,
and
so,
even
if
it's
not
necessary
pestering
the
user,
are
we
encouraging
people
via
this
mechanism
to
pester
the
radio
on
the
device
and
just
send
packets
to
wake
up
the
devices?
Hey,
hey.
B
K
O
I
O
And
I
guess
it's
a
little
more
impactful
when
it's
actually
interrupting
the
connection
as
well.
So
so
so
I
think
the
idea
with
the
Signum
protocol
is
that
it's
potentially
more
reliable
and
that
is
coming
from
the
thing
that's
actually
making
this
decision
I
want
to
wanted.
One
of
the
big
points
is
that
if
you
keep,
if
you
make
all
the
decisions
centrally,
it's
a
lot
harder
to
make
misconfigure
a
lot
harder
to
mess
up
so
I
mean
that
maybe
that's
part
of
the
reason
behind
it.
O
Regarding
the
the
is
a
little
blurb
in
the
giraffe
talking
about
why
we
have
that
and
it's
to
make
the
make
a
more
seamless.
So
you
don't
lose
connectivity
first,
so
maybe,
rather
than
you
know,
I
you
can
I
guess
it'll
be
up
to
the
UI
to
decide.
Okay,
well,
the
API
or
maybe
I
said
we
have
10
minutes
to
expiry.
Let's
maybe
do
something
in
9
minutes.
It's.
L
So
yeah
I
guess
I
was
gonna,
make
something
similar
captive.
Portals
can
currently
do
this
and
some
of
them
do,
but
it
seems
that
having
an
ability
to
at
least
signal,
you
should
come
back
and
look
at
the
API
piece
would
be
useful
because
I
mean
some
captive
portals.
You
sign
up
for
an
hour
and
the
timer
starts
now
and
continues
running
for
sixty
minutes
and
then
stops.
L
Otherwise
you
sign
up
for
an
hour
and
then,
if
you
decide
to
leave
the
hotel
and
go
to
Starbucks
and
get
some
coffee
and
come
back,
the
timer
stops
and
when
you
reconnect
having
a
you
know,
you
should
come,
have
a
look.
You
thought
you
only
had
15
minutes
left.
You
now
actually
have
45.
We
could
also
agree
that
the
user
will
only
be
annoyed
if
the
timer,
you
know
with
the
you
should
probably
log
in
again.
If
the
timer
says
that
it's
less
than
five
minutes
or
maybe
something
that
the
user
says.
L
I
I
so
I,
don't
think,
there's
an
incentive
for
the
captive
portal
operator
necessarily
to
ask
the
user
to
go
to
the
API,
and
they
the
only
thing
that
the
only
thing
that
you
know
appears
to
me
to
be
an
incentive
for
the
us
operators
is
to
show
the
user
stuff.
Everything
else
is
caught
and
so
I
think
if
we,
if
we
get
prompted
to
go
to
the
API,
even
if
it
results
in
us,
you
know
burning
packets,
I,
don't
see
a
lot
of
harm
in
it.
I
Most
will
update
our
idea
of
what
the
JSON
values
are,
including
perhaps
time
left
on
the
clock
and
if
those
don't
actually
result
in
you
know
please
for
attention
to
the
user,
then
maybe
that's
fine
right.
You
know
it
Tommy's
point.
We
just
update
our
clock
with
our
new
idea
of
what
the
clock
is
so,
but
you
know
that
was
one
of
the
thing.
One
of
the
points
I
think
we'd
made
and
Chicago
I
think
was
it.
Where
are
we
or
maybe
London?
Where
we
said?
I
O
M
This
is
dkg,
so
I
just
wanted
to
ask
that
we
think
clearly
about
the
sort
of
power
structures
that
we're
putting
in
place
here
and
I
tend
to
agree
that
providing
the
signaling
protocol
to
happen
after
the
fact
puts
a
lot
more
power
in
the
hands
of
the
network
operator.
And
if
we
say
that
you
only
get
this
during
connection,
then
the
network
operator
basically
has
to
state
something
and
then
stick
to
it
right.
M
It
negotiates
something
during
that
during
the
registration
phase,
I
might
be
using
the
wrong
term
there,
but
right
during
that
during
the
phase
where
the
user
interacts
with
the
captive
portal
and
it's
committing
to
something
that
the
user
and
the
user
agent
is
going
to
keep
track
of
and
we'll
do
the
right
thing
appropriately.
Now,
if
you
want
to
do
during
the
negotiation
phase,
tell
the
user
I'm
gonna
register
you,
but
only
for
two
and
a
half
minutes.
M
You'll
come
back
and
look
at
an
ad
in
two
and
a
half
minutes,
then
the
user
can
say
I'm.
This
network
is
not
functional
for
me
and
be
done
if,
instead,
it
says
sure
sure
go
ahead.
I'm
registering
you
for
an
hour
and
then
it
comes
back
two
and
a
half
minutes
later
and
says:
Bo
you
got
to
check
it
out.
Something
then
I
think
that's
a
problem
and
so
I
think
we
can.
This
is
something
that
will
be
more
useful
for
the
users.
It's
a
negotiation.
If
the.
O
If,
when
we
you
know
in
the
API,
we
are
a
little
more
strict
about
changing
time'
right,
if
it's
also
is,
it
is
weird
discontinuity
in
the
in
the
remaining
time
when
you
go
and
visit
indicate
something's
wrong,
but
I
mean
you
know
you
go
and
Eve
it.
What's
that,
what's
the
damage
of
going
to
visiting
the
API
again
aside
from
cell
power,
API
is
different
from
the
web
portal,
so
that
was
Lorenzo's
point
is
that
we
need
to
make
sure
this
is.
This
is
a
signal
for
the
headless
portion
of
the
program.
M
Wise
has
a
limited
set
of
resources
right,
whether
it's
my
brain
or
whether
it's
my
smartphone
or
whatever,
that's
battery.
That's
radio,
that
what
all
of
that
right
when,
when
the
network
comes
back
to
me
and
says,
hey
I,
need
you
to
do
this
thing.
You're
burning
my
resources
and,
if
I'd
negotiated
with
you
to
not
you're,
not
gonna
burn
my
resources
for
the
next.
You
know
X
amount
of
time
I'm
choosing
to
do
it.
I
want
you
to
stick
to
that.
N
So
yep
you,
sir,
so,
given
that
we
have
an
API,
we
are
designing
an
API
portal
that
it
runs
on
HTTP
that
it's
trusted.
So
this
looks
a
bit
unsecure
to
me
to
rely
too
much
on
such
a
signalling
protocol.
So
for
me
it
would
really
be
useful
in
case
there
is
some
synchronization
issue
between
the
API
portal
and
the
network.
For
some
reason
you
know
load
balancing
in
your
network.
N
So
yeah
when
you
send
a
packet
that
packet
has
to
be
dropped
by
the
enforcement
point
yeah,
it
seems
fair
that
it
would
send
you
an
ICMP
message
telling
you
oh
you're,
captive
and
probably
go
to
the
API
portal
that
you
already
should
know.
The
URI
for,
like
URI,
should
not
be
in
the
ICMP
message.
Otherwise,
it's
an
attack,
vector
and
and
I
would
be
fine
with
you.
You
know
that
would
be
an
information
if
you
actually
get
such
an
ICMP
message
and
your
connection
is
running
fine.
Why
would
you
do
anything?
N
L
So
Warren
Kumari
I
think
that
there
is
some
incentive
for
people
to
play
any
games
here.
So
unless
and
I
don't
quite
know
where
this
goes,
maybe
architecture
doctor
when
I
come
along
and
I
join
the
Fairmont
Network
and
it
pops
up
a
captive
model.
And
then
it
says
you
have
access
for
47
years.
You
should
come
back
every
30
seconds
in
check
or
they
use
this
to
signal.
L
Come
back
and
check
now,
I
go
to
the
Hilton
and
various
other
hotels
and
Starbucks
and
wander
around
and
the
whole
time
I'm
checking
in
for
the
next
47
years
to
tell
them
exactly
where
I
am
so.
We
need
to
make
sure
that
the
captive
portal
information
stays
scoped
to
the
network
that
you
actually
join
and
doesn't,
and
that's
not
actually
I,
don't
think
that
that's
actually
written
in
a
document.
It
seems
common
sense.
I
Think
we
have
to,
we
have
to
accept
the
sad
reality
that
there
is
no
enforcement
of
anything
that
is
in
the
API
at
all
right,
because
the
user
doesn't
see
it
and
therefore
they
can't
keep
anyone
honest
right,
the
only
thing
that
you
know
so
so
to
my
point
about
you
know
to
the
earlier
point
about.
We
should
only
do
this
on
on
initial
signaling
there's
nothing
in
initial
signaling,
which
makes
this
remotely
trust
work
at
all.
I
The
API
is
just
there,
for
you,
know,
information
and
you
can't
trust
any
of
it,
because
the
user
is
not
in
a
position
to
to
it
to
enforce
any
of
it
or
to
keep
anyone
on
this.
So
I,
don't
I,
don't
see,
there's
a
lot
of
ways
that
networks
can
use
your
battery,
they
can
send
you
packets
and
they
cause
you
to
drop
them
and
something
will
on
your
device
will
wake
up
when
you
do
that,
even
if
it's
just
the
chipset,
it
still
does
wake
up,
and
so
they
can
find
you
with
packets.
I
They
can
do
all
sorts
of
stuff
and
I
think
if
we
don't
give
them
incentive
to
do
that.
It's
just
gonna
be
more
trouble
than
it's
worth
for
them
to
attempt
it
so
I
don't
see
yeah.
So
if
all,
if
all
that
happens,
when
we
do
this
ICMP
is
we
hit
their
URL
and
ask
for
Jason,
then
we're
just
like
they're
just
imposing
costs
on
themselves
to
do
X
or
SSL
handshakes
for
no
benefit
because
yeah
we
update
our
idea
over
the
timer.
That's
left
on
the
clock.
I
K
Tommy
Paulie
two
points
here,
one
just
to
what
Lorenzo
was
saying.
You
could
imagine
that
if
there
is
information
in
the
API
like
expiry
time
or
something
else,
simply
the
moment
you
get
through
the
portal
and
we're
like
hey
we're
good
now
the
system
could
give
a
summary
of
like
hey,
you've
joined
this
network.
It
says
you
have
this
much
time
left,
and
that
is
the
opportunity
at
which
user
says,
but
I
paid
for
an
hour-
and
you
say:
I
only
have
this
so
like
it's
potentially
a
way
to
confirm.
Is
that
useful?
K
Is
that
spoof
able
sure
the
other
point
kind
of
basic
info
is
what
peer
was
saying
earlier:
I'm,
not
totally
sure
about
all
the
deployment
models
and
someone
like
David
burger
would
be
able
to
help
with
this
better.
But
when
we're
looking
at
the
indication
before
portal
closure,
that
assumes
that
the
thing
that
is
giving
the
signaling
like
ICMP
is
aware
of
the
kind
of
the
long-term
state
of
these,
and
when
it's
going
to
close
I
could
imagine
an
architecture
in
which
the
thing
that
is
sending
the
ICMP
are
the
redirects.
O
I
Why
would
we
even
send
before
portal
closure
right?
You
know
if
we,
we
are
absolutely
100%,
Craven
and
sent
it
like
if
we,
if
we,
if
we,
if
we're
gonna,
present
that
to
the
user
in
terms
of
a
captive
portal
login
page,
it's
gonna
be
a
disaster
right,
because
you
know,
because
you
know
they're
just
gonna-
do
that
every
20
seconds
I
think.
O
What
issue
I
mean
like
trying
to
consider
like
the
there
are
some
people
in
here
a
while
back
talking
about
the
telecom
use
cases
where
something
you
know
you're
inspected
with
a
virus,
and
they
want
to
tell
you
that
you're
infected
with
a
virus
right
now,
they're,
just
sending
you
a
302
redirect
to
a
random
like
HTTP
access.
Well,.
O
I
So
let
me
summarize
a
conversation
that
we
had
with
a
apparently
quite
competent
captive
portal
operator
right.
The
only
thing
that
their
customers
wanted.
The
only
reason
why
they
were
providing
free
Wi-Fi
at
all
was
that
they
got
to
show
the
user
a
page
at
the
end
of
the
captive
portal,
signing
work,
sign-in,
okay
and
they
hate
our
guts,
because
we
closed
that
page
as
soon
as
they
unlock
the
portal
right
they
and
so
right.
So
they
were
basically
saying
that
makes
it
like
entirely
useless
to
us
from
that.
I
I
It's
basically,
you
know
and
I
think
literally
the
yes
capital
portals
can
lock
on
you
today,
but
what
they
do
is
they
cause
themselves
collateral
damage,
because
you
know
you
E's
can
switch
away
from
their
network
and
it
also
provides
irritating
stuff
to
irritation
to
the
user
when
they're
browsing
and
they
get
interrupted
and
it's
a
disincentive
for
them.
If
we
just
give
them
a
free
incentive,
then
they're
gonna
use
it
so.
L
Warren
Kumari
I
mean
I.
Think
that's
exactly
my
point.
Is
that
users
don't
like
it
when
their
captive
portal
suddenly
stops
like
the
destination
unreachable
as
being
a
good
signal?
I,
don't
like
that
idea,
cuz
I'm
on
a
FaceTime
call,
or
you
know,
Google
Hangouts
call
with
my
wife
and
suddenly
it
stops
and
dies
in
the
middle
of
an
argument,
and
she
figures:
I
hung
up
on
her
I
would.
R
I
In
at
certain
myself
and
the
queue
there,
it
might
be
that
you
can
get
your
time
remaining
warning
from
the
system
because
it
got
it
out
of
the
captive
portal
API
and
not
from
destination
and
reachable
zand.
One
thing
one
very
hypothetical
thing
I
would
put
to
the
room
for
consideration
is
what,
if
we
just
stick
with
the
existing
ICMP
destination
and
reachable
as
the
enforcement
thing
when
they
want
to
shut
connections
down,
we
remove
signalling
protocol
altogether
and
replace
it
with
a
recommendation
that
operating
systems
provide
a
mechanism.
I
L
I
L
So
the
earlier
thing,
if
they
can
just
keep
popping
things
up
the
reason
that
captive
portals
don't
currently
said
a
one-minute
time
out
is
because
users
will
get
annoyed
and
wander
off.
All
I
was
suggesting
is
the
signaling
thing
we
could
ignore
it
until
we
think
that
there's
only
a
small
amount
of
time
left,
although
that
breaks
yeah
when
you
lose
state,
okay,.
L
N
Basically,
just
repeating
what
has
been
said
already:
sorry,
it
was
just
before
it
looks
like
a
cmp
destination.
Unreachable
is
the
thing
that
we
are
looking
for.
I
we
could
add
a
new
type
like
you
are
captive
type,
to
give
a
little
bit
more
information
about
the
reason
why
the
packet
was
dropped.
Not
Monday
did
I
mean
if,
if
and
all
the
router
wants
to
use
the
destination
or
reachable
for
some
other
types
might
make
sense
and
it
Lauren.
N
So
so,
when
you
log
in
when
you
log
into
the
portal
you
you
pay
for
something
for
some
time
and
and
that
time
should
be
the
one
that's
even
by
the
API
and
you
shouldn't
have
to
connect
again
and
again
and
again,
every
time
you
get
an
ICMP
message.
That's
what
you're
looking
for
I!
Think
that's
what
you
that's!
What
you
asked
for
to
make
sure
that
the
hose
doesn't
need
to
do
more
connections
that
what
the
API
asked
for
and
if
the
API
says
oh
you're,
only
allowed
for
30
seconds.
N
I
Personally,
I,
don't
care
about,
like
I
can
hit
the
API
every
five
seconds.
No
one's
gonna
make
me
do
that
no
one's
gonna
care
unless
there's
an
incentive
in
the
form
of
like
annoying
the
user
with
an
ADD
and
in
that
case
I
promise
you
they're
gonna,
do
that
and
that
that's
the
thing
I'm
trying
to
I'm
trying
to
ensure
here:
I,
don't
care,
you
know.
If
we,
if
we
get
a
signal,
hit
the
API
sure
we'll
update
our
counter,
because
our
clocks
might
have
drifted
I,
don't
know
who
cares?
I
I
My
point
to
that
is,
like
I
said:
we
can't
have
nice
things,
and
so,
even
if
it
says
30
seconds,
we're
just
gonna
ignore
it
right.
I
mean
I.
I
mean
like
the
only
the
only
way
I
see
around.
This
is
Tommy's.
Suggestion
says,
like
the
summary
says,
you're
an
hour
logged
in
for
an
hour
and
then
the
user
might
get
pissed
off.
I
What
do
we
do
right
and
my
point
is
I-
think
we
have
to
design
this
with
an
adversarial
mindset
right
and
so,
like
I
said,
I,
don't
care
if
we
hit
the
API
every
time
every
twenty
seconds,
because
no
one's
gonna
make
us
do
that
because
it's
just
like
it
couldn't
increase
the
load
on
their
server
and
they're.
Not
gonna.
Do
that
right!
So
there's
no
point:
there's
there's
no
attack
vector
there.
The
attack
vector
there
is
the
attack
vectors
in
terms
of
user
attention.
J
So
I
think
I'm,
maybe
I'm
missing
it,
but
I
think
I
just
wanted
to
point
out
that
when
we
talk
about
the
you
know
is
that
a
captive
you
are
either
logged
in
or
not
I
don't
think.
Logging
in
is
actually
always
a
binary
stay.
You
may
be
like
when
you
connect
your
captive
portal.
You
miss
is
like
okay,
you
chose
the
free,
low
speed
connection
right
and
if
you
try
to
connect
on
Netflix,
it's
gonna
block
you
right.
It's
like
you're
not
allowed
to
stream
blocked
Netflix.
J
D
D
I
I
Like
passionate
emails,
I
could
like
rail
at
people
risk
being
banned
from
the
list
like
you
can
do
it
as
well,
and
you
could
do
it
as
well,
and
then
we
have
this
great
argument,
say:
okay,
there's
no
hope
of
ever
reaching
consensus
on
this.
Let's
declare
it
out
of
scope
forever.
So
my
understanding,
my.
D
Understanding
was
that
we
wouldn't
we
wouldn't,
engage
on
this
topic.
For
that
reason,
if,
if
people
think
that
I'm
wrong
come
and
talk
to
me,
private
come
talk
with
me
privately,
but
my
understanding
was
that
when
we,
when
we
built
this
yeah,
the
expectation
was
that
any
such
information
of
that
nature
will
be
left
to
communication
between
the
the
network
operator
and
the
users
using
the
captive
portal
pages.
Or
what
have?
What
have
you
and
we
wouldn't
provide
any
specific
mechanisms
in
support
of
those.
O
Sorts
of
things
I
think
the
problem
comes
when
we
have
a
mechanism
that
seems
to
offer
some
benefits,
but
also
has
some
downsides,
but
then
one
of
the
possible
benefits
that
is
really
strong
for
it
is
the
is
this
use
and
I
guess
we
just
need
to
strike
that
benefit
from
consideration.
If
we're
going
to
I
wasn't.
O
J
Wasn't
a
suggesting
that
we
need
to
do
anything
about
you
all
I'm
saying?
Is
we
just
history
to
account
for
the
fact
that
that's
a
reality
right
and
whatever
we
say
recommend
in
here
has
to
occur
at
least
say
something
that
something
like
that
could
happen,
and
you
do
blah
right.
We
don't
deal
with
it,
but
you
at
least
have
to
mention
it.
I
know,
I
know
if
you're
not
gonna
get
any
consensus.
L
So
we're
enquiry.
I
can't
tell
if
this
as
part
of
that
third
rail
subject
or
not
I
get
on
a
United,
plane
and
I
connect
to
the
network,
and
it
gives
me
automatically
the
pretty
thing
that
tells
me
how
far
the
plane
is
and
streaming
from
their
internal.
You
know
thing
of
movies
versus
connect
to
the
internet.
Is
that
a
differentiation
of
surface
or
no,
because
one
sort
of
thing
behind
the
capture
pole
and
one
isn't
right,
like
I
get
internet,
but
the
Internet's
is
very
limited
to
just
the
stuff
on
this
plane.
I.
I
Mean
I
think,
okay,
so
too
much
to
the
earlier
point.
This
is
this:
is
you
know
this
is
the
reality
of
things?
You
know
it
also.
It's
also
a
reality
that
we
can't
write
anything
unless
you
get
rough
consensus
on
it
and
certain
topics
they're,
just
like
no
point
in
discussing
them,
because
we
know
they're,
not
they're,
not
going
to
result
in
consensus,
because
we've
had
those
discussions
recently
and
frequently
and
we
just
end
up
with
the
same
conclusion.
I
I
That's
inside
the
portal
and
that's
it's
available,
regardless
of
whether
the
portal
is
unlocked
or
not,
and
the
intern
right
and
I
think
you
know
we
can
probably
on
that
I
don't
know
I,
don't
think
we
can't
ruin
anything
else.
So
we
might
as
well
say
look.
It
is
out
of
scope
and
we're
because
I
don't
I,
don't
know
if
we
can
say
there's
no
consensus
or
we
could
say
look
you
know
it
raises
count.
Isn't
there
are
some
IAB
document
that
we
can
point
you
or
something
that's
already
written
down
that
says.
E
K
So
I
think
we
should
have
as
a
requirement
to
ourselves
that
any
solution
that
we
come
up
with,
which
is
less
bad
for
Internet
or
not
captive
portals,
is
also
less
bad
for
the
other
ones,
so
doing
something
in
our
architecture
or
in
a
protocol
that
actually
limits
or
harms
those
use
cases
in
ways
that
we
don't
need
to
make
those
use
cases
much
much
better.
But
we
need
to
make
sure
that
we
don't
make
them
worse.
What
I'm
concerned
about
with
the
signaling?
K
Everything
I
can
possibly
do
or
want
to
do
with
the
portal
and
I'm
still
blocked
on
Netflix,
and
so
the
fact
that
Netflix
gives
me
an
ICMP
or
some
signal
should
not
cause
me
to
do
anything
more
because
that
is
potentially
this
good,
steady
state.
So
that's
my
concern
with
the
signaling
protocol
is
that,
if
we're
assuming
that
some
signal,
that
your
your
being
blocked
by
a
captive
portal
implies
that
you
need
to
go
and
do
something
more
is
I
think
an
incorrect
assumption.
K
The
reason
I
like
the
API
more
than
the
signaling
and
more
than
even
today's
redirect
model
is
that
it
truly
separates
them
outright
says
there
is
a
path
and
the
API
is
not
about
employment,
as
we
are
going
on
with
David
bird
on
the
list.
Api
has
nothing
to
do
with
enforcement.
It
is
only
a
bootstrap
for
user
experience
and
I
think
that's
actually.
What
we're
trying
to
solve
the
enforcement
model
is
not
something
actually
I.
O
Wanna
make
sure
I
understand
your
point
so
regarding
Netflix
and
instance,
a
state.
So
the
idea
is,
the
user
leaves
they've
connected
the
portal,
they've
chosen
their
plan
and
that's
it
and
you
know
they
know
that
Netflix
isn't
gonna
work
but
for
some
reason
they
have
a
window
open
and
is
just
trying
to
connect
Netflix
in
the
background,
and
they
just
don't
care.
So
why
would
you
pop
something
up?
Just
gonna
annoy
them.
I
Netflix
doesn't
work,
it's
an
outage
right
if
they,
if
the
user
expects
that
outage,
then
that's
fine,
I
mean
I,
agree,
I,
agree
with
Tommy,
I,
think
and
also
I.
Don't
think
we
can
I,
don't
think,
there's
anything
we
can
do
about
these
partial
connectivity
use
cases
we
can
I.
We
certainly
can't
make
them
worse
because
they're
just
gonna
be
the
operators
just
gonna
make
you
know
continue
to
do
whatever
they
need
to
do
in
order
to
enforce
their
business
models
right.
We
can
try
to
make
other
stuff
better.
I
We
can't
try
to
make
this
stuff
better
because
we
can't
agree
on
it
so,
and
you
can't
make
it
worse,
we
can't
make
it
better,
I
think
in
the
case
where
the
user
paid,
for
you
know
the
non
video
streaming
service
right,
they
there's.
No,
there
isn't,
there's
I,
don't
understand
what
will
be
gained
from
a
protocol
to
tell
them
you're
going
to
Netflix,
and
you
could
pay
more.
If
you
wanted
to,
we
have
the
API
for
the
URL
for
the
user
interaction.
I
O
It
to
us
I
guess
the
one
nice
thing
would
be
if
the
failure
was
a
little
more
explicit
like
just
no
I
mean
just
more
like,
rather
than
just
hanging
and
waiting
and
waiting
and
waiting
or
mine,
sh
t
I
could
fail
randomly
it
just
just
fails
and
then
that's
where
maybe
what
Eric
was
saying
earlier,
it
was
anyways
Eric
who
said
it
that
the
ability
of
an
application
to
request
the
OS
to
validate
the
network
and
I
said
I
kind
of
like
that.
Just
but.
I
L
So
Warren
Kumari-
maybe
this
is
already
covered-
or
maybe
it's
too
much
UI,
but
what's
often
happened
to
me
as
I've
gone
along
to
a
hotel
and
I
connect
to
the
capture
portal
and
it
says
for
free,
you
can
get
internet
access
at
one
Meg
for
$9.99.
You
can
get
it
at
10.
Meg
like
I,
had
I
want
to
pay
10
Meg
when
you
nine
a
night,
so
I
get
the
free
one
and
then
I
discovered.
L
That
was
not
a
good
option,
because
there
one
Meg
is
not
actually
one
wreck
and
then
I
can
never
actually
find
the
captive
portal
thing
again.
So
it
would
be
really.
Nice
is
I,
guess
that
this
is
a
UI
thing
or
something
where
I
can
then
click
on
a
button
and
be
like
what
was
that
URL
again
cuz
I'd
like
to
upgrade
now.
Please.
N
I
also
I
really
don't
see
the
issue
that
we
are
right
now
like.
If
the
user
tries
to
connect
to
netflix
and
that's
not
provided
by
a
service,
there
is
an
ICMP
return
message:
it
doesn't
egg
out.
The
connection
is
just
closed,
because
there
is
the
ICMP
error
you
can
display
it
in
the
browser
or
whatever
in
whatever
way
you
want.
If
the
ICMP
message
actually
is
you
are
captive,
then
you
can
display.
N
I
Lines
are
clearly
not
instead
of
well
mostly
related
we.
So
we
we
encountered
a
captive
portal
where
the
user
signed
into
the
messaging
plan,
which
included
I,
don't
know
what
and-
and
we
know
that
it
included
Google
comm,
because
the
Google
Search
app
was
telling
us
quite
regularly
that
they
had
connectivity,
and
then
there
were
the
other
apps
that
were
telling
us
and
we
do
have
such
an
API
to
report
internet
continue.
There
are
other
apps
that
we're
telling
us
we,
we
really
don't
have
connectivity
and
unfortunately,
the
probe
that
we
do
for
Internet.
I
Connectivity
includes
a
random
element
and
some
of
those
were
302
and
some
of
them
were
not,
and
so
he
ended
up.
We
ended
up
and
the
bug
that
was
followed
was
I.
Keep
getting
prompted
for
access,
but
I
already
signed
into
everything.
I
signed
into
I
wanted
the
messaging
plan
get
on
my
way.
I,
don't
know
how
to
fix
that,
but
yeah
so
and
I.
Don't
think
this
would
help
to
be
honest
right.
D
So
I
think
we've
run
that
one
to
ground
and
there
seems
to
be
pretty
pretty
strong
consensus
about
this.
One
I
think
the
conclusion
there
was
that
we're
not
making
things
worse
and
I've
put
in
I
put
an
issue
in
on
the
on
the
architecture
draft
to
simply
state
explicitly
what
we're
doing
and
what
we're
not
doing.
With
respect
to
this
sort
of
news
case
and
I
think
that'll
be
relatively
straightforward.
To
do.
R
D
D
O
All
right
moving
on
okay,
so
some
open
issues
and
questions
that
aren't
the
ones
we've
been
talking
about.
So
there
was
a
issue
open,
saying:
hey.
We
need
a
way
to
indicate
that
there
is
no
captive
portal,
so
we
can
just
go
on
Eric.
Has
that
in
the
draft
I
think
you
actually
answered
my
question
on
github
today
and
I
think
I
noticed
in
the
API,
no,
the
in
the
PVD
document.
There
is
also
a
note
about
it.
You're
always
right
slice,
yeah,
so
I
think
probably
can
just
close
that
issue.
O
There
was
also
something
we
had
some
language
in
the
draft
talking
about
PVD
and
now
that
pierre
has
nicely
provided,
one
I'm
assuming
it
gets
adopted.
I
think
I
can
probably
clean
that
text
up
and
get
rid
of
the
issue.
There
is
a
section
talking
about
the
backwards
compatibility
of
signals.
In
particular
it's
talking
about
how
you
know
a
portal
might
choose
to
continue
to
do
redirects
as
well
as
do
signals
I.
Think
I,
don't
know
what
we
want.
O
O
I
What
is
the
section
give
us
except
an
opportunity
for
disagreement?
I
mean
I,
don't
disagree
with
it,
but
you
know
I,
don't
think
it
also
provides
a
lot
of
information.
It's
like
yeah.
You
could
do
this
sure.
Of
course
you
could
and
also
saying
you
should
implement
this
RFC
in
the
RFC
itself
is
like
a
you
must
read.
O
O
O
D
D
J
D
O
K
N
If
you
imagine
that
signaling
protocol
that
can
come
out
of
the
blue
from
anywhere
anybody
that
knows
your
source
address,
even
though
it's
a
hint
that's
going
to
be
an
issue
that
anyone
can
send
you
that
all
your
captives
signal
from
anywhere,
if
it's
nicely
mPHA
below
that,
and
that
you
need
to
make
sure
that
it
comes
from
the
path
and
that
it's
related
to
an
actual
connection
that
you
are
having
it's
a
little
bit
better.
Just
possibility
would
be
you
know
in
the
API
there
was
the
H
Mak
possibility
that
can
be
done.
I
N
Help
you,
sir
I,
think
there
will
be
cases
where
there
will.
You
know
bugs
going
on
between
the
API
and
the
network
and
as
as
I
said
before,
I
don't
want
the
page
to
just
hang
forever
waiting
for
something
to
happen.
It's
good
to
have
some
message
from
the
network
saying
I'm
the
network.
There
is
something
wrong,
please
you
know
reach
the
API
or,
as
the
user
to
do
something
or
I
mean
at
least
inform
the
device
that
there
was
something
going
wrong
and
it's
because
of
you
kept
you
kept
a
bottle.
L
Warren
Kumari
I
think
removing
everything
about
signaling
might
be
a
bad
thing,
but
saying
signaling
is
out
of
scope
for
now
we're
planning
on
writing
a
document
in
the
future
to
deal
with.
That
would
be
perfectly
fine
with
me,
or
you
know
there
may
be.
Somebody
may
one
day
write
a
protocol
that
does
this
but
like
at
least
showing
that
we
thought
about
it.
So.
O
D
Just
as
a
suggestion
there
that
that
suggests
that
maybe
you
could
lighten
the
requirements
in
the
sense
that
they
could
be
a
little
bit
more
abstract
and
a
little
bit
more
sure
a
little
bit
shorter
and
not
go
into
these
sorts
of
details
in
too
much
at
too
much
length.
But
but
still
say
you
know,
this
is
what
it
the
role
that
would
would
play
in
the
architecture,
but
we're
not
really
describing
a
concrete
manifestation
of
it.
J
Yeah
I
think
I
think
we
need
to
at
least
have
some
statement
and
I
think
probably
it
is
some
some
level
of
character,
it
doesn't
have
to
be
requirements
or
it
can
just
be
characteristics
like
it
should
ideally
have
these.
You
know
these
characteristics
and
that
that
might
be
okay
but
laceration.
One.
O
So
we're
going
down
his
path
of
considering
shrinking
the
scope
with
a
signal.
More
does
right
now,
there's
there's
a
fair
amount
of
text
describing
how
the
signal
actually
works
in
the
work
flow.
If
it
were
there
with
that
also
involved,
just
removing
all
of
that
removed
from
the
diagrams
and
just
have
a
brief,
blurb
saying,
hey,
we
would
kind
of
use
it
to
talk
between
me
for
some
point.
These
are
equipment
kind
of
look
like
this.
It's.
D
Probably
not
the
right
room
to
be
having
that
discussion
without
actually
having
the
text
in
front
of
us
in
the
time.
So
my
suggestion
would
be
that
you
and
those
who
are
interested
go
back
and
have
a
look
at
the
document
and
what
you've
got
at
the
moment
and
make
some
suggestions
on
what
what
might
be
done.
Okay,.
N
Can
I
make
a
suggestion
that
that's
what
I
was
planning
to
do?
Would
anybody
disagree
with
this?
So
we
just
say
that
the
the
network,
the
enforcement
point
should-
or
you
know,
maybe
must
when
it
drops
the
packets,
send
the
destination
unreachable,
ICMP
message
so
just
like,
we
make
sure
that
something
happens.
Another
packet
is
silently
dropped.
That's.
D
A
question
really,
but
that's
a
separate
question,
but
please
we
should.
We
should
talk
about
that,
but
right
now
this
is
about
the
that
the
trigger
for
going
and
fetching
the
API
and
the
requirements
we
have
around
that.
That's
a
separate,
separate
thing
that
maybe
we
should
talk
about
I'd
like
to
get
to
the
answer
on
this
one.
Are
you
happy
taking
an
action
to
to
look
at
the
signaling
stuff
and
seeing
what
you
can
do
to
reduce
the
the
level
of
detail,
perhaps
and
maybe
come
up
with
the
repose
'el
yep?
Okay,.
D
D
That,
as
it
is,
is
anyone
does
anyone
have
any
objection
to
that?
To
that
plan,
cause
gonna
go
and
have
a
look
at
the
draft
and
look
at
the
signaling
that
stuff
and
and
remove
the
landmines
of
this
nature
and
try
to
get
it
down
to
the
essential
parts
and
I
think
you're
close,
but
you've
got
a
lot
of
detail
in
there
and
we'd,
probably
just
lighten
that
bit.
Yeah.
K
All
right,
Tommy
so
should
not
solving
this
problem
but
more
to
go
and
what
Dara
was
saying.
One
thing
we
could
say-
and
you
can
take
this
down
of
the
notes
that
I
think
could
be
helpful,
is
just
silent.
Dropping
is
considered
harmful
and
that's
it
right
like
if
you
have
some
mechanism
that
will
produce
an
error
and
cause
the
connection
to
be
closed
or
redirected
or
whatever
that
isn't
preferred
to
black
holing
traffic,
and
then
we
can
just
stop
there.
D
I
Feel
free
to
ignore
me
because
I'm
gonna
say
something
not
very
helpful
but
and
I
think
my
feeling
is.
The
value
that
we
can
provide
in
this
group
is
in
terms
of
a
protocol
to
try
to
help
clarify
some
sort
of
contract
between
two
different
devices.
It's
really
not
I
think
that
useful
in
this
group
to
tell
captive
portal
operators
how
to
build
what
they've
already
built.
So
you
know
if
we
already
have
text-
and
we
agree
with
that
sure,
but
if
not
I,
think
that's
not
the
value
necessarily
here.
So
you.
I
L
So
war
inquiry
and
I
think
that
this
is
property
on
this
topic,
so
enforcement
stuff,
a
while
back
I,
was
wandering
around
with
an
Ubuntu
laptop
and
I
really
wanted
to
reach
google.com
for
some
reason.
So
I
opened
up
my
laptop
and
I
connected
to
the
captive
portal
and
I
didn't
have
any
internets,
and
I
taked
in
google,
calm
and
sure
enough.
L
It
sent
me
a
destination
unreachable
which
my
machine
decided
was
met,
destination,
unreachable
and
then
I
paid
for
the
CAPTCHA
for
I
could
reach
everything
other
than
google.com,
so
very
careful
with
making
sure
that
you
know
what
signal
we
send
back
or
what
is
suggested
and
what
one
actually
does
with
that.
Yeah
turns
out
clearing
Oh,
like
this
nation,
reachable
that
the
kernels
learnt
is
kind
of
tricky
and
rebooting
is
the
right
way
that.
O
Is
not
good
user
experience?
Okay,
so
so
tiller
ends
this
point.
If
we
talk,
we
should
probably
be
the
case
that
if
we
talk
about
the
be
more
descriptive
than
prescriptive,
when
it
could
term
when
it
comes
to
the
enforcement
point,
we're
just
give
descriptions
of
how
we
think
it's
working
in
order
to
illustrate
the
main
things
we're
doing,
which
is
the
protocol
right
all
right,
I
think
that's
it
any
closing
thoughts.
D
H
D
N
So
hello,
everyone,
I'm
Shep
Reiser,
as
you
probably
noticed
and
I'm
going
to
talk
about.
Thank
you
I'm,
looking
going
to
talk
about
this
new
draft,
which
is
about
discovering
the
CAPTCHA
bottle
API
with
using
provisioning
domains,
and
so
it's
caught
hers
cause
our
twist.
Tommy
wrote
quite
about
everything
in
the
documents
but
I'm
presenting
it,
Thank
You
Tommy.
N
So
this
is
not
something
totally
new:
the
concept
of
provisioning
domains.
It
was
defined
by
the
myth,
working
group,
and
we
discussed
it
quite
a
lot
in
this
working
group.
But
now
is
the
opportunity
to
have
a
deeper
loop,
a
deeper
look
at
it.
Since
there
is
a
there
is
an
actual
document
to
look
at,
so
it's
defined
in
the
architecture
document
RFC
3550,
six
as
a
consistent
set
of
information.
N
Basically,
this
is
the
set
of
things
that
you
receive
from
the
network
that
lets
you
access
the
network.
Now
we
have
an
additional
draft:
the
provisional
domain
in
the
interior
working
group,
which
intends,
which
is
like
two
main
objectives.
The
first
objective
is
to
identify
the
provisioning
domain,
and
for
that
purpose
we
use
fully
fully
qualified
domain
name,
which
means
that,
if
you're
connected
on
one
interface
to
one
Wi-Fi,
you
would
receive
some
notification
telling
you
the
name
of
the
PVD.
So
it's
a
fully
qualified
domain
name
and
on
another
interface,
another
provisioning
domain.
N
You
might
have
multiple
different
provisioning
domains
on
the
same
interface
by
the
mean
of
you,
know,
different
router
advertisements,
meaning
that
they
would
have
different
fully
qualified
domain
names
or
you
could
even
have
the
same
provisioning
domains
on
two
different
interfaces
if
they
ultimately
connect
you
to
the
same
upstream
networks
like,
for
instance,
in
a
hotel
room,
you
get
Wi-Fi
and
wire,
but
in
the
end
the
upstream
connectivity
is
the
same.
It's
the
same
service
that
is
provided
with
the
same
characteristics.
N
So
there
is,
the
idea
would
be
to
let
host
know
that
it's
actually
the
same
service
that
is
provided
and
now
the
the
second
objective
of
the
provisioning
domain
work
is
to
provide
additional
information
about
the
fundamental
properties
of
the
upstream
link.
You're
connected
to
the
way
you
access
the
Internet.
So
that
can
be,
you
know
the
the
service
provider,
the
name
of
the
upstream
connectivity
it
can
be.
For
instance,
we
are
going
to
talk
about
it.
Whether
or
not
there
is
a
capture
photo.
It
could
be
the
the
throughput.
N
So
we
are
not
right
now,
currently
defining
all
that
in
the
in
the
draft
in
the
free
stream
of
that
domain
draft.
But
the
idea
is
to
provide
something
that
is
generic
by
no
mean
of
JSON
objects
that
is
provided
to
you
by
the
network
and
that
lists
the
different
properties
of
the
network
for
the
folder
host.
N
You
know
annoying
to
to
define
a
new
array
or
the
HTTP
option
for
every
use
case,
so
not
saying
that
that
working
group
shouldn't
do
that,
but
we
have
lots
of
cases
where
you
would
like
the
host
to
know
more
about
the
network
and
that
you
don't
want
to
have
to
define
a
new
ipv6
ICMP
option
to
do
that
so
for
the
phase
one.
The
way
it
works
is
that
the
fully
qualified
domain
name
is
put
in
the
router
advertisements
packet
that
you
received
from
your
router.
N
So
in
the
first
in
this
example,
you
have
two
interfaces
with
two
different
routers,
but,
as
I
mentioned,
you
may
have
a
single
router
with
multiple
pvd's,
and
so
this
is
the
option
that
has
been
defined.
You
see.
So
there
is
on
the
middle
of
it.
There
is
activity
ID.
So
that's
the
fully
qualified
domain
name.
N
We
have
a
set
of
bits
that
are
set
or
not
so
the
H
bit
is
the
one
that
is
pretty
important
because
it's
it
stands
for
HTTP
it's
because
it
means
that,
based
on
the
fully
qualified
domain
name,
the
host
is
allowed
to
create
an
HTTP
requests
to
retrieve
the
JSON
objects
which
you
can
see
on
the
other
part
on
the
bottom
of
the
side.
So
that's
an
example
of
a
JSON
object
that
you
can
get.
N
The
other
bits
are
the
L
beat,
which
is
for
a
legacy,
which
means
that
the
provisioning
domain
ID
is
applicable
to
the
ipv4
connection
as
well.
So
it's
compatible
with
ipv4,
although
it
requires
an
router
attachments.
So
you
can
say
that
the
PVD
works
for
the
ipv4
link,
and
then
we
have
other
fields
like
whether
or
not
there
is
a
specific
router
advertisement,
options
that
are
included
in
the
PPID,
so
you
can
play
with
the
options
that
you
want.
N
There
also
is
a
delay
field
that
lets
you
avoid
thundering
herd
problem
when
you
want
to
update
the
DVD
now
for
the
JSON
object,
the
the
the
keys
that
we
have
today
are
the
name,
so
you
can
display
a
fancy
name
to
the
user.
There
is
a
localized
name,
so
you
can
display
a
fancy
name
in
the
language
of
the
user.
N
We
have
a
time
of
expiry
such
that
from
time
to
time
you
can
update
the
JSON
objects,
know
that
time
shouldn't
be
really
often
right,
because
it's
really
about
the
characteristics
of
the
link
and
those
are
not
intended
to
change
all
the
time.
So
the
JSON
object
can
be
seen
as
something
that
is
pretty
stable
over
time.
We
put
a
prefix
in
order
to
validate
that
the
JSON
object
that
you
receive
from
a
server
that
I
didn't
mention
it
yet,
but
we
use
HTTP.
N
So
we
validate
the
fact
that
the
server
is
actually
owning
the
name
that
is
inside
the
PVD,
but
then
that
wouldn't
prevent
an
attacker
for
from
advertising
a
PVD
ID.
That
is
not
that
it
doesn't
her
own.
So
there
is
as
well
the
prefix
there
to
make
sure
that
the
PVD
is
used
on
a
network
which
uses
the
same
source,
addresses
and
configured
addresses,
and
then
we
just
have
an
additional
key
for
saying.
N
If
there
is
internet
access
or
no,
but
that's
not
what
that's
not
what
we
are
going
to
use
for
CAPTCHA
photo
it's
a
bit
different,
because
this
internet
equals
true
or
false
is
really
a
fixed
property.
So
in
the
case
of
a
captive
portal
use
case,
it
would
be
actually
false
like
there
you
would
have
internet
access,
but
there
is
a
CAPTCHA
photo.
So
in
that
case,
in
the
captive
portal
case,
the
key
would
be
a
kind
of
absent
yeah,
so
implementation
status,
it's
been
implemented
for
quite
a
while.
N
Now
we
have
a
daemon
that
helps
the
user
space
application
to
get
information
about
the
object.
There
is
a
patch
for
the
Linux
kernel,
but
right
now
it's
not
abstruse
having
the
our
RFC
published
will
help
with
up
streaming
the
the
kernel
modifications
we
have
IP
route
change.
Wireshark
dissector
are
a
DVD
for
an
OD
HPD
for
open
wrt.
So
just
one
slide
to
talk
about
happily
hotel.
No,
it's
really
simple.
We
are
just
proposing
to
add
an
additional
key
in
the
JSON
object
that
you
get
from
your
network.
N
That
additional
key
is
called
captive
api.
It
gives
you
the
URI
of
the
API
such
that
when
it
is
present,
the
host
would
know
that
it
is
captive
and
that
it
can
connect
to
the
API
to
login
to
the
CAPTCHA,
but
also
really
really
simple,
basically
not
anything
more
to
say
about
the
actual
proposal
for
the
capture
portal
working
group
and
just
to
mention
that
it's
that
simple,
that
we
actually
implemented
it
twice
in
two
different
Agathon,
so
that
was
HF,
101
I
got
on.
N
We
implemented
it
and
demonstrated
it,
and
then
it
was
HF
99
Bacchus
on
yeah
that
so
final
slide
for
discussion
today.
Four
main
topics,
I,
would
guess
whether
we
should
add
an
additional
key,
that's
kind
of
short
the
API
to
go
to
the
UI
faster.
So
that's
one
possibility:
should
we
define
a
way
to
stage
that
there
is
no
CAPTCHA
photo,
so
that
would
be
as
simple
as
particular,
an
empty,
an
empty
string.
Instead
of
the
your
API,
then
we
can
discuss
the
pros
and
cons
of
using
pvd's.
I
Another
thing:
actually
another
question
was
which
we
I
don't
know
if
we've
considered
that
in
the
in
the
API
doc
is
what,
if
this
URL
changes,
because
the
PVD
can
actually
PPD
has
a
big
mechanism.
So
what
what
should
happen
if
the
captive
API
URL
changes
during
the
lifetime
of
the
network?
That's
another
question
to
ask:
as
for
whether
we
should
use
the
RA
or
DHCP
option
well,
I
mean
pvd's
or
v6
only
right,
so
so
for
before
no.
P
I
was
about
to
say
this,
if
you
don't
mind,
jumping
in
the
queue.
Indeed,
it
requires
@p
v6,
but
what
defines
an
ipv6
networks
are
and
oast
not
network.
As
long
as
android
iOS
are
there
and
listen
for
ipv6
array,
it
works,
the
URL
can
be
fetch
over
HTTP
over
ipv4,
the
DNS
requests
or
CSP
can
be
done
over
TV.
For
so
let.
I
O
J
I
Initial
was
my
initial
advice
would
be
to
say.
Well,
let's
use
that's
used
7710
for
before
we
could
consider
using
this
instead
of
adding
7710
to
b6.
If
we
wanted
to
given
that
like
in
real
captive
portals
v
sixes
or
in
most
of
them,
B
sixes,
you
know
one
of
those
yeah.
We
have
no
plans
for
it
right
now,
so
you
could
be
an
incentive
really,
okay,
that
was
yeah.
N
K
As
co-author,
but
also
speaking
just
from
my
being
a
working
group,
my
answers
to
these
questions
and
other
people,
please
agree
or
shoot
them
down
for
the
first
one.
Should
we
have
a
direct,
essentially
a
shortcut
of
the
API
I
would
say,
no
extra
methods
are
kind
of
extraneous
and
it
kind
of
ossifies
on
one
current
deployment
model.
That's
why
we
left
it
out
for
now.
K
The
second
one,
based
on
the
7710
bists
document
that
we
have
now
seen,
which
we
did
not
have
earlier
I,
would
argue
that
they
should
be
the
same
string
for
marking
that
there
is
no
captive
portal,
because
that
already
defines
one.
So
we
should
just
copy
that
that
seems
natural
as
far
as
the
coexistence
with
72
seven
ten
bits.
K
There
are
benefits
to
having
a
PVD.
So,
first
of
all,
if
you
have
a
PVD,
this
feels
like
this
should
be
a
property
of
your
provisioning
domain.
It's
a
natural
thing
to
extend
so
like
I
think
this
is
good
work
for
this
group
to
do
in
order
to
extend
that
set
of
available
information,
and
that
should
be
specified
here.
K
Maybe
they
all
point
to
the
same
API
they
have
different
API
is,
but
they
can
point
to
the
same
user
portal
for
actually
buying
the
things.
But
then
we
actually
have
multiple
PVD
States
associated
with
different
captive
portal.
Api
is
to
maintain
the
lifetimes
of
the
different
services
that
you've
bought.
So
I
think
this
is
useful.
Work
to
keep
doing.
I
K
Right
this,
these
would
be
separate
deployment
models,
but
a
I
get
Android.
Our
iOS
host
would
understand
either
and
if
you
want
to
use
the
one
that
lets
you
give
different
sub
networks
great.
If
you
want
to
just
have
the
one:
that's
just
the
boom.
Here's,
your
are
a
DHCP
option
that
works
too,
which
ones
who
proceeds
if
they
defer
that's
very
different
I.
K
N
One
option
as
well
is
that
if
there
is
an
array
option
that
is,
that
is
defined
for
discovering
the
API,
you
can
put
it
in
the
array
with
the
PVD
and
if
you
have
multiple
services,
different
services,
you
can
put,
you
know,
send
multiple
pvd's,
multiple
arrays
and
each
related
to
one
of
the
services
that
you
provide
with
different
captive
portal.
Api's.
N
P
N
M
This
is
Daniel,
can't
go
more
so
as
I'm
thinking
about
this
I'm,
imagining
connecting
to
a
network
where
I
get
dhcpv6
with
cat
porn
info
I
get
a
route
advertisement
with
a
cat
for
the
information.
It
also
has
a
PVD
information.
I
get
the
PVD,
and
the
PVD
gives
me
additional
portable
information
and
I
get
another
PV.
I
As
someone
who
is
responsible
for
building
implementation,
I
can't,
if
I
kind
of
with
you
I
mean
I,
think
we're
here
already
instead
of
talking
about
already
talking
about,
you
know,
7710
and
then
well,
but
like
7710
is
hard.
So
let's
do
the
location,
header
and
I.
You
know
that
that's
actually
I
almost
feel
that
we
should
just.
Maybe
just
only
do
that.
I
First
and
publishing
a
document
doesn't
automatically
create
a
swamp,
but
it
also,
if
it
doesn't
do
anything,
then
there's
no
point
in
publishing
it
so
I
mean
we
could
either
publish
it,
and
then
you
know
people
will
implement
it
or
not
or
wait
until
let's
say
the
PVD
work
actually
gathers
a
lot
of
steam
and
when
that
is
actually
sort
of
mainstream
and
fully
supported,
we
would
just
put
it
in
there.
I
I
would
almost
say:
let's
delay
this
until
the
PVD
work
actually
goes
in
and
becomes
a
standard
and
sort
of
weight
on
it.
I
And
yes,
of
course,
you
can
do
this.
Another
thing
that,
of
course,
the
PVD
option
does
is
God
it
may
or
may
not,
depending
on
we
have
where,
where
this
lands
have
this
containerized
IRA
option,
in
which
case
you
can
containerize
the
the
7710
URL
anyway.
So
yeah
we've
got
like
this
combinatorial
explosion
of
ways.
Simply
captive
portals
I
would
wait
on
this
one
to
be
other.
M
Dkg
again,
so
let
me
let
me
just
ask
a
question
that
perhaps
okay,
so
maybe
this
is
already
specified
and
I
apologize
if
I
haven't
understood
it
properly.
If
I
receive
two
different
captive
portal,
informations
from
one
link,
whether
it's
via
pvd's
or
dhcp
announcements
or
our
Ras
directly
or
whatever
and
they're
the
same
thing
and
I
go
to
that
captive
portal
API
to
register
what
is
my
expectation
as
an
endpoint
have
I
registered
to
both
of
those
things
or
have
I
registered
to
one
of
them
right.
N
M
K
So
yeah
I
really
liked
ekgs
point
there
so
yeah
this
is
not
specified
the
multi-tenancy.
Yet
one
thing
I'd
be
tempted
to
do
is
say
like
that
they
shoot
like
they
should
not
be
the
same,
and
maybe
they
can
point
to
the
same
user
portal
but
be
different
API
eyes.
So
one
thing
that
this
brings
up
and
if
Barton
you
can
take
this
in
the
notes
that
we
need
to
specify
in
the
API
document
separately
is
once
you
have
interacted
with
the
user
portal,
and
you
think
you
are
done.
K
We
do
need
to
check
in
again
with
the
API
to
see
what
the
updated
values
are.
I,
don't
think
it
actually
ever
says
that
anywhere,
because
it's
kind
of
important.
So
one
thing
you
could
imagine
doing
like
if
they
pointed
to
the
same
portal
user
interaction
and
on
that
user
interaction
I
bought
two
out
of
three
services,
then
ideally
I
should
be
able
to
check
in
with
the
API
is
for
those
services
or
those
pvd's
and
figure
out
which
one's
of
those
did
the
user
just
open
up.
So
it's
gonna
be
some
model
like
that.
I
So,
generally
speaking,
PVD
is
a
sort
of
separate
networks
right.
So
if
it's
not
just
a
source
address,
it's
you
know
the
DNS
lookup
yeah.
Let's
say
that
I
have
a
PVD
host
name
of
like
I'd,
okay,
so
it
has
to
pass-
and
this
is
else
art.
So
it's
gotta
be
a
valid
host
name,
but
it
could
be
like
you
well
login
dot.
You
know
whatever
captive
portal,
dot,
login
or
whatever
I
mean
yeah.
Probably
not
it's
gonna,
be
you
know
or
login
Boingo
comm
right,
but
they
could
be
entirely
separate.
I
You
know,
networks
and
yeah
login
for
one
wouldn't
assume
login
for
the
other.
You'd
have
to
do
a
DNS
lookup
on
both
those
pvd's
and
like
it
an
ssl
connection
on
both
of
them.
If
you
wanted
to
login
to
both
of
them,
how
you
present
this
to
the
user
of
courses
is
basically
tear
your
hair
up,
because
it's
really
like
yeah,
I
don't
know.
I
I
will
say
one
thing
that
is
interesting
about
having
the
captive
portal
API
available
via
BVDs,
is
that
if
the
network
is
extended
saved
by
tethering,
it
might
be
easier
to
discover
that
there's
a
capture
portal
there,
rather
than
having
to
have
all
the
things
that
do
the
tethering
and
the
tethering
and
the
tethering
and
the
preview
delegation
remember
that
they
need
to
also
pass
along
7710.
This
urls
know.
N
On
the
on
your
EO
point
about
having
j
GP
v
for
HPV
6
erase,
what's
the
what's,
the
current
definition
define
behavior
with
you
know
you
have
dual
stack
network.
You
get
a
an
array
with
an
option
with
the
API
and
then
DHCP
with
an
API.
Are
you
supposed
to
log
in
to
both,
or
do
you
assume
that
the
ipv4
and
ipv6
are
bound
together?
You
just
need
to
connect.
One
I
mean
my
point
is
to
really
defend.
Ppp
is
that
in
the
PD
spec
II,
it
is
defined.
J
If
I
understand
the
kind
of
questions
you
guys
I
think
what
we
should
do
if
we
are
going
to
use
the
PVD
right
so
I
guess
that's
a
good
question
is
between.
If
you
also
receive
a
DHCP
option
and
a
PVD
now
the
DHCP
option
is
going
to
be
ipv4
only
well,
maybe
v6.
But
before
let's
say
now,
we
have
to
give
some
player
I
don't
have
an
answer.
We
have
to
give
a
clarification
on
which
one
is
which
one
wins
right,
especially
if
they
are
different
captive
or
EPA.