►
From YouTube: IETF105-CAPPORT-20190722-1000
Description
CAPPORT meeting session at IETF105
2019/07/22 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
A
Really,
okay,
because
this
is
the
start
of
the
week
I'm
going
to
spend
a
little
bit
of
time
on
this
one.
The
note
well
outlines
your
obligations
as
you
participate
in
this
meeting.
That
means
at
a
high
level.
We
want
professional
conduct
here,
be
civil,
be
kind
to
your
fellow
human
being
and
also
let
us
know
if
you
have
intellectual
property
rights
or
are
aware
of
any
that
relate
to
the
things
that
you're
talking
about
I'm,
assuming
everyone
is
familiar
with
this,
but
it's
worth
spending
a
month.
Think
about
that.
A
A
D
F
For
7710
Biss
it
was
a
there
was
a
call
on
the
mailing
list.
It
was
adopted
enough
loaded
as
IETF
it
was.
We
have
some
improved
content
negotiation
texts
thanks
to
mark
it
was
moved
to
the
captive
portal
working
group.
Github
repository
and
I
wanted
to
propose
a
question
for
the
group,
and
that
was
whether
or
not
we
should
request
that
the
IETF
106
network
run
an
experiment
where
we
hand
out
7710
this
URL.
That
is,
takes
you
to
a
static
web
page,
basically
an
API
that
just
has
this
JSON
in
it.
F
It
just
says
captive,
false
and
the
venue
info
URL
takes
you
to
the
meeting
page
for
the
meeting
page
you
can
get
to
the
agenda
and
you
can
get
the
floor
guide
and
you
can
get
to
the
how
to
get
to
the
emergency
hospital
stuff
and
all
that
all
that
good
things.
So
if
the
working
group
thinks
this
is
a
good
idea,
I
can
take
care
of
sending
the
request
to
the
naka
and
Alisa
and
so
on.
F
G
F
So
as
a
part
of
the
DNS
of
rutila's
experiment,
I
think
we
had
to
say
what
data
would
be
collected
and
what
would
not
be
I
was
imagining.
We
would
just
be
interested
in
the
diversity
of
user
agents
and
the
number
of
times
the
API
had
been
fetched.
I
expect
for
106.
Maybe
it
won't
be
that
many,
but
maybe
for
107.
Things
will
be
different
by
then
do
any
of
the
implementers
any
of
the
operating
system
and
implementers
in
the
room.
Think
that
something
could
possibly
query
this
by
Singapore,
even
even
an
experimental
build.
B
G
B
I
J
A
L
J
B
All
right,
hello,
everyone,
I'm,
Tommy,
Pauly
and
I'm,
one
of
the
co
editors
of
the
captive
portal
API
document.
We
have
recently
posted
a
revision
of
it
not
hugely
changed.
What
I
did
want
to
give
an
overview
of
what
we
have
done
and
get
feedback
from
the
group
on
that
all
right.
So
the
relevant
changes
to
talk
about
in
oh
three
are:
we
did
a
much
more
rigorous
definition
of
the
registry
for
the
keys
that
we
would
have
in
the
captive
portal
API
and
how
we
would
allow
people
to
extend
that.
B
So
that's
now
a
Ayana
registry
that
we're
creating
there.
So
this
allows
us
to
have
new,
JSON,
keys
and
values.
To
extend
this.
We
definitely
do
expect
this
to
be
extended.
The
set
we
have
right
now
is
very
minimal.
For
example,
it
does
not
allow
things
to
do
kind
of
headless
captive
portal
Association
if
you
don't
have
a
UI
and
that's
something
that
people
would
want
to
do
in
the
future.
This
would
allow
that
we
also
changed
one
of
the
names
of
the
keys
from
a
vendor
info
URL
to
a
venue
info
URL.
B
B
There
was
one
open
issue,
that's
remaining
on
the
github,
and
it
was
originally
about
just
we
should
have
a
registry,
so
we
did
that
part
of
it,
but
there's
still
a
comment
about.
Should
we,
within
this
rarity
registry
have
a
specific
guidance
for
how
we
have
either
sub
dictionaries
or
labels
on
keys
that
are
organisations
specific
such
as?
If
that
WBA
wanted
a
set
of
keys
for
things?
Should
there
be
an
official
prefix
mechanism
that
they
reserved
that
way
or
not?
B
G
I
J
I
J
I
I
B
So
there
are
two
URLs
that
are
specified
already
in
the
JSON
for
the
API
one
is
the
like
the
portal
URL,
which
is
the
thing
you
go
to
initially,
but
you
could
also
essentially
go
back
if
you
need
to
re-up
your
plan
and
then
there's
an
extra
one
for
like
here's,
the
information
about
your
flight.
If
you
need
that
so
imagine
you
I
could
link
to
both
deeply
all
the
time.
I
B
And
if
there
any
changes
we
would
want
to
make
to
the
API
to
do
that.
That'd
be
good.
I
mean
the
the
JSON
here
can
be
dynamically
generated,
so
it
could
include
a
session
ID
in
the
URL.
We
could
also
have
new
keys
that
get
registered
to
specifically
define
a
session
ID
that
is
to
be
used
on
future
connections.
B
A
J
So
thanks
a
lot
Mike,
my
name
is
Brian
shields.
I
work
employing
the
wireless
you're
in
Los,
Angeles
California
you
make
might
be
familiar
with
our
Airport
Wi-Fi,
but
we're
also
big
on
cellular
and
other
technologies
and
convention,
centers
military
bases
and
a
lot
more
and
I've
been
working
in
blingo
since
2007
and
also
portal.
Since
then,
as
you
probably
you're,
well
aware,
a
lot
has
changed
since
that
year
when
the
iPhone
came
out
and
was
a
member
of
the
wireless
broadband.
J
This
alliance,
where
I'm
representing
today
and
I'll,
be
talking
about
the
WPA
and
what
we
do
in
projects
especially
little
project
and
how
it
would
be
a
mutually
beneficial
for
it--.
Yes,
all
right,
especially
hearing
what
you're
all
talking
about
right
now.
This
is
music
to
my
ears.
So
if
you
can
hang
on
in
this
slide,
I'll
go
over
the
WBA
overall,
it's
an
alliance
of
over
100
members.
It's
a
community
of
network
providers,
manufacturers
and
technology
providers.
I
was
established
in
2003
with
the
Charter
of
developing
seamless
and
interoperable
services
across
wireless
technologies.
J
The
next
slide,
this
is
a
quick
overview
of
the
work
groups
and
projects
at
the
WEA.
The
group
serve
their
groups,
focus
on
wireless
deployments
and
convergence.
Ing
IOT
technologies
is
roaming,
workgroups
for
sharing
customer
access
across
our
networks
and,
finally,
there's
testing
interoperability
group.
That's
when
the
captain
or
the
project
is
based
and
I
know
this.
Many
of
that
I
have
membership
that
are
already
members
of
the
WBA,
so
I'd
like
them
to
participate
in
the
program
as
well,
but
we're
also
very
happy
to
work
on
the.
J
J
Then
also
out
of
that
on
auditing
that
behavior,
we
also
want
to
recommend
improvements
for
the
clients
and
onboarding.
For
an
example
of
one
of
the
issues
is
on
the
next
slide.
So
this
is
a
diagram
Oh
diagram
that
shows
the
captive
portal
flow
kind
of
overlay.
I
operate
the
system
and,
as
you
can
see,
it's
obviously
very
fragmented,
there's
a
lot
of
cases,
a
target,
but
a
different
process.
I've
mentioned
earlier
for
the
postdoc
issue,
where
the
portal
closes
automatically
on
authentication
on
Android,
iOS
and
Mac
OS.
It
stays
open
for
post.
J
So
three
of
the
main
pressing
issues:
first,
one
is
a
lot
of
different
operating
systems,
use
different.
You
are
eyes
there.
Reference
creates
a
management
issue
on
the
operator
side
to
whitelist
the
URIs,
as
well
as
any
that
are
calling
HDS
they're
all
well
aware
that
this
great
stirred
up
early
for
his
smashers
when
the
CA
is
checked
and
just
overall
depend.
The
mental
behavior
creates
a
lot
of
like
collections
but
find
ourselves
how
we
work
around
also
the
fragment
in
use
cases,
as
I've
mentioned,
before,
difference
between
Apple
and
Android
and
Windows
interpretations.
J
J
J
I
Speaking
which,
actually
we
were
we're
writing
code
for
77
tenants,
as
we
speak,
I
think
was
last
week,
so
many
was
during
right.
Curtains.
We
sent
to
Colonel
a
touch
screen
for
the
RA
auction
as
well,
but
the
you
know,
I
think
a
couple
things
really
one
of
them
was
is
that
is
the
classification
legacy.
Behavior
I
would
not
maybe
spend
too
much
on
that,
because
it
will
be
subject
to
change
and
I.
Think
it's
it's
of
not
really
to
characterize.
Even
even
the
behavior
amongst
Android
devices
radically
different.
I
You
know,
different
OEMs
have
different
behaviors
and
so
on.
I
know
I
would
instead
try
to
focus
on.
How
can
we
make
this
better
going
forward
using
some
like
proper
API?
It's
you
know,
I
think
7710
is
part
of
it.
One
thing
I
don't
see
here,
hotspot
2.0
is
I,
think
in
a
much
better
shape.
One
thing
I
don't
see
here
is
the
is
the
captive
portal
API
and
I
think
that
that
is
something
that
it
would
be
good.
I
If
you
to
be
honest,
you
know
from
a
network
perspective,
we
want
to
implement
that,
but
we
don't
really
have
existence.
Proof
of
a
network
operator
that
can
build
it,
and
so
until
we
do
we're
sort
of
not
sure
what
priority
we
need
to
assign
to
it.
So
I
think
if
someone
is
willing
to
sort
of
bring
up
some
test,
write
some
code
and
bring
up
something
some
test
environments,
we're
happier
to
collaborate
on
that.
You
know
so
I
think
the
API
would
be
really
good
to
our
come
together.
Yeah.
M
M
J
B
B
You
know,
as
we
were
talking
about
for
next
ITF.
It
would
be
good
to
do
a
experiment
here
on
this
network,
but
it
would
also
be
graded
at
the
same
time,
if
we
could
do
some
testing,
perhaps
in
the
hackathon,
perhaps
over
that
kind
of
on
site
with
a
captive
portal
network,
would
it
be
possible
to
have
your
site
the
vendor
like
come
and
like
bring
a
box
that
has
this
implementer?
So
we
could
test
this
out
at
the
hackathon.
F
J
J
K
A
Okay,
thanks
Brian
I,
think
the
next
item
on
our
agenda
is
the
open
issues
that
we
have
on
the
the
architecture
document.
I
just
want
to
go
through
those
briefly.
We
talked
about
most
of
these
last
time
we
met,
but
I
think
it's
a
good
opportunity
for
us
to,
hopefully
close
some
of
them,
or
at
least
it
you
don't
need
to
worry
about
being
logged
in
just
go
to
the
architecture.
Job.
A
A
A
O
A
O
O
O
You
can
log
in
if
I
use
your
DNS
server
library
anyway.
The
point
is
that
I
have
to
reconfigure
everything,
use
your
DNS
server
and
there.
So
I
would
like
to
have
some
some
statement
that
DNS
SEC
I
should
be
able,
if
you
put
DNS
SEC
on
your
portal
link,
I
should
be
able
to
validate
it,
and
that
means
I
need
to
access
all
the
resolvers
above
your
knee
all
the
38
resolvers
of
underneath,
not
just
your
your
recursive
resolver,
to
get
your
the
name
of
your
captive
api.
O
F
I
That
the
issue
was
made
I
mean
I,
think
you
know
if,
if
if
let's
say,
if
the
captive
portal
operator
forgets
to
block
you
know
4
4
3
2
the
VMS
server,
then
it's
sort
of
all
falls
over
for
me
from
an
implementation
perspective.
To
be
honest,
the
simplest
thing
here
is
to
say,
look
just
use
clear
text
CMS
to
this.
For
this
to
the
network's
DNS
service,
you.
J
I
Personally,
that
seems
the
simplest
option,
I
think
if
we,
if
we
require,
if
we
require
the
name
to
be
globally,
reachable
and
resolvable
by
global
dns
service
that
may
make
it
more
complicated
to
deploy.
So
you
know,
I
was
I,
was
on
a
plane
yesterday
and,
of
course,
that
the
name
isn't
global
reachable.
So
it
brings
the
standard
captive
portal
flow,
but
it
doesn't
rate
the
captive
portal
up
to
the
captive
portal.
App
knows
not
to
do
this.
One
thing
that
I
would
oppose
is
do
not
disable,
never
say
disable
encrypted.
A
I
B
Tommy
so
yeah
very
much
agree
with
Lorenzo's
comments
and
yeah
I
think
we
could
probably
go
as
far
as
saying
that
when
you
are
doing
the
resolution
of
the
API
and
the
connection
to
the
API,
you
kind
of
must
use
the
local
infrastructure.
For
that
and
one
way
to
think
of
this,
if
we're
talking
about
like
provisioning
domains
and
consistent
sets
of
my
DNS
plus
my
routing
and
other
things,
when
I
am.
O
B
Dns
over
TLS
and
have
an
external
server
that
I've
configured
that's
effectively
a
custom
PVD,
that's
not
purely
local,
and
so
we
kind
of
just
want
to
say
that
if
you
are
doing
any
connection
to
the
captive
API
or
at
this
stuff,
he
needs
to
be
within
a
purely
local
provisioning
and
doing
just
use
the
local
information.
Don't
try
to
access
anything
else,
and
that
can
and
should
be
separate
from
what
other
applications
are
doing
and
that
you
should
allow
applications
to
essentially
choose
into
the
local
config.
Just
for
this
purpose,.
D
A
B
B
Say
this
can't
happen,
they
can
lie
and
implementations
can
decide
what
to
do
about
it.
They
should
have
some
approach
either
by
you
know,
doing
the
probes
that
are
validating
the.
We
could
have
an
any
number
of
heuristics
any
number
of
ways
to
kind
of
like
that.
Hufford
detect
the
people
who
lie
or
flag
them
or
allow
the
user
to
say:
oh
I,
don't
this
network
seems
to
be
acting
strangely
I.
Don't
think
that's
for
this
document
to
be
designed
the
solution
to
and.
A
This
is
consistent
with
decisions
we've
made
in
the
past.
People
do
whitelist
the
captive
portal
checks
for
various
operating
systems,
and
we
explicitly
decided
not
to
address
that
so
that
I
think
this
falls
under
that
as
well.
So
do
we
need
a
text
change
here.
I
think
it
might
be
worth
acknowledging
the
problem
even.
B
O
O
E
I
A
O
O
P
Yes,
Rahul
I'm,
trying
to
think
of
what
what
someone
saying
captive,
force
and
steel
advertising
URL
would
mean
by
that
and
how
how
I
could
want
to
react
to
that?
If,
if
we're
going
to
put
up
a
notification
to
to
respond
to
who's
advertise,
your
else
then
sometimes-
and
if
we
don't
do
that,
then
I
can
easily
see
operators
putting
that
flag
through
saying
yes,
yes,
yes,
its
captive
just
so.
A
C
A
O
F
A
A
K
K
A
By
saying
by
saying
nothing
here
we
make
the
problem,
something
that
the
captive
portal
vendor
and
the
network
need
to
address.
They
need
to
make
sure
that
if
they
want
to
put
a
new
one
in
then
retain
the
old
one
as
a
working
end
point
I
think
that's
probably
a
better
way
to
do
with
this
particular
problem.
A
B
Technically,
within
the
URLs
given
out
by
the
API
JSON,
those
can
change,
because
there
is
an
expiry
time.
That's
listed
JSON,
so
the
clients
can
wretch.
So
you
there
is
a
limited
amount
of
times
that
is
defined
by
the
portal
that
it
needs
to
maintain
old
end
points,
and
do
that
so
that
you
can
have
a
fairly
recent
transition.
There
I
think
that,
so
we
can
mention
that
to
say
that
that's
a
way
to
change
the
your
eyes
of
actual
resources.
B
A
A
A
We
seem
to
have
agreement
on
the
way
forward
on
all
of
the
issues
that
we
do
have
expect
to
work
in
group
last
call
when
these
documents
are
updated.
Does
anyone
have
any
objections
to
going
to
that
step
once
we
once
we're
done
here,
I
would
like
to
get
some
more
eyes
on
the
7710
document,
because
that
one's
a
little
fresher,
so
maybe
a
show
of
hands
from
folks
in
the
room
who
are
willing
to
read
and
review
that
and
your
you
will
get
in
the
minutes.
I
see
a
few.