►
From YouTube: IETF109 IAB Open
Description
This is the Internet Architecture Board open session from the IETF 109 Online meeting.
B
A
C
B
Breakfast
all
right,
I
think
it
is
time
you
want
to
get
started.
Yeah,
okay,
so
welcome
to
the
internet
architecture
board
open
meeting
and
we
will
go
through
a
few
slides
and
then
we're
going
to
switch
places
and
mary's
gonna
talk
this
we
do
cover.
This
is
an
ib
meeting,
but
we
do
cover
it
under
the
note.
Well,
it
is
being
held
within
the
atf
and
we
hold
most
of
our
meetings
internet
well
that
everybody
might
participate
in.
Hopefully
you
all
know
it
consult
a
lawyer
because
I'm
not
one.
B
So
what
is
the
iab
open
meeting?
It
is
a
ib
organized
session
trying
to
focus
on
sort
of
the
the
things
that
we've
been
up
to
the
technical
aspects
and
the
architectural
topics
trying
to
get.
You
know
more
visibility
into
what
the
ieb
is
actually
doing
at
the
moment,
as
well
as
what
we
might
do
in
the
future
and
then
collect
feedback
and
give
community
input
about
ongoing
and
new
work.
B
In
particular,
you
know:
there's
an
open
mic
at
the
end
feel
free
to
contribute
to
the
discussion
at
any
point
along
the
way
we
have
mailing
lists
that
we
use.
The
iab
has
a
wider
architectural
discussion
where
we
hold
conversations
about
the
architecture
of
the
internet
in
general,
which
is
at
architecture
discuss
at
iab.org.
B
Actually
here,
mary
well,
so
the
agenda
today
we're
going
to
do
the
welcome
and
updates
we've
just
done
a
good
percentage
of
that,
then
we're
going
to
talk
about
the
covet,
19
network
impacts
workshop
and
that
was
held
last
week.
I
think,
if
I
have
my
timing
right,
we'll
talk
about
the
two
technical
programs
that
we
have
up
and
running,
which
are
the
edm
program
and
then
the
model
t
the
first
being
evolvability,
deployability
and
maintainability
program
and
tommy
will
talk
about
that.
And
then
the
internet
threat
model
program.
B
A
Yes,
so
one
state
is
the
update
regarding
programs,
so
the
ib
has
been
talking
for
quite
a
while
actually
about
how
to
better
organize
programs-
and
we've
been
very
active
on
on
that
and
have
some
discussion
about
that
that
lately
and
at
the
end
we
came
up
with
a
proposal
where
we
figured
out
that
we
have
actually
two
very
different
kind
of
things
that
we
call
programs
currently,
which
somehow
also
need
different
management,
different
different
treatments.
A
So
the
biggest
change
here
really
is
that
what
we're
proposing
is
that
in
future
we
want
to
have
two
different
things.
One
is
called
technical
programs
and
the
other
one.
We
call
currently
administrative
support
groups.
There
was
already
some
name
bashing
about
this
on
the
mailing
list,
but
the
point
was
really
also
to
not
call
a
second
thing
program
to
have
a
clear
distinction.
A
The
whole
point
about
this
effort
or
why
this
discussion
started
in
the
ieb
at
all
was
really
to
be
more
open
to
make
programs,
especially
technical
programs,
more
visible
and
increase
transparency
and
have
a
better
exchange
with
the
community
before
we
go
in
the
next
slide.
One
note
so:
whatever
we
discuss
here
will
not
impact
the
rc
future
editor
model
program
and
also
not
our
stock,
because
those
are
related.
The
the
future
editor
model
program
is
is
progressing
well
and
will
probably
impact
what
our
stock
is
doing.
A
So
we
definitely
wait
for
that
to
conclude
before
we
want
to
implement
any
changes
or
whatever
so
there's
no
effect
here,
no,
no
plans
from
the
iab
to
interfere.
If
you
can
go
on
the
next
slide
quickly,
I
give
you
some
more
details
about
what
we
mean
by
those
two
different
things.
A
So
for
technical
programs,
we
see
those
as
kind
of
as
as
the
slide
says,
here's
short-lived.
That
doesn't
mean
we're
talking
about
weeks
or
months.
It's
it's
still
about
years,
but
it's
still
about
probably
longer
than
an
iab
term
might
be.
But
the
real
point
is
that
those
programs
are
focused
on
a
specific
technical
architecture
issue
or
current
problem,
so
the
iab
goes
ahead
and
identifies
something
that
they
want
to
discuss
that
they
want
to
move
forward.
They
form
a
program.
A
Usually,
the
program
has
a
task
to
kind
of
step,
establish
the
discussion
in
the
itf
or
start
some
work
in
the
itf.
It's
not
about
solving
the
problem,
it's
more
about
creating
awareness
and
having
a
discussion
going,
maybe
giving
recommendations.
A
And
then,
if
this
happens,
if
there
is
work
going
in
the
itf
or
some
discussion
concluded
in
the
itf
or
whatever,
that
means
the
program
has
been
successful
and
it
can
be
closed
again
and
we
also
realized
which
is
like
kind
of
different
than
than
then
programs
worked
initially,
that
this
really
needs
a
lot
of
exchange
with
the
community.
A
It
needs
both
technical
experts
to
give
input,
but
the
important
part
is
the
exchange
with
the
community
awareness
and
openness,
and
so
the
other
thing
that
we
currently
call
programs
are
really
more
long-term
activities,
which
means
we
have
a
program
in
it.
That
will
stay
there
kind
of
forever,
except
which
we
we
decide.
We
want
to
handle
our
responsibilities
differently
and
those
groups
really
support
the
I,
the
iab
in
their
charter
responsibilities.
A
So
and
that's
that's
very
much
in
the
sense
of
original
programs
as
well,
where
we
figured
out.
We
have
some
responsibilities
where
we
need
additional
expertise,
because
we
don't
have
it
in
the
iab
or
we
definitely
need
long-term
continuity.
We
want
to
have
people
who
have
his
story
about
this
and
who
are
involved
in
these
topics
for
a
longer
time
and
that's
where
we
need
administrative
support
groups.
A
So
if
we
talk
about
technical
program
programs,
that's
currently
model
t
and
the
edm
program
that
we
will
hear
later
on
and
when
we
talk
about
admin,
support
groups-
and
they
are
currently
the
plenary
planning
program,
the
iana
program
and
the
leasehold
program
or
groups
in
future,
and
we're
also
reviewing
these.
A
So
this
slide
is
really
to
provide
awareness.
We've
sent
out
a
call
for
feedback
on
the
architecture
discuss
list.
We
discussed
this
for
a
while
internally.
A
We
also
try
to
try
to
clarify
the
kind
of
procedures
we
want
to
use
to
manage
these
things
also
to
provide
more
transparency
in
the
community
and
to
also
maintain
expectations
and
knowledge
about
what
these
things
are
and
how
they're
supposed
to
work,
and
so
there's
a
long
document
on
github
that
you
can
look
at
and
read
and
comment
on
and
provide
feedback,
because
maybe
we
didn't
consider
everything.
A
We
can
also
take
quick
questions
if
you,
if
you
have
something
that
needs
clarification,
but
I
think,
like
the
main
discussion,
should
go
on
the
architect
to
discuss
this
or
provide
direct
feedback
to
the
iap
or
provide
or
open
issues
at
github.
If
you
have
very
concrete.
A
A
D
D
About
three
tries
for
me:
I'm
not
sure
why
I
had
two.
I
had
two
things
that
I
said
on
the
mailing
list.
I
just
wanted
to
get
maybe
a
little
bit
bit
more
visibility
for
one.
Is
that
the
calling
these
things
administ
administrative
support
group
groups-
usually
administration,
means
something
else
in
the
ietf,
and
it
seemed
like
to
me
that
these
were
all
oversight,
support
groups.
So
I
was
suggesting
that
change.
You
know
just
a
change
of
turn
there.
The
other
thing
was.
D
This
is
not
on
your
slide,
but
I
thought
that
one
of
the
things
with
the
technical
programs
was
that
they
were
more
headed
towards
open
membership,
where
the
oversight
support
groups
really
a
lot
of
the
stuff.
A
lot
of
those
things,
at
least
at
some
times,
have
needed
to
have
close
closed
membership,
so
just
when
you're
explaining
this
to
people,
maybe
including
that,
if
that's
true,
maybe
including
that
in
the
description.
Thank
you.
A
A
C
And
right
you're
saying
that
there
are
no
long-lived
technical
programs
because
it
looks
like
now.
The
iab
is
deciding
that
there
is
no
such
thing
as
a
long-lived
technical,
architectural
issues.
Is
that
correct,
when
the
notion
of
programs
was
first
created
in
the
iab,
the
program
was
sort
of
by
definition
only
the
long-lived
things,
the
short-lived
things.
The
ib
did
not
create
a
program
for
I
just
had
people
doing
it
and
never
called
it
a
program
and,
of
course,
I've
reorganized
itself
whenever
it
was
to
do
whatever
it
was.
B
So
I'm
going
to
take
the
blame
for
that
one,
because
steven
rightly
pointed
out
that
we
should
have
put
frequently
short-lived
on
the
slides
and
I
failed
to
update
the
slides
by
the
time
because
it
was
like
you
know
in
the
last.
You
know
12
hours
or
something
like
that.
So
I
I
think
that
the
answer
is
I
I.
I
would
think
that
trying
not
to
speak
for
everybody.
This
is
a
framework.
It
is
not.
You
know
hard
and
fast
rules.
B
C
A
Yeah,
but
there's
also
a
point
that
technical
programs
should
really
be
focused
on
a
specific
problem,
and
so
ideally
you
succeed
with
the
problem.
If
the
problem
is
addressed
in
the
ietf
right,
if
it's
kind
of
an
unaddressable
program,
maybe
you
also
want
to
give
up
at
some
point.
I
don't
know
or
you
keep
it
open
forever,
but
what
we've
seen
in
the
past
is
actually
that
the
sec
proof
program
the
stack
evil
program,
whatever
they
actually
have
like
concluded
successfully.
A
A
B
B
Yeah,
so
we,
I
know
we're
short
on
time
today,
so
do
expect
to
come
back
during
open
mic.
If
there's
more
questions
about
this
in
the
meantime,
I
think
we'll
switch
to
yeah.
It
looks
like
matthew
anyway.
In
the
meantime,
let's
switch
to
yari
and
the
covet
19
network
impacts
workshop
yuri-
I
hope
you're
here
somewhere
and
do
you
want
to
present
your
slides
or
do
you
want
me
to.
G
It
would
be
preferable
if
you
can
do
it.
I
haven't
tested
it
actually
and
I
actually
uploaded
also
new
ones
like
three
minutes
ago.
Amazingly,
you
may
not
have,
but
but
it
doesn't
really
matter
we
can,
if
you
can
easily
get
to
that,
then
that
way.
G
Yeah,
so
so
this
is
about
the
workshop
that
iab
held
actually
last
week.
We
announced
it
in
actually
the
previous.
I
had
the
open
meeting
in
july
and
had
a
paper
tissue
paper
deadline
early
october
and
just
held
the
workshop,
and
I
see
that
the
screen
share
is
being
started.
H
G
Anyway,
so
we
did
receive
about
20
position,
paper,
submissions
and
many
of
them
actually
very,
very
interesting
measurement
results
and
very
thankful
that
people
from
both
academia
and
industry
were
able
to
provide
information
for
for
us.
G
G
The
papers
are
available
at
the
link
that
you
can
see
on
the
screen
and
the
recordings
and
notes
will
be
available
soon.
Actually,
the
recordings
are
already
available.
I
just
don't
have
the
link
here,
but
I
can
post
the
youtube
links
to
to
the
chamber
room
in
a
moment
and
go
to
the
next
slide.
G
So
we
had
lots
of
discussion
in
the
workshop.
We
we
met
on
three
separate
days
and
and
thought
about
like
what
you
know.
What
did
we
see
and
you
know
what
worked
well
and
why
and
what
did
not
work
well
and
so
forth
and
let's
go
through
briefly
some
of
the
thoughts
that
were
expressed
in
the
workshop.
I
think
the
overall
feeling
was
that
the
internet
did
pretty
well.
G
We
had
a
reasonably
good
situation,
not
perfect.
You
know
some
slowdowns
and
you
know
all
of
us
probably
experience
some
kind
of
this
meeting.
A
thing
doesn't
work
right
now,
event
quite
often,
but
but
it
was
a
reasonably
good
situation.
I
think
particularly
alarming,
at
least
according
to
the
statistics
that
we've
been
able
to
see
and
and
of
course
the
internet
actually
helped
a
huge
amount
of
people
in
the
world
this
year
to
continue
their
work
or
you
know,
be
in
contact
with
the
family
and
so
forth.
G
We
also
have
indeed
very
interesting
data
about
the
situation
from
many
many
directions.
So
that's
great,
and
I
think
that
when
you
actually
talk
to
people
that
run
operator
networks
or
we're
running
services,
what
comes
across
is
that
everybody
was
very
highly
motivated
to
ensure
a
good
good
experience.
People
were
calling
each
other
making
sure
that
hey
we're
seeing
this
problem
over
there
in
your
network.
Can
we
do
something
about
that
and
so
on.
G
So
a
lot
of
things
happened
actually
in
the
background
that
may
not
be
so
visible
in
the
public
eye,
but
that
that
was
the
feeling
that
when
you
talk
to
people
that
you
get-
and
I
guess,
we
also
felt
that
the
internet
is
fairly
well
suited
for
adapting
the
new
situations.
G
So
all
this
is
great
if
you
click
one
of
those
one
more
time
go
to
the
next
slide.
Thank
you,
but
of
course,
there's
there's
also
some
some
issues,
so
so
one
is
that
we
actually
have
somewhat
limited
ability
to
observe
like
what's
actually
going
on.
We
have
also
limited
ability
to
control
things
like,
even
if
you
know
I,
as
a
user,
would
like
to
do
something
for
my
traffic.
I
I
can't
necessarily
always
make
that
happen.
G
G
We
should
also
remember
that
we
had
one
situation
like
what,
if
we
had,
you
know
something
else
like
a
catastrophe
or
master
a
natural
catastrophe
somewhere
that
would
take
some
networks
down
and
so
on.
How
would
we
have
fared
in
that
case,
so
it's
worthwhile
to
think
about
the
different
kinds
of
scenarios
that
we
could
have
been
in
and,
of
course
the
internet
is,
you
know,
has
been
hugely
important
for
us,
particularly
this
year.
Like
we
just
can't
do
our
work,
we
can't
do
our
e-health.
G
We
can't
do
much
without
the
internet,
so
that
has
kind
of
also
amplified
the
digital
device
device.
So
if
you
were
not
having
a
connectivity
previously,
you
know-
maybe
that
was
you
know
bad,
but
not
super
bad,
because
you
were
still
able
to
do
your
work.
G
But
now,
if
you
don't
have
connectivity,
you
will
not
be
working
and
you
will
not
be
going
to
school
and
so
on.
So
that's
that's
the
thing.
The
other
thing
is
that
you
know
could
we
could
we
think
about
ways
to
make
this
better
for
some
of
the
other
situations
that
we
could
get
into
and
also.
G
We
all,
of
course
know
that
there's
tons
of
things
to
improve
in
the
internet
from
you
know,
security
and
digital
divide
and
all
kinds
of
technical
issues.
So
so
the
you
know,
the
fact
that
we
fared
reasonably
well
during
the
pandemic
doesn't
mean
that
we
don't
have
these
issues.
We
obviously
need
to
work
on
those
next
slide.
Please.
G
So
some
potential
future
things
to
address,
obviously
all
the
usual
things
that
we
actually
have
to
do
anyway.
So
everybody
needs
to
make
sure
that
they
have.
You
know
the
reasonable
capacity
and
ability
to
respond
to
situations
different
from
you
know
current
day
or
this
week,
make
sure
that
our
implementations
are
improving,
make
sure
that
we
run
the
right
security
practice
and
so
forth.
G
But
more
specifically,
of
course,
we
could
have
more
measurements,
but
are
are
the
humans
getting
what
they
actually
need
and
because
the
human
sort
of
need
for
internet
actually
increased
this
year,
then
that
it's
also
a
question
of
whether
we're
actually
matching
that
or
not
jana
was
at
the
workshop,
and
he
talked
about
networks
and
applications
collaborating
perhaps
at
an
aggregate
level
instead
of
like
detailed
information
about
flaws.
So
that's
an
interesting
direction
to
think
about.
G
We
also
think
about
resilience
in
different
ways.
What
can
we
do
to
make
sure
the
internet
will
not
fall
over
because
of
some
some
issue
or
incident?
It
was
also
discussed
that
centralization
and
consolidation
is
bad
in
this
respect.
G
G
So
this
was
the
first
time
I
think
that
the
iab
has
held
a
virtual
workshop
or
like
a
proper
workshop,
but
not
not
meeting
physically,
and
I
guess
the
general
feeling
was
that
this
seemed
to
work.
Well,
we
had
a
healthy
amount
of
discussion.
We
had
about
30
to
40
people
at
different
times
in
the
workshop
and
seemed
to
be
the
right
amount
of
people,
and
you
know
very,
very
good
discussion.
G
We
did
split
that
center
in
the
three
days
or
sessions
with
a
free
day
in
between,
and
this
many
people
found
useful
because
you
actually
had
some
time
to
think
about
stuff.
If
you
we
had
had
like
actual
physical
work,
so
we
would
have
backed
it
in
a
day
and
a
half
and
it
would
have
been
a
coffee
break
and
immediately
to
the
next
thing
so
that
that
was
a
really
good
thing.
G
We
did
have
some
practical
issues
and
we
did
have
difficulties
in
separating
sometimes
the
kobe
19
aspect
of
things
and
everything
else
about
the
internet
because,
as
we
know,
there's
things
to
do,
but
that's
roughly
the
report-
I
don't
know
if
anybody
else,
media
or
others
who
were
at
the
workshop
wants
to
add
anything.
Stephen.
A
H
Hey
good
morning,
good
afternoon,
good
evening,
friends
yadi,
I
have
one
question
that
I
hope
you
can
delve
into
in
the
report.
Who
is
this?
H
We
and
if
you
go
back
to
your
slide,
two,
I
think
it
is,
and
and
throughout
your
presentation
you
talk
about,
we
don't
we
have
limited
information,
we
have
I'm
sorry.
It
was
slide
three,
my
apologies,
who
doesn't
have
the
who
has
the
information
and
who
and
under
what
circumstances,
should
that
information
be
shared
and
how
should
it
be
collated
and
with
what
authorization?
H
G
We'll
we'll
deal
with
that
in
the
reports
is
to
make
a
quick
observation
that
that
we
in
this
case-
and
it
was
slowly
written
in
the
slides,
but
but
we
can
be
a
number
of
things
like
I
mean
just
from
a
like
personal
directive
like
I
don't
have
enough
information
like
why
on
earth
is
my
conference
call
working
well
today
is
it
you
know
the
wi-fi
or
the
isp
or
or
something
else
and,
and
the
same
is
true
of
the
other
end
like
if
you're
the
conference
provider
can
you
can
actually
get
enough
information,
but
also
in
a
more
broader
sense
like
the
society
would
actually
benefit
from
having
an
understanding
of
how
well
is
the
internet
doing
in
our
country?
G
A
Yeah-
and
it
was
discussed
at
the
workshop
because,
at
least
for
me,
it
was
very
nice
to
see
all
these
measurements
together
from
different
angles.
So
there
was
a
lot
of
discussion
about
how
to
better
share
information
or
provide
information.
F
Oh
yeah,
so
thanks
for
this,
unfortunately,
I
couldn't
attend
last
week,
but
it
would
certainly
be
good
to
see
if
there
can
be
a
little
bit
more
ongoing.
You
know
considerations
about
this,
not
you
know
limited
only
to
cope
it
right
because
I
think
we've
seen
over
the
decades.
F
A
lot
of
you
know
questions
about
reliability
of
critical
services,
and
I
think
that
limiting
this
to
just
quote
the
internet,
or
so,
which
is
what
we
see
at
home,
which
obviously
is
now
with
covert
a
big
thing
is,
is
not
very
inclusive,
because
the
the
bigger
issues
seem
to
be
with
a
lot
of
the
controlled
networks
that
may
be
using
parts
of
the
same
infrastructure,
but
so,
for
example,
we've
seen
in
in
any
type
of
catastrophes
a
lot
of
the
critical
you
know:
providers
of
of
service,
in
that
instance,
to
break
down
which
may
or
may
not
impact
part
of
the
internet,
or
when
we
basically
see
something
that
impacts
the
911
service.
F
G
Thank
you
yeah.
I
I
think
that
makes
sense,
of
course,
just
not
just
the
iatf
and
iab,
but
lots
of
other
players.
So,
but
I
do
agree
that
we
do
need
focus
on
this
in
in
the
world,
in
some
fashion,.
I
Hi
yari
thanks.
I
was
hoping
to
attend
as
well
last
week,
but
I
didn't
you
said
that
one
of
the
things
that
happened
there
was
a
lot
of
conversations
among
operators.
I
guess
about
fixing
this
and
fixing
that,
and
I
I
I
don't
expect
you
have
that
information,
but
I
think
that
the
public
kind
of
needs
to
know
that
some
of
the
nature
of
that
and
you
were
just
speaking-
an
answer
to
elliot
as
well
about
who's,
the
wii
and
all
this
kind
of
stuff
and
are
we
getting
the
internet
we
deserve?
J
That
the
protocols
we're
designing
are
evolvable
and
going
to
work
in
deployments
and
over
time,
both
in
how
they're
designed
and
how
we
are
kind
of
evaluating
them
and
testing
them
during
the
the
protocol
development
process
and
the
two
topics
that
we've
discussed
so
far.
Most
are
one
on
the
evolvability
side,
how
we
handle
protocol
extensions
and
ossification
and
then
on
more
of
the
kind
of
practical
deployability
side
as
we're
getting
protocols
ready
discussing.
J
How
are
we
tracking
implementation,
testing
and
interoperability
in
our
working
groups
and
trying
to
understand
you
know
kind
of
what
our
strategy
there
ends
up
leading
to
in
the
actual
deployed
internet
later
after
we've
kind
of
finished
the
work
in
the
itf?
So
next
slide.
Please.
J
So,
on
the
extensibility
side
of
things,
the
main
item
that
we're
planning
on
doing
is
discussing
and
kind
of
moving
forward,
a
draft
that
martin
thompson
had
written
previously
a
couple
years
ago,
which
is
called
use
it
or
lose
it,
which
is
the
formal
name,
is
long-term
viability
of
protocol
extension
mechanisms.
J
And
a
lot
of
this
is
trying
to
formalize
an
iab
document,
some
of
the
notions
around
greasing
and
active
use.
And
how
do
we
ensure
that
our
protocols
aren't
as
vulnerable
to
ossification
as
we've
seen
for
a
lot
of
protocols
in
the
past?
It
has
a
lot
of
good
discussion
around
different
examples
of
protocols
that
have
succeeded
or
failed
and
the
strategies
that
we
are
seeing
come
out
to
successfully
avoid
protocols
ossifying
to
the
point
that
you
cannot
actually
use
some
of
the
extension
points
you
designed
in
the
protocol.
J
Talks
about
how
you
can
encrypt
that
to
make
sure
that
fewer
people
can
ossify
it
discusses
greasing
mechanisms
and
also
talks
about
invariance.
So
this
is
going
to
be
one
of
the
main
topics
we
have
for
our
december
meeting
and
particularly
we've
had
some
conversations
on
the
list
and
on
github
about
greasing.
Specifically
greasing
is
a
technique
that
we've
seen
come
from
tls
and
we're
talking
about
it
for
other
protocols,
but
generally
it's
been
applied
to
protocols
that
have
already
had
ossification
problems
and
we're
trying
to
rectify
things.
J
I
think
it's
an
interesting
conversation
that
we're
having
about
you
know
as
we're
designing
new
protocols
or
new
protocol
versions.
What
does
it
mean
to
put
something
like
greasing
or
build
more
active
use
into
the
protocol
design
itself,
rather
than
tacking
it
on
later?
So
that's
going
to
be
interesting
discussion
and
if
you
want
to
participate
in
that,
please
join
the
list
and
you'll
get
the
coordinates
for
that
meeting
next
slide.
Please.
J
And
then
just
very
quickly
a
note
on
the
other
side
of
things
we're
talking
about
how
do
we
track
our
interoperability
and
deployments
as
we're
developing
them?
A
couple
of
us
did
an
experiment
during
this
hackathon,
in
which
we
are
trying
to
build
some
generic
tools
that,
hopefully
other
hackathon
teams
or
also
other
people
doing.
Protocol
development
in
general
in
itf
could
use
to
have
some
more
automated
tools
for
tracking
results
and
reporting
results
of
testing
against
documents.
J
So
in
this
case,
we
defined
some
tags
that
we
could
add
to
markdown
files
for
drafts.
That
would
essentially
annotate
here
are
some
of
the
requirements
that
we
think
need
to
be
tested
or
validated
as
you're
building
a
implementation,
specifically
that
ensure
that
you
are
interoperable,
but
also
that
maybe
you're
following
some
of
the
requirements
we
have
around
extensibility
and
then
this
generates
a
file
that
actual
implementations
as
they're.
Doing
testing
can
essentially
just
upload
a
json
to
say
whether
or
not
they
pass
that
given
test
so
next
slide.
J
I
shamelessly
base
this
on
something
that
mark
nottingham
had
made
for
some
http
cache
testing
across
different
browsers,
but
we
are
working
on
making
this
into
a
generic
template
that
anyone
could
drop
into
any
repository
they
have
for
their
documents.
This
is
on
github
here,
that's
being
hosted
and
you
can
just
have
columns
that
are
automatically
generated
for
any
implementations
that
are
being
created
against
these
specs
next
slide.
J
This
is
something
maybe
that
we
could
see
going
forward
for
working
groups
and
other
documents
to
do
such
that
people
who
are
coming
to
work
on
these
protocols
or
even
as
the
working
groups
themselves
are
evaluating.
The
status
of
the
document
being
ready
to
move
on
can
see
what
exactly
has
been
done.
What's
been
tested,
which
points
have
actually
been
exercised
in
the
protocol
by
active
implementations
and
that's
all.
I
have.
K
Forgive
me
tommy,
but
I
jumped
back
in
the
queue
because
I
got
kicked
out
with
the
glitch
that
happened.
I
just
wanted
to
comment
on
what
yari
akko
said
and
agree
with
that,
and
I
expect
you
will
agree
too.
I
think
it
would
be
really
really
good
if
the
ietf
could
work
on
defining
network
quality
users
all
over
the
world.
K
Today
they
go
to
speedtest.net
and
they
measure
the
megabits
up
and
the
megabits
down,
and
they
think
that
tells
them
whether
meat
echo
is
going
to
work
for
them
and
I
think,
would
be
really
valuable
if
we
could
start
some
discussions
about
what
constitutes
network
quality,
doesn't
isp
support
ipv6.
K
Do
they
block
dns
queries
for
anything
other
than
v4
and
v6
addresses,
because
that
impacts
the
http
svc
dns
query:
do
they
block
tcp
fast
open?
Do
they
block
multipath
tcp?
There
are
many
many
aspects
of
network
performance
and
reliability
and
quality
that
go
far
beyond
how
many
megabits
download
speed.
Can
you
get
so?
I
would
love
to
see
the
ietf.
Do
some
work
in
that
area.
A
K
I
think
the
documents
are
there,
I
think
collecting
them
and
deciding
which
are
important,
and
I
think
what
I'm
really
talking
about
is-
and
this
is
maybe
more
of
an
open
source
thing
than
an
idf
thing.
But
if
we
could
build
some
tool
that
people
can
run,
that
gives
them
a
dashboard
about
what
kind
of
service
they're
getting
and
what's
broken,
and
what's
working
that
that
would
be
useful
to
end
users
in
a
way
that
rfcs
don't
directly
answer
that
question.
A
Thank
you
any
questions
for
tommy
any
quick
questions
for
tommy.
L
Hey
so
yeah
the
model
t
program,
I've
made
to
say
and
won't
use
much
time,
so
the
program
basically
exists
to
try
and
discuss
the
internet
model
and
changes
to
that
and
possibly
to
offer
some
updated
text
back
to
the
ietf
that
could
be
considered
by
sag
or
by
the
securities
as
a
possible
bcp.
L
There's
not
much
has
happened
in
in
the
last.
While
we
did
have
a
chat
back
in
august,
there
will
has
been
a
huge
amount
of
follow-up.
For
that,
probably,
I
think
it's
mostly
down
to
20
20,
isn't
people
are
busy
elsewhere
and
it's
hard
to
concentrate
on
everything?
I
guess
the
list.
Is
there
it's
an
open
program
and
there's
a
bunch
of
slide
a
bunch
of
drafts.
People
have
written
so
next
slide.
L
L
I
guess
that's,
there's
kind
of
reasonable
text
amongst
a
whole
bunch
of
them
that
we
need
to
kind
of
get
through
and
see
which
bits
need
are
worth
kind
of
trying
to
preserve
in
or
see
like
format
or
give
try
and
offer
back
to
the
ietf
as
a
possible
bcp
and
yeah
if
you're
interested
in
in
the
internet
model
and
how
that's
evolving
then
jump
on
the
list
and
get
involved
and
we'll
probably
try
and
organize
a
chat
either
before
or
after
the
holidays
to
see.
If
we
can
get
things
moving
again.
A
A
A
Yes,
so
just
quickly,
we
have
10
minutes
to
go,
that's
good,
so
this
open
mic
really
is
about
architectural,
architectural
and
technical
topics,
and
we
also
have
the
open
mic
tomorrow
in
the
plenary
session,
which
is
like
more
on
maybe
administrative
questions
or
whatever,
but
like
this
open
mic.
Specifically,
you
want
to
get
feedback
on
the
ib
open
session,
as
well
as
as
a
whole.
You
can
provide
feedback
on
the
talks
we
have
or
other
architecture
and
technical
topics,
and
with
that
we
start
with
mark.
E
B
A
level
higher
too,
because
I
mean
I
think
that
that's
an
issue
across
the
entire
industry
from
academia
into
irtf
into
ietf
into
you
know,
tech
transfer
into
industry
has
always
been
a
long-term
issue
within
the
atf
and
you're,
absolutely
right
that
ib
programs
are
going
to
suffer
the
exact
same
problem
unless
we
figure
out
how
to
act.
You
know
adequately
transition
stuff
and
I've
spoken
to
a
lot
of
people
about
that,
and
if
you
have
ideas
on
making
that
work
really
well,
certainly
bring
them
up
on
architecture.
Discuss.
A
Yeah,
I
also
wanted
to
comment,
but
that,
as
you
said
right
now,
I
think
the
main
purpose
of
the
ib
program
is
really
to
transition
or
start
discussion
start
working,
the
ietf
and
that's
not
always
well
defined.
So
we
did
have
problems
in
the
past
to
actually
figure
out
when
a
program
ended
when
we
achieved
enough,
which
is
also
why
we've
been
reconsidering
this
to
make
sure
and
we
have
a
kind
of
quicker
feedback
loop
in
figuring
out
where
we
are
in
the
programs.
But
it's
it's
not
like.
A
B
M
Hello,
I
just
want
to
save
you
from
like
seven
minutes
of
awkward
silence,
so
I
want
to
go
back
to
something
from
the
the
iv
covert
workshop,
which
I
attended,
which
was
actually
quite
an
awesome
experience.
Well
done
again
for
the
organizers
of
that
there
was
some
discussion
at
the
end
of
that
that
I
would
encourage
the
iab
to
think
about
about
like
sort
of
the
very
end
of
the
last
day.
M
M
Is
it
moves
bandwidth
to
end
points
really
quickly,
because
that's
what
we
designed
it
to
do
and
like
sort
of
anecdotes
from
that
are
like
people
saying
that
the
the
limiting
factor
that
this
network
has
had
in
terms
of
moving
everybody
online
has
not
been
the
bandwidth
in
most
markets
right
and
when
it
was
the
bandwidth
in
those
markets.
It
ended
up
not
being
the
bandwidth,
because
we
could,
you
know,
add
bandwidth
relatively
quickly.
The
limiting
factor
is
has
been
in
a
lot
of
cases,
room
right
like
so.
M
If
you've
got
a
family
of
five
and
they're
all
expected
to
be
online
at
the
same
time,
a
lot
of
houses
don't
have
five
doors.
You
can
close
to
keep
the
the
ambient
noise
down
right
or
another.
One.
I've
heard
is
devices
right
like
so
you
have
a
six-year-old
and
an
eight-year-old.
They
don't
all
need
their
own
tablets,
but
now
they
do
because
they
both
have
to
be
in
in
remote
schooling.
M
I
would
I'm
not
sure
how
to
turn
this
into
a
thing
that
the
ieb
should
consider
that
isn't
like
sort
of
a
rabbit
hole,
and
maybe
it
turns
into
something
kind
of
like
the
discussion
that
we
tried
to
have
about
consolidation,
where
you
know
we'd,
run
it
off
into
the
economic
corners
and
then
say:
oop,
not
not
our
area.
But
I
think
considering.
M
Not
just
the
affordances
of
the
network
and
the
architecture,
but
at
the
application
architecture
that's
built
been
built
on
top
of
it
in
the
last
10
to
15
years,
so
the
web
and
the
service
sit
on
top
of
the
web.
It
would
be
interesting
to
sort
of
like
sit
back
and
reflect
on.
You
know
what
success
is
for
taking
everything
remote
and
what
success
is,
for
you
know
beyond
just
the
sort
of
the
pushing
packets
part
of
it.
M
G
Thank
you
yeah.
Thank
you.
That
was
a
really
good
good
comment,
and
it
is
true
that
this
is
much
broader
than
the
the
sort
of
narrow
technical
thing
that
we
we
like
to
think
of
and
and
and
your
examples
aren't,
the
only
ones
like
you
know.
We
didn't
have
much
congestion.
In
fact,
they
didn't
have
any
congestion
from
those
people
who
were
not
connected
to
the
internet.
G
So
there's
there's
lots
of
things
that
that
one
should
think
about
and
for
for
the
sort
of
social
impact
of
you
know
ict
technologies
or
the
internet
to
to
what
the
rest
of
us
do.
So
I
don't
know
exactly
how
to
go
about
that,
but
it's
good
to
keep
that
in
mind
that
it's
not
all
that
the
packet
moving
part
of
this
is
not
the
whole
picture.
A
Thanks,
we
have
brian
back
in
the
queue,
I'm
not
sure
if
you
want
to
reply
or
if
we
should
move
on
with
the
queue.
M
I
have
like
a
30-second
thing
that
I
would
add
to
that
yeah
so,
like
you
said,
like
the
there
was
no
congestion
for
people
who
weren't
connected
to
the
internet,
and
the
internet.
Society,
for
example,
has
a
a
wide
variety
of
programs.
Looking
at
improving
connectivity
for
large
parts
of
the
world
that
were
kind
of
left
behind.
M
As
part
of
of
of
this
shift
online
and
possibly
you
know,
figuring
out
how
to
use
the
iab
in
its
capacity
as
a
technical
advisory
committee
to
the
internet
society
and
how
the
internet
society
could
work
on
sort
of
problems.
Other
than
basic
connectivity,
sort
of
like
leveling
up
might
be
worth
your
time.
A
I
Hi
thanks
I'll
try
to
break
this
again,
so
what
brian
said
about
not
having
enough
doors
to
close,
and
that
was
reminding
me
of
the
you
know
the
concept
that
people
have
devices
and
they
don't
always
want
to
use
the
same
devices
and
the
devices
tend
to
be
kind
of
single
usery
in
the
sense
that
it's
hard
to.
Actually,
you
know
get
my
settings
onto
the
device,
that's
in
question.
I
You
know
just
figuring
out
who
has
the
net
foot
in
the
netflix
password
and
how
do
I
type
it
in
and
why
do
I
have
that
in
the
first
place?
And
so
I
think
that
there
is
a
question
here
of
of
identity
and
data,
and
how
do
I
move
that
from
device
to
device
without
having
to
do
all
this
complexity,
and
so
actually
there's
some
place
for
standards
that
actually
for
bits
that
go
over
the
wire
in
a
somewhat
secure
way?
And
we
see
this
in
iot
as
well.
I
Okay,
that
you
need
to
get
configurations
on
and
off
devices,
and
you
need
to
replace
them
when
they
break
and
all
sorts
of
stuff.
And
so
actually,
I
think,
there's
a
whole
bunch
of
work
there.
That
you
know
is
very
end
user
focused,
but
is
still
bits
in
the
wire
that
stuff
that
we
basically
need
to
intelligently
hide
from
them,
so
that
it's
done
right
rather
than
you
know,
password
one.
Two,
three
four.
B
I
have
a
whole
soapbox
on
that.
I
could
go
on
for
much
longer
than
two
minutes,
because
I
agree
with
you
completely.
I
mean
it's.
It's
insane
that,
in
order
to
send
something
from
one
phone
to
another
phone,
we
basically
leave
the
house
network
and
that
has
to
do
with
identification
more
than
anything
else
and
how
to
identify
stuff
and
we've.
J
B
Progress
there
with
you,
know
local
dns,
you
know
mdns
type
resolution
and
things
like
that
to
try
and
find
stuff,
but
to
the
the
vast
majority
of
the
simpler
solution
for
most
people
is
send
it
out
of
the
house
and
then
back
in
I've
sent
a
file
to
my
wife
using
dropbox,
which
is
not
true,
because
I
never
use
dropbox.
But
you
know
a
lot
of
people
do
that.
B
It's
a
very
valid
point
with
michael.
I
think
you
know
it's
interesting
that
there's
a
lot
of
comments
in
the
last
few
questions
about
edge
networks,
right,
we've
concentrated
for
a
long
time
on
the
core
infrastructure
and
less
on
the
edge,
and
I
will
note
that
the
coin
irtf
group,
as
you
might
be
interested
in
looking
at
too,
which
is
sort
of
dabbling
around
the
space
as
well.
For
those
that
aren't
familiar
with
it.
That's
the
computing
on
the
internet
network.
What's
the
I
don't.
B
What
it
stands
for,
but
it's
edge
network,
compute,
cpu
thinking
more
than
anything
else.
F
A
B
Yeah,
so
I
guess
we're
out
of
time
and
we're
out
we're
out
of
queue
so
that
worked
out
perfectly.
Thank
you,
everybody
for
coming
and
we
will
see
you.