►
From YouTube: IETF111-IABOPEN-20210729-2330
Description
IABOPEN meeting session at IETF111
2021/07/29 2330
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
You
know
she's
the
she's,
the
chair
and
the
rest
of
us.
You
know
I
have
to
do
what
she
says
no
just
kidding,
so
so
what?
What
welcome
to
the
iab
open
meeting
yeah
and
with
that
we
have
the
usual
thanks.
We
have
you
know.
Obviously
this
is
you
know
the
notewell.
If
it's
thursday
and
you
haven't
seen
the
notewell
good
job
or
you
know
I
you're
you're
enjoying
your
summer
vacation.
A
Well,
you
know,
but
definitely
you
know
you
know
that.
So
what
is
I?
What
is
iab
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.
You
know
where
you
could
go
and
reach
out
to
the
iab,
and
you
know
we
have.
We
have
a
number
of
different
programs
and
liaison
activities
that
we're
responsible
for
coordinating.
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
corporate
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
iap,
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
jared
disappear.
That
he's
big.
B
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
You
could
join
all
of
the
av
course,
but
you
can
also
just
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.
A
Yeah,
actually
this
one,
I'm
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
on.
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
have
you
know.
I
know
I
personally
would
love
to
hear
about
this.
You
know
as
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
itf
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
atf
as
well,
since
some
people
won't
be
able
to
make
it
to
this
one.
C
C
Charles
eccle
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,
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
01
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.
C
A
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
tried
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
that
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
observations
and
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
greece
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
How
active
use
can
maintain
extensibility
such
as
using
cryptography
and
encryption
having
a
relatively
limited
set
of
extension
points
so
that
they
get
used
a
lot
defining
invariants
and
monitoring
brokenness
with
feedback,
and
I
think
that's
it
for
these
slides,
you
check
one
more
where's,
this
hit
yeah,
that's
the
last
slide
cool
yeah.
So
that's
a
summary
of
the
things
we
are
talking
about
in
this
document
and
talking
about
in
the
program.
C
E
Oh
a
quick
comment:
this
is
coming
out
of
yang
work,
specifically
the
bhp
anger.
One
of
the
interesting
headaches
that
we
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
1.0
for
a
lot
of
the
documents.
E
E
F
G
Thank
you.
Yeah.
We've
have
lot
quite
a
lot
of
experience
with
in
ipv6,
with
extension,
headers
hop
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
hop
I
operators
in
transit,
routers
and
but
I
think
the
worst
problem
is
middle
boxes
that
filter
or
decide.
They
really
want
to
look
at
the
whole
packet
and
we
are
trying
to
fix
some
of
that.
G
A
C
G
F
F
Afternoon
tommy,
I
did
have
a
look
at
this
draft
when
it
initially
came
out,
and
I
just
reviewed
it
again.
One
of
the
examples
you
give
is
ipv4
and
class
e,
addressing
as
being
a
wasted
space.
Two
two
comments
I
wanna
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.
F
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.
The
second
point
I
want
to
make
about
that
example
is:
if
we
didn't
have
the
reserve
space,
I'm
not
sure
we
would
have
known
what
to
do
about
multicast,
quite
frankly,
which
wasn't
invented
at
the
time
of
rfc
791.
I
So
I
I
think,
I'm
not
sure
you
know
the
the
layer
difference
between
layer,
3
and
you
know
for
work
and
and
you're
lovely
much
easier,
much
more
agile,
I'm
just
jealous
right,
so
land
of
the
applications
is
probably
really
that
the
unit
of
time,
which
is
in
the
scope
of
use,
it
may
just
be
orders
of
magnitudes
larger
right.
So
I
mean
if
in
our
case
we
start
using
extension
points
every
five
years,
we're
happy
that
was
fast
and
in
your
case,
an
application
that
might
be
an
eternity
right.
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.
C
D
D
D
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
are
not
necessarily
very
good
and
to
bob's
earlier
point.
The
the
ip
extension
header
thing
is
an
ongoing
discussion
that
I
don't
think
we
can
draw
any
real
conclusions
from
at
this
point
and
sort
of
mentioned
the
existence
of
the
problem,
but
haven't
really
tried
to
to
point
at
any
one
solution
for
that
sort
of
thing.
D
One
of
the
things
that
came
up
in
earlier
discussions
about
this-
and
I
think
told
us,
mentioned
this
as
well-
was
that
the
cadence
at
which
updates
occur
may
determine
that
the
shape
of
the
response
that
you
have,
but
that
doesn't
necessarily
mean
that
the
fundamentals
are
necessarily
different.
All
right,
so
you
update
on
a
five-year
cycle.
Fine,
then
you
update
on
a
five-year
cycle,
and
some
of
the
some
of
the
things
that
you
might
need
to
do
on
the
interim
might
be
a
little
different.
But
that's
the
fundamentals
are
about
the
same.
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
the
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
C
F
C
Of
the
different
things
that
we
talked
to,
the
liaison
managers
about
they're
generally
pretty
open-ended
conversations.
But
we
wanted
to
understand
how
much
time
people
were
spending,
how
much
prior
knowledge
they
needed
to
fill
their
role
and
specifically,
what
type
of
communication
was
going
on
from
their
organization
and
from
their
liaison
ship
to
the
iab
and
what
the
ib
was
giving
its
input
back
to
them.
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
Some
of
them
are
quite
technical,
but
others
are
really
about
understanding.
The
organization
and
essentially
the
social
structure
there
and
how
to
work
within
it.
So
these
are
the
type
of
things
that
we
want
to
make
sure
documented.
Well,
so
that,
as
we
need
to
fill
liaison
rules
going
forward,
we
know
who
are
the
right
people
to
fill
those
roles.
C
Yeah,
so
the
next
steps
here,
the
kind
of
the
main
concrete
thing
is
that
we
want
to
start
establishing
more
official
communication
frequency
from
liaisons
to
the
iab.
Just
doesn't
necessarily
need
to
be
a
lot
of
things
being
said,
but
just
a
status
update
on
a
regular
cadence.
So
we
know
what
is
active
and
what
isn't
so?
C
This
is
something
that
hasn't
happened
for
quite
a
while
and
then
overall,
just
our
goals
as
we're
thinking
about
this
are
to
improve
the
communication
that
we
have
to
the
liaison
managers,
improve
the
amount
of
attention
and
focus
that
we're
giving
to
liaison
activities
to
make
sure
that
if
there
are
things
that
we
should
be
doing
more
proactively,
we
can
understand
what
those
are
support.
The
liaison
managers
more
in
general
and
also
to
have
a
clearer
point
of
contact
when
people
in
the
community
have
questions
about
what
they
should
do
for
a
given
liaison.
J
Like
yeah,
so
this
is
a
topic
that
some
of
us
current
and
ex
ia
beers
have
been
talking
about
application,
network
collaboration
and
path
signals
and
how
to
do
them
properly,
and
the
name
of
the
draft
actually
is
mistakenly
set
here
as
draft
arco
passing
or
something.
But
it's
so
it
should
have
iab
there
somewhere
after
iab
path
and
so
forth.
J
J
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
center
expectations
to
have
next
slide,
please
so
that
was
the
past.
Of
course.
J
Now
we
have
some
good
news
with
increased
use
of
encryption.
A
lot
of
this
has
changed
for
the
better.
We
won't
be
doing
some
of
that.
Some
of
those
things
anymore,
of
course,
at
the
same
time,
kind
of
radically
cut
down
on
this
kind
of
interaction,
and
perhaps
there
are
some
some
need
for
for
some
of
those
interactions
to
actually
happen,
so
maybe
we're
in
a
situation
where
we're
sort
of
cutting
away
almost
all
of
this
signaling
and
and
now
we
have
to
build
some
of
it
back.
J
The
the
parts
that
actually
make
sense
and
have
positive
incentives
for
all
the
parties
to
actually
engage
in
and
also
the
other
part
of
the
good
news,
is
that,
given
this
encrypted
situation,
it's
it's
now
also
an
opportunity
for
us
to
redesign
whatever
things
that
we
actually
need.
We
can
redesign
them
to
do
do
things
properly
or
be
explicit,
for
instance,
and
be
insecure.
J
J
J
J
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
so
some
bad
examples.
Let's
take
an
example
of
sort
of
the
recipient
side.
J
So
as
an
example,
we
had
lots
of
discussions
in
the
itf
about
there
is
broker's
ability
to
process
hooked
by
hop
headers
or
willingness
to
process.
So
that's
an
example
of
a
thing
where
somebody
you
know
from
the
endpoints
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.
J
J
You
know
whether
the
information
is
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.
J
J
One
note
about
authentication,
so
you
might
have
authentication
of
parties
whether
it's
these
specific
nodes
or
otherwise
bigger
groups
of
nodes,
and
even
if
you
do
authentication
it
doesn't
imply
that
you
actually
have
full
trust
into
the
entities.
As
an
example,
you
might
authenticate
the
party
to
do
some
some
service,
where
you
provide
some
confidential
information,
but
the
party
might
still
leak
that
confidential
information
for
commercial
purposes
or
by
accident,
or
something
next
slide.
J
So
those
on
the
previous
slide,
they
were
sort
of
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
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.
J
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.
You
actually
have
to
have
a
business
model
to
to
back
that
up
and
and
that
that's
really
important.
So
if
you
know
whatever
you're
trying
to
do
requires
that,
then
then
you
do
need
to
think
about
it.
J
Secure
communications
with
path
elements.
We
talked
about
this
a
little
bit
on
the
previous
slide,
but
that
is
of
course,
in
the
general
case,
fairly
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.
J
Ted
had
been
working
on
something
in
this
space,
and
maybe
he
wants
to
talk
about
it
later
on
comments
a
little
bit,
but
you
could
perhaps
do
some
throttling
of
of
flaws
related
to
general
service
attacks.
For
instance,
if
we
had
the
necessary
pad
signals
for
that
hand
waving
a
little
bit
here,
we
could
do
more
protection
of
information
held
by
various
network
elements
or
even
by
the
servers
essentially
going
beyond
communication
security.
J
One
example
here
is
the
various
oblivious
dns
designs.
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
One
example
here
is
that
the
mobile
networks
actually
know
quite
a
little
about
the
network
capacity
and
the
you
know
you,
the
pipe
that's
available
for
the
user,
how
that's
likely
going
to
change
in
the
next
few
seconds,
but
there
are,
of
course,
are
significant
security
question
marks
here
like.
Can
you
actually
share
that
information
without,
for
instance,
accidentally
disclosing
where
the
user
is
so?
I
think
I'll
stop
here,
and
I
don't
know
if
my
co-authors
want
to
add
anything
ted,
media,
tommy,
otherwise
open
it
up
for
discussion.
K
Yeah
thanks
thanks
yari.
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
but
the
middle,
the
the
info-
that
that
is
needed
for
the
task
and
that's
a
that's,
a
really
dangerous
open
door.
K
So
I
think
you
have
to
be
be
careful
with
that,
because
one
person's
need
is
another
person's
bad
idea,
yep,
I'm
not
what
leads
absolutely
to
that.
The
consent
of
parties
thing
and
we
sort
of
see
that,
with
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
the
user
understanding.
J
Yeah,
that's
been
actually
one
of
the
inspirations
for
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're
concerned
on
yeah.
I
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
animal
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
nodes,
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
90
of
our
you
know.
J
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,
know
to
go
end
to
end
and
whether
you
choose
to
disclose
information
that
can
be
used
for
path.
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.
L
What
we're
talking
about
are
necessarily
ones
where
the
action
which
is
taken
as
a
result
of
the
signal
isn't
a
command
it's
advisory
to
some
extent,
and
I
think
ecn
is
one
we're,
probably
all
very
familiar
with
right.
And
so
this
is
a
signal
which
comes
through
the
path
and
it
is
advisory
to
the
to
the
nodes
through
which
it
passes
and
the
decision
exactly
what
action
to
take
is
not
set
in
stone.
L
And
I
think,
in
a
lot
of
the
cases
when
we're
talking
about
these,
what
we're
actually
trying
to
to
work
out
is
what
are
signals
that
are
useful
to
send
across
the
path
that
retain
that
sort
of
advisory
character
and
that
are
useful
to
both
ends
of
the
of
the
flow
as
well.
And
I
think
the
most
controversial
one
is
obviously
the
one
that
brian
and
I
talked
about
some
some
time
ago,
which
is
the
source
quench
issue.
It's
like.
L
The
other
sending
side
is
going
to
know
that
that's
happening
at
at
some
interval
right.
There
will
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
float.
The
question
is:
if
the,
if
you
have
a
bad
center
one
who
is
engaged
in
attack,
is
there
any
advisory
mechanism?
L
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.
L
It's
only
an
area
for
research
for
darn,
good
reason.
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.
A
M
M
So
in
that
year
the
iab
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,
because
an
ib
program
really
needs
ieb
backing?
B
It's?
It's
not
if
it's
not
a
pure
community
group,
and
we
always
have
to
have
some
broader
interests
in
the
iab
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.
J
Yeah,
yes,
I
just
wanted
to
agree
with
the
characterization
that
this
is
sort
of
a,
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.
N
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
J
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.
J
At
least
you
know
like
85
58,
that
says
a
thing
and
and
doesn't
go
into
huge
amount
of
detail.
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
what
I
want
to
do
next.
There.