►
From YouTube: IETF 108: IAB Open
Description
The Internet Architecture Board (IAB) will for the first time hold an open meeting on Tuesday, July 28 at 13:00-13:50 UTC. This session will provide an opportunity for more direct interaction and technical discussion between the community and the IAB, in both directions: providing information about and reporting back on work done as well as gathering input about on-going work.
A
A
B
C
C
Okay,
now
we're
ready
to
start
now.
You
see
my
screen
and
you
hear
me
that's
great,
so
I
was
already
saying
welcome,
but
you
didn't
hear
me
so
welcome
again
everybody
I'm
mia
cooleven,
I'm
the
iep
chair
and
tommy
paulie
is
co-sharing
with
me
today.
C
Good
as
we
already
lost
three
minutes,
let's
start
right
away,
and
this
is
an
iab
session,
but
it's
also
part
of
the
iab
meetings.
So
everything
you
say
here
is
also
part
of
the
usual
notewall
and
ipr
coverage.
C
It's
not
only
about
apr,
there's
also
some
links
here
about,
for
example,
code
of
conduct.
So
if
you're
not
aware
of
these
documents,
please
have
a
look
at
them
and
study
them
with
that.
We
start
quickly
looking
at
our
agenda
today
so-
and
this
is
the
first
time
we're
having
such
an
ieb
open
meeting.
So
we
have
planned
10
minutes
for
a
little
welcome
and
some
updates
and
some
introductions
about
what
we're
planning
to
do
with
this
meeting.
And
then
we
want
to
talk
mostly
about
technical
and
architectural
work.
C
The
iap
is
doing
in
terms
of
documents,
workshops
and
programs
and
at
the
very
end
we
have
a
little
bit
time,
hopefully
for
a
little
open
mic,
and
the
idea
here
is
to
specifically
look
at
or
have
some
discussion
about
how
you
found
this
meeting
or
what
you
would
expect
from
future
kind
of
ib
open
meetings.
C
So,
what's
this
all
about?
Why
do
we
have
this
this
meeting?
C
The
idea
here
is
to
really
focus
on
technical
and
architectural
aspects
of
the
work
that
the
iab
is
doing
and
the
goals
is
to,
on
the
one
hand,
increase
visibility
of
what
we're
doing
to
the
community
to
increase
transparency,
but
also
kind
of
promote
the
work
we're
doing,
but,
on
the
other
hand,
also
to
collect
feedback
and
input
from
the
community.
C
We
can
have
a
more
interactive
way
of
contact
connecting
to
the
community
and
get
more
direct
input
from
you,
rather
than
just
discussing
discussion
on
mailing
lists
again.
I
said
this
already.
This
is
like
focusing
on
the
technical
and
architectural
work.
The
iab
is
doing
everything
that
is
more
administrative
or
process
related.
C
Also
related,
you
can
always
send
comments
or
any
kind
of
input
and
feedback
directly
to
the
ieb
using
the
ib
iab.org
mailing
list,
but
we
also
have
the
architecture
discuss
maintenance,
which
is
like
an
open
mailing
list.
Everybody
can
join
and
you
the
community
or
we
together
can
have
discussions
related
to
architectural
discussions
topics.
C
So
we
use
this
mailing
list
also
to
announce
when
we're
working
on
iab
documents
when
we're
going
to
plan
to
adopt,
or
at
least
discuss
the
adoption
of
a
new
ib
document,
or
when
we
collect
feedback
of
these
documents,
for
example.
So
that's
an
open
list
to
join.
If
you
are
interested
in
specific
topics
that
is
related
to
a
certain
id
program,
usually
there's
also
an
open
mailing
list
for
each
program
that
you're
able
to
join
and
provide
feedback
there.
C
Then
I
would
like
to
take
the
opportunity
and
quickly
report
back
a
little
bit
before
we
start
with
the
rest
of
the
agenda
on
the
ib
virtual
retreat.
We
had,
I
wrote
a
blog
post
about
this,
and
the
link
is
at
the
very
bottom
of
this
slide
and
the
the
reason
why
I
would
like
to
report
back
is
because
usually
at
the
retreat,
we
have
a
lot
of
topics
also,
which
are
more
related
to
kind
of
housekeeping
processing
and
so
on.
C
Some
technical
topics
as
well,
but
this
time
also
because
we
had
this
architectural
because
we
had
this
virtual
meeting-
we
had
like
actually
a
chance
to
differently
organize
our
meetings.
We
had
only
very
few
meetings
where
we
were
all
together,
but
we're
organizing
ourselves
into
various
breakout
sessions.
So
we
took
the
opportunity
to
before
the
ib
retreat
think
a
little
bit
more
broadly
about
strategy
about
trends.
C
Challenges
make
a
little
survey
between
us
to
get
input
from
from
us
as
a
group
and
then
based
on
that,
we
created
a
couple
of
breakout
groups
discussing
the
topics
listed
here
on
the
screen.
So,
as
you
can
see,
some
of
the
topics
were
related
to
the
current
situation,
but
also
other
technical
factors
on
more
strategic
points
as
well.
C
Okay,
so,
let's
start
with
the
first
part
of
our
agenda
that
we
were
interested
in
which
is
focusing
on
documents.
Currently,
we
don't
have
any
active
ib
documents
which
are
kind
of
not
really
ready.
Yet
we
have
the
draft
iab
for
the
users,
which
is
already
in
the
rfc
editing
queue,
and
we
see
a
little
bit
of
a
presentation
about
this
next
and
we
have
the
data
report,
which
is
still
an
iep
document,
but
that's
a
workshop
report.
It's
not
like
any
architecture,
guidance
or
anything
like
that
there.
C
C
There
are
also
a
couple
of
recently
published
documents,
I'm
just
putting
put
on
the
slide
here
because
we
didn't.
This
is
the
first
time
we
have
this
kind
of
meeting
so
in
the
last
year,
and
there
was,
for
example,
rcm
8546
on
the
wire
image
of
network
protocol
related
to
that
there's
also.
The
protocol
transfer
protocol
passengers
rc
8558,
and
there
was
another
workshop
report
if
you're
interested
in
that.
E
Okay,
that's
a
good
start
yeah,
so
draft
id
for
the
users
is
a
document.
If
you
recall
the
abstract
is
here,
it
explains
why
the
eye
believes
that
when
there's
conflict
between
the
interests
of
end
users
of
the
internet
and
other
parties,
itf
decisions
should
pay
for
users,
and
it
also
exploits
how
they
can
be
more
achieved.
E
So
this
started
a
while
back
in
august
2015
as
an
individual
draft
adopted
by
the
iesg
the
middle
of
last
year
and
then
approved
in
earlier
in
this
year
after
a
few
rounds
of
community
review,
and
the
community
review
gave
us
some
really
good
input,
I'm
making
sure
we
clearly
more
clearly
identified
the
document
as
suggestions
from
the
ib
rather
than
an
idm
consensus
or
something
that
was
sourced
from
the
entire
community
and
also
to
expand
the
suggestions
of
how
to
better
represent
user
needs.
E
So
there's
actually
a
fair
amount
of
detail
in
the
document.
Suggestions
about
how
the
ietf
can
more
effectively
consider
the
needs
of
end
users
in
in
its
deliberations,
and
so
that's
the
really
brief
summary
it's
in
the
rc
editor
queue.
It's
been
there
for
a
while.
So
hopefully
we'll
see
it,
I
can
sign
a
number
and
be
published
fairly
soon.
I
think
the
only
open
question
on
this
one
is:
are
there
any
next
steps
that
we
might
take
in
terms
of
following
the
the
thoughts
of
that
document
or
expanding
upon
it?
E
It
talks
about,
for
example,
the
the
current
body
of
knowledge
we
have
around
privacy
and
other
other
things
that
are
our
principles.
We
use
to
guide
our
decisions
that
might
impact
users.
Do
we
need
more
of
those,
I
think
that's
an
open
and
ongoing
discussion,
but
if
it's
something
that
folks
have
interest
in
something
you
might
consider
bringing
the
iap,
that's
all
I
got
good
mary
did
you
want
to
do
discussion
or
just
just
an
update.
C
F
E
It
is
trying
to
establish
how
we
consider
the
end
user
needs
and
and
and
to
what
degree
would
you
consider
end
user
needs
and
make
decisions,
especially
when
they
were
in
conflict
with
other
stakeholders.
So
I
I'd
encourage
you
to
read
the
draft.
If
you
haven't
already.
F
G
This
one
isn't
speaking
a
question
about
this
end
user
thing.
I
apologize
that
I
didn't
join
earlier
session,
but
does
this
also
involve
some
stuff
on
the
end
user
side
that
the
itf
has
so
far
not
been
approaching,
like
user
interface
issues
and
this
kind
of
stuff?
E
Now
the
the
draft
doesn't
directly
address
expanding
the
scope
of
the
itf's
work
or
or
you
know,
are
our
considerations
of
of.
What's
what
we're
good
at
and
what
we're?
Not,
I
think
user
experience
is
something
that,
in
the
past
generally,
we've
had
a
lot
of
reticence
to
dive
into
for
a
lot
of
good
reasons.
The
few
places
where
I've
seen
the
itf
attempt
something
or
where
there
are
overriding
security
concerns,
that's
something
that
occasionally
happens,
but
it
doesn't
delve
into
these
areas
in
any
depth.
E
Not
currently
now
it's
certainly,
I
think
something
that
I'm
interested
in
a
number
of
people.
Other
people
are
interested
in,
but
it's
not
something.
That's
a
current
error
discussion.
It's
also
an
area.
Frankly,
that
is,
is
there's
expertise
in
a
number
of
other
places.
Besides
the
iatf
and
other
places
that
might
be
closer
to
those
decisions
that
are
being
made
that
have
those
effects
thanks.
G
C
Okay,
that's
even
better!
So,
let's
move
on
so
let
me
see
if
I
can
change
to
the
next
slide
there.
We
are
okay.
So,
as
I
said,
this
is
what
our
current
scope
of
iv
documents
is.
So
the
next
part
we
want
to
look
in
is
workshops,
and
we
take
the
opportunity
to
report
out
on
one
of
the
workshops
we
have
done
last
year,
which
is
the
data
workshop
and
then
we
would
also
like
to
announce
the
new
workshop
you're
planning
for
november.
H
Yeah,
thank
you
and
since
this
first
one
is
simply
calling
for
review
of
the
report.
I'll,
take
it
very
briefly
and
just
use
this
slide,
so
we
had
a
workshop
last
year,
the
the
report
has
been
out
for
a
while
and
we
would
like
to
get
some
some
more
review
of
that.
A
few
different
people
who
were
part
of
the
workshop
before
publishing
it
as
an
rfc
there's
a
bunch
of
interesting,
hopefully
interesting
conclusions.
H
If
you
look
at
the
slides
on
your
own
time
or
the
report,
and
we
actually
identified
some
things
that
we
later
started
doing
at
the
itf
steven,
we'll
talk
about
one
of
one
of
those
topics
later
in
this
session,
but
basically
please
review
and
we'll
be
publishing
this
in
rfc
soon.
So
I
think
that's
it.
Unless
people
have
questions
we
can
move
to
the
next
one.
H
Okay,
yeah
to
the
next
place:
yeah
okay,
so
this
is
a
proposed
workshop
that
we
are
planning
to
have
that
and
that
we
are
about
to
send
the
call
for
papers
out
in
in
a
few
days
already
went
out.
I'm
not
sure-
and
you
can
see
the
organizing
committee
here
on
the
screen
and
next
time
yeah.
H
So
the
background
for
this
is
that,
of
course,
we've
been
affected
greatly
by
this
copic
19
pandemic,
but
it
also
has
had
an
impact
on
networking
and
we've
seen
isps
and
conversational
multimedia
systems
and
conferencing
systems
impacted.
H
H
H
So
we
would
like
to
have
a
workshop
that
talks
about
the
traffic
patterns
and
their
changes.
We're
going
to
learn
about
that
we'd
like
to
understand
how
the
different
operators
and
service
providers
responded.
What
kind
of
things
they
have
to
do,
it's
an
opportunity
for
us
to
share
our
understanding
or
different
people's
understandings
of
what
the
impacts
were.
What
was
it,
what
was
needed
and
what
worked
and
what
did
not,
and
maybe
also
an
opportunity
to
learn
for
the
future
next
slide.
H
So,
topics
in
scope
for
the
workshop
are
measurements
discussion
about
the
behind
the
scenes,
network,
management
and
other
activities
that
have
to
be
going
on
different
experiences,
probably
in
when
we
talk
about
general
network
connectivity
or
conferencing
systems
or
entertainment
systems.
H
If
you
plan
to
separate
those
topics
out
a
little
bit,
but
we
probably
also
learned
some
things
or
can
learn
some
things
for
preparedness
and
operations,
and
possibly
also
for
internet
technology
and
architecture,
so
that
I
think,
would
be
an
interesting
thing
to
talk
about
like
how
can
we
adjust
to
to
adjust
in
the
future
even
better?
I
I
think
it
is
a
reasonably
well
done
performance
from
the
internet,
but
we
can
probably
improve
even
more
next
slide.
H
So
so
this
is
a
virtual
workshop
and,
as
is
useful
for
for
iab
workshops,
we
call
for
position
papers.
H
People
can
submit
position
papers
in
this
form,
like
you
know,
provide
information
for
for
the
participants
and
for
others,
and
also
is
a
reason
for
for
us
to
invite
the
set
of
people
that
are
have
written
the
interesting
papers
and
and
then
we'll
have
not
just
one
session
or
not
not
one.
Two
day
long
conference
call
but
several
sessions
separated
by
the
topics
a
little
bit.
H
So
so,
if
you
only
know
and
care
about
conferencing
systems,
you
can
probably
attend
only
that
part
if
you
want
to
and
that
will
be
in
november,
you
can
see
the
other
dates
on
the
screen.
So
that's
basically
it
we're
setting
it
up
and
expect
to
see
the
call
for
papers
out
soon
and
we'd
love
to
have
people's
participation
in
this
and
submissions
and
feedback
as
well.
So
that's
it.
B
Thank
you.
We
have
pkg
in.
I
Queue
hello:
this
is
daniel
kahn,
gilmore
from
aclu.
I'm
was
a
little
bit
surprised
to
see
in
your
list
of
topics
which
covers
a
fair,
fairly
wide
range,
no
mention
of
either
the
consolidation
questions
that
have
we've
been
grappling
with
as
an
organization
and
how
those
are
impacted
by
the
move
towards
everything
being
online
and
not
in
person
and
questions
around.
I
Privacy
and
security,
what
tradeoffs
happened
there
as
well,
are
those
just
there
by
implication,
because
we're
always
talking
about
all
those
topics
or
is
there
a
reason
to
not
include
them
in
the
list
of
I.
H
Think
those
are
really
good
points
and
and
certainly
impacts
that
we
should
think
about.
That
sounds
like
a
perfect
topic
for
position,
paper
or
multiple
papers,
so
so
I
I
personally
do
hope
that
we
we
get
to
discuss
that
topic.
Also,
I've
been
personally
quite
interested
in
in
that
topic
in
other
other
contexts
as
well,
so
certainly
food
for
dog.
Thank
you.
H
C
Yeah,
there's
also
a
question
in
the
driver
room
why
this
is
invitation
only
when
it's
a
virtual
meeting.
H
We
usually
like
to
have
like
it
it
or
discussions
are
best
had
when,
when
you
have
very
well
informed
participants
and
made
sort
of
contributions
that
we
verify
by
by
looking
at
the
position
papers
now,
I
I
think,
given
that
we
are
virtual,
my
personal
hope
is
that
essentially
we
would
have
participants
and
then
you
can
sort
of
freely
listen
by
anybody
who's
interested.
I
I
haven't
discussed
this
with
the
other
organizers,
so
I
don't
know
how
they
feel
about
that.
C
Yeah,
maybe
let
me
add
that
I
mean
it's
not
meant
to
be
a
barrier
to
participate.
Please,
if
you're
interested
just
send
some
kind
of
paper
position
paper,
it
doesn't
have
to
be
long.
What
we
want
to
make
sure
is
that
we
have
a
good
group
of
people
with
a
good
discussion,
and
I
think
this
is
true
both
for
in
person
as
well
as
virtual.
If
you
have
like
a
group
of
like
hundreds
of
people,
it's
not
the
same
discussion.
C
B
C
Okay
and
now
it
also
shows
everything
right
to
me,
okay,
so
we
move
on
to
the
third
part
here,
which
is
reporting
back
a
little
bit
about
technical
programs.
We
have
one
active
program
which
is
the
internet's
redmond
program
and
that's
why
steven
just
joined
the
audio
because
he
will
tell
us
a
little
bit
about
it.
Also,
we
listed
here
some
programs
we
closed
recently
last
year,
just
for
information.
C
More
information
is
also
on
the
ieb
webpage
and
then
after
steven
we
have
tommy
who
will
tell
us
a
little
bit
about
a
new
program.
We
are
discussing
right
now,
but
let's
start
with
stephen.
J
Hi
so
in
fact,
there's
not
much
to
say
mostly
because
I
did
booger
all
in
the
last
period,
because
I
was
basically
busy
elsewhere,
so
the
usual
excuse.
However,
other
people
have
done
a
few
things
and
we
hope
to
kind
of
get
ramped
up
again
this
week
and
subsequently.
J
So
we
had
a
good
call
on
april
20th.
After
you
know,
it
could
be
in
the
period
of
itf
107.
we're
planning
to
do
a
virtual
meeting
soon.
J
So
there's
a
doodle,
a
poll
on
the
mailing
list
for
to
organize
one
of
those
in
august
september
time
and
trying
to
be
friendly
to
our
australasian
located
people
who
were
to
whom
we
were
unfriendly
last
time
and
that
do
you
have
a
link
there
to
the
character
and
to
the
mailing
lists,
we're
considering
the
evolution
of
the
threat
model,
possibly
to
offer
an
update,
speciep
72
that
the
iaf
itf
might
consider
and
next
slides.
J
There's
a
bunch
of
drafts
being
considered
that
have
been
discussed
on
the
list.
I
wouldn't
say
any
of
them,
are
you
know
completely
finished
or
nearest
people
are
discussing,
there's
overlap
between
these
drafts
and
that's
okay.
You
know
we
may
find
somewhere
during
this
question,
to
see
how
to
proceed
with
them.
J
We're
also
at
the
area
suggestion
going
to
try
and
see
if
people
are
around
this
week,
just
to
have
an
informal
get
together
on
thursday
at
16,
10,
utc
and
again
details
for
that
are
on
the
mailing
list.
If
you're,
if
you
can't
join
a
viewer
and
that's
totally
informal,
just
to
try
and
reboot
ourselves
after
a
period
of
activity,
that's
all
I
had.
If
any
has
a
question
comment.
K
Dominic
see,
can
you
hear
me
just
thanks
to
steven
for
presenting
this,
and
I
just
wanted
to
make
a
comment
about
the
fact
that
there's
been
a
lot
of
work
done
on
all
these
drafts
and
they're
quite
interesting,
it'd
be
great
to
to
get
as
many
people
who
are
interested
and
involved,
so
just
a
plug
for
the
work
that
we're
all
doing
on
this
thanks.
L
J
That
list
of
graphs
is
the
list
of
drafts
recently
mentioned
on
the
model,
t
mailing
list-
and
you
know
none
of
these
things
has
any
particularly
formal
status,
so
anything
like
that
would
come
later,
so
it
could
be
my
mission.
It
could
be
that
the
author
thought
it
was
better
elsewhere.
I
don't.
C
C
C
B
Yes,
all
right,
thank
you.
So
we
did
send
out
a
note
about
this
to
the
architecture
discuss
list.
B
So
one
of
the
topics
that
we
covered
in
our
iab
retreat
was
just
looking
at
what
are
the
different
architectural
issues
that
we
see
right
now
and
a
lot
of
the
topics
kept
coming
back
to
this
common
theme,
which
I'm
trying
to
consolidate
here
as
evolvability
deployability
and
maintainability,
and
we're
calling
it
edm
for
short-
and
this
is
definitely
related
to
you-
know-
work-
that's
happened
in
iab
previously,
most
recently,
we
had
the
stack
evolution
group
that
was
looking
kind
of
specifically
at
how
our
protocols
and
the
protocol
stack
that
we're
running
on
hosts
is
evolving
and
making
sure
that
we
can
make
it
extensible.
B
Are
there
practices
that
we
could
have
that
would
better
ensure
that
our
protocols
are
actually
evolvable
and
create
an
architecture
that
scales
up
for
this
and
doesn't
end
up
being
hampered
by
ossification,
because
middle
boxes
are
handling
things
correctly
or
implementations
are
stuck
or
even
just
because
we
don't
have
enough
insight
into
how
things
are
actually
working
as
we're
designing
protocols.
So
next
slide,
so
just
to
talk
about
kind
of
what
are
the
different
topics
that
we
think
are
in
scope
for
this
program?
B
B
B
B
So
that's
one
aspect
of
evolvability
and
as
we
see
that
has
to
do
a
lot
with
you
know
what
are
the
extension
points
to
a
given
protocol.
B
B
There
are
already
iab
rfcs
that
talk
about
how
to
extend
specific
protocols
such
as
rfc
5507,
on
expanding
dns
and
talking
about
all
the
different
options
you
have
there
and
what
is
the
best
way
to
extend
things,
and
I
think
this
is
a
very
interesting
area,
specifically
when
you're
looking
at
protocol
evolution,
because
you
may
have
certain
extension
points
that
are
preferred
to
try
new
things
with
these
are
the
points
that
should
be
greased.
B
B
B
B
B
B
Various
working
groups
are
already
doing
a
lot
of
this,
but
there's
not
a
standard
way,
and
this
is
something
that
may
be
very
beneficial
for
the
community.
So
you
want
to
be
able
to
catalog
what
are
the
different
implementations
we
have
during
development
and
after
what
are
the
versions
that
are
being
supported
as
we
are
revving
our
documents,
when
we've
done
interoperability,
testing
are
the
results
cataloged
anywhere,
do
we
know?
B
Do
the
document
authors
for
a
protocol
know
what
are
these
problems
and
issues
that
various
implementations
are
hitting
and
when
we're
actively
running
an
experiment,
to
try
out
a
new
code
point
on
the
internet
and
see
if
it's
working?
Where
are
we
able
to
share
that
information?
So
next
slide.
B
So,
as
just
some
examples,
various
working
groups
are
already
doing.
This
here
is
on
the
tls
github
page,
a
list
of
various
implementations
for
tls13,
and
so
this
is
an
already
published
protocol.
B
B
And
so
those
previous
ones
were
kind
of
official
working
group
lists
that
we
had
on
the
working
group
github.
We
also
see
sometimes
not
that
happening,
not
in
an
official
working
group
github,
but
just
on
a
given
document.
So
here's
an
example
for
the
service
binding
https
dns
record
recently
on
the
list
they
advertised
that
they
were
on
their
github
page
posting.
A
list
of
implementations
and
people
have
started
to
fill
that
in
next
slide.
B
And
then,
on
the
interoperability
standpoint.
Quick,
of
course,
has
this
great
google
doc
that
tracks
all
the
interoperability
results
for
various
versions
of
the
quick
drafts,
and
this
is
a
really
useful
way
to
see
how
all
the
protocols
are.
All
the
implementations
of
the
protocol
are
working
together,
what
features
they
have,
which
ones
are
actually
being
tested,
and
this
is
great
for
the
implementers,
but
it's
also
really
useful
for
the
people
who
are
writing
the
protocols
and
making
sure
that
we.
B
What
is
being
tested
now?
The
thing
I'd
like
to
point
out
here
is
all
of
these.
So
far
as
examples
have
been
either
github
pages
hosted
by
a
working
group,
github
pages
hosted
for
a
specific
document
or
a
google
doc
hosted
for
a
specific
working
group.
These
aren't
necessarily
easy
to
find
off
of
data
tracker
and
they're,
not
and
more
importantly,
they're
not
easy
to
replicate.
B
So
this
is
something
that
we
can
look
at
next
slide
and
then,
lastly,
we
want
to
talk
about
maintainability
of
saying,
even
after
a
working
group
has
shipped
its
protocol.
How
do
we
make
sure
that
the
extension
points
that
we
have
defined
continue
to
be
used
correctly?
How
do
these
work?
This
is
about
supporting
the
community
of
implementers
for
a
given.
B
Protocol
a
lot
of
this
doesn't
necessarily
need
to
be
done
in
terms
of
rfc
content.
Some
of
it
certainly
can
be,
but
oftentimes,
it's
maybe
more
appropriate
to
have
wikis
or
faqs.
These
are
things
that
could
be
viewed
as
living
documents,
but
they
don't
have
to
be
even
that
formal,
but
having
a
place
where
people
know
to
talk
and
talk
about
a
given
protocol,
given
issues
would
be
useful.
B
Earlier,
I
mentioned
there's
the
effort
to
try
to
do
greasing
for
http,
and
that
requires
some
level
of
coordination
within
the
community
of
implementers
to
know
what
types
of
headers
are
we
going
to
grease
today?
What
are
we
going
to
send
a
different
cadence,
and
this
is
something
that's
not
really
the
best
it's
not
best
suited
for
a
normal
working
group,
that's
about
shipping
documents,
but
it
is
still
a
function
that
the
protocol
experts
and
the
community
that
comes
out
of
the
working
group
can
be
involved
in.
B
So
we
want
to
talk
about
what
happens
for
these
kinds
of
things
that
are
going
to
go
on
beyond
the
length
of
developing
a
protocol.
Next
slide.
B
And
just
as
one
example,
the
tls
working
groups
website,
I
think,
is
a
really
good
example
to
look
at
it
links
to
a
lot
of
different
resources
on
their
github
and
has
beyond
kind
of
the
list
of
implementations
a
lot
of
information
about.
How
do
I
do
testing
for
my
implementation,
other
kind
of
wiki
resources?
B
This
is
something
that
we'd
love
to
see
be
a
lot
more
easy
for
other
other
protocols
and
working
groups
to
be
able
to
host
next
slide.
Please
so
from
a
practical
aspect,
the
different
tasks
that
we
want
to
do
to
start
up.
The
group
we're
getting
representatives
from
within
the
iab,
but
also
we've
talked
to
the
iasg
about
this,
and
we
have
various
iesg
members
who
want
to
be
involved.
B
We
also
want
to
as
a
group
review
what
are
the
successful
models
we
see
in
working
groups
for
making
sure
that
things
are
deployable
and
also
extensible,
and
also
look
at
the
cases
where
we've
seen
struggles
of
defining
a
protocol
and
then,
after
we've
shipped
the
protocol,
realizing
that
it
has
some
of
these
issues
thanks
a
lot.
Please,
specifically
for
the
output
of
the
group.
B
I
Hi
there
this
is
dkg,
I
just
put
in
the
chat
a
pointer
to
openpgp,
test
suite
and
that
test
suite
is
in
part
functioning
as
a
result
of
a
draft
that
I
wrote
that
I've
not
even
bothered
to
try
to
put
into
rfc
status,
because
the
draft
defines
an
api-
and
I
know
you
know
everyone's
hair
stood
up
on
the
back
of
their
neck
when
I
said
that,
but
I
actually
think
that
defining
an
api
trying
to
define
a
minimal
api,
that
exercise
was
super
useful
in
terms
of
thinking
about
what
we
want,
the
high
level
semantics
of
our
protocols
to
be,
and
it
also
gives
implementers
something
that
they
can
work
towards
to
hook
into
test
suites.
I
So
I
know
that
the
ietf
has
traditionally
not
done
that,
but
I
wonder
whether
apis
aren't
something
that
we
should
be
thinking
about.
Maybe
maybe
they're
abstract
apis,
maybe
they're
simple
or
you
know,
implausible
apis
for
actual
use,
but
I
do
find
that
it
makes
giving
a
simple
api
people
can
understand
both
helps
to
clarify
the
goals
of
the
protocol
and
helps
to
make
interoperability
test
routes
work.
A
Hi
tommy
hi
thanks
for
this,
I
think
this
is
sorry
I
am
employed
by
the
internet
society,
but
not
speaking
for
them.
The.
I
think
this
is
great
because
at
the
internet
study
I've
been
involved
several
projects
where
we've
been
trying
to
help
people
deploy
protocols
that
have
been
developed
by
the
itf
and
and
done
that,
and
the
big
challenge
has
often
been
that
the
only
deployment
advice
that
people
are
given
in
is
read
the
rfcs
and
and
those
don't
necessarily
help.
A
A
I
think,
as
I
listen
to
what
you're
saying,
I
think
it's
important
to
differentiate
between
two
parts,
one
is
is
the
great
work
that
you've
highlighted
here
in
helping
people
develop
the
protocols,
while
they're
in
development
and
and
getting
the
implementation
matrixes,
the
the
hackathon
work,
the
various
different
pieces
in
there
that
help
guide
the
authors
in
the
development
of
that,
and
I
think
a
lot
of
that
can
be
found
through
things
like
the
the
working
group,
github
portals
and
the
pieces
like
that.
A
I
think
the
challenge
is
what
happens
once
the
rscs
get
published,
and
and
how
do
we
help?
How
do
we
help
people
once
they're
once
the
products
the
protocols
are
out
there?
How
do
we
help
people
with
that
deployment,
work,
the
implementation
work
and
I
think
one
challenge
there
is
just
how
do
they
find
it,
and
I
think
it's
very
interesting
what
you're
saying
about
linking
into
the?
A
But
I
think
that
discoverability
is
a
huge
issue
because
there's
a
ton
of
information
about
how
to
implement
many
of
the
different
protocols
that
are
out
there,
but
it's
all
in
different
places.
It
has
different.
You
know
works
for
different
operating
systems,
it's
up
to
date
at
different
levels,
so
helping
get
to
a
place
where
we
have
a
defined
set
of
test.
Suites
reference
documentation
error
that
people
can
find,
I
think,
would
be
hugely
helpful
if
we
can
get
to
that
yeah.
C
Yeah,
let's,
I
really
would
like
to
get
some
more
feedback
from
the
community
about
the
session
in
general
or
other
topics
you
want
to
bring
up.
Let
me
say
one
thing
before
I
go
to
chris
wood
who's
on
the
queue
now
you
didn't
put
on
this
slide
that
we
already
have
a
mailing
list
for
this.
So
edm
ib.org
is
the
place
to
provide
more
feedback,
because
I
also
see
a
lot
of
feedback
in
the
jubber.
C
So
I
think
there's
broad
interest
and
the
the
only
remaining
challenge
is
to
figure
out
what
we
don't
want
to
do.
First,
I
think
so
yeah,
but
then
let's
have
chris
quickly.
D
Yeah
thanks,
I
just
want
to
say
I'm
supportive
of
this
program,
as
demonstrated
by
the
screenshots.
It's
easy
for
different
working
groups
to
do
different
things
and
it'd
be
nice
if
there
was
like
a
common
way
to
specify
and
provide
this
information
linked
to
it
from
the
relevant
protocol
document
of
the
working
group.
So
whatever
we
can
do
to
simplify
that
process
for
accurate
home
development
would
be
absolutely
lovely.
D
G
Yeah,
maybe
a
quick
thanks,
a
lot
to
tommy
for
the
for
starting
this
I
mean
this
is
a
really
big,
but
important
can
of
worms,
and
maybe
one
of
the
main
issues
is
is
trying
to
figure
out
what
the
processes
are
to
actually
do
these
things
right
and
maybe
starting
with
experimentation
of
interested
community
members,
but
seeing
how
things
can
be
professionalized,
which
might
then
cost
you
know
more
development
side
on
the
tools
team,
so
that
meta
discussion
might
help
to
actually
get
work
started
yeah
for
the
open
mic
stuff,
and
I
sent
that
as
as
mail
already
out
in
before
the
session
right.
G
So
we
think
there
is
interest
and
need
to
investigate
the
encoding
options
of
future
network
layer
protocols
beyond
ipv6
extension
headers,
for
example,
to
explore
how
to
better
leverage
the
evolving
capabilities
of
programmable
asic
based
wide
area
network
forwarding,
plane
elements,
and
we
brought
this
up
with
the
irtf
chair,
but
he's
already
rejected
these
goals
as
appropriate
questions
for
research
group,
he
thinks
it's
solely
an
engineering
question.
I
do
of
course
disagree,
but
I'd
really
like
to
hear
the
opinion
of
the
iab.
G
What
would
be
the
right
place
to
do
this
type
of
work
in
the
community,
given
how
it's
meant
to
not
immediately
address
possible
standardization,
but
rather
to
examine
feasibility
and
possible
benefits
right
and
a
corollary
of
that
is
really,
you
know.
Could
the
iab,
maybe
please
present
a
short
statement
about
how
maybe
decides
what
workshops
to
run
and
when
to
start
new
programs,
and
then
maybe
you
know
how
the
community
could
have
an
impact
on
that
process.
Thanks.
C
Yeah
and
let
me
quickly
just
say
two
things,
because
I
saw
your
email
we
reply
to
it,
so
we
are
actually
in
the
process
of
of
also
discussing
what
programs
are
and
how
they
should
be.
C
M
Yeah,
so
we,
if
I
remember
correctly,
terlas
and
I
had
a
brief
conversation
in
the
hallway
at
the
singapore
atf
meeting.
Yes,
I
actually
said
was
that
I
didn't
that's
the
discussion
that
you
know,
but,
based
on
what
I
understood
of
what
you
said
at
the
time,
I
didn't
see
any
res
an
appropriate
research
topic.
M
Clearly,
if
you
have
a
more
detailed
proposal
then
or
a
proposal
on
a
different
topic,
then
obviously
we
would
discuss
it,
but
I
think
perhaps
trying
to
claim
the
irtf
has
refused
a
certain
topic
for
all
time,
based
on
a
very
short
hallway.
Conversation
is
perhaps
overstating
the
case.
G
That
that's
fine
thanks
and
but
I
I
think
the
interesting
question
for
me
was
when
we
had
the
discussion
that
I
felt
a
little
bit
like
architectural
questions
in
general
and
specifically
for
these
type
of
you
know.
Maybe
hardware-centric
problems
fall
somewhere
in
the
crack
between
research
question
and
what
I
consider
to
be
engineering
question.
Maybe
there
is
something
to
it,
but
maybe
iab
has
different
opinions
about
that.
So
that's
that's
also
part
of
the
question.
N
I
just
wanted
to
answer
your
question
and
say
that
I
enjoyed
the
session.
I
found
it
useful
and
informative.
I'm.
I
think
it's
a
a
worthwhile
endeavor
on
the
the
edm
topic.
I
think
I
agree
with
with
perlis
it's
especially
for
interactive
test
services.
The
idea
of
trying
to
set
up
and
then
maintain
an
interactive
test.
Endpoint
like
example.com
indefinitely,
is
a
daunting
proposition.
It
would
certainly
help
if,
if
isoc
or
iutf
somehow
had
support
for
that.
K
Thanks
yeah
and
I
I
really
appreciate
the
the
presentation
and
yeah.
I
definitely
think
the
work
is
is
useful
and
be
interested
in
participating
about
the
deployability
and
endpoints
as
well.
Just
a
quick
question
for
the
open
mic
we've
been
discussing
in
the
chat
about
the
consolidation
document
and
yari
provided
some
comments
on
it,
but
I
just
wanted
to
see
what
the
status
was
of
that
in
terms
of
publication
and
and
future
work
thanks.
C
Yeah,
the
iab
didn't
discuss
this
document
specifically
recently,
but
we
are
still
discussing
the
whole
topic
on
on
consolidation
and
what
to
do
in
that
scope.
So
that's
still
on
our
gender.
So
I'm
I
mean
gary's
on
the
ib,
so
he
can
bring
it
back
up
anytime,
okay
and
then
we
go
for
jim.
O
Thanks
very
much
gloria,
I
just
want
to
say
this
has
been
a
very
useful
and
very
very
informative
session
and
hope
we'll
see
more
of
these
at
future
itf
meetings.
I
think
it's
also
very
good
that
we're
raining
able
to
have
more
of
a
direct
dialogue
between
if
you
like,
the
participants
in
the
itf
and
the
ib
directly,
and
I
think
that's
also
a
very
valuable
thing
to
do
so,
we'd
like
to
see
more
of
it.
Thank
you.
C
Okay,
thank
you.
That's
very
useful
if
you
have
any
more
feedback,
just
send
it
to
us
directly
at
ib,
ib.org
or
use
the
architecture
discuss
list
also
for
general
topics
you
want
to
discuss,
so
I
believe
we
do
plan
to
have
this
again
at
some
point
yeah
this
one
was
a
little
bit
short
in
time,
but
this
is
because
of
the
whole
schedule,
as
we
have
it
right
now.
So,
let's
see
where
we
are
next
time
and
how
to
organize
it
and
that's
the
end
of
it.
I
think
tommy
anything
else.