►
From YouTube: IETF110-IABOPEN-20210311-1430
Description
IABOPEN meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
C
C
C
Okay,
okay,
hello,
everyone!
So
thanks
very
much
for
your
join
this,
the
ib
open
meeting.
So
these
are
the
mirror
and
the
champion.
Okay
mira
is
always
take
the
chair
and
I
beat
here
so
there's.
Another
co-chair
is
alternated
ib
members,
okay,
so
this
is
the
ietf
note
well,
so
this
is
the
remainder
of
the
itr
policies
so
that
you
are
maybe
familiar
with
this.
The
ietf
note.
Well,
I
hope
that
you
can
go
through
this
the
noteworld
very
quickly
and
to
understand
the
ideal
policies.
C
C
C
C
A
Yeah,
I
mean
actually
I
want
like.
I
would
like
to
add
something.
So
if
you
look
at
the
meeting
material,
there's
an
additional
presentation
there,
where
we,
where
yari
actually
summarized
nicely
some
of
the
previous
discussions
around
centralization
and
previous
work,
that
happened
around
centralization,
so
that
is
something
that
he
curated
based
on
the
discussion
we
had
yesterday
in
the
in
the
plenary.
A
C
C
A
Okay,
thank
you
yeah.
So
as
usually
we
try
to
update
you
a
little
bit
on
the
technical
work
we're
doing
so.
Since
the
last
meeting
we
published
one
rfc,
this
one
has
been
around
for
a
while,
but
it's
finally
published
and
has
an
rfc
number
and
that's
a
report
for
the
data
workshop.
A
But
the
more
interesting
news
is
that
we
also
have
now
a
draft
for
the
kovit
19
workshop,
which
is
workshop.
That
happened
last
november,
so
that's
kind
of
reasonably
new,
but
it's
already
in
very
good
shape.
We
got
a
bunch
of
video
comments.
Already
it's
a
research,
it's
a
workshop
report,
which
means
like
I
don't
think
I
hope,
there's
not
like
a
huge
amount
of
discussion
about
what
needs
to
be
in
the
document.
It's
really
trying
just
to
report
what's
happening.
A
A
So
if
you
haven't
read
this
yet
and
you
want
to
read
it
it's
a
good
time
now,
but
we
will
also
send
out
an
official
community
call
yeah.
So
yeah,
that's
only
workshop
reports.
This
time
the
we
might
come
up
with
new
documents
soon,
let's
go
to
the
next
slide.
A
Yeah
then
program
updates.
Last
time
in
the
iab
open
meeting,
we
reported
a
little
bit
that
we
looked
at
our
programs
and
we
also
considered
the
structure
of
the
programs
a
little
bit
and
we
discovered
that
we
have
like
two
different
kind
of
programs.
A
So
that's
why
we
introduced
this
restructuring
of
programs
and
since
then,
we've
been
working
on
also
reviewing
all
the
programs.
We
have
to
make
sure
they
are
fit
for
purpose.
Basically,
they
serve.
They
serve
and
support
the
iab
in
the
way
they
are
supposed
to
be,
and
what
we
did
is
we
looked
at
two
of
the
programs
which
are
more
in
the
group
of
admin
support
groups,
so
not
technical
programs,
but
I
still
want
to
quickly
mention
this
here,
because
that
has
been
recent
work.
A
Even
so,
it's
like
not
really
bringing
the
technical,
architectural
discussion
for
fashion
forward.
So
we
have
the
ayanna
program,
which
will
now
become
the
ietf
vienna
group,
so
the
chatter
of
this
program
will
be
updated
and
what
we
do
is
we
align
a
little
bit
the
activities
and
the
communication
we
have.
We
had
with
diana
into
this
program
matching
up
with
reality.
Basically,
you
might
have
seen
that
there
was
already
a
mail
on
this
send
out
to
the
architecture
discuss
list,
so
you
had
a
chance
to
comment
there.
A
The
other
support,
group
or
previous
program
is
the
liaison
oversight,
program
and
bib
decided
to
close
this
program,
and,
first
of
all,
we
like
to
thank
all
program
members
for
their
service,
and
this
program
has
been
dormant
for
many
years.
There
was
really
no
activity
and
that's
because
this
program
wasn't
like
even
so,
the
name
seems
to
suggest
that
wasn't
involved
in
the
actual
oversight
of
the
liaison
management.
A
So
this
is
what
the
iab
is
currently
doing,
we're
in
the
process
of
looking
at
our
liaison
management
and
try
to
improve
it.
This
is
because
we
think
it's
really
important
an
important
role
in
the
iub,
and
we
want
to
make
sure
it's
more
clear,
because
there
have
been
a
lot
of
confusions.
You
know
how
who
to
contact.
A
You
know
where
activities
are
needed
or
not
needed.
Another.
Another
point
here
is
that
we
also
noticed
that
we
are
at
the
point
where
we
actually
have
to
work
on
knowledge
transfer.
It
is
happening
that
people
do
retire
and
we
have
to
make
sure
that
we
transfer
this
knowledge
and
that
we
keep
continuity
of
this
knowledge
for
a
bunch
of
experts
in
different
regions
of
the
iab
itf.
A
And
it's
not
enough
to
just
like
you
know,
have
their
email
address,
put
them
on
a
mailing
list
or
whatever,
because
those
people
might
actually
go
away
at
some
point.
So
we
have
to
be
more
active
here.
A
So
this
position
has
the
goal
to
be
really
one
clear
contact
point
for
the
lease
on
managers,
as
well
as
for
the
community,
and
therefore
we
have
established
an
email,
alias
that
you
can
use
to
send
us
questions
about
liaisons
or
lease
on
statement.
Of
course,
you
can
still
contact
the
news
managers.
You
can
still
contact
the
ib
directly,
but
also
this
email,
alias,
is
really
for
any
laser
related
question.
A
A
good
first
contact
point,
if
you
don't
know
who
to
ask
otherwise,
so
this
new
position
basically
replaces
the
current
shepard
structure
that
we
have.
The
current
structure
was
a
one-to-one
structure
where
we
had
like
one
iab
shepard
for
each
liaison
manager.
The
liaison
managers
are
stable
positions
because
that's
where
the
knowledge
is
about
the
other
sdo
about
like
how
to
interact
with
them.
A
So
like
concentrating
this
on,
like
one
position,
which
probably
will
be
filled
by
two
people
to
have
a
backup
should
like
make
things
more
clear
and
easier,
hopefully,
but
we're
also
still
in
the
pro
process
to
define
this
position
a
little
bit
more
to
figure
out
if
there
are
further
tasks
that
these
people
that
fill
the
position
can
take
on,
and
we
will
provide
you
further
information,
hopefully
very
soon
by
email,
but
that's
only
really
just
the
first
step.
A
There
is
more
what
we
want
to
do
and
because
this
is
an
important
topic,
and
we
also
want
to
involve
community
experts
and
resource
managers
to
get
feedback
from
them
to
understand
what
needs
to
be
done
where
improvements
are
needed,
and
I'm
bringing
this
up
here
as
part
of
the
iboga
meeting.
Even
so,
this
is
not
on
the
technical
side.
A
It's
really
more
internal
admin
administrator,
but
still,
I
think
this
is
a
good
opportunity
to
get
you
all
the
information
as
a
community
that
you
need,
especially
that
we
now
have
this
new
role,
but
also
to
have
a
discussion
and
have
a
forum
for
that,
and
with
that
I
will
make
a
pause.
A
A
B
A
It's
in
the
iab
report
again
about
the
liaison
coordinator.
I
will
also
provide
more
detailed
information
soon
and
we
are
about
to
update
the
webpage.
I
thought
we
already
did,
but
maybe
we
didn't
so
it's
like
it's
all
fresh
news
and
it
will
all
happen
very
soon.
Okay,
thank
you.
D
I
I
just
wanted
to
say
that
that
I
think
this
is
definitely
a
step
in
the
right
direction.
The
the
situation
last
several
years
in
which
there
was
so
much
silence
that,
if
liaison
managers
needed
help,
they
couldn't
figure
out
a
to
was
was
definitely
a
bad
situation.
D
We're
all
concerned,
and-
and
I
really
appreciate
that
the
iab
is
is
taking
this
seriously
again
and
and
moving
in
some
direction,
which
is
will
keep
both
the
liaison
managers
and
the
ia
be
a
little
bit
more
informed
of
what
each
other
are
doing
and
coordinated.
So
thank
you.
A
Definitely
that's
the
goal
here.
I
I
got
a
bunch
of
emails
over
the
last
year
where
people
just
didn't
know
who
to
ask,
but
it's
also
that,
like
we
have,
the
iap
want
to
have
a
better
view
about
what's
happening
and
to
answer
martin's
question
from
the
chat.
So
this
is
not
an
email
list.
A
This
is
an
alias,
that's
really
just
forwarded
to
the
person
who
are
serving
in
this
position
and
this
this
per
the
person
who's
serving
in
this
position
is
usually
the
one
who
can
hopefully
like
some
of
the
easy
questions,
just
answer
them
directly.
If
it's
more
about
you
know
process,
but
in
other
cases
it's
also
just
like
part
of
the
role
to
just
forward
those
questions
to
the
right
people.
A
Hopefully,
so,
if
it's
for
you,
it
will
be
forwarded
to
you
if
you're
a
liaison
manager,
but
we
also
want
to
add
a
function
to
the
data
tracker
that
we
can
actually
reach
easily
all
the
leads
or
managers
and
create
a
list
for
that,
because
that
also
doesn't
exist
right
now.
So
many
small
things
that
we
are
looking
at
at
the.
A
E
Queue
yeah
hi,
so
one
of
the
things
I've
been
spending
a
lot
of
time
on
and
especially
recently
is
open
source
and
it's
relation
to
standards,
and
you
know,
there's
a
really
nice
ongoing
set
of
sessions
that
open
forum
urine
open
forum,
europe's
putting
on
and
alyssa
spoke
there.
I
also
work
closely
with
the
linux
foundation
and
I
think
they're
they're
talking
today.
I
I
think
in
general.
We
need,
I
don't
know
if
the
liaison's
the
right
thing,
but
it
doesn't
work.
E
E
You
know
we
don't
have
a
problem
with
open
source
organizations
and
the
liaisons
usually
like
you
know
when
we're
when
we're
dealing
with
problems,
but
it
just
seems
like
a
liaisons
handy
thing
so
that
we,
you
know
we
pop
up
on
their
slides,
even
as
an
organization
that
that
they're
working
with
and
that
we
have
a
little
bit
more
communication
as
these
worlds
of
open
source
and
standards
continue
to.
You
know
have
more
and
more
impact
on
each
other.
I'd
say.
A
Yeah,
so
this
is
two
points
here.
One
is:
can
you
mute
because.
F
A
Thanks,
so
one
point
is
that,
like
those
cases
where
we
kind
of
had
to
establish
a
nissan
relationship,
it's
often
because
the
other
organization
requires
us
to
have
like
this
kind
of
formal
relationship
to
you
know
get
into
the
meetings,
access
their
documents
or
whatever,
and
that's
the
case
where
we
really
need
the
formula
you
saw
in
other
cases
it's
sufficient
if
like-
or
it's
usually
like
just
having
the
formal
you
saw-
doesn't
help
that
actually
anything
would
change.
A
So
it
really
is
the
people
that
have
to
go
there
and
work
together
and
talk
to
each
other
right
and
that
doesn't
require
a
formal
lisa.
But
the
other
point
really
is
here
also
to
figure
out
where
we
need
to
go
and
who
we
need
to
talk
to
and
so
on,
and
I
see
that
actually
independent
of
like
the
strict
police
or
management
itself.
It's
really
about
outreach.
A
It's
really
about
figuring
out
what
other
stos
and
organizations
are
doing,
make
sure
we
are
well
aligned
with
them
and
that's
definitely
a
big
field
where
we
need
to
do
more
work-
and
I
have
this
on
my
list
of
to
do's.
But
I
to
this
put
this
a
little
bit
in
a
different
bucket
and
it's
definitely
something
I
want
to
drive
forward
and
discuss.
A
But
it's
also
less
straightforward,
because
it's
and
you
know
it's
sometimes
people
go
to
other
organizations
and
they
give
a
presentation
at
a
conference
and
whatever
and
that's
always
very
positive,
but
like
we
don't
have
a
task
force,
we
don't
have
like
a
way
to
send
people
somewhere,
it's
really
kind
of
on
like
if
they
are
there.
If
they
have
the
possibility,
they
can
do
it,
and
but
even
for
those
occasions,
I
think
we
need
better
coordination
and
have
a
better
visibility
what's
happening
and
who's
going.
E
Did
that
very
great
thanks
and
sort
of
your
take
on
is
how
I
feel
too.
It's
like
you
know
the
people
who
are
involved
everything's
going
well,
there's,
not
a
problem
there,
we're
able
to
work
with
open
source
organizations
very
well,
it's
just
sort
of
from
an
optics
point
of
view.
It
almost
looks
like
we're,
not
because
we
don't
have
that
liaison,
and
so
I
think,
and
for
some
people
who
are
looking
to
get
more
involved
in
this
or
don't
know
what's
already
going
on.
I
think
it'd
be
very
helpful
as
well.
So,
okay.
F
If
I
can
add
to
that
really
quickly,
I
think
there's
a
lot
of
we.
The
the
important
thing
to
take
into
account
is
that
all
technical,
you
know,
discussions
and
stuff
should
happen
as
regardless
of
whether
there's
a
liaison
ship
and
regardless
of
anything
else
right,
there's
nothing,
stopping
etf
participants
to
engage
in
multiple
other
communities.
F
F
But-
and
I
think
you
know
we
would
love
feedback
for
what
is
working
and
what
is
not
working
so
that
we
can
figure
out
how
to
better.
You
know
update
the
liaison
management
roles
in
the
first
place
and
which
ones
are
working
well,
which
ones
are
not,
but
don't
let
you
know
any
of
this
program.
Stop
people
from
you
know,
working
in
multiple
organizations
and
bringing
work,
both
directions
and
correspondence,
both
directions.
A
And
I
mean
this
is
still
not
like
a
structural
approach
but
like
if
you
have
information
that
you
think
is
like
about
another
seo,
but
another
organization
that
you
think
is
important
like
please
send
an
email
to
the
ib.
We
are
always
open
for
that
and
we're
always
able
or
like
keen
to
learn
something.
G
Last
year
I
got
involved
with
ansi
on
unmanned
aircraft
systems.
Standards
works,
they're,
collecting
who's,
doing
what
and
I
basically
have
to
represent
the
ietf
and
what
we
are
doing
in
our
standards
which
impact
uas.
I
did
reach
out
to
try
to
get
any
lays
under
other
official
contacts.
I
got
only
minimal
support
on
that.
I
think
the
final
document
coming
out
of
antsy
was
reasonably
well
in
including
ietf
as
an
sdo
involved
in
unmanned
aircraft
systems.
G
So
just
kind
of
saying
that
my
experience
has
been
a
little
bit
on
a
struggle
side,
particularly
now,
I'm
dealing
more
and
more
in
more,
shall
we
say,
closed
sdos
like
in
aviation
iko
and
working
with
astm,
where
they
have
some
very
formal
rules
for
liaisoning,
and
it's
I'm
just
participating
there
as
a
technical
expert.
G
But
it's
having
more
eye
tip
backing
may
be
of
real
value,
particularly
if
you
see
what's
I've
managed
to
get
into
the
the
private
network
proposal
for
aviation.
They
call
grain,
and
some
of
the
they
do
have
ik
does
have
a
liaison
with
icann,
but
that's
different
in
intent.
So
I'm
just
kind
of
sharing
with
you
that
there
is
a
other
areas
that
we
maybe
would
do
better,
and
I
don't
know
if
it
should
be.
I
should
be
doing
more
or
how
to
proceed
on
this.
A
Yeah
I
mean
I
understand,
I
understand
the
point
when
you
say
you,
you
would
appreciate
more
backing
from
the
ietf,
but
on
the
other
hand
it
wouldn't
change
the
situation
that
we
still
need.
Somebody
like
you
who
actually
participates
in
in
this
organization
and
goes
there
and
has
the
time
and
the
bandwidth
to
actually
contribute
where
needed
and
that's
not
necessarily
always
the
requirement
we
have
for
all
these
law
managers.
It's
really
more
like
kind
of
conflict
handling
when
it
comes
up
right.
So
that's
a
much
stronger
commitment.
G
I'll
have
to
look
at
the
emails
and
see
it
may
be,
maybe
lisa
when
I
was
doing
with
the
the
ansi
standards
work.
We
did
get
an
a
more
or
less
an
official
right
wording
of
that
pulled
together
for
what
the
ietf
is
as
an
sdo
which
they
they
wanted.
You
know
officially,
how
do
you
define
yourself
as
an
sdo
and
I
and
I
what
did
get
pulled
some
wording
together
to
do
that
and
I'll
afford
you?
What
I
have
on
that,
so
you
can
see
it.
C
Okay,
because
of
the
reason
of
the
time,
I
think
we
have
to
cut
the
line.
I
think
the
semen
is
the
last
one:
okay,.
H
Cool
thanks,
I
was
just
going
to
say
I'm
I've
kind
of
wound
up
in
an
unofficial
liaison
position.
A
couple
of
places
have
been
invited
as
a
technical
expert
to
tc39s
date.
Time
work
that
that
we
talked
about
in
dispatch
early
this
week
and
also
at
the
cal
connect
side.
I
am
I'm
kind
of
unofficially
at
least
the
liaison
to
iatf,
because
I'm
a
chair
on
the
calendaring
group
over
here
as
well,
is
this
something
that
that
I
mean
I'm
sure
there
are
plenty
of
other
people
who
are
in
similar
positions.
A
So
it
is,
there's
no
requirement
to
track
that.
I
think
it's
it's
again
generally
a
good
thing
if
people
keep
an
eye
out
and
and
promote
itf
work
in
other
organizations,
I
mean
it's,
but
I
mean
like
you're,
also
not
making
any
official
statements
for
the
iatf
in
your
position
right,
like
you're,
if
you're
contributing
on
a
technical
matter-
and
you
say,
hey
guys,
watch
out,
there's
some
work
in
the
ietf
that
you
should
be
aware
of.
That's
that's
always
a
good
thing.
A
If
you,
if
you
need
some
backing,
if
you
want
some
support,
if
you
have
a
problem,
that's
really
the
point
where
you're
very
welcome
to
reach
out
to
the
iab
or
in
general,
like
we
are
always
interesting
to
learn.
What's
going
on
right
and,
as
I
said
like,
we,
we
don't
have
a
good
track
record
yet
so
it
would
be
helpful
to
to
learn
more,
but
we
also
don't
really
know
how
to
organize
that
in
an
efficient
way.
At
this
point,
all.
A
Yeah
so
martin,
let
me
just
reply
to
that.
One
quickly,
martin
mentioned
that
people
might
misrepresent
work
of
the
idf,
so
that
happens
as
well,
but
like
that
will
always
happen,
that's
something
we
don't
have
a
control
of
the
it's.
As
I
said
like
it's,
I
think
there's
a
very
in
very
few
cases
the
the
need
to
talk
as
the
ietf.
I
I
The
problem,
apart
from
sort
of
could
we
strengthen
the
secretariat
in
some
way
to
do
this,
which
I
appreciate
is
a
cost
issue,
etc,
etc,
and
is
there
and
is
and
is
there
and
is
there
and
is
therefore
not
easy,
but
I
think
sort
of
ietf
would
would
benefit
in
the
overall
sdo
ecosystem
if
there,
if
there
was
some
sort
of
central
contact
point
that
could
do
some
of
this
interfacing
and
again,
I
appreciate
that's
not
a
role
that
the
the
secretary
of
united
curry
takes
is
very
much
more
of
an
organizational
thing,
but
I
think
you
know,
as
we
as
we
get
a
more
integrated
global
system.
I
You
know
something
like
6g
demands
that
standards
interface
all
over
the
place
in
ways
in
which
they
haven't
done
before.
You
know
we're
going
to
need
more
sdo
contact
and
you
know
if
if
we
can't
get
the
sdo
ecosystem
talking
to
each
other
better
and
understanding
each
other
better,
then
we
are
going
to
become
more
and
more
awkward
and
which
I
think
will
just
fragment
our
the
overall
seo
system,
even
even
even
even
more
badly
than
arguably
at
the
moment,
you
know
and
sort
of
how
do.
How
do
we
do
standards,
etc,
etc?.
A
So
the
the
official
point
here
contact
point
here
is
the
iab
and,
I
hope,
having
a
separate
email
alias
here.
That
is
like
more
clear
to
that.
It
helps
a
little
bit
and
we
will
put
the
information
on
the
website
in
the
right
places.
Hopefully
even
so,
the
website
might
also
not
be
super
clear
and
easy
to
find.
So
I'm
not
sure
maybe
it's
just
like
a
missing
information
to
other
seos,
like
that.
A
The
ib
is
the
right
point
to
talk
to,
but
to
be
honest,
if
you,
if
you
you
know,
if
you
use
any
of
the
other
email
addresses
that
you
find
on
our
website,
most
of
them
go
to
the
secretariat
and
they
know
how
to
forward
this
to
the
iap.
So
it
shouldn't
be
that
hard
to
reach
us.
It's
probably
just
like
unclear
how
to
do
it.
C
A
Do
you
think
this,
like
a
siemens
already
gone
right?
Do
you
think
this
like
email
address
will
help,
or
is
there
more
kind
of
advertisement
needed.
I
I
would
I
would
just
an
email
address
would
do
does
help,
but
it's
actually
being
able
to
engage
in
a
two-way
conversation
with
a
person
who
understands
your
system
and
can
be
a
central
contact
point
of
system
and
in
a
way
in
which
sdos
with
a
larger
secretariat
can
and
do
you
know.
I
appreciate
their
they're,
probably
rather
more
formal
than
what
than
we
are
in
iatf.
You
know,
but
I
think
you
know,
as
we
get
this
greater
level
of
interfacing,
that
I
think
we
need
in
in
technology
as
a
whole.
I
You
know,
I
think
all
sdos
have
to
have
to
move
with
the
times
and
then
we've
we've
seen
more
and
more
sort
of
central
coordination.
Iitf
as
the
years
have
gone
by
and
I
think
as
we
move
forward,
we
we
need
a
greater
degree
of
central
coordination
here
in
the
sense
of
people.
You
can
actually
engage
in
a
conversation
with,
rather
than
just
a
a
mailbox
you
can.
I
mean
you
can
send
an
email
to.
A
Okay,
understood,
I
think,
that's
a
yeah,
probably
a
slightly
separate
problem,
because
we
do
have,
for
example,
leadership,
meetings
with
other
sdo
slides,
like
I
triple
e
and
so
on.
So
that's
probably
more
in
this
category,
but
it's
yeah
good
input.
Thank
you.
C
Okay,
so
next
topic
is
the
edm
for
the
latest
progress
from
the
tommy.
Okay,
let's
share
okay.
J
Okay,
all
right,
slides
up;
okay,
thank
you!
Okay,
hello,
everyone
I'll
be
giving
a
quick
update
on
one
of
our
technical
programs,
which
is
one
of
the
newer
ones
we
have.
J
This
is
the
program
that's
on
talking
about
evolvability
protocols,
deployability
and
maintainability,
and
in
a
lot
of
ways
it's
carrying
on
work
that
ib
had
done
in
the
past,
but
trying
to
build
on
that
and
find
ways
that
we
can
come
to
more
technical
recommendations
to
the
ietf
for
how
we
ensure
that
the
protocols
we're
developing
have
good
properties
around
these
aspects,
and
one
administrative
change
here
is
that
david
schnauzy
is
now
going
to
be
a
co-lead
of
this
program.
J
K
J
I
love
it
all
right
next
slide,
please
so
just
some
details
here
we
do
have
a
github
where
you
can
see
some
of
the
issues
we're
thinking
about
it's
at
that
link
and
the
document
that
we're
currently
talking
most
about
is
actually
one
that
existed
prior
to
this
program
being
created.
But
we
think
is
a
very
important
work
item
that
we
want
to
progress
that
martin
thompson
began,
it's
the
draft,
use
it
or
lose
it,
and
we've
met
now
twice.
J
J
So,
at
the
last
meeting,
one
of
the
major
topics
we
covered
was
just
looking
at
what
are
the
mechanisms
that
we're
doing
for
protocol
extensions
and
are
there
things
that
we
could
add
as
notes
to
the
user,
we
lose
it
draft
and
one
of
the
topics
here
was
looking
at
the
relative
success
and
how
ossified
we
see
things
when
we're
using
something.
That's
a
proper
version,
negotiation
versus
just
extending
a
protocol.
J
One
of
the
observations
in
the
document
is
that
you
want
to
be
able
to
use
an
extension
point
often,
and
that
is
the
best
way
to
ensure
it
does
not
ossify,
but
version.
Negotiation
specifically,
is
something
that
can
get
used
very
infrequently
and
especially,
is
not
being
used
when
you
first
deploy
a
new
protocol,
and
so
we
were
noting
that
actually,
some
of
the
most
successful
cases
of
this
is
when
a
protocol
has
this
version.
Negotiation
in
some
other
protocols.
J
We
also
discussed
some
anti-patterns
like
how
we
see
that
the
iip
itself
has
a
version
field
that
really
is
often
not
used,
and
you
need
to
have
some
encapsulating
protocol,
like
the
ether
type,
actually
determine
what
is
the
protocol
version.
So
we
have
a
lot
of
redundant
version
indicators
in
that
case,
so
we
have
some
initial
text
that
was
added
to
the
document
based
on
this,
but
we're
going
to
continue
to
refine
that
and
go
further
next
slide.
Please.
J
And
there's
also
areas
that
we
noted
that
you
know
we
are
still
learning
about.
There
are
ongoing,
essentially
experiments,
particularly
in
what
quick
is
doing
and
the
experience
we're
having
in
tls
and
http
quick
is
one
of
the
kind
of
first
protocols
like
this.
That's
really
defining
a
strong
notion
of
invariance
that
will
last
across
multiple
versions
going
to
the
future.
We
haven't
deployed
those
other
versions.
Yet
so
we're
going
to
have
to
see
how
that
works
out.
J
Greasing
is
also
something
that's
done
a
lot
already
in
tls.
It's
something
that
we
can
do
in
quick
and
we're
talking
about
doing
more
in
http,
and
this
is
an
area
again
where
we'd
like
to
have
advice
on
this,
but
we're
also
still
gathering
information,
and
particularly
one
of
the
interesting
areas
for
greasing,
is
talking
about
how
we
can
coordinate
this.
J
J
So
that's
something
that
we
want
to
further
explore
in
our
next
meeting.
So
if
these
are
interesting,
topics
to
you,
please
join
in
anyone
can
join
the
list
and
anyone
can
join
the
meetings
next
slide.
J
I
think
that
yep,
so
here's
the
mailing
list,
you
can
join
we'll,
be
scheduling
a
call
very
soon
and
you
can
send
your
thoughts
through
email
or
github
elliot.
L
Great
permissions
problem
correction,
thanks
for
the
opportunity
to
comment.
Just
one
quick
comment,
which
is,
I
think,
there's
a
difference
in
a
qualitative
difference
between
protocols
and
formats.
L
And
so
when
you
look
at
each
right
a
protocol,
you
can
negotiate,
you
can
fail
fast.
There
are
all
sorts
of
things
you
can
do
in
a
protocol
with
a
an
object
format.
You
have
less
opportunity
to
fail,
and
so
you
have
to
look
at
the
problem
a
little
differently,
which
is
to
say
how
do
you
handle
backward
compatibility?
L
And
this
has,
I
think,
plagued
some
of
the
systems
that
we
use
pretty
regularly
like
email
and
other
things
where
you
really
don't
want
to
have
to
have
a
backward
compatibility,
but
then
you've
got
that
one
person
who's
using.
You
know
a
teletype
from
you
know
or
something
they
bought
because
they
can't
they
can't
see
they
bought
it
10
15
years
ago
and
they're
not
going
to
replace
it
so
the
there
there
are
some
aspects
around
those
formats
and
as
you're
going
through
this
exercise,
it
might
be
worth
just
teasing
out
those
differences.
J
M
The
just
a
data
point
really,
you
said
ip
versions:
weren't
used.
Actually
we
use
ipv
versions
to
identify
whether
a
packet
is
or
isn't
a
an
ip
packet
in
the
mpls
domain
and
then
actually
sequester
those
fields
for
some
other
internal
notations.
So
it's
not
actually
correct
to
pick
that
particular
example.
J
Yeah,
thank
you
for
that
note,
and
I
I
think
the
way
I
was
explaining
it
was
overly
simplified
and
the
text
we're
working
on
in
the
document
should
be
hopefully
a
bit
more
nuanced
of
just
pointing.
J
M
H
A
A
Yeah,
I
think
we
move
on
with
picking
up
the
centralization
discussion
from
yesterday.
Basically,.
N
There
we
go
excellent,
so
this
is
basically
just
as
noted,
continuing
the
discussion
from
from
yesterday
and
a
little
bit
of
context,
setting
and
pointers
to
existing
work
and
a
couple
of
thoughts
about
way
forward
or
how
this
can
be
best
discussed,
because
the
next
slide
please.
N
So.
The
topics
that
I
think
we
are
discussing
about
is
two
things
really.
N
Like
you
know
my
website
or
alternative
dns
server,
you
know
it's
their
information.
Only
one
place
can
really
really
provide
it.
Other
services
could
be
such
that
they
are
fundamentally
collaborative.
I
think
packet
forwarding
might
be
one
example
here,
so
you
have
to
forward
to
others
essentially
and
there's
some
service
that
could
be
either
way.
N
So
that's
that's
sort
of
a
technical
thing
in
in
some
sense
that
we
we
are
within
one
one
domain
or
one
administrative
entity
and
then
there's
internet
consolidation,
which
is
more
about
like
competition
and
companies
and
so
forth,
and
how
many
service
providers
we
have,
for
particular
things
in
the
world
and
how
much
choice
do
you
have
as
a
consumer?
N
N
N
The
question
is:
does
it
does
it
actually
matter
and
should
we
be
discussing
it,
and
I
at
least
personally
think
it
matters?
I
think
other
people
were
also
saying
that
so
it
can
have
many
impacts
and
and
sort
of
important
to
realize
that
there
can
be
in
many
directions,
so
so,
first
of
all,
some
of
this
can
be
good.
N
It's
particularly
easy
if
you
control
multiple
parties
in
a
protocol
exchange,
it's
also
useful,
sometimes
to
hide
in
a
crowd,
but
there
are
also
serious
drawbacks.
One
is,
of
course,
resilience
like
if
that
one
big
service
goes
down
and
we've
seen
this
kind
of
thing
happen.
Occasionally,
then
we
are
in
a
world
of
hurt.
N
Even
if
you
are
you
know
well-meaning,
you
want
to
do
like
all
of
us.
I
think
in
the
itf
everybody
who's
involved
is
doing
this
or
any
of
these
services,
and
they
are
very
good
intentions,
but
but
they
are
also
affected
by
governments
and
shareholders
and
so
on
that
might
be
asking
for
for
access
to
the
data,
for
instance.
N
So
I
think
we
want
to
avoid
that
in
some
ways-
there's,
of
course,
economics
involved.
I
won't
go
into
details
of
that.
You
can
read
some
of
that
when
we
move
to
the
next
slide,
so
I
was
trying
to
collect
a
little
bit
of
previously
published
material
about
this
and,
of
course,
at
least
for
me,
it's
it's
surprising
how
good
stuff
you're
going
to
find
from
the
old
rfcs.
N
They
were
really
written.
Cleverly
rc1958,
for
instance,
talks
about
competitive
multi-vendor,
multi-provider
public
networks,
3935
talks
about
decentralized
control,
it's
used,
user,
empowerment
and
so
forth.
Next
slide,
please.
I
have
a
few
other
things
here.
I
won't
go
into
the
details
of
these.
These
things
save
time
for
a
discussion,
but
I
just
wanted
to
point
you,
the
internet
societies,
global
report
on
consolidation
and
the
journal
of
cyber
policy,
and
if
you
click
one
more
slide
forward,
so
they
actually
published
a
special
issue
that
was
sponsored
by
isaac.
N
I
don't
see
the
next
light
yet,
but
can
you
move
to
the
next
slide?
Oh
there
we
go
so
they
published
a
an
issue
with
consolidation
related
articles,
but
various
kinds
of
research
or
thoughts
around
this
topic
worth
reading.
N
To
take
a
look-
and
maybe
that's
enough
for
for
this
past
work-
the
point
was
just
to
say
that
there's
quite
a
lot
of
that's
already
been
written
about
it.
If
you
go
to
the
last
slide,
where
I
had
a
few
thoughts
about
how
to
move
forward-
and
I
see
many
possibilities
for
failing
to
discuss
this
properly.
N
The
other
thing
that
we
want
to
avoid
is
that
we
shouldn't
trade,
take
the
debate
to
the
extremes
that
just
because
we
can't
have
like
fully
peer-to-peer
network
with
you
know,
bitcoin
exchanged
all
over
the
place
doesn't
mean
that
we
shouldn't
do
anything,
and
the
same
is
true
of
also
like.
Not
everything
is
going
to
be
centralized
doesn't
mean
that
we
shouldn't
think
about
it's
each
case
that
we
come
across
carefully
and
think
about
whether
that's
we're
doing
the
right
thing
or
the
wrong
thing.
N
Third
point
is
that
we
should
actually
understand
this
this
space,
and
sometimes
you
get
this
frustration
like
I
I
get
it
that
well,
I
can't
really
do
much.
So
what
what
should?
I
should?
I
stop,
but
I
think
it's
actually
useful
to
understand
like
understand
the
issues
understand
the
impacts,
collect
measurement
data.
N
N
One
example
is
is
that
if
you
have
something
where
you're
only
using
one
instance
of
something
some
technology,
for
instance,
and
and
that's
too
centralized
or
consolidated
for
for
people's
taste,
then
having
a
way
to
discover
other
places
that
offer
the
same
service
can
actually
be
useful.
I
think
we've
done
this
in
the
dns
space
or
are
doing
it
at
least
so
I
think
that's
a
helpful
technique,
or
example
of
a
helpful
technique,
and
I
think
that's
it
from
my
side.
N
A
Yeah,
I
I
would
like
to
add
one
point
and
that
tommy
made
yesterday
and
probably
he's
much
better
in
making
his
point
herself,
but
I
think
it's
also
that,
like
we
can
not
necessarily
push
somebody
to
adopt
a
certain
technique
just
because
they
think
we
think
it's
like
it's
it's
better
for
the
internet.
I
think
deployment
is
always
driven
by
you
know.
What's
the
benefits
that
a
solution
provides?
A
L
That
I'm
still
having
some
permissions
issues,
hey
thanks,
yari.
This
is
good
work
and
I
think
it's
something
that's
been
around
everybody's.
It's
been
in
people's
minds
for
a
while.
I
wanna
once
again
acknowledge
even
early
comments
that
mark
nottingham
made
on
on
this
in
an
iab
plenary
going,
although
going
way
back
to
2014
or
so.
L
The
two
points
I
wanted
to
make
is
that,
first
of
all,
I
I
do
think
there
are
times
when
we
should
be
thinking
about
these
aspects.
Architecturally
not
and
as
they
apply
to
our
protocol
suite.
Perhaps
one
of
the
most
egregious
aspects
of
private
networking
is
that
it
forces
a
form
of
concentration
in
that
endpoints
are
all
but
prohibited
from
offering
services
without
intermediaries.
This
is
something
that
I
raised
early
on
as
far
back
as
1994
as
a
concern
with
with
private
network
addresses.
L
So
this
is
a
problem
that
can
recur
and
I
think
martin
has
written
eloquently
on
the
value
and
use
and
perhaps
risks
of
intermediaries,
and
that
comes
into
this
discussion.
The
second
point
is
that
I
wanted
to
agree
with
you
about
just
how
complex
a
problem
this
is.
One
can
easily
argue
that
mail
services,
these
days
are
considerably
more
reliable
than
they've
ever
ever
been
because
the
there
is
not
only
a
concentration
of
service
providers,
but
there's
a
concentration
of
expertise
who
then
know
how
to
scale
these
services,
which
is
really
good.
L
The
problem
is
when
one
of
these
providers
fails,
the
damage
is
considerable,
and
we
just
saw
a
good
example
of
that
outside
of
the
help
mail
environment
over
the
last
few
days,
with
one
particular
offering
where
they
they
took
out.
You
know
there
was
a
risk
that
hit
many
thousands
of
businesses.
L
So
it's
very
one
of
the
things
we
should
be
thinking
about
in
terms
of
resolving
this.
By
the
way
is,
can
standards
play
a
role?
Can
open
standards
or
open
guidance
open
up
interfaces
today?
That
are
in
fact
closed
that
might
improve
the
the
environment
in
terms
of
the
risks
of
resiliency
that
we
face
all
right
thanks
very
much.
A
Say
that
we
will
close
the
queue
very
soon,
because
we
have
now
a
huge
number
of
people
in
the
queue
and
only
eight
minutes.
Seven
minutes
left.
So
if
you
want
to
say
something
jump
into
the
queue
now
and
we'll
be
close
in
10
seconds.
O
So
purely
questions,
one
thing-
and
maybe
I
missed
it
at
the
top-
is
where
can
folks
get
more
involved
in
the
discussion
and
participate
in
this
discussion,
because
I
think
you
know
this
is
one
of
my
things
too.
I
think
a
lot
of
people
care
about
this
one
and
would
like
to
figure
out
how
to
give
input.
The
other
is.
O
Does
the
iab
have
any
good
levers
to
pull
to
to
actually
not
just
work
against
this,
but
just
deal
with
it?
Whether
it's
work
against
it
or
say
this
is
looking
like
it's
centralizing
and
maybe
it's
good.
Maybe
it's
bad
and
we
have
to
examine-
and
you
know
how
might
those
levers
affect
ietf
work?
How
might
they
affect
other
work?
I'm
just
trying
to
get
my
head
around
how
this
is
going
to
be
useful
discussion
other
than
just
shouting
at
clouds,
which
some
of
us
love
to
do
anyway.
N
Yeah
I'm
looking
for
my
decentralized
button,
but
I
can't
find
it
right
now.
I
I
think
the
only
lever
that
we
have
is
is
information
and
educating
people
and
with
regards
to
where
to
discuss
this,
I
think
yesterday
somebody
suggested
that
we
should
organize
a
workshop,
that's
a
possibility,
but
we
actually
had
workshops
in
this
space,
and
so
that
was
in
the
slides.
N
O
It
would
be
nice
to
have
something
more
ongoing
than
a
workshop.
I
mean
I
think,
workshops
are
great
and
they
always
produce
great
output,
but
this
seems
like
such
a
big
topic
that
having
something
more
long-lived
that
the
iab
was
running
would
be
great.
Okay,.
I
Hi
yeah
well,
thank
you
for
covering
it
again
so
briefly,
but
but
thoroughly
yarry.
I
I
I
just
would
debate
two
points
you
touched
on
the
fact
there
could
be
some
benefits
to
users
from
centralization,
and
you
mentioned
some
of
them
like
the
sort
of
quick
adoption
of
standards,
etc.
I
think
I
would
argue
that
that's
unlikely
to
be
true
over
the
long
term.
So,
yes,
there
might
be
some
short-term
gains,
but
I
think
long-term
yeah
privacy,
resilience
etc
is
toast.
I
I
don't
see
how
the
there's
it's
in
the
long-term
interest
of
of
users.
You
know,
even
if
it
means
that
ipv6
gets
adopted
more
quickly,
yeah,
but
all
of
my
personal
data
is
now
available
on
the
dot
web
feels
like
a
bad
trade-off
over
the
long
term.
So
I
think
long
term.
I
question
if
there
are
any
meaningful
gains
from
it
and
in
terms
of
so
what
to
do
about
it.
I
I
do
think
that
there
needs
to
be
the
ability
to
review
and
challenge
sort
of
new
protocols
etc
before
they're
they're
allowed
through
standards
to
see
if,
if
they
do
make
the
problem
worse
and
pick
up
on
a
point
that
tommy
made
very
very
well
yesterday
and
maybe
intervene
to
improve
them
to
try
and
allow
for
those
significant
negative
side
effects
to
be
ameliorated
in
in
some
way
but
yeah.
Otherwise,
I
think
this
is
just
a
disaster
for
the
end
user
and
completely
against
rfc8890
thanks.
P
Thanks
yeah-
and
I
just
want
to
thank
you
yuri
for
for
highlighting
the
complexity
and
the
different
issues
of
involved
in
this,
because
it
is
social,
political,
economic,
it's
it's
market-based,
it's
technical,
it's
it's
very
complicated,
and
I
really
appreciate
that.
All
I
want
to
say
is
I
just
support
pete's
idea
about
doing
something.
P
That's
iab
sponsored
you
know,
maybe
using
the
workshop
as
a
jumping
off
point,
but
I
think
it
would
be
great
to
kind
of
have
a
discussion
ongoing
discussion,
at
least
for
a
little
while,
even
though
ones
have
already
happened
in
the
past,
it's
a
perfect
time
right
now,
so
I'm
looking
for
the
to
the
iab
for
some
some
ideas.
So
thanks.
K
David
hi,
david
kanazi
iab,
so
first
off,
I
want
to
say
that
I
agree
that
this
is
a
complex
topic
that
is
important
like
to
say,
and
I
agree
that
too
much
centralization
is
bad.
Absolutely
that
said,
I'm
very
confused
as
to
what
the
iab
or
the
larger
scale
the
ietf
community
can
do
here,
because
we
are
not
the
protocol
police.
K
We
are
not
legislators.
So
if
what
is
the
outcome
here,
if
we
are
gonna,
if
we
write
an
rfc
that
says,
centralization
is
bad,
that's
not
gonna
change
the
needle
a
bit.
If
we
go
and
have
a
workshop
and
say
why
is
centralization
bad,
because
a
b
and
c
I
don't
see
that
as
moving
the
needle
either.
So
while
I
think
this
is
an
important
topic,
I
kind
of
see
it
as
out
of
scope
for
the
itf
in
general.
K
All
we
can
do
to
make
sure
we
don't
encourage
centralization
to
make
sure
our
protocols
are
open
and
extensible,
so
anyone
can
do
anything
they
want
with
them,
but
that's
been
in
our
ethos
since
the
beginning.
So
I'm
not
sure
there's
much
more
to
be
done
from
us
here.
N
N
Thank
you.
Martin.
J
Yeah,
so
just
to
reply,
because
a
couple
people
mentioned
what
I
had
said
at
plenary
with
regards
to
this,
I
just
want
to
clarify
that
I
very
much
agree
with
what
david
said
like
we
cannot
be
a
protocol
police
here,
but
that
we
should
be
just
focusing
on
promoting
protocols
that
allow
distributed
and
non-centralized
ways
of
doing
things,
and
I
think
there
are
positive
things
we
can
do,
but
we
should
not
be
focusing
on
transfer.
Q
Yeah,
so
I
share
the
concerns
a
lot
of
people
about
centralization
in
many,
oh
by
the
way,
martin
duke
f5
and
iesg.
I
I
do
share
the
concerns.
A
lot
of
people
have
about
centralization
in
many
aspects
of
the
internet
works.
I
do
think
that
the
work
of
creating
interoperable
standards
is
inherently
decentralizing,
because
you
know
they
allow
you
to.
Q
Quite
basically,
I
I
do
in
my
non-expert
opinion,
centralization
is
largely
regulatory
and
and
legal
problem,
and
I
remain
a
little
skeptical
that
the
itf
has
the
levers.
I
mean
you
mentioned
one
thing
here,
which
is
the
client
side
discovery.
We
do
things
like
abd,
which
I
think
an
effort
to
address
that
I
think
we've
been
doing
discovery
techniques
for
for
a
long
time,
but
I
I
have
trouble
seeing
the
letters
that
ietf
has
to
to
move
the
ball
forward
on
this
thanks.
R
I
mean
david
and
martin
said
a
number
of
things.
I
would
say
I
guess
you
know.
I
I
think
it's
important
to
distinguish
between
things
which
are
you
know,
inherently
centralizing.
R
And
things
which
are
not
so
I
mean
like:
let's
take
the
web,
which
is
like
inherently
decentralized
technology
like
you
can
as
many
websites
you
want,
you
can
have.
You
know
like
people
like
other
websites,
et
cetera,
and
yet,
when
you
look
at
how
the
web
practice
gets
deployed,
you
know
it's
almost
impractical
for
on
any
substantial
site
having
using
aws
or
using
a
cdn
or
hosting
or
having
hosted
for
you,
and
so
here
we
have
a
situation
where
there
is
a
nominally.
R
System
that
is
technically
decentralized,
and
yet
there
are
powerful
economic
and
technical
reasons
why
it
gets
shoved
into
a
very
small
number
of
boxes,
and
so
the
extent
to
which
you
know
you
might
ask
the
iatf
to
die
in
the
system
differently,
but
like
what
would
you
have
done?
What
are
you
doing
to
make
that
inherently
less
centralized?
And
so,
if
you
know,
if
we
want
to
do
something
meaningful
here,
then
we
have
to
ask
is
what
are
the
technical
functions?
R
That
would
reverse
the
incentives
towards
taking
things
which
are
nominally
decentralized
and
actually
centralizing
them,
and
I
think,
there's
a
really
big
open
question.
I
think
there's
been
a
lot
of
work
on
it
frankly,
a
lot
of
which
I
don't
think
works
super
well
and
it
isn't
as
persuasive
as
my
hope,
but
I
think
those
are
the
those
are
the
anchors
that
you
know
or
are
the
the
levers
that
we
have
to
pull.
R
If
there
are
any-
and
I
think
you
know
our
rfcs
or
blog
posts
about
hazard-
realization
is
bad
will
not.
It
will
not
have
much
of
an
impact.
C
Chenbin
and
miriam
okay
says
mira:
do
you
have
any
the
word.
A
No
so,
unfortunately,
we
have
no
time
left
for
any
other
open
mic,
but
feel
free
to
send
an
email
to
ib
ib.org.
If
you
want
to
tell
us
something
or
have
a
conversation
with
us,
I
think
this
conversation
can
go
to
the
architecture
discuss
list
and
we
can.
I
can
keep
discussing
there
and
with
that.
I
think
we're
done
sorry
for
going
overtime
for
a
few
minutes.
I
hope
you
enjoyed
it
anyway.