►
From YouTube: IETF 110 Internet Architecture Board (IAB) Open Meeting
Description
The Internet Architecture Board (IAB) will hold an open meeting on 11 March 2021 at 14: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.
C
B
A
D
B
B
B
F
B
B
B
B
So
besides
this
the
ib
open
meeting,
we
have
the
several
of
these.
The
main
list
so
including
this,
the
architecture
discuss
main
list
for
the
architectural
discussion
and
the
ib
documents
and
the
ib
at
ib.org
for
comments
and
concerns
directly
to
the
ib,
and
we
also
had
this
the
program
mainly
list
for
direct
comments
on
work
of
a
specific
program.
B
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.
A
B
B
A
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
A
So
that's
why
we
we
introduced
this
restructuring
of
programs
and
since
then,
we've
been
working
on
also
reviewing
all
the
programs.
We
have
to
make
sure
and
they
are
fit
for
purpose.
Basically,
they
serve.
They
surf
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
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.
You
can
still
comment,
but
basically
this
is
ready
and,
and
the
iab
is,
is
ready
to
go
ahead
and
make
this
change.
A
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
iab,
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
If
you
have
a
question
like
when
to
send
a
liaison
statement
when
to
have
a
lease
on
relationship
and
so
on,
so
we
really
want
to
make
this
process
more
clear
and
more
transparent
and
also
improve
the
internal
communication
and
the
view
that
the
iab
has,
because
sometimes
it
wasn't
actually
easy
to
find
out
for
the
iab
itself.
You
know
where
activities
are
needed
or
not
needed.
A
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
A
So
this
position
has
the
goal
to
be
really
one
clear
contact
point
for
the
lease
or
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
lease
or
managers.
You
can
still
contact
the
iab
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
There
is
more
what
we
want
to
do
and
because
this
is
an
important
topic,
and
we
also
want
to
involve
community
experts
and
lease
our
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
ibog
meeting.
Even
so,
this
is
not
on
the
technical
side.
C
C
A
E
E
G
The
the
situation
lasts
several
years
in
which
there
was
so
much
silence
that,
if
liaison
managers
needed
help,
they
couldn't
figure
out
a
go-to
was
was
definitely
a
bad
situation
for
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
A
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,
the
right
people,
hopefully
so,
if
it's
for
you
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
H
Yeah
hi,
so
one
of
the
things
I've
been
spending
a
lot
of
time
on
and
especially
recently
is
open
source
and
its
relation
to
standards,
and
you
know,
there's
a
really
nice
ongoing
set
of
sessions
that
open
forum
urum,
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.
H
H
You
know
you
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
that:
liaison's
a
handy
thing
so
that
we,
you
know
we
pop
up
on
their
slides,
even
as
an
organization
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
it's
echo
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
a
formula.
So
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
reason.
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
resource
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.
H
Did
that
very
quick
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.
I
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
ietf
participants
to
engage
in
multiple
other
communities.
I
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
it's
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
to
are
like
keen
to
learn
something.
J
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
context.
I
got
only
minimal
support
on
that.
I
think
the
final
document
coming
out
of
ansi
was
reasonably
well
in
including
itf
as
an
sdo
involved
in
unmanned
aircraft
systems.
J
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
so
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.
J
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
the
islam
managers.
It's
really
more,
like
kind
of
conflict
handling
when
it
comes
up
right.
So
that's
a
much
stronger
commitment
that.
J
I'll
have
to
look
at
the
emails
and
see,
and
maybe
maybe
lisa
the
ansi
standards
work.
We
did
get
an
a
more
or
less
an
official
right
wording
of
I
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.
B
K
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
earlier
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
promote
ietf
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
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.
L
L
So
I
I
I
don't
really
see
any
answer.
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
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
secretary
of
united
curry
takes
it's.
L
L
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
et
cetera,
et
cetera,.
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
key
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
iab
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,
as
it's
probably
just
like
unclear,
how
to
do
it.
B
A
L
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,
and
I
appreciate
their
they're,
probably
rather
more
formal
than
we
are
in
ihf.
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.
L
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
in
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
M
M
N
M
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.
M
M
M
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.
M
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.
M
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.
M
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.
M
M
F
F
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?
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.
F
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
are
some
aspects
around
those
formats
and
as
you're
going
through
this
exercise,
it
might
be
worth
just
teasing
out
those
differences.
M
O
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.
O
A
P
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
we
have
to
forward
to
others
essentially
and
there's
some
service
that
could
be
either
way.
P
P
P
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
they
can
be
in
many
directions,
so
so,
first
of
all,
some
of
this
can
be
good.
P
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.
P
One
sort
of
a
personally
concerning
issue
is
also
that
if
you
have
two
large
entities
that
have
a
lot
of
data-
let's
say
not
just
pick
a
random
example
entities
that
would
know
the
browsing
histories
of
people
for
large
number
of
people
that's
very
attractive
target.
Even
if
you
are
you
know
well-meaning,
you
want
to
do
like
all
of
us.
P
P
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
gonna
find
from
the
old
rfcs.
They
were
really
written.
Cleverly
rc1958,
for
instance,
talks
about
competitive
multi-vendor,
multi-provider
public
networks,
3935
talks
about
decentralized
control,
it's
use,
user,
empowerment
and
so
forth.
Next
slide,
please.
P
P
P
P
The
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.
P
One
example
is
is
that
if
you
have
something
where
you're
only
using
one
instance
of
something
some
technology,
for
instance,
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
used,
for.
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.
P
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?
What's
the
cheapest
solution,
what's
more
easy,
easier
to
deploy
solution,
and
so
on?
F
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
think
I
wanna
once
again
acknowledge
even
early
comments
that
mark
nottingham
made
on
on
this
in
an
ied
plenary
going,
although
going
way
back
to
2014
or
so.
F
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
the
private
network
addresses.
F
So
this
is
a
problem
that
can
recur,
and
I
think
martin
has
written
eloquently
on
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's
not
only
concentration
of
service
providers,
but
there's
a
concentration
of
expertise
who
then
know
how
to
scale
these
services,
which
is
really
good.
F
F
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
Q
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.
Q
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.
P
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.
Q
Q
L
Oh
yeah
well,
thank
you
for
covering
it
again
so
briefly,
but
but
thoroughly
yarry.
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
qriket
operating
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.
L
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
dark
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.
L
I
do
think
that
there
needs
to
be
the
ability
to
review
and
challenge
some
new
protocols
etc
before
they're
they're
allowed
through
the
standards
to
see
if,
if
they
do
make
the
problem
worse
and
pick
you
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.
R
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.
R
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
that
to
the
iab
for
some
some
ideas.
So
thanks.
N
Hi
david
schnazzy
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.
N
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.
N
P
S
S
Yeah,
so
I
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
way
the
internet
works.
I
I
do
think
that
the
work
of
creating
interoperable
standards
is
inherently
decentralizing,
because
you
know
they
allow
you
to
switch
out
the
vendors
for
things
very.
S
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
add,
which
I
think
our
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.
T
T
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?
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.
T
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
hope,
but
I
think
those
are
the
those
are
the
anchors
that
you
know
or
are
the
the
levers
that
we
have
to
pull.
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.
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.