►
From YouTube: IETF104-CAPPORT-20190327-1120
Description
CAPPORT meeting session at IETF104
2019/03/27 1120
https://datatracker.ietf.org/meeting/104/proceedings/
B
D
A
Right,
I
guess
we'll
get
underway
welcome
to
cap
book.
If
this
is
you're
here
for
something
else,
you
can
stay
but
white
wine
Evie
wait!
What'd!
You
expect.
A
D
A
C
D
G
A
There
should
be
blue
sheets
somewhere,
please
we
need
to
start
another
second
sheet.
A
C
So
this
is
breakfast
to
this.
We've
talked
about
updating
7710
in
the
past
and
in
the
absence
of
volunteers,
Eric
has
worked
with
Warren
to
produce
a
biz
document
and
so
I'll
be
assessing
whether
or
not
the
group
has
consensus
to
adopt
or
what
have
you
after
this,
but
keep
in
mind.
This
is
something
we've
discussed
in
the
past.
A
The
things
that
we
originally
intended
to
do
were
clarify
that
IP
string
literals
are
in
fact
not
recommended
that
the
URA
option
should
be
that
of
the
capture
portal.
Endpoint
that
capture
portals
may
do
content
negotiation.
I
mean
we
weren't
aware
of
anybody
actually
using
this
option
in
the
wild,
but
if
they
are,
they
might
have
used
the
captive
portal
option
to
be
the
the
HTML
user
interface
URI.
A
You
can
so
there's
some
text
about
content
negotiation
in
there
which
we'll
ask
about
later
I
had
text
about
cap
before
old,
URI
precedents,
because
we
added
another
way
to
get
the
capture
portal
URI
and
I
thought.
Maybe
it
was
worth
having
some
text
so
describe
what
to
do
in
the
event
of
a
network
configuration
error.
Maybe
that
text
should
just
be
something
else.
F
A
Had
an
order
of
preference
in
the
document-
yes,
it's,
but
what
I
did
not
do
was
choose
an
order
of
preference
among
address
family,
specific
things.
So
network
choose
the
option
given
to
you
by
the
network.
First
then
choose
the
the
option
given
to
you
by
the
link,
relation,
I,
think
or
PVD
rather,
and
then
the
link
relation,
but
within
the
network,
specific
things
I
didn't
order
before
before
v6
or
v6
before
before,
or
anything
like
that.
No,
that's
that's
cool!
A
Let's
see
we
added
a
you.
This
idea
a
request
to
the
I
honor
to
allocate
this
you
RN
that
says
the
you
can
put
in
place
of
the
capture
portal
option
instead
of
an
HTTP,
URL
or
something
you
can
just
include
this.
That
says
you
should
be
free
to
go
and
then
in
discussions
with
a
captive
portal
vendor,
they
said
it
was
hard
in
some
time
some
cases
to
change
the
on
link
infrastructure.
A
They
wouldn't
want
to
change
the
DHCP
infrastructure
and
that
it
would
be
better
if
they
could
just
intercept
things
if
they
could
continue
to
use
the
HTTP
intercept
to
redirect
and
include
something
like
a
link.
Relation
header
in
there
to
indicate
where
the
capture
portal
API
was
so
we
added
that,
along
with
some
texts,
saying
don't
ever
interpret
this
in
any
other
context,
except
when
deliberately
probing
for
captive
portals
so
I'm,
not
an
HTTP
person.
A
I,
don't
know
if
the
content
negotiation
text
looks
reasonable,
I,
don't
know
what
people
think
about
the
order
of
precedence
in
cuvette
to
this
configuration
or
what
other
people
would
like
to
do.
If
this
is
incomplete,
I
think
most
of
the
issues
on
the
github
have
basically
been
closed,
except
to
make
sure
that
the
final
diff
from
7710
section
is
up-to-date.
H
H
C
You
I
noticed
a
mark
nodding
he
was
sitting
there.
Would
you
be
okay
to
look
at
the
content
negotiation
text
in
here
just
to
make
sure
it's
saying?
Okay,
I'll!
Do
that
Thanks
and
anyone
else
willing
to
throw
their
head
in
in
terms
of
reviewing
things.
We
now
have
quite
a
number
of
different
mechanisms
described
in
the
one
draft,
all
sort
of
fall
into
the
same
backup
we
get
dhcp
we've
got
our
A's
we've
got.
C
A
C
C
E
C
So
unfortunately,
we
don't
have
our
volunteer
editors
for
the
architecture
draft
with
us
today
there
are
a
couple
of
issues
that
we
might
get
time
to
discuss.
At
the
end,
there
are
five
omissions
issues
on
the
draft
that
I
would
like
to
have
a
little
bit
of
a
discussion
about
later
on
in
the
session.
H
All
right,
I
am
Tommy
dark,
just
not
here
in
person
but
I'm
speaking
for
him.
Also
as
a
editor,
we've
done
some
updates
to
the
API
a
document.
This
should
be
pretty
quick.
Thank
you,
so
I
just
want
to
cover
what
were
the
changes
that
we
did
make
in
the
O
2
version.
We
did
add
a
terminology
section.
There
was
already
a
terminology
section
in
the
architecture
document,
but
we
wanted
to
extend
it
for
the
purpose
of
the
API
to
say
what
are
our
clients
in
the
API
server.
Specifically,
we
did.
H
Some
editorial
passes
to
converge
on
calling
things
clients
rather
than
hosts,
because
multiple
things
in
this
setup
can
be
hosts
and
it
was
unclear
which
ones
were
which
we
added
a
consideration
about
white
listing
and
TP.
If
you
are
trying
to
validate
your
certificates,
you
should
probably
have
a
way
to
validate
your
time
on
the
network
as
well.
That
would
be
good
and
there
are
some
edits
to
the
JSON
keys
that
the
API
server
can
serve
up.
We
had
agreed
last
time
to
switch.
H
The
notion
of
you
are
permitted
on
this
captive
network
to
flip
the
boolean
meaning
to
be.
You
are
captive
and
we
also
added
a
vendor
info.
Url
I
think
dark,
headed
that
we
have
some
comments
on
clarifying
that
that
we
got
from
Kyle.
So
we
got
a
nice
good
review
from
Kyle
and
so
we're
going
to
be
updating
those
again.
H
We've
done
some
implementation
playing
around,
but
would
be
nice
I
think
to
get
more
concrete
implementation
experience.
So
if
people
have
a
captive
portal
set
up
that,
they
would
like
to
mock
out
and
I'd
be
happy
to
provide
a
client
for
that,
and
we
can
do
some
Interop
testing
on
that.
I
think
that
would
be
useful
to
do
before
we
say.
Yes,
we
are
done,
but
I
think
other
than
that
modulo
review.
These
documents
are
in
pretty
cheap,
so
their
questions
comments
so.
C
You
have
about
8,000
issues
on
the
github
related
to
this.
Some
of
the
Merdan
new
ish
I
think
some
of
them.
Actually,
you
mention
here
and
I
could
see
comments
on
them.
Suggesting
that
they've
been
closed,
so
yeah
I
can
do
a
pass
of
those
to
make
sure
that
any
ones
that
we
have
fixed
our
closed.
How
many
I'd
say
a
couple
of
relatively
recent:
how
many
do
you
think
we
have
open
left
I,
see
a.
H
H
The
vendor
page,
your
eye,
is
added.
So
that
should
be
closed.
We
do
want
to
add
some
more
clarification
text,
so
that
will
probably
become
a
new
issue.
The
NTP
one
is
done.
The
bytes
remaining
I
think
there
were
some
comments
still
on
that
from
Kyle's
review,
so
I
think
our
edits
to
the
text.
There
are
not
sufficient
to
clear
up
all
things
that
we'll
probably
want
to
do
another
pass
at
that
we
did
a
flip
to
permitted
bit.
H
A
J
It's
Chris
seal
that
if
it's
relevant
from
an
operator
point
of
view,
tenancy
portals
also
applied,
because,
if
you've
run
out
of
credit,
we
would
block
until
such
time
for
prepaid
until
you
pay.
But
in
that
case
all
the
control
plane
would
not
count
towards
any
point.
No,
it
would
be
purely
what
the
user
sees
in
terms
of
the
data
it
can.
J
Your
layer,
you
never
see
it
so
there's
a
control
plane
for
the
sticking
on
a
mobile
network,
sure
and
then
there's
tunneling,
but
the
tunneling
overheads
are
not
counted
as
parts
of
the
points
remaining
that
they
are
because
they're
stripped
before
they
actually
get
to
the
phone
they're
only
across
the
core
network.
So
if
the
client
counts
up
the
length
of.
J
A
There
is
an
issue
with
in-plane
captor
port
yeah
in
plane,
capture
portal,
bytes
right,
so
in
other
words
the
the
bytes
that
you
send
in
order
to
interact
with
the
capture
portal
periodically,
do
they
account
they
do
not
count.
You
need
to
be
able
to
account
for
them
separately
or
you're
gonna
over
count,
which
is
maybe
also
fine,
I.
E
John
Sherlock
would
have
cool.
I
was
thinking
that
if
this
is
teamed
to
possibly
Bistro
faced
to
use
to
the
user
in
the
UI,
if
it's
layer,
two
is
going
to
be
completely
impossible
for
user
to
relate
to
right.
If,
if
I
know,
I
have
100
minimize
remaining
and
I
want
you
to
ninety
megabytes
download,
let's
say
you
two
bytes
that
doesn't
help
at
all
I
mean.
H
Layer,
three
bytes,
don't
necessarily
help
you
a
ton
either,
because
that's
not
really
your
the
download
of
your
file
size
but
I
think
it
is
much
more
practical.
I
believe
like
when
we
show
you
the
cellular
data
that
you
have
used
on
your
iPhone.
That's
going
to
be
in
terms
of
those
packets
packet
counter,
so
I
think
that's
something
that
people
are
used
to
seeing.
So
at
this
point,
based
on
the
feedback,
I'd
lean
towards
just
saying
you
want
to
do
layer,
three
bytes
and
then
have
a
comment
about
whitelist
of
traffic.
K
L
I
There
are
given
I
think
it's
a
layer
tree
on
it's
only
one
that
it
really
makes
sense,
because
I,
don't
think
layer
to
fractional
Wi-Fi
or
not
thick.
We
actually
know
that
information,
crystals
kind
of
accent,
all
kind
of
extra
stuff
that
is
added
there,
that
you
don't
know
about
or
know
the
management
dissociation.
Association
messages
are
so
I.
Don't.
I
H
C
I
get
to
say
that
yeah,
it's
rough
consensus.
C
H
C
Reasonable,
alright,
thanks
Tom,
thank
you
and
I
realized
that
I
dropped
the
ball
on
the
last
one.
Let's
go
back
to
the
7710
issue.
I
would
like
to
at
least
get
a
sense
of
the
room.
Does
anyone
think
that
it's
a
bad
idea
to
pursue
this
thing
I'd
like
to
to
understand
whether,
if,
when
I,
send
an
email
to
the
mailing
list
in
the
next
little?
While
is
anyone
going
to
tell
me
that
it
was
terrible
idea
in
a
way
that
could
have
been
much
more
succinctly
expressed
at
the
microphone?
C
C
How
the
fun
part
yeah,
so
you
saw
there
that
we
have
a
number
of
minor
issues
on
the
API
draft.
I.
Think
the
the
plan
here
is
for
Tommy
to
and
to
work
on
the
next
provision
of
that.
That
document
and
our
hope
is
to
do
a
working
group
last
call
based
on
that.
Once
that's
that's
out,
we
have
a
couple
of
issues,
but
I
think
the
ones
who
have
discussed
the
phone
once
you
get
the
vendor
URL
thing
going
will
decide
one
wherever
the
architects
draft
has
a
number
of
issues
as
well.
C
Yeah,
this
isn't
not
making
me
feel
happy.
This
is
the
set
of
issues
that
I
would
like
to
to
spend
a
little
bit
of
time
discussing
here
today,
because
I
think,
based
on
the
discussion
that
we've
had,
we
either
ship
these
things
or
we
don't
ship
these
things,
and
we
can
make
that
decision
based
on
where
we
are
now.
Mostly
these
issues,
I
think
we
could
get
some
insight
on,
but
I
think
we
have
a
couple
of
larger
issues
to
discuss
and
I
think
I
put
that
in
the
in
the
slide
deck.
F
C
C
That's
amazing
I
would
that
exceeds
expectations.
Thank
you.
So
we,
we
have
had
several
pieces
of
feedback
that
the
simple
yes/no
signal
that
we
have
in
the
end
of
that
I
guess
it's
a
little
more
than
that.
Now
we
have
sort
of
bytes
that
were
counting
in
and
and
time
remaining
those
sorts
of
things.
We've
heard
some
signals
from
various
folks
that
there's
a
lot
more
nuance
that
you
could
convey
in
the
signalling
from
the
network
toward
the
client
and
networks
are
clearly
more
complex.
C
C
The
question
for
this
group
would
be
then,
what's
the
what's
our
level
of
comfort
with
providing
a
very
reduced
signal
to
the
endpoints,
we
have
effectively
a
boolean
switch
in
this
protocol.
That
says
captive
not
captive.
Do
we
want
to
have
some
way
for
networks
to
be
able
to
express
more
than
that?
C
Unfortunately,
no
other
people
have
expressed
a
desire
to
do
this
or
in
this
room
is
anyone?
Does
anyone
have
any
interest
in
doing
this?
Now
there
is
go
where
we're
establishing
a
means
of
communication
between
the
network
and
the
endpoint
sentence,
it's
possible
that
we
can
extend
this
format.
It's
Jason
we
can
put
whatever
we
want
in
there
in
the
future.
Should
we
decide
it's
a
good
idea.
M
C
C
H
Tommy
Polly,
so
not
really
commenting
on
this,
because
I
think
I
agree
with
the
simple
view:
that's
why
we
have
what
we
have
today.
I
agree
that
the
outlet
for
this
is
that
we
can
extend
the
keys
in
the
future.
Looking
at
the
document,
I
realize
that
we
don't
define
the
mechanism
for
extension
right
now,
the
JSON
keys
are
listed.
They
are
not
listed.
It's
not
an!
I
anna
registry
that
we're
creating
it
doesn't
specify
anything
about
extension,
so
we
can
either
leave
it
as
as
is,
but
that's
rather
ambiguous.
H
We
can
define
a
way
to
extend
it
without
actually
providing
registry,
or
we
could
define
the
registry
with
the
current
keys
and
the
process
for
extending
it,
and
that
could
be
expert
review
or
whatever
we
want
there,
such
that
if
people
need
an
outlet,
especially
if
a
captive
portal
vendor
wants
to
add
something.
That's
a
well-known
thing
and
we
get
enough
people
wanting
to
do
that.
Then
we
can
actually
add
these
in
I,
don't
know
what
our
thoughts
out
there.
C
C
C
Whether
we
should
go
with
what
we
have
and
simply
fix
the
issues
that
we
have,
which
I
think
we
just
saw
a
relatively
minor
or
whether
we
need
to
go
back
and
more
fully
engage
on
this
topic
so
that
we
can
come
up
with
some
answer
to
this.
To
this
question
about
networks
telling
telling
devices
that
enter
those
networks,
the
more
about
the
terms
of
their
confinement
to
use
the
terms
from
the
from
the
the
Charter,
so
I
guess.
The
first
question
will
be
and
I'll
ask
people
to
hum,
because
this
is
silly.
C
C
C
Can
hear
the
sirens
in
the
background
that
was
pretty
clear,
the
eyes
have
it
I
guess
and
we
will
proceed
with
what
we
have
I
will
confirm
that
on
the
list
of
course,
and
hopefully
once
the
editors
of
these
documents
have
sorted
out
those
few
remaining
issues,
we'll
talk
about
working.
That
last
call
for
those.
C
If
we
do
not
do
that
by
Montreal,
some
people
will
get
some
slaps
and
various
other
things.
I.
Think
that
there's
probably
pretty
reasonable
to
expect
that
the
changes
that
we
reviewed
for
the
API
document
can
happen
in
a
relatively
short
amount
of
time
and
I.
Don't
know
what
sirisha
status
is,
but
he's
promised
some
time
on
this,
and
all
we've
chairs
will
consult
with
him
and
make
sure
that
we
can
get
get
the
the
last
few
issues
on
the
on
the
architecture
updated
and,
of
course
it
if
Thomas
provides
us
with
extra
text.