►
From YouTube: IETF 111 Internet Architecture Board (IAB) Open Meeting
Description
The Internet Architecture Board (IAB) held an open meeting on 29 July 2021 at 23:30 UTC. This session will provide an opportunity for more direct interaction and technical discussion between the community and the IAB, and reporting back on work done as well as gathering input about on-going work.
A
Yeah,
I
was
just
gonna
say:
welcome
to
the
iab
open
meeting.
You
know
mira,
miriah
is
also
you
know
miriam,
and
I
are
you
know
here,
to
give
you
the
grand
tour
of
all
the
recent
activities
in
the
iab.
You
know
she's
the
she's,
the
chair
and
the
rest
of
us.
You
know
have
to
do
what
she
says
no
just
kidding,
so
so
what
welcome
to
the
iab
open
meeting
yeah
and
with
that
we
have
the
usual
things
we
have.
You
know.
A
Obviously
this
is
you
know
the
notewell
if
it's
thursday
and
you
haven't
seen
the
note
well
good
job
or
you
know,
you're
you're
enjoying
your
summer
vacation.
Well,
you
know,
but
definitely
you
know
you
know
that.
So
what
is
that?
What
is
ib
open?
The
ib?
You
know
it's
ib
organized
session,
focusing
on
all
the
technical
and
architectural
topics.
It's
really
trying
to
give
everyone
visibility
into
the
iab
work,
collect
feedback
and
such
here's
a
list
of
the
the
mailing
list.
A
A
So
agenda
you
know:
welcome
status,
update,
we're
doing
that.
We'll
have
updates
on
liaison
management.
You
know
wes
will
present
for
that.
You
know
the
edm
program.
Tommy's
gonna
spend
some
time
talking
on
that
some
considerations
on
applications
and
then
some
open
mic
time
after
he
already
talks
about
his
little
piece.
B
A
B
Sure
so,
good
news
is:
we
published
the
report
from
the
last
workshop
that
we
held
in
november,
which
was
the
covert
19
impact.
So
that's
that's
out
there.
It
has
an
rc
number
and
you're
happy
we're
happy
if
you
read
it
and
and
also
provide
still
feedback,
even
so
it's
published,
and
then
we
have
one
document
that
is
approved
for
publication,
but
you
might
still
want
to
have
a
look
at
it
and
then
I
really
wanted
to
draw
your
attention
at.
B
There
are
a
few
more
documents
that
are
somehow
on
the
horizon
for
the
ib,
but
the
one
which
is
called
draft,
ib,
lucid
or
use
it
or
lose
it
it's
the
one
that
is
like,
probably
the
next
one.
We
will
look
at
in
evolution,
that's
currently
in
discussion
in
the
eda
program,
and
if
you
want
to
review
it,
if
you
want
to
comment
on
it,
then
it's
the
right
point
of
time
to
do
it
now,
but
I'm
pretty
sure
tommy
will
talk
more
about
it
later
and
now
jerry
disappeared.
There
he's
back.
B
And
then
I
or
we
wanted
to
also
point
your
attention
at
something
new
that
we're
doing
on
the
ib,
which
is
we
now
have
one
of
our
calls
once
per
month.
Our
calls
focus
entirely
on
technical
discussions.
Only
so
usually
those
calls
will
have
only
one
topic
scheduled
and
we
have
like
a
full
hour
to
discuss
it,
and
you
can
see
here
some
of
the
topics
that
we
discussed
over
the
last
couple
of
months.
B
So
this
is
a
mixture
of
things
that
is
brought
up
by
the
iab
members
by
the
community
and
also
since
we
have
these
kind
of
invited
talks
where
we
have
excellent
experts
into
a
topic
that
we
find
interesting
or
recently.
We
also
had
some
people
from
isab
providing
us
some
of
the
more
legal
and
political
background
for
a
topic
that
we
discussed
on
the
ib
and
the
reason
why
I'm
mentioning
this
here
is
because
all
the
ib
calls
are
open
for
observers,
so
you
could
even
join.
B
You
could
join
all
of
the
ap
course,
but
you
can
also
just
and
look
for
the
interesting
ones
which
might
be
one
of
these
technical
discussions
and
the
agenda
is
usually
published
on
our
ib
web.
There's
also
calendar
you
can
subscribe
to,
so
you
have
it
in
your
calendar
and
you
can
see
what's
going
on
and
of
course,
if
you
miss
a
meeting,
you
can
also
check
the.
B
A
Yeah
yeah,
actually
this
one
I'm
very
excited
about
this
one.
It's
the
the
workshop
ib
workshop
we've
put
together
or
you
know,
a
number
of
people
are
working
on
it.
I'm
very
excited
for
this
on
measuring
the
network
quality
for
end
users.
Really,
you
know
you
know
you,
you
can
read
what
the
questions
are:
we're
really
soliciting
people.
You
know
submissions
are
due.
You
know
on
monday,
you
know
so,
just
in
just
in
a
few
more
days.
A
You
know
for
that,
and
we
want
to
understand
things.
So
if
you
could
please
you
know,
if
you
have
any
data
or
anything
interesting,
you
want
to
share
any
interesting
observations.
You
know
love
to
that.
You
know.
I
know
I
personally
would
love
to
hear
about
this.
You
know
somebody
who
works
with
cdn
but
also
runs
my
own
end
user
network.
A
A
C
Okay,
I
think
we
may
have
been
gonna
we're
supposed
to
do
the
liaison
one
first,
but
it
doesn't
matter
because
I'll
do
both
of
them.
So
we
can
talk
about
the
edm
program.
First,
all
right,
so
I'll.
Just
give
a
brief
update
on
this
technical
program
that
we
have
on
evolvability,
deployability
and
maintainability.
C
C
So
just
for
administrative
stuff,
we've
had,
I
think,
three
or
four
calls
at
this
point.
We
have
our
next
one
coming
up
next
week
on
wednesday
august
4th.
So
if
you,
you
know,
if
you've
had
your
full
ietf
week
and
you
just
want
more
and
you
miss,
everyone
already
feel
free
to
join
us,
and
I
think
you
know
we'll
actually
be
having
another
call,
probably
in
september
october,
before
the
next
daytf
as
well,
since
some
people
won't
be
able
to
make
it
to
this
one.
C
C
Charles
eckel
proposed
some
work
on
how
to
find
code,
implementations
and
that's
one
topic
that
will
probably
also
bleed
over
into
the
next
call,
and
then
we'll
also
want
to
talk
more
about
coordination
mechanisms
between
implementations,
which
is
one
of
the
topics
that
kind
of
comes
out
of
user
to
set
all
right.
Next
slide
now,
all
right
so
just
to
give
I
wanted
to
give
a
brief
kind
of
overview
of
this
document
since
we're
trying
to
get
it
to
progress.
C
So
if
you
are
interested
in
reading
it,
you
can
kind
of
get
an
idea
of
what
is
in
the
document.
Currently
we
are
on
the
one
version
of
the
iab
document.
It
had
a
lot
of
earlier
individual
draft
document
versions
and
we'd
like
to
get
this
ready
to
publish
soon
before
the
next
itf,
and
so
essentially
we
are
soliciting
reviews
and
thoughts.
We've
already
asked
the
edm
list
for
this
sometime
after
the
call,
once
we've
merged
in
everything,
and
had
a
good
discussion,
we'll
ask
for
wider
community
review
next
slide.
D
I
think
probably
the
only
other
thing
to
add
here
is
that
a
lot
of
this
depends
on
the
fact
that
the
participants
in
the
protocol
deliberately
decide
to
block
extensibility,
but
they
just
do
it
by
accident
by
virtue
of
bugs
or
not
thinking
about
it.
Or
what
have
you
there's
a
recent
changes
in
the
draft
to
sort
of
try
to
capture
that
one?
C
C
It
looks
at
some
of
the
protocols
that
have
good
extensibility
properties
and
notes
that
those
are
protocols
that
often
use
these
extension
points
a
lot
and
that's
in
two
ways
right:
it's
both
in
defining
new
extensions
or
new
values
for
these
extension
points,
as
well
as
actually
using
them
in
practice
and
kind
of
beyond.
Just
really
using
these
extension
mechanisms.
C
A
lot
you
it's
really
best
when
the
functionality
of
the
protocol
altogether
has
a
strong
dependency
on
the
extension
point
such
that,
if
something
happens
to
it
or
you
have
a
bug
in
that
extension
point
everything
falls
over
and
you
notice
it
very
quickly,
and
it's
also
noted
that
there
are
some
examples
of
protocols
that
had
kind
of
lost
their
ability
to
use
their
extensions,
and
then
they
regained
them
by
active
use.
So
that
leads
on
to
the
next
slide.
C
Essentially,
the
document
ends
with
some
of
observations
or
recommendations,
primarily
that
active
use
is
the
biggest
thing
to
guarantee
extensibility
highlights
that
version.
Negotiation
is
an
interesting
special
case
and
that
techniques
like
grease
or
greasing
a
protocol
is
a
way
to
get
some
of
the
benefits,
but
not
all
of
them
by
falsifying
active
use.
So
if
you're
not
actively
deploying
new
features,
you
can
at
least
get
some
of
the
benefits,
and
then
there
are
a
number
of
things
that
relate
to
improving.
C
E
A
quick
comment:
this
is
coming
out
of
yang
work,
specifically
the
bhp
ang
work.
One
of
the
interesting
headaches
that
you
sort
of
see
is
that
extensibility
is
hard
to
prove
until
you've
actually
tried
to
do
the
first
version
of
that
extension.
So
as
an
example,
an
awful
lot
of
our
stuff
is
basically
just
barely
v1.0
for
a
lot
of
the
documents.
E
We've
had
to
do
a
lot
of
what
I
like
to
call
inner
work
to
make
sure
that,
can
you
actually
do
the
next
thing
for
this
extension,
based
on
what
bgp
would
need
to
do
for
the
yang
model,
its
extensions,
so
one
thing
I'd,
encourage
for
the
document
that
you're
working
on
is
try
to
find
a
way
to.
You
know,
prove
out
the
you
know,
n
plus
one
case.
G
Thank
you,
yeah.
We
have
a
lot
quite
a
lot
of
experience
with
in
ipv6,
with
extension,
headers
hot
by
hop
headers
destination
headers
and
it's
not
been
a
wild
success.
I
guess
I
could
say
particularly.
I
think
the
particular
problem
is.
You
know
in
hope
I
operators
in
transit,
routers
and
but
I
think
the
worst
problem
is
middle
boxes
that
filter
or
decide.
G
G
F
F
One
of
the
examples
you
give
is
ipv4
and
class
e,
addressing
as
being
a
wasted
space.
Two
two
comments
I
want
to
make
the
first
is:
there
is
still
an
open
question
as
to
whether
that's
really
true
as
the
person
who
author
who
co-authored
the
reuse
of
240.
I
know
we
dropped
that,
but
I
know
that
there
are
people
who
really
think
it's
okay
to
use
that
address
space
and
have
tested
against
it
for
now
and
just
repurposing
it
for
for
unicast.
F
I
The
the
other
part,
then,
is
really
just
the
two-party
versus
end
party
thing,
and
I
think
what
I
heard
in
before
you
know.
Just
you
know
the
typical
tcp,
where
just
two
parties
are
talking
with
each
other's
versus
when
you
actually
want
to
explicitly
have
you
know
desirable
middle
boxes
like
the
proxies,
as
you
said,
right
and
ip
obviously
is
the
desirable
middle
boxes,
because
you
have
n
forward
is
on
the
path
and
I
think
yeah.
I
Definitely
what
I
heard
in
before
here
in
in
the
comment,
maybe
putting
the
undesirable
middle
boxes
out
of
scope,
because
right
now
it's
a
little
bit
leaking
out
into
that,
because
that's
a
huge
other
area
of
itself.
Maybe
at
that
point
in
time,
when
we
take
those
out
of
scope,
then
we
can
still
figure
out
how
to
discuss
the
well.
It's
a
simple
peer-to-peer
communication
or
it's
a
multi-party
communication
and
that
might
be
able
to
capture
both
of
the
application
and
and
the
network
layer
we'll
see.
Thank
you.
C
D
D
Comment
there
about
the
upper
layers
thing.
The
introduction
of
the
draft
actually
deliberately
addresses
the
point
and
and
says-
and
I
quote,
the
experience
that
informs
this
document
is
predominantly
at
higher
layers
of
the
network
stack.
And
so
I
think
we've
been
very
clear
about
our
biases
here
in
terms
of
of
what
what
the
learnings
are.
We
do
have
some
examples
at
lower
layers
of
the
stack
they're,
not
necessarily
very
good
and
to
bob's
earlier
point.
D
The
the
ip
extension
header
thing
is
an
ongoing
discussion
and
I
don't
think
we
can
draw
any
real
conclusions
from
at
this
point
and
sort
of
mention
the
existence
of
the
problem,
but
haven't
really
tried
to
to
point
at
any
one
solution
for
that
sort
of
thing.
So
I
think
we
are
getting
there,
but
I'm
not
really
enthusiastic
about
trying
to
formalize
the
difference.
D
G
G
You
know
you
do
some
queries
and
you
see
it
supports
the
new
one
and
you
can
use
it
it's
much
much
harder
when
you're
having
to
change
everything
along
the
path
needs
to
do
it,
and
so
I
think
that's
maybe
a
good
character
way.
It's
not
so
much
layering.
I
think
it's
just
how
many
things
have
to
change
in
order
to
get
any
advantage
of
it.
You
know,
personally,
I've
worked
on
two
protocols
that
I've
been
very
happy
with
verb
and
ipv6
with
verb.
G
C
G
C
C
C
C
So
we
haven't
kind
of
formally
compiled
all
of
the
information.
I
think
this
is
going
to
be
a
discussion
that
the
ib
will
have
ongoing
for
some
time
after
this,
but
some
initial
observations
we
can
make
at
this
point.
There
are
a
lot
of
the
layers
and
roles
that
we
found
that
are
essentially
no
ops.
Maybe
they
are
a
role
that
is
required
to
be
filled
because
there's
some
charter
reason
in
a
given
organization.
That
needs
a
certain
role
to
have
someone
sitting
in
it.
C
But
then
there
are
other
roles,
particularly
the
appointed
positions
that
are
not
traditional
liaisons,
but
something
that
is
still
appointed
in
that
general
bucket
of
people
spending
quite
a
lot
of
their
time
on
these
roles.
So
there's
a
huge
range
of
involvement
and
requirements
for
these,
and
a
lot
of
them
also
have
different
cadences,
depending
on
whatever
organization
that
their
liaison
liaising
with.
Sometimes
it's
a
once
a
year
thing
twice
a
year
thing,
etc
and
there's
also
a
pretty
big
variety
in
what
what
type
of
backgrounds
that
you
need
to
fill
the
role.
C
C
C
C
D
G
H
H
Also,
you
might
be
basing
behavior
in
the
network
on
information
that
could
be
incomplete
or
wrong,
primarily
because
it
wasn't
really
designed
to
be
read
in
the
network
and
also
you.
Basically,
if
you
have
this
kind
of
setup,
then
you
create
an
expectation
that
network
elements
can
see
rich
data
about
flows
passing
through
them,
and
that's
that's
not
the
reality
that
we're
living
now
or
we'll
be
living
in.
So
not
the
right
right
signal,
descent
or
expectation
to
have
next
slide
please.
H
H
H
H
H
H
So
that
you
you,
you
only
target
the
particular
entity
that
you
want
to
perform
a
task,
and
I
know
I
may
be
stretching
a
little
bit.
The
definition
of
path
signals
in
this
particular
case
should
dns
queries
be
included
in
that,
maybe
maybe
not
moving
on
so
minimum
information
don't
provide
information
that
is
sort
of
extra
just
the
information
that
is
needed
for
the
tasks,
so
some
bad
examples
that
you
could
try
and
do
like
if
you
try
to
communicate
user's
identity
or
real-world
identity
or
applications
exact
identity.
H
Of
course,
you
should
have
content
of
parties
so
essentially
both
center.
That
is
willing
to
send
some
information
and
obviously,
in
this
new
explicit,
encrypted
design
model,
only
those
who
actually
want
to
send
something
will
be
doing
that
so
that's
kind
of
easily
handled,
but
also
the
recipe
and
then
ultimately,
the
user
needs
to
be
willing
to
do
things.
H
So
some
bad
examples:
let's
take
an
example
of
sort
of
the
recipient
side.
So
as
an
example,
we
had
lots
of
discussions
in
the
itf
about
there
is
broker's
ability
to
process
hooked
by
hope,
headers
or
willingness
to
process.
So
that's
an
example
of
a
thing
where
somebody
you
know
from
the
end
points
wants
to
send
some
information,
but
the
receivers
don't
actually
want
to
process
it,
because
it
will
significantly
impact
the
ability
of
those
devices
to
function
efficiently
for
the
fast
path
case.
H
H
You
know
whether
the
information
needs
to
be
protected
and
somehow
do
the
parties
need
to
be
authenticated
and
there
might
be
different
cases
here
for
for
different
situations,
so
you
might
have
like
a
simple
case.
You
share
some
simple
data,
for
instance
the
ecm
bits,
and
you
know,
maybe
you
don't
need
to
encrypt
that
in
any
fashion.
You
may
actually
want
to
be
able
to
show
that
information
and
be
able
to
modify
that
information
sort
of
in
multiple
different
entities
and
the
impacts
of
changing
that.
H
H
So
those
on
the
previous
slide,
they
were
guiding
principles
that
we
can.
We
can
sort
of
clearly
enumerate
on
this
slide.
We
have
a
few
topics
where
we
believe
that
some
some
further
work
is
needed,
and
this
is
much
less
clear
situation
or
you
know
some
aspects
of
the
previous
slide.
Also
here,
like
security
and
one
common
topic
here
is
the
business
arrangements
and
sometimes
you've
had
lots
of
complicated
designs.
Let's
do
some
qs
design,
for
instance,
and
there's
a
technology
side
of
that,
but
there's
also
a
business
side.
H
So
if
you
start
to
assume
things
like
well,
you
know
we
need
to
be
able
to
pay
for
a
service
and
we
get
paid
for
for
doing
something.
So
in
those
situations
the
technology
itself
is
not
enough.
We
actually
have
to
have
a
business
model
to
back
that
up
and
and
that
that's
really
important.
So
if
you
know
whatever
you're
trying
to
do
requires
that,
then
you
do
need
to
think
about
it.
H
Secure
communications
with
path
elements.
We
talked
about
this
a
little
bit
on
the
previous
slide,
but
that
is
of
course,
in
the
channel
case
really
hard.
So
you
might
have
like
multiple
parties
and
so
on
so
so
there
are
some
challenges
in
the
in
this.
Of
course,
you
could
have
potentially
various
kinds
of
new
ideas
about
how
to
do
new
things
with
pad
signals
and
one
one
idea
that
we
did
talked
about
a
little
bit.
H
Ted
had
had
been
working
on
something
in
this
space,
and
maybe
he
wants
to
talk
about
it
later
on
the
comments
a
little
bit,
but
you
could
perhaps
do
some
throttling
of
of
laws
related
to
general
service
attacks.
For
instance,
if
we
had
the
necessary
passing
laws
for
that
hand
waving
a
little
bit
here
could
do
more
protection
of
information
held
by
various
network
elements
or
even
by
the
servers
essentially
going
beyond
communication
security.
One
example
here
is
the
various
oblivious
dns
designs.
H
Confidential
computing
is
another
other
example
could
be
applied
potentially,
and
also
we
in
many
cases
talk
about
these
bad
signals
in
terms
of
well.
Can
the
application
tell
the
network
something
or
shoot
the
application
till
the
network,
something,
but
this
also
the
other
direction.
So
it
could
be
that
the
network
wants
to
or
can
tell
something
to,
the
application.
That
would
be
useful
in
terms
of
like
the
transport
parameters
or
congestion
control,
or
you
know,
future
expectations
of
bandwidth
and
so
forth.
J
Yeah
thanks
thanks
yuri.
That
was
a
really
helpful
presentation
which
clarified
a
lot
of
things
for
me
from
the
draft
and
made
me
think
a
lot
in
your
your
slide.
Four,
there
were,
I
guess,
two
things
that
that
struck
me.
One
was
that
that
the
middle
box,
not
the
middle
block,
the
the
info
that
that
is
needed
for
the
task
and
that's
a
that's,
a
really
dangerous
open
door.
J
So
I
think
you
have
to
be
be
careful
with
that,
because
one
person's
need
is
another
person's
bad
idea.
Yep.
Absolutely
that's,
certainly
one
to
the
consent
of
parties
thing,
and
we
sort
of
see
that,
with
that
with
the
geo
location
stuff,
that
the
application
decides
is
not
the
same
as
the
user
consents
and
the
user
consenting
is
not
necessarily
the
same
as
a
user
understanding.
H
Yeah,
that's
been
actually
one
of
the
inspirations
for
some
of
this
work.
What
can
we
do
and
what?
What
can
we
not
do?
And
I
fully
agree
with
your
your
points
and
in
particular
the
one
about
things
needed
for
tasks,
and
the
comment
that
I
would
make
here
is
just
because
I'm
a
network
element-
and
I
I
think
I
want
to
do
a
task-
doesn't
mean
that
other
parties
should
actually
agree
to
that.
So
so
even
the
existence
of
a
particular
task
needs
to
be
a
thing
that
that
you
concentrate
on.
I
And
you
know
there,
there
are
a
lot
of
fewer
problems
that
you
get
when
you
start
from
from
the
simple
side,
and
you
know
if
we
would
put,
for
example,
these
all
these
type
of
requirements
here
that
rightfully
apply
to
the
internet
upfront
against
the
design
of.
Let's
say
your
packet
processing
of
mpls,
or
so
we
would
have
never
deployed
it,
and
yet
we
do
know
that
it
is
important
and
and
works
perfectly
fine
in
private
networks.
We've
done
a
lot
more
security
work.
I
Even
for
these
you
know
limited
domain
networks
in
the
recent
past,
so,
for
example,
the
nmr
work
simply
automates,
what's
been
very
much
standard
in
many
of
the
you
know,
secure
networks
I
know
which
is
just
hop
by
hop
link,
encryption,
secure
notes,
and
so
you
don't
have
to
put
all
this
security
into
the
end
to
end
signaling
right.
So
there
are
a
lot
of
different
options
here
and
would
be
great
not
to
only
focus
on
the
ones
for
the
internet,
because
in
my
opinion,
you
know
my
accounting.
H
E
E
Part
of
the
problem
for
some
of
these
signals
is
that
it's
a
matter
of
scoping
for
some
of
them.
A
lot
of
our
protocols
are
effectively
designed
to
know
to
go
end-to-end
and
whether
you
choose
to
disclose
information
that
can
be
used
for
paths.
Signals
may
vary
depending
on
where
you
are
at
a
given
network
now.
Clearly
we
we
do
a
lot
of
tunnels
for
various
things,
and
that
may
be
the
answer
in
question,
but
maybe
that
should
actually
be
called
out
as
the
explicit
point
yeah,
that's
a
good.
K
K
K
The
other
sending
side
is
going
to
know
that
that's
happening
at
at
some
interval.
Right
there'll
be
a
withdrawal
of
consent
in
in
rtc
web.
You
know,
through
through
the
sun
ice
mechanisms
that
were
designed
for
that
as
an
example,
and
the
sender
will
stop
upon
receiving
receiving
that
from
the
other
side
of
the
flow.
The
question
is:
if
the,
if
you
have
a
bad
center,
one
who
is
engaged
in
attack,
is
there
any
advisory
mechanism?
K
You
could
send
to
the
path
that
would
say
by
the
way
this
is
being
dropped.
So,
if
you
don't
want
to
send
it
to
me,
so
you
don't
use
you
know
your
your
high
bdp
satellite
link
or
you
don't
want
to
use
your
expensive
peering,
a
non-peering
transit
link
or
whatever
you
now
know.
It's
not
getting
to
the
end
point
and
you
can
decide
whether
you
want
to
send
it
further
or
try
another
path
or
do
something
else.
K
What
signal
you
can
send
in
such
a
situation
that
isn't
subject
to
an
injection
attack,
and
you
know
we
we
played
with
a
whole
bunch
of
different
mechanisms
that
would
allow
the
end
system
to
know
that
it
wasn't
inject
an
injection
attack
and
we
kind
of
believe
that
that's
a
solvable
problem
but
letting
the
path
know
that
it's
not
an
injection
attack
from
some
other
part
of
the
path
is
very
difficult
indeed,
and
so
I
I
think
it's
an
it's.
It's
only
an
area
for
research
for
darn,
good
reason.
K
There
is
no
engineering
work
to
do
right
here,
but
there
is
research
to
do
to
figure
out
if
there
is
some
mechanism
that
would
let
those
advisory
messages
demonstrate
that
they
are
able
to
take
the
action
that
they're
claiming
to
take,
and
so
there's
there's
some
interesting
research
here
to
do.
But
it
is
definitely
not
done
and
that's
the
reason
you
don't
see
a
proposal
from
us
in
the
form
of
an
internet
draft
but
noodling
on
the
side
of
of
napkins,
in
the
way
that
these
things
go
thanks.
A
L
L
So
in
that
year
the
ib
hasn't
convened
another
meeting,
but
still
the
participants
in
it
have
revised
older
drafts.
They've
created
new
drafts
and
members
out
of
the
community.
Have
I
have
volunteered
to
help
with
the
organization,
so
I
I
I
think,
what's
missing
what
I'd
like
to
see
is
rather
than
an
iab
review
of
the
program,
to
put
some
energy
back
into
having
model
t
meet.
I
think
that
would
be
a
really
valuable
thing.
B
Yes,
so
that's
definitely
true.
The
the
leads
of
the
program
haven't
set
up
a
meeting
and
the
iab
wasn't
as
much
involved
and
this
recently,
but
this
is
really
also
part
of
the
review
that
we
want
to
take
to
see
what
the
view
of
the
iab
on
this
program
is:
how
much
interest
is
there
in
the
iab?
And
how
do
we
proceed
with
this
topic?
B
Because
an
ib
program
really
needs
iab
backing?
It's
it's
not
if
it's
not
a
pure
community
group,
we
always
have
to
have
some
broader
interests
in
the
iab
and
in
order
to
keep
it
driving
to
make
sure
we
have
everything
organized
and
designed.
So
this
is
really
the
purpose
of
the
ib
program
review
and
after
the
review,
we
will
come
back
and
figure
out
what
to
do
next
and
yeah
aria.
Is
there
I'm
pretty
sure
you
want
to
say
more
about
it.
K
H
Yes,
I
just
wanted
to
agree
with
the
characterization
that
this
is
sort
of,
I
wouldn't
say
an
iab
problem,
but
it's
a
leadership
problem
for
the
model,
t
group
and
I'm
part
of
the
leadership.
So
I'm
at
fault
here
that
that's
clearly
been
a
problem.
I
I
you
know:
we've
seen
that
there's
lots
of
energy,
or
at
least
some
energy
on
producing
documents,
so
let's
fix
the
leadership
and
and
and
do
something.
Thank
you.
M
Next
is
watson,
hello.
I
was
just
going
to
say
that
when
it
comes
to
multi,
I
think
there's
there
remained
a
very
big
gap
amongst
participants
and
discussions,
sort
of
dwindled,
and
it's
not
clear.
There
was
any
progress
towards
closing
that
gap,
and
I
think
that
before
we
say,
oh
another
meeting
we'll
solve
it,
another
round
of
drafts
will
solve
it.
Discussion
on
the
list
has
really
dwindled
in
part.
I
H
Yeah,
I
also
want
to
agree
with
with
this
statement.
I
think
there
is
has
been
a
gap
of
like
what
exactly
are
we
doing.
I
think
some
of
that
was
how
you
characterize
things
that
you
know.
There's
there's
no
progress
towards
solution.
I
think
this
difference
of
opinion
of
exactly
what
should
be
produced.
I
think
there's
you
know
many
possible
alternatives,
I'm
kind
of
like
you
know
in
favor
of
short
to
the
point
high
level
rfcs
from
iab.
H
I
think
this
might
be
case
for
that.
I
don't
think
everybody
else
is
on
the
same
same
plan,
there's
been
a
lot
of
interest
in
in
looking
at
a
lot
of
the
detailed
technology,
technical
solutions
that
we
could
do,
and
but
it's
also
a
problem
at
that
problematic
area,
because
it's
it
you
know
it's
so
many
dependencies
and-
and
it's
not
as
easy
thing
to
tackle
going
beyond
communication
security.
B
So
I
just
wanted
before
we
have
a
very
lengthy
discussion
here.
We
didn't
have
an
extensive
report
on
this
program
because
we
really
have
this
review
coming
up.
So
these
are
all
questions
that
we
need
to
discuss
in
the
ib,
where
we
are
with
the
program
where
we
want
to
go
and
what
the
right
direction
is,
and
then
we
can
report
back
and
and
tell
you
know
what
I
want
to
do
next.
There.
A
All
right,
good
night,
everyone
and
cindy
thank
you
for
taking
minutes
and
the
medo
meet
echo
team.
Thank
you.
I
know
it's
late
for
everyone
in
europe.
I
believe
they're,
all
all
based
many
or
all
of
them
are
based
in
italy.
So
thank
you
for
thank
you
for
supporting
us
this
week.
It's
been
awesome
thanks,
smooth
for.