►
From YouTube: IETF115-DINRG-20221107-1530
Description
DINRG meeting session at IETF115
2022/11/07 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
I
think
it's
his
time:
let's
get
it
started.
So
this
is
a
King
research
group,
meeting,
decentralized,
the
internet
infrastructure
and.
A
Yeah
I
think
I
participated
in
the
last
one.
This
is
actually
my
second
thing,
RG
meeting
and
we'll
move
on
to
the
next
one
up
front.
We
will
have
some
matters
yeah.
A
Speakers
can
take
off
the
mask
temporarily,
which
is
good.
So
that's
your
role.
We're
gonna
first
go
through
a
few
who
are
not
well
notifications,
so
this
is
the
RTF,
follow
the
ietf
intellectual
property
right
by
participating
in
the
irtf.
You
follow
those
processes
in
the
policies
contributions.
If
it's
covered
by
the
patents
you
need
to
inform
the
community
yeah
and
the
file
such
as
APR
disclosures
in
a
timely
manner
in
the
arkf,
prefers
the
most
liberal
licensing
terms.
A
You
you
can
read
as
as
clearly
as
I
could
just
read
them
myself
right
personal
informations
you
provided
to
RTF
will
be
handled
in
accordance
with
a
privacy
policies
stated
there
and
as
a
participant
or
attendee,
you
agree
to
work
respectively
with
other
participants
and
she's
overseas
for
the
code
of
conduct.
Next
slide,
please
go
for.
Artf
is
a
focused
on
the
longer-term
research
issues
like
this
one,
we're
not
really
making
standard
but,
looking
to
addressing
you
know,
Mara
long-term
challenges.
A
A
B
Yes,
so
kindly
Raymond
has
volunteered
so
Raymond.
Are
you
in
the
meeting.
A
What's
what's
her
name,
I
lost,
or
can
we
just
get
that
one
more
volunteers
for
note
taking.
A
B
A
C
A
B
That's
great
thanks,
if
you,
if
you
like,
you,
could
take
notes
in
the
Hedge
talk
document
and
there's
a
link
in
the
chat.
If
you
don't
know
whether
it's.
A
So
this
is
just
recap
of
what
happened
at
ietf
Philadelphia,
where.
A
We
put
the
pointer
there
for
whoever
wants
to
refresh
your
memory
all
the
materials
of
that
meeting
over
there
I
think
that
essentially
I
give
a
report
on
this
Workshop
thing
RG
conducted
in
June,
2021
and
I
think
the
two
major
points
we
extract
out
from
that
very
interesting
Workshop
is
the
following.
That
is
the
really
two
major
factors
We
Believe
that
have
driven
to
this
internet.
A
A
Centralization
is
the
lacking
of
effective
Security
Solutions
and
that
have
driven
people
into
the
clouds
so
that,
with
the
thick
walls
of
the
castle,
people,
somehow
you
know,
put
their
web
services
and
other
services
into
the
clouds,
because
individually,
one
doesn't
really
have
the
power
to
mitigate
like
the
scale
and
then
the
the
strengths
of
today's
deny
of
service
attacks.
A
Of
course,
this
is
just
from
the
workshop
discussions.
Further
discussions
will
be
needed
and
then
the
next
main
point
we
took
away
from
the
last
meeting
is
that
that
the
people
by
the
large
agreed
we
can
use
the
visiting
RG
as
a
forum
to
other
focal
points
to
collect
the
future
inputs
and
run
discussions
so
that
it's
more
or
less
organized
more
better
organized
effort,
as
opposed
to
previously
we
have
a
long
list
of
Internet
drafts
around
this
area.
A
This
challenging
topic,
but
you
know
scattered
in
different
places
as
individual
submissions
I
think
drg
now
would
agree
to
be
the
host
of
those
the
home
for
those
discussions
next
slides
so
moving
forward.
Since
the
Philadelphia,
we
received
multiple
inputs,
individual
messages
here
and
there,
and
also
see
in
the
global
broader
interest
product
community
that
those
growing
interest
in
addressing
these
challenges.
So
today
we
focus
on
this.
The
second
task
we
collected
from
Philadelphia-
that
is
beginning
the
the
very
first.
A
Kind
of
a
discussion
we'll
have
five
presentations
that
covers
a
broad
area,
looking
at
the
centralization
or
Mitigation
Of
The
centralization
from
different
angles.
We
hope
that
today's
discussion
will
really
trigger
the
group
of
gpn
and
therefore
helping
moving
the
effort
forward
and
then
I
hope.
We
still
have
time
at
the
end
we're
going
to
discuss
about
the
drg
charter
updates,
given
that
the
charter
was
written
several
years
back
now,
our
understanding
of
the
problem
space
have
changed
in
a
significant
way.
So
by
the
end,
turkey
will
lead
that
discussion.
A
A
We
know
that
not
everyone
would
be
able
to
make
that
time
slot,
given
this
last
minute,
the
plugin,
but
that
Turk
and
I
will
try
to
draft
something
after
today's
discussion
so
that
we
can
conduct
the
conversation
about
the
charter,
app
updates
over
email
and
continue
on
to
the
Wednesday.
So
that's
the
end
of
my
10
minutes,
I
think
I'm
right
on
time
and
our
next
one
will
be
Mark
sitting
right
here.
You
can
draw
your
own
presentation.
D
Okay,
let's
see
I'm
gonna,
do
it
from
here,
rather
than
stand
up
so
I
I
have
to
sort
of
add
to
the
contributions
here.
I've
authored
a
draft
based
on
the
conversations
that
we
had
in
Philadelphia
and
also
in
the
workshop.
Let
me
sort
of
bring
up
a
little
bit
of
context
here.
I
think
we
know
about
the
word
taxonomy.
This
is
not
where
I'm
headed
our
understanding
of
taxonomy
when
we
were
learning
in
in
early
school
days,
is
something
that
is
a
complex
hierarchy
of
organizing
organizing
information.
D
That's
really
not
where
I'm
headed
here,
but
I
wanted
to
remind
you
of
the
uses
of
that
word
in
in
my
case,
the
word
taxonomy
is
something
that
is
actually
suggested
by
the
authors
of
the
workshop
report
on
centralization.
They
actually
have
a
paragraph
in
the
workshop
report
that
basically
talks
about
this
issue,
and
let
me
put
it
into
sort
of
a
very
simple
English
here.
If
you
have
four
people
who
are
looking
at
a
work
of
Modern
Art,
you
have
probably
they're
seeing
four
different
things
right.
D
If
you
have
four
people
taking
a
Rorschach
test,
they're
going
to
tell
you
that
there
are
different
things
in
each
one
of
them
and
I
believe
that
one
of
the
things
that
we
learned
from
Philadelphia
is
when
you
say
the
word
centralization,
it
means
different
things
to
different
people.
It
it
just
Rings
a
different
Bell
and
that's
without
making
any
judgment
about
the
validity
of
that
interpretation
or
the
applicability
I'm.
D
If
for
those
people
who
were
at
the
Philadelphia
research
group
meeting
dinarg,
there
was
a
really
robust
discussion
and
what
was
interesting
was
there
were
long
mic
lines
and
people
talking
about
many
different
things.
D
So
the
workshop
report
has
this
text
in
it
and
I'm
not
going
to
read
this
text
to
you.
Instead
I'm
going
to
basically
tell
you
that,
when
looking
at
talk
to
you
about
organizing
the
content
of
this
session,
many
of
the
features
of
the
workshop
report
are
were
built
into
her
presentation
that
you
just
saw
five
minutes
ago.
D
For
instance,
the
first
one
is
about
the
power
of
the
economies
of
scale
right
and
service
customization,
which
we'll
talk
about
in
a
second
and
and
then
the
the
overall
effect
of
Monopoly
players
in
the
market
right.
So
this
is.
This
is
text
that's
lifted
from
the
workshop
report
and
it's
part
of
the
it's
part
of
the
motivation
for
this
taxonomy
document.
D
Now
there
is
just
this
first
version
of
the
taxonomy
and
it
divides
the
topic
into
four
areas,
and
this
is
where
I'm
going
to
spend
my
time
here,
the
rest
of
my
time
on
the
agenda.
So
there
is
the
concept
of
economic
consolidation
right
and
centralization.
D
We
hear
a
lot
about
that,
because
it's
Market
forces
that
make
this
happen.
There's
traffic
and
infrastructure
consolidation,
if
you've
ever
seen,
statistics
here,
like
the
statistics
that
Jeff
produces
there's
a
lot
of
people
who
produce
statistics
about
traffic
changes
to
traffic
models
in
the
public
internet,
there's
a
whole
facet
here
related
to
Traffic
and
infrastructure,
and
it
has
an
interesting
knock-on
effect
because
it
affects
architectural
consolidation
right.
We
see
that
the
internet
is
provided
in
a
different
way
than
it
was
say
15
years
ago.
D
Finally,
we
have
service
and
application
consolidation
right,
a
separate
area
where
we
see
the
application
layer
having
more
and
more
of
a
role,
especially
from
dominant
providers
of
those
services
and
applications,
and
so
the
taxonomy
breaks
the
it
breaks
up
the
issue
of
centralization
into
these
four
topic
areas:
okay,
and
that's
really,
the
the
the
fundamental
part
of
this
taxonomy
economic
consolidation
is
something
that
we've
talked
about
a
lot.
We
talked
about
it
in
Philadelphia.
D
There
are
some
great
papers
in
the
workshop
related
to
economic
consolidation
and
the
centralization
refers
to
the
effects
of
Market,
Market
players
right
and
and
the
effects
on
competition
and
the
economic
power
of
a
very
small
set
of
companies
and
in
the
taxonomy
document.
One
of
the
things
we
suggest
is
that
there's
two
aspects
to
this:
first,
a
small
number
of
companies
dominate
the
marketplace
right
and
also
that
that
small
number
of
companies
dominate
the
flow
of
capital
in
the
internet's
economic
ecosystem
right
two
separate
features,
but
both
about
economic
consolidation
and
centralization
sure.
A
D
I
think
I
think
at
the
end
is
what
I
would
say
here
so
separate
from
economic
centralization?
Is
the
concept
of
traffic
and
infrastructure
consolidation?
What
we're
seeing
is
that
a
significant
majority
of
the
internet's
public
traffic
is
delivered
from
very,
very
large,
Services,
okay
and
and
someone
in
the
room
in
the
in
the
workshop
report.
D
There
are
actual
statistics
provided
for
that,
so
there's
there's
actual
data
that
drives
that
first
bullet
and
naturally,
what
these
companies
are
trying
to
do
is
they're
trying
to
provide
the
best
possible
service
for
their
end
customers,
because
that
drives
the
user
base
up
and
that
builds
the
economy
of
scale
in
today's
internet.
The
result
is
really
a
flattening
of
the
traditional
topology
of
the
internet.
What
we've
got
is
a
situation
where
the
end-to-end
principle
isn't
really
the
principle.
That's
at
work
here
right.
D
In
fact,
one
of
the
things
that
was
in
the
workshop
report
is
this
first
sub
bullet
here.
A
recent
study
shows
that
these
large
Services
reach
more
than
three
quarters
of
the
internet
without
having
to
do
any
Transit
of
traditional
isps,
traditional
large-scale
isps
and
another
report
that
was
done
in
February
right
around
the
time
or
just
before.
The
Philadelphia
meeting
was
that
the
number
of
web
pages
hosted
on
large
dominant
companies
has
increased
at
a
rate
exceeding
80
percent
on
a
year-by-year
basis.
That's
enormous
centralization!
That's
enormous
consolidation!
D
Now,
the
third.
The
third
of
the
four
categories
in
the
taxonomy
is
architectural
consolidation
and
in
my
paper,
what
I?
The
draft
suggests
that
there
are
really
two
pieces
to
this.
One
is
the
emergence
of
intermediary
Services
right
services
that
are
sitting
either
in
the
core
of
the
network
or
provide
services
that
look
as
if
they're
not
being
provided
at
the
edges
of
the
network
and
then
the
movement
of
Transport
related
code
to
the
application
layer,
all
right.
D
Well,
one
of
the
things
that
we
have
are
things
like
dnfs
over
HTTP
right,
the
things
like
that,
where
we're
pushing
up
to
the
application
layer,
things
that
used
to
be
provided
by
different
layers
in
the
network.
Let
me
talk
about
both
of
these.
In
turn,
intermediaries
Technologies,
like
cdns,
are
actually
built
into
the
network
for
very
good
reasons:
right,
efficient
delivery
of
services
and
content,
lower
latency
for
end
users.
D
The
ability
to
one
of
the
things
that's
important
about
intermediaries
is
the
ability
to
distribute
the
content
very
very
efficiently
and
the
end
user
is
almost
always
unaware
that
the
service
or
application
that
they're
trying
to
take
advantage
of
isn't
what
they're
getting
the
service
from
right.
D
The
second
of
the
two
is
the
actual
movement
of
movement
of
services
from
say
the
transport
layer
up
to
the
application
layer,
the
application
layer
now
providing
those
Services
specific
for
the
application.
I'll
talk
more
about
this
in
a
second,
but
these
are
things
that
are
very
familiar
to
all
of
us
in
the
room.
I'm
sure
the
fourth
bullet
is
the
one
that's
important
to
me.
E
D
Part
of
the
taxonomy
is
service
and
application
consolidation.
This
is
the
fourth
sort
of
this
is
my
suggestion
of
a
fourth
layer
for
the
taxonomy.
It's
the
services
and
applications
that
the
users
see
when
they're,
actually
interacting
with
the
internet
and
one
of
the
things
that
was
in
an
isoc
report
that
I
think
was
from
last
year.
D
Is
this
quote
and
I
think
it's
a
very
germane
quote
for
this
part
of
the
taxonomy
is
that
what
we
have
here
is
a
very
small
number
of
companies
operating
some
of
the
internet's
most
popular
services
and
many
of
those
companies
act
as
multi-sided
markets,
so
they're
actually
working
not
just
with
the
the
people
who
are
transporting
bits
across
the
network,
but
they're
also
delivering
Services
directly
to
the
end
user,
and
so
they
that
means
that
those
Services
act
as
a
base
upon
which
other
companies
can
build
services
on
top
of
and
all
that
does,
is
increase
the
power
of
that
dominant
dominant
organization.
D
That's
very
different
from
an
architectural
consider
consideration.
This
pushing
pushing
the
consolidation
and
centralization
up
to
the
application
layer
is
a
very,
very
important
part
of
what
we
saw.
Come
out
of
the
workshop
and
also
the
discussions
we
had
in
this
research
group
in
Philadelphia
before
I,
ask
for
questions.
D
Let
me
finish
up
so
the
four
the
four
areas
I
had
to
have
one
graphic.
The
four
areas
in
terms
of
consolidation
and
centralization
that
I'm
talking
about
here
are
economic
centralization,
traffic
and
infrastructure,
centralization,
architectural
centralization
and
service
and
application
layer
centralization.
D
My
goal
with
this
taxonomy
document
is
to
get
us
to
think
about
individual
parts
of
this
and
talk
about
how,
for
instance,
the
the
irtf
can
give
guidance
to
the
ietf
about
protocol
design.
That
addresses
a
particular
issue.
Now,
maybe
that's
not
possible,
but
here
was
my
suggestion.
A
year
ago,
is
that
what
the
irtf
could
do
is
actually
provide
guidance
to
the
ietf
about,
just
as
we
provide
security
considerations
or
Iana
considerations
in
an
RFC,
we
might
talk
about
centralization
considerations
right
and
the
irtf
could
possibly
give
guidance
in
that
area.
D
Just
like
RFC
3552
gives
guidance
regarding
security
considerations.
So
too,
you
could
imagine
an
informational
document
coming
out
of
the
irtf
that
gave
consolidation
considerations
that
that
was
what
was
behind
my
interest
in
creating
a
taxonomy
so
setting
up
for
questions
here.
What
this
is
supposed
to
do
is
just
guide
future
discussion
of
consolidation.
What
I'm?
It's
currently
a
zero
draft
document,
so
I'm,
obviously
looking
for
comments
suggestions.
One
of
the
comments
that's
perfectly
appropriate
here
is
that
this
isn't
going
to
work.
D
I
would
listen
to
that,
although
I
might
push
back
whether
or
not
these
four
categories
are
accurate.
Is
it
a
correct
description
of
the
kinds
of
inputs
that
we
got
for
the
workshop
and
the
kinds
of
inputs
we
got
for
from
people
at
the
microphone
in
Philadelphia?
F
Yes,
hi
well,
firstly,.
F
For
what
it's
worth
I
think
that's
a
good
reflection
of
the
discussion,
As
I,
understood
it
in
in
Philadelphia
and
then
just
made
one
comment
on
the
document
you
might
want
to
just
put
perhaps
in
the
economic
piece
something
about
the
Sprint
net,
because
in
my
opinion
this
is,
if
you're
like
a
different
aspect
of
the
Splinter
net.
F
Oh
sorry,
as
it
says
on
the
screen,
Andrew
camping.
F
Sorry,
that's
the
point
of
the
Mike
Q
anyway,
as
I
was
saying,
there's
a
whole
Splinter
net
aspect
here
and
I
think
this
is
another
aspect
of
the
Sprinter
net,
not
the
one
that
people
traditionally
talk
about.
But
arguably
this
is
far
more
important
to
users
than
the
sort
of
the
political
Splinter
net,
because
this
is
actually
real
now,
rather
than
something
which
is
perhaps
a
threat
for
the
future.
Okay.
G
Needs
no
affiliation,
I
work
for
myself
and
I.
Don't
know
what
I'm
doing
here.
Mark
I
think
you've
done
a
very
great
job
of
summarizing
the
discussions
and
how
we've
got
to
where
we
are
here
just
now
so
kudos
for
that
and
I
think.
The
initial
content
of
the
draft
is
a
reasonable
reflection
of
where
we
are
at
the
moment.
It
mainly
thought
about
tweaking
further
on,
but
I
do
think
this
is
an
important
topic
and
it's
something
that
this
research
group
could
explode
further.
G
As
you
see,
I
think
there's
a
potential
chance
later
on
about
how
that
research
work
can
then
feed
into
the
rest
of
the
ietf
that'll,
be
an
interesting
discussion
to
have
maybe
further
down
the
line,
but
I
think
it's
very
important
that
we
start
talking
about
this
and
it
seems
to
be
at
the
moment.
This
is
the
only
Forum
we've
got
in
the
ITF.
To
do
that,
so
I
would
hope.
G
D
B
You're
next,
yes,
yeah
thanks
Mark
for
putting
this
together.
I
just
wanted
to
challenge
a
little
bit.
This
notion
of
this
centralization
considerations
that
that
you
mentioned
so
in
my
experience
quite
often,
it's
really
not
easy
to
tell
the
effect
of
certain
protocols
or
political
features
with
respect
to
centralization.
So
I
was
wondering
whether
you
had
some
further
thoughts
on
this
already.
B
D
You
I
think
well,
I
do
and
they're
they're
just
my
thoughts,
Dirk
and
they're,
not
sanitized
for
the
office.
The
first
example
that
I'll
give
you
is
an
example
like
privacy
pass,
which
is
under
development
right
now,
which
is
an
example
of
a
a
protocol
that
by
design,
has
a
very
small
number
of
it's.
It's
a
token-based
system
to
provide
privacy
for
end
users
and
yet
allow
for
authentication
at
servers
Etc,
but
by
Design.
The
architecture
limits.
D
Another
number
of
token
granting
servers,
and
so
the
protocol
by
Design
does
that
and
I
I.
For
my
myself,
I
look
at
the
the
services
that
we
are
developing
in
the
ietf
that
have
intermediary
components
like
the
oblivious
HTTP
as
an
example
right
where
you
have
something
in
the
middle
between
the
requester
and
the
provider
of
services
and
I.
Think
in
those
cases,
what
I
worry
about
is
the
the
quantity
or
the
consolidation
of
those
services
in
the
middle.
B
Okay,
great
thanks
I
could
imagine
this
characterization
could
be
quite
controversial
at
times,
but
yeah.
Let's
think
about
this
for
now.
Thank
you.
D
H
Next
yeah,
thank
you
Mark,
so
Arnold
from
broadcom.
So
thank
you
for
putting
this
work
together.
In
fact,
so
it's
a
support
to
this
work.
It's
just
have
you
considered
other
aspects
of
consolidation
like
overall
resilience,
so
what
happens
when
we
have
a
major
problem
with
one
of
these
Consolidated
actor?
H
We
have
a
number
of
examples
in
the
past
that
that
seems
to
be
minimized,
but
they
are
not
in
terms
of
when
it
fails.
What
happens?
Another
one
is
trust.
So
what
is
it?
The
trustworthiness
that
we
have
in
these
Consolidated
actors
and
another
one
which
is
perhaps
more
difficult
to
approach,
is
probably
the
current
gravitation
of
regenerization
in
the
world.
That
is,
that
he's
going
against
a
consolidation
regardless
if
they
want
it
or
not.
So
there
are
three
aspects
here
that
might
be
considered
by
the
draft,
but
in
general
we
support
distract.
I
I
D
Well,
that's
a
great
question
and
you'll
not
be
surprised
to
hear
that
I
don't
have
a
good
answer
for
that.
I
think
the
draft
should
consider
that,
but
that
feels
like
a
separate
piece
of
work.
What
you'd
eventually
like
out
of
this
piece
of
work?
The
taxonomy
is
sort
of
a
narrowing
of
scope
for
certain
kinds
of
research
that
that
so
that
the
research
group
is
productive
in
the
future
by
focusing
on,
for
instance,
architectural
principles
as
an
example
right
or
focusing
perhaps
on
the
application.
The
changes
that
the
application
layer.
D
A
You
okay,
many
thanks
to
everyone.
I
will
inserted
myself
at
the
last
because
I
cannot
get
into
my
laptop
I
would
like
to
Second
columns
the
comment.
This
is
really
a
great
contribution.
I
think
it's
so
much
material.
That's
all
part
of
the
discussion
on
this
topic,
two
specific
comments.
One
is
that
you
mentioned
about
the
architectural
centralization
and
use
the
CDN
as
an
example.
My
question
is:
is
the
CDN
Architectural
Components
or
is
it
actually
independent
from
the
protocol
stack
of
the
architecture?
A
I
A
I
just
like
to
bring
up
for
discussion,
like
you
mentioned
in
yours,
draft
that
you
can't
have
a
skill,
it's
a
fundamental
factor
that
that
has
to
where
we
are
today
now.
The
question
is
whether
we
can
just
divide
the
Technical
Solutions
alone
to
actually
mitigating
this
fundamental,
economical
problem.
D
Well,
let
me
let
me
respond
to
your
first
question.
The
second
question
about
economics
is
something
where
I
feel
like
I'm
on
Shaky
Ground
And,
so
I
would
be.
I
would
be
thrilled
if
people
provided
comments
on
the
mailing
list
about
the
economics.
Part
in
terms
of
the
architectural
considerations
see
cdns
is
an
example
of
an
architectural
change
to
the
internet
and
the
way
the
way
I
think
about
it
is
the
historic
view
of
the
end-to-end
principle
is
really
no
longer
in
play.
D
We're
asking
we're
asking
the
core
and
the
edges
of
the
network
to
do
much
more
than
they
they
used
to
do.
I
think
that's
an
architectural
change
and
I
think
we
don't
I.
Don't
I
think
that
there
are
many
times
where
we
don't
acknowledge
that
and
and
I
see.
There's
disagreement
and
I
can't
wait
to
talk
to
you
about
it.
So.
A
F
A
You
want
to
be
around
I
would
just
say
that
to
keep
the
schedule.
I
was
still
back
how
much
and
to
send
to
the
mailing
list,
but
I
think
that's
a
great
question
to
bring
up.
That
is
what
is
the
entrance
principle
and
as
the
the
world
changes,
that's
the
definition
also
change.
All
right
there
used
to
be
end-to-end
is
end-to-end
reliability
and
that's
no
longer
there.
D
Well,
we've
taken
we've
taken
her
20
minutes,
but
I
look
forward
to
having
conversations
with
you
in
the
hall
and
also
online
on
the
mailing
list.
So
Dominique
you
up.
K
K
So,
thank
you
Mark
and
Mark's
long
before
Mark's
excellent
work.
We
co-authored
this
particular
draft
which
actually
addresses
the
end-to-end
principle
addresses
what
a
little
bit
to
a
short
extent
also
addresses
some
of
the
threat.
Analysis.
I
think
our
no
brought
it
up
so
hopefully,
I'll
address,
answer
your
question
or
no
a
little
bit
as
well.
So
can
I
have
the
next
slide.
Thank
you
right.
K
So
here
we
are
in
version
five,
so
we
started
this
this
originally
in
November
2020
and
in
the
last
version
in
the
current
version.
One
thing
that
we
did
is,
or
in
particular
I
did-
is
actually
really
narrow
it
down
because
of
your
taxonomy
and
I've
referenced
a
little
bit
more
of
Mark's
excellent
work
in
terms
of
really
getting
a
broader
view.
So
so
basically
this
particular
this
particular
draft
is,
is
kind
of
looking
at
the
current
state
at
a
higher
level
than
than
Mark
goes
into.
K
But
but
the
other
thing
it
does
is
talk
about
maybe
potential
outcomes
or
options
or
ideas
for
going
forward.
It
also
talks
about
a
little
bit
some
of
the
risks
so
I'll
get
into
that
a
little
bit
in
depth,
but
I'm
not
going
to
take
too
much
time
thanks
so
yeah.
So,
as
Mark
said
in
his
taxonomy
draft,
you
know
there's
a
wide
variety
of
different
views,
there's
even
different
definitions
right
some
people
are
using
the
word.
Consolidation.
K
Some
are
using
centralization
I'm,
finding
we're
interchanging
it
a
lot,
but
we
really
need
to
kind
of
think
about
linguistically
what
we're.
What
we're
looking
at
and
and
there's
a
there's
a
couple
of
definitions
in
there
as
well
I
have
a
bit
more
background
in
economics.
So
we
look
a
little
bit
more
of
the
positive
I
would
say
aspects
of
consolidation,
the
economies
of
scale,
the
ability
to
build
data
centers
and
have
Investments
at
a
very
big
and
Grand
scale.
K
But
then,
conversely,
a
lack
of
Market
competition
in
some
areas
in
some
places,
depending
on
the
layer
and
the
platform
and
whatever
else
and
and
we
originally
Mark
and
I,
originally
looked
at
that
based
on
a
report
that
was
done
in
the
US
was
is
done
in
Congress
and
you
know
that's
going
back
to
two
and
a
half
years
now,
I
think,
and
that
was
sort
of
some
of
the
interest
of
the
economic
background
in
terms
of
security,
end-to-end,
encryption
forces,
data
to
the
endpoints
there's
a
little
bit
more
I'll
show
in
the
next
slide
or
next
couple
slides
on
on
that
idea
and
on
that
concept
and
again
picking
up
probably
earlier
than
Mark
talking
a
bit
about
consolidation
through
development
choices,
architectural
choices
and
protocol
development
choices.
K
So
next
slide
right.
So
we
talked
a
bit
or
Mark
talked
a
bit
about
this.
The
changing
architecture,
the
internet
and
I
think
that
choices.
You
know
people
make
obviously
have
effects
architectural
and
Engineering
effects
and,
in
my
personal
interest,
I'm
also
interested
in
the
wider
effects,
the
economic
effects,
the
policy
effects,
the
effects
that
actually
make
users
make
different
choices.
K
So
we
talk
quite
a
bit
about
that
in
this
draft
and
also
I
think
it
would
be
worth
it
to
have
even
more
discussion
about
it,
but
the
n-10
principle
that
Lexia
brought
up
the
reliability
and
the
trustworthiness
and-
and
you
know
it's
moving
to
from
end
to
end-
to
edge
to
edge
and
I,
really
like
your
questions,
Alexia,
because
I
think
in
the
next
draft,
I'm
gonna
probably
look
at
that
a
bit
more
right,
you
know:
do
we
need
to
think
about
defining
this?
K
A
bit
differently
briefly
talked
about
Network
and
devices
as
consolidators
as
well.
A
little
bit
with
the
upcoming
5G
Network
slicing.
Things
like
that
and
and
one
thing
on
the
edge
to
edge
is
something
that
I
think
Russ
was
talking
about
through
his
get
and
get
his
GitHub
post
and
everything
about
the
the
sort
of
protocols
not
being
doing
one
thing
but
being
the
Beyond
end-all
of
all
things.
K
So
the
idea
that
protocol
development,
in
some
cases,
not
all
cases,
have
quite
a
number
of
activities
and
characteristics
that
they
take
on
that
that's
taken
on
when
they're
deployed.
Thank
you
so
risks.
Hopefully
this
is
something
that
is
touched
upon
briefly
by
two
examples,
but
again
decentralized
to
centralization
decreased
stability
and
fragility.
K
K
So
the
redundancy
issue
around
the
idea
of
the
decentralized
internet
and
and
redundancy
when
you
have
fewer
providers
and
we've
seen
that,
obviously,
with
a
number
of
issues
like
when
WhatsApp
went
down
last
week,
you
know
everybody
freaks
out,
but
yeah,
that's
basically
what
we're
trying
to
capture
in
a
more
in
a
more
technical
sense
and
also
a
threat,
visibility
and
diversity.
So
one
more
I
think
there's.
This
is
the
last
slide.
K
So
I
really
appreciate
the
the
opportunity
to
have
a
place
for
this
now
through
that,
through
all
of
you
and
and
so
just
thinking
about
some
of
the
options
coming
up.
Do
you
know
what
do
we
look
further
at
I
like
the
idea
that
Colin
mentioned
about
what
isn't
you
know,
consolidation
as
a
work
item
and
or
as
a
potential
draft,
but
also
focusing
on
more
measurement
in
different
areas?
But
what
else?
What
else
can
we
continue?
K
The
discussions
on
and
here
I
have
a
couple
of
proposals
that
were
in
some
earlier
drafts
that
we
did,
but
you
know
measurement
consideration
of
consolidation
in
rfcs.
You
know:
should
it
be
its
own
section,
should
it
potentially
be
reviewed
by
people
or
as
an
item
that
people
review?
Who
knows,
but
just
throwing
out
some
ideas
and
human
rights
review
as
well,
something
that
that
I
I
think
would
be
interesting
to
discover
and
talk
about.
So
any
further
thoughts
is
welcome,
happy
to
take
it
offline
and
again
I'm.
K
It's
going
a
bit
more
hand
in
hand
with
your
work
too.
So
I
think
that's
it.
L
M
Have
think
of
a
nice
summary
that
is
great
I
have
a
question
regarding
your
work
on
the
end
to
end
there's
another
draft
in
progress
with
Mallory
Nuttall
and
yet
another
one
with
Alec
Moffett
and
both
of
those
just
address
a
basically
a
conceptual
flaw
in
how
we
have
been
looking
at
end
to
end
and
how
that
has
been
propagated.
I,
like
sort
of
the
term
edge
to
edge
that
you're
working
with
here,
but
there's
also
catches
with
adding
yet
more
vocabulary
to
a
space
that
has
holes
in
it.
M
K
A
really
good
idea,
so
I
one
of
the
things
and
I
don't
know
if
Mallory
is
here
in
the
room
yay
so
can
I
catch
up
with
you
this
week,
because
I
would
love
to
do
that.
I
know
Alec
really
well,
but
I
haven't
read
his
draft
yet
so
I
think
again,
the
economies
of
scale
would
make
more
sense,
but
maybe
maybe
we
need
to
talk
more
about
the
definition
of
it.
But
thank
you
actually.
That's
a
really
good
point
that
I
need
to
kind
of
think
more
about
that.
K
K
L
Hello,
Roland
Bliss,
just
a
quick
comment
on
end
to
end.
That
is
quite
fuzzy
term.
So
there's
the
end-to-end
argument
system
design.
There
is
end-to-end
transparency,
there's
end-to-end
encryption
and
what
are
the
ends
actually
depends
on
which
layer
you
are
talking
about.
Is
it
the
network
layer?
Is
it
the
transfer
layer
or
the
application
layer?
And
this
is
all
at
least
from
my
point
of
view
mixed
up
somehow,
so
we
need
to
really
Define
things
concisely
and
precisely.
A
And
I
would
just
added
one
more
comment
regarding
end
to
end
people.
Think
in
trend
is
fishing
challenges.
Clearly
that
means
there's
something
in
the
middle
that
interrupted
this
end-to-end,
something
and
therefore
what
are
this
thing
in
the
middle
and
why
they
showed
up
in
the
middle
actually
I
I
called
the
the
word
middlebox
that
really
started
I
think
30
years
back
almost
that
we
started
seeing
something
pop
up
in
the
middle
and
that
middle
thing
is
a
girl,
wider
and
wider
yeah
yeah.
A
A
N
Yes,
hello.
Thank
you
yeah!
You
can
skip
this
slide
it's
about
web
centralization.
My
name
is
jensenkoser
joke
inviting
here
he
said
that
the
talk
I
gave
at
first
earlier
this
year
was
something
I
should
repeat
here.
So
that's
what
I'm
doing
but
much
shorter
I
have
a
small,
tiny,
tiny
non-profit
that
tries
to
do
a
bit
of
r
d
and
internet
technology,
and
this
talks
more
about
how
we
got
into
the
internet.
Society
Foundation
grants
to
work
on
Solutions,
potentially
potential
Solutions.
N
Thank
you
so
when
I
say
web
centralization,
the
way
I
talk
about
this
I
usually
divide
the
room
and
what
I
want
to
say
is
I
want
to
start
off
with
a
bit
of
context
here,
first
and
I'm
not
sure
whether
this
picture
that
I've
picked.
There
is
actually
accurate
for
for
my
illustration
here,
but
I
want
to
show
you
basically
an
easy
path
and
a
difficult
path
to
the
same
goal
right
and
with
the
web.
I
get
the
impression
that
the
easy
path
leads
somewhere.
We
don't
want
to
be.
N
Sorry,
this
is
about
decentralized
Network
infrastructure.
I
tend
to
talk
about
distributed
a
lot
more
I'm
sure
all
of
you
have
seen
this
diagram
I
just
wanted
to
to
basically
bring
it
up,
because
if
I
talk
about
distribution,
that's
what
I'm
talking
about
the
the
this
one
here,
no,
the
rightmost
type
of
architecture.
N
My
my
view
here
is-
and
this
is
why
I
wanted
to
bring
this
up-
is
that
this
kind
of
this
video
network
doesn't
really
work
well
with
the
client,
server,
Paradigm
and
I'm
going
to
go
into
this
very
briefly
later
on.
Thank
you,
I,
don't
have
to
tell
you
what
the
web
is,
but
rest
is,
but
it's
kind
of
important
to
point
out
once
in
a
while
that
rest
and
restful
is
not
the
same
thing.
N
We
can
have
long
discussion
about
this
outside,
but
there
is
something
about
restful
that
tries
to
map
HTTP
methods
to
prod
style
operations,
and
that
is
actually
an
important
part
in
What.
I
want
to
talk
about
here.
Thank
you.
N
This
is
the
diagram
from
the
from
the
rest,
the
dissertation.
All
what
you
have
to
understand
here
is
basically
that
from
the
user
agent,
that's
on
the
left
hand
side
all
the
three
paths
lead
with
through
the
same
interface,
and
we
don't
need
to
know
at
all,
what's
going
to
happen
on
the
right
hand,
side
how
the
service
is
provided.
This
is
essentially
the
core
of
rest
that
we
have
an
abstract
interface
for
all
of
this.
N
So
web
centralization
I'm
I'm
a
bit
concerned
that,
because
HTTP
pre-assigns
the
client
server
roads,
that
means
it's
impossible
for
each
node,
that's
in
in
an
HTTP
environment
to
Route
Around
failures,
because
they're
already
either
waiting
for
something
to
happen
if
they're
a
server
or
they're
trying
to
reach
something
that
doesn't
happen
if
there
are
clients,
so
the
whole
idea
of
resiliency,
there
doesn't
really
work
well
with
the
client
server
model
and
I
think
this.
This
contributes
to
to
why
the
web
pushes
towards
centralization.
N
The
other
aspect
there
that
I
see
is
that
authentication
is
centralized
on
the
web,
centralized
not
in
the
sense
that
the
entire
internet
is,
you
know,
authenticated
in
the
same
place,
but
in
a
service
at
least,
and
that
means
that
the
endpoint
decides
also
how
data
is
is
may
or
may
not
be
accessed,
and
I
already
mentioned
that
this.
This
restful
approach,
that
maps
maps
crowd
style
operations
to
HT
methods
is
technically
not
how
rest
was
meant,
but
it
has
a
point.
N
Thank
you,
and
that
is
that
we
have
actually-
and
this
is
where
kind
of
the
core
of
what
I
want
to
point
out.
We
have
a
natural
mapping
of
these
methods.
I
think
this
is
why
this
has
become
so
popular.
We
have
a
natural
mapping
of
these
these
operations
to
some
to
most
of
the
HTTP
methods,
except
for
updates
and
one
of
the
things
that
that
I
realized
when
I
read
the
rest
destination
again.
N
Is
that
actually
it
says
there
that
the
the
whole
point
of
code
transfer
is
optional
now
called
transfer
is
optional
back
then
we
were
talking
about
Java
or
JavaScript,
but
nowadays
it's
JavaScript,
but
if
you
have
a
client
that
that
is
supposed
to
be
generic,
which
is
what
HTTP
is
all
about,
and
you
can
read
any
resource
it
can,
it
can
delete
any
resource,
can
create
any
resource
if
it
can't
update
it
without
getting
instructions
from
the
server
how
to
do
so.
N
Then
that's
those
instructions
does
that
code
and
the
data
become
an
entangled
method
that
you
can't
take
apart
anymore,
and
this
is
what
puts
control
over
the
data
with
the
server.
Thank
you
and
then
I
can
only
briefly
repeat
what
what
people
have
been
saying
before.
Basically,
there
are
economic
incentives
for
for
continuing
with
this
right.
I.
Don't
really
need
to
read
to
this,
but
except
that
that
you
know
the
natural
fit
of
all
Gathering.
All
this
data
is
surveillance,
Capital
capitalism,
which
which
is
a
problem
nowadays.
N
So
maybe
we
have
to
work
against
this
somehow
so
again,
I'm
coming
back
to
this
picture,
because
centralization
isn't
really
required
by
the
web
right.
Nothing,
nothing
in
the
web
requires
some
fertilizations,
but
I
feel
like
on
a
technological
level
the
incentives
already
stacked
towards
centralization.
So
the
question
for
me
and
for
us
this
is
I-
think
I
understand
why
Dirk
and
writes
me
to
this
group
is
how
can
we
maybe
make
decisions
that
push
into
the
opposite
direction?
Thank
you.
N
So,
from
my
point
of
view
and
I'd
love
to
hear
a
lot
about
this
from
you
guys,
you
know
more
about
this
than
me
is
that
we
already
have
solved
some
of
the
the
authentication
authorization
authentication
is
solved
in
quotes,
because
you
know
there's
tons
to
do
it's
just
the
prince
of
the
sound.
They
have
something
like
public
cryptography.
We
can
authenticate
people
without
needing
a
third
party
in
the
middle
authorization,
is
harder,
I'm
working
on
something
basing
capabilities.
N
There's
going
to
be
a
talk
about
power
of
attorney,
which
I
don't
know,
but
I
read
as
being
something
similar,
I'm
very
interested
in
the
talk,
so
I
think
there
are
ways
we
can
move
forward
with
approaches
that
don't
require
any
Central
components
in
a
web
architecture,
web-based
architecture
or
in
any
web-like
architecture.
For
these
parts
of
authentication
authorization
next
slide.
Thank
you
and
then
the
other
part
is
the
how
the
how
to
disentangle
this.
N
This
mess
of
data
and
operations
being
controlled
entirely
by
service
and
well,
from
my
point
of
view,
we
have
to
make
the
data
presentation.
That's
the
core
party
of
rest
know
that
the
data
is
representational
and-
and
that
is
what
drives
the
fact
that
the
service
can
control
how
to
modify
it.
We
have
to
make
this
an
end-to-end
problem
or
client
to
client
problem
right.
It's
it's
it.
N
It
should
not
be
a
client
to
serve
a
problem
at
all
and
if
we
just
default
to
just
default
to
end-to-end
encryption
and
then
that
that
takes
the
service
out
of
the
process,
we
have
data
artists
instead
of
services,
which
has
other
side
effects.
We
have
to
talk
about
those
at
some
point,
and
that
also
means
that
we
don't
really
need
all
these.
N
These
crowd
start
operations
anymore,
because
basically,
this
is
also
an
end
to
end
problem
at
that
point,
and
then
we
don't
need
much
of
the
web
anymore,
which
is
not
something
people
like
to
hear
and
what
I
see
a
natural
fit
for.
This
is
information
Centric
networking,
which
is
another
group
that
doc
invites
me
to
probably
because
of
this.
Thank
you
and
that's
it.
Thank
you.
Any
questions.
O
I'm
Rick
Moran
I'm,
responding
on
your
remark
that
the
web
is
centralizing
usernames
as
far
as
I
can
tell
by
tracing
back.
O
I
I
Colin
Perkins
I
fear
I
may
be
jumping
the
queue.
Apologies.
You
see
that
clients
server
sort
of
opposes
decentralization
yeah
I,
don't
disagree,
but
we
seem
to
have
very
distributed
service,
yeah
and
I.
Wonder
if
there's
you
know
so
it's
it's
opposing
decentralization
in
one
way.
Yet
we
can
build
massive
scale,
largely
distributed
servers.
So
this
is
clearly
a
middle
ground
somewhere.
N
There
is
a
helium
underground,
yes,
I
mean
what
that's
that's.
Why
I
mentioned
this
or
brought
up
this,
this
diagram
of
distribution,
I'm
talking
about
the
resilience
of
distribution
really
in
in
a
decentralized
system.
I,
don't
see
that
as
that
big
of
a
problem-
oh
you
don't
I,
don't
see
that
as
that
big
of
a
problem
in
a
decentralized
system
and
distributed
it's
it's
more
of
a
problem,
does
it
make
sense
yeah.
Thank
you
here.
B
Yes,
this
is
Duke
thanks
for
bringing
your
work
here.
So
maybe
could
you
maybe
explain
once
more.
So
what
is,
in
your
view,
the
problem
of
using
post
for
updates
and
what
other
say,
negative
consequences
that
are
stemming
from
that
and
what?
How
would
a
better
update
protocol
look
like.
N
Sorry,
I
probably
rushed
through
this
a
little
bit.
The
problem
with
with
with
using
post
is
not
not
posed
in
itself.
N
N
So
it's
a
very,
very
fundamental
feature
of
how
how
we
got
to
where
we
are
today,
in
my
opinion,
but
if
you
look
at
how
actually
any
any
update
request
to
to
web
services
being
made,
you
you
don't
have
the
standardized
HTTP
form
data
anymore
right,
my
smartphone
detailing?
Well,
it
doesn't
doesn't
nobody
uses
this
anymore,
except
for
very
small
use
cases?
N
What
happens
almost
exclusively
is
that
the
server
sends
some
data,
some
some
code
enrollments
to
the
clients
which
the
client
executes
to
form
a
request
that
creates
the
specific
representation
that
the
server
requires,
and
that
brings
control
over
updating
and
therefore
also
over
the
data
completely
to
the
server
side.
Does
that
make
more
sense.
D
Thanks
I'm,
going
to
close
the
queue
here
and
I'm
gonna
take
the
microphone
in
the
room.
Next
then
I'm
going
to
go
to
Lexia
and
then
I'll
go
to
Wolfgang.
So
please.
C
Your
point
about
authentication
is
a
good
opportunity
to
remind
everyone
that
the
driving
forces
to
centralization
are
not
only
economic
or
technical.
There
is
also
a
problem
with
the
users.
Some
users
may
be
most
users,
don't
want
to
face
the
internet
directly.
They
want
some
sort
of
intermediary
between
them
on
the
Internet
on,
for
instance,
for
authentication.
It's
a
good
example,
because
managing
your
own
private
key
is
odd.
It's
a
real
problem,
so
autumn
decentralized
authentication
through
public
key
cryptography
can
be
quite
dangerous
at
was
experienced
by
many
blockchain
users,
for
instance.
N
Don't
even
disagree
with
this
I
I.
Consider
this
a
user
experience
issue
right.
What
I
find
interesting
in
the
context
of
this-
and
this
is
just
an
observation-
is
that
in
in
Germany,
when
you
want
to
submit
your
taxes
electronically,
you
actually
have
to
handle
private
Keys
public
keys
and
somehow
it
hasn't
stopped
people
from
doing
so.
So
I
think
it
is
workable.
Yeah.
L
A
The
first
thing
I
want
to
say
is
that
I'm
so
glad
to
see
that
we
have
within
RG
as
a
platform
for
all
the
conversations
I
think
to
this
talk,
which
every
one
of
them
brought
up
different
views
different
perspective
after
this
meeting
I
think
we're
going
to
have
lots
of
discussions
on
the
on
the
Middle
East,
but
for
specific
questions
this
this
point
that
the
current
server
somehow
facilitated
is
a
centralization.
A
I
just
want
to
point
out
when
a
wipe
first
occurred
in
the
early
90s,
we
didn't
have
a
centralization
problem
for
many
years.
I
think
the
centralization
became
my
issue
only
in
the
last
I
think
less
than
10
years
it's
ever
increasingly
become
an
issue.
So
therefore
the
question,
whether
it's
really
the
protocol
design,
that's
a
major
factor
or
it's
some
other
major
factor
that
actually
has
been
driving
the
centralization.
N
I
I
think
sorry
should
I
answer
this
sure.
Okay,
thank
you,
I.
Think
it's
a
bit
like
the
nature
versus
nurture
debate
right.
You
have
to
have
both
factors
in
order
to
several
factors
in
order
to
to
come
to
a
certain
point
and
the
approach
could
design
certain
contributes,
I'm,
not
sure
and
that's
my
opinion.
N
Of
course,
right
I'm
not
sure
whether
it's
the
soul
cause
I,
think
what
happens
here
is
that
the
protocol
design
was
sort
of
a
little
bit
oblivious
to
how
the
economies
of
scale
would
work
in
back
when
it
was
done.
I
don't
know,
I
wasn't
part
of
this
right,
so
this
is
my
take
from
nowadays
and
then
the
economies
of
scale
came
in
and
decided
to
exploit
this.
A
It's
a
question
where
the
protocol
design
decides
distributed
or
centralized.
Take
the
DNS
Services,
as
example,
many
years
as
it
was
fully
distributed.
It's
only
in
the
recent
years
that
became
so
centralized
and
the
protocol
hasn't
changed.
Another
example
are
mail
services.
Many
years
the
individual
organizations
ran
their
own
mail
servers
and
SMTP
has
not
changed,
but
the
email
Services
got
banned,
a
large
centralized.
A
So
this
opens
the
question
whether
we
actually
can
change
the
protocol
design
as
a
way
to
mitigate
centralization,
but
more
specifically
to
your
question
with
regarding
to
the
client
I
think
a
client
URL
into
the
http
that
brought
up
two
questions.
The
first
is:
what
is
the
identity
for
clients?
Do
you
have
a
dance
name?
I,
don't
I'm,
pretty
sure
most
of
people
are
in
this
room.
A
A
In
the
last
question,
oh
comment:
you
mentioned
that
we
have
distributed
authentication
problem
solved,
solved,
yes,
I
think
authentication
actually
is
the
easy
part
again.
It
goes
back
to
the
harder
question
how
you
get
the
public
key
in
the
authentic
way.
A
A
Do
you
have
in
mind
that
everyone
get
a
certificate
from
the
cas
or
watching
the
fundamentally
different?
It's.
N
N
A
great
question:
I
I,
don't
have
an
answer
to
this.
I
have
a
I
have
a
thought
about
this,
and
this
goes
back
to
what
other
people
have
done.
It's
not
based
on
me.
N
N
There
is
another
approach
to
doing
this,
which
is
usually
called
a
patch
name
system
which
I
quite
like
is
that
if
I
receive
a
public
key
from
any
of
you-
and
you
tell
me
that
it's
Bob
then
to
me
that
is
Bob,
because
that's
what
I'm
being
told
and
I
can
base
my
trust
level
on
how
much
I
trust,
Bob
or
the
person
who
sends
me
this
key,
which
is
very
much
like
the
web
of
trust,
except
you
can
do
better
than
the
web
of
trust,
I,
think
and
I
think
for
very
very
many
contexts.
E
Okay,
we
really
must
distinguish
between
technological
centralization
and
economical
centralization,
because
Google
doesn't
run
one
big
web
server.
It's
has
a
decentralized
architecture,
I
guess
if
we
can
solve
the
economical
centralization
problem,
I
doubt
that
smart
point.
N
H
So,
thank
you.
In
fact,
there
was
a
lot
of
good
points
in
the
previous
interventions,
so
I
would
like
to
start
30
years
ago
when
I
started.
My
career
I
arrived
at
a
place
called
serum
and
when
I
open
my
office
in
the
office
in
front
of
mine
with
a
certain
team,
be
honestly
I
had
the
chance
to
witness
what
happened
and
I
promise
you
that
team
would
be
in
this
room.
He
would
hate
what
this
world
has
become
today.
H
So
from
a
layer
7,
we
are
now
moved
to
layer
eight,
because
some
parties
understood
oh,
we
can
evade
regulatory
scrutiny
by
creating
something
which
is
outside,
and
now
we
have
a
layer,
9..
So
the
issue,
in
fact
they
started
to
recognizes
that
we
are
Technologies.
So
we
like
to
speak
about
protocols,
but
in
the
way
you
present
it
it's
about
protocol,
design
and
I.
Think
we
forget
the
other
term
which
is
designed.
H
The
problem
we
face
is
that
when
we
create
technology
we
create
technology
on
something
where
there
is
zero
anthropology.
What
we
are
doing,
that
means
we
create
something
and
well,
let's
see
what
happens?
Let's
see
how
people
adopt
it,
but
it's
not
like
in
other
areas
like
civil
engineering,
civil
engineering,
which
actually
is
rather
recent,
but
when
you
trace
that
down
to
what
a
bridge
is
what
the
experience
of
a
road
of
a
building
or
something
it's
a
thousand
years
ago,
we
have
many
anthropologies
of
that.
H
So
when
we
do
things
here
is
from
what
we
do,
we
don't
understand
that,
from
the
technology
possibilities
might
infer
many
legislative
possibilities
that
might
infer
many
ethics
possibilities
that
will
end
up
with
anthropologies
ensures
that,
unfortunately,
for
us,
some
people
were
faster
to
understand
that
design,
piece
and
understood.
What
is
it
that
we
have
in
these
three
to
optimize
our
gain
and
they
fixed
that,
and
some
parties
here
wrote
about
that
that
it
created
a
very
narrow
murder
of
the
human
being.
H
That
could
give
a
framework
about
now
if
we
distillate
that,
against
this
view,
what
does
it
mean
then,
for
the
regulation
Parts,
the
economic
part
and
so
on
and
the
human
parts
we,
you
could
have
a
model
to
reframe
that
and
and
reposition
your
work
in
a
systematic
approach
across
your
work
then
as
well.
You
can
ask
yourself:
is
this
valid?
Is
this
good?
Is
this
so
others
can
other
people?
Other
communities
could
look
at
it
from
an
Ethics
perspective
from
an
anthropologic
perspective
and
say
actually
are
we
in
French?
H
We
call
that
La
fuzz
bonide
the
Fool's
good
idea.
It
looks
like
a
great
idea
when
it
started
distributed
and
so
on,
and
we
don't
think
about
this
River
of
unconscious
behind
us
about
all
of
these
layers,
because
we
think,
as
you
know,
I
am
who
I
am
54
years
old
made
white
blah
blah
blah,
and
maybe
somebody
would
have
a
very
different
idea.
H
N
D
So
Colin
and
Britta
I
did
close
the
queue
behind
our
note
but
I'm
happy
to
accommodate
you.
No
no
I'm
happy
to
accommodate
you
if
you
can
be
short,
I.
I
Will
be
very
short,
I
think
Colin,
Perkins
Licious
said
you
know
the
protocols
haven't
changed
and
therefore
that's
a
sign
that
we
can't
predict.
Perhaps
whether
the
protocols
will
drive
centralization
or
not.
I
M
So
here
I'll
be
very
short
as
well.
Thank
you
for
this.
You
mentioned
before
about
basically
the
Trust
on
first
use
model,
and,
although
that's
very
usable,
there's
also
a
huge
judgment
when
we
look
at
this
from
an
adversarial
side
and
really
when
we're
talking
about
the
space,
we're
trying
to
talk
about
improvements
on
both
the
usability
and
the
security
or
at
least
maintaining
the
security,
while
doing
that
correct
and
I
would
just
add
a
caveat
as
we
go
down
this
route
as
we
aren't
focusing
strictly
on
the
usability
improvements
that
we
don't
drop.
N
P
Okay,
hello,
we're
going
to
talk
about
power
of
attorneys
here
in
digital
form.
Here's
three
Lakshmi
she's
gone
around
most
of
the
presentation,
I'm
a
love
and
we
are
from
Lulu
University
in
Sweden.
P
P
P
So,
first
a
little
bit
about
positioning
and
a
motivation
here,
so
we
propose
this
power
attorney,
based
authorization
and-
and
the
second
bullet
here
is
important.
It's
really
to
authorize
entities,
for
example,
say
I
mean
autonomous
devices
or
it
could
be
non-physical
entities
too.
But
the
important
thing
here
is:
they
have
an
identity.
P
That's
the
whole
point:
you
can't
use
POA
unless
you
have
an
identity
for
the
other
party,
so
we're
going
to
look
at
at
fairly
powerful
things
here,
they're
called
agents
and
they
can
then
act
on
behalf
of
the
resource
owner
for
some
time
and
they're
called
the
principal
here,
the
one
that
is
signing
so
we're
using
like
public
key
signatures
here,
so
that
POA
is
signed
by
the
principal
and
using
the
public
key
of
the
agent
so
that
it
can
use
it
later.
P
Okay,
we
have
some
examples
that
we're
going
to
talk
about
like
onboarding,
for
example,
in
a
scalable
way
where
you
can
delegate
onboarding
privileges
to
others
right
the
outline
of
the
presentation.
We
just
go
ahead
and
present
it
now.
First,
because
there's
so
much
complementary,
Technologies
and
state-of-the-art,
like
all
often
other
things
that
would
be
caught
up
with
starting
with
comparison,
so
we
do
that
at
the
end.
Okay,
so
we
just
steam
ahead
next,
please.
P
P
Originally,
however,
we
can
have
it
supported
by
an
optionally
signatory
registry
that
can
store
poas
and
sign
them
to
increase
credibility,
there's
also
separation
in
time.
This
is
really
important,
so
you
can
sign
a
POA
today,
and
your
agent
can
act
upon
this
next
day
or
next
week
or
next
month.
The
POA
will
expire
at
some
point
in
time.
It's
written
into
it,
and
also
the
principle
may
not
be
online
or
available
when
the
agent
executes
on
the
POA.
P
So
this
is
clearly
different
from
like
single
sign-on
or
when
you
delegate
to
like
a
browser
app
or
something
one
while
you're
online
yourself,
okay,
so
we're
in
a
different
domain.
Here
we
also
enable
multi-level
sub-granting,
so
I
can,
for
example,
give
you
a
general
POA
that
you
can
onboard
devices
to
my
network
and
then
you
can
provide
poas
to
your
devices
and
they
come
one
by
one
show
the
general
POA
and
the
specific
POA.
That
is
more
restricted,
of
course,
or
you
could
delegate
all
your
credentials
right.
P
So
the
POA
includes
detailed
credentials
like
expiration
time
and
contain
also
could
contain
additional
Integrity
info,
for
example,
hash
of
the
hardware
hash
of
the
software.
If
you
want
to
ensure
that
POA
is
valid
only
if
this
guy
hasn't
changed.
J
Yep,
thank
you,
hello.
This
is
the
best
idea
of
what
is
power
of
attorney
based
authorization.
So
we
have
these
three
entities.
The
first
one
is
the
principal
and
this
agent
and
the
resource
server.
The
principal
is
the
one
who
generates
the
POA
and
then
he
or
she
can
send
it
to
the
agent.
J
The
agent
is
the
is
the
device
which
can
be
a
cyber
physical
system,
as
ulo
mentioned,
it
can
be
a
semi-autonomous
or
autonomous
device
and
we
have
the
resource
server,
so
the
poe,
which
is
generated
by
the
principal
and
transfer
to
the
agent.
The
agent
now
can
use
the
POA
for
to
act
or
to
work
on
behalf
of
the
of
the
principle,
and
it's
also
time
limited.
So
after
a
certain
time,
it
gets
expired.
So
we
we
have.
J
We
also
have
the
signature
registry,
which
is
nothing
but
a
database
that
you
can
use
to
store
metadata
or
POA,
which
is
an
optional
optional
thing.
So
the
basic
idea
is
the:
the
agent
now
can
work
on
behalf
of
the
principal
using
this
POA
next
slide,
please
yep.
J
So
this
is
our
approach
to
to
use
POA
for
onboarding
device
on
body,
so
we
actually
establish
a
trust
chain
between
the
different
entities
in
the
onboarding
process,
which
is
which
are
the
subcontractor,
which
is
nothing
but
the
owner
of
the
device,
and
we
have
the
the
device
and
then
the
network
on
the
target
network
onboarding
controller.
So
we
establish
a
trust
between
these
three
entities.
J
So
in
order
to
do
that,
how
do
we
do
this?
So
this
is
done
by
the
POA.
So
we
we
send
a
POA
between
the
the
onboarding
controller,
which
is
the
target
Network
on
boarding
controller
and
the
subcontractor
and
nether
one
which
is
generated
by
the
subcontractor
to
the
for
the
device.
So
it's
from
the
subcontractor
to
the
device.
J
So
these
are
the
two
pois
that
we
use
for
the
this
use
case
on
body
device
on
body,
and
these
are
the
different
properties
or
with
with
this,
we
can
achieve
more,
more
Administration
detail,
level,
scalability
and
security,
and
also
the
type
time
limit.
Limited
thing
that
I
explained
before
and
also
the
credentials
can
also
be
passed
through.
The
POI
and
law
management
overhead,
and
also
we
have
to
we-
we
we
the
ownership
of
the
device
it
is.
J
It
may
or
may
not
be
a
transfer
from
one
one
person
to
another
in
this
case,
because
the
subcontractor
is
the
owner
of
the
device
in
this
case,
so
there's
a
contract
doesn't
really
need
to
transfer
it
to
another
another
entity,
another
person
so
yeah
next
slide.
Please
Yep.
This
is
the
protocol
flow.
We
have
the
subcontractor,
and
this
is
the
onboarding
component
and
the
First
Step
A
and
B
are
the
two
poets
I
mentioned
earlier.
The
first
one
is
the
on
on
the
POA,
that's
generated
by
the
onboarding
component.
J
That's
sent
to
the
subcontractor
so
that
the
subcontractor
right
now
can
now
from
now
on
can
work
on
behalf
of
the
onboarding
component,
which
is
nothing
but
on
an
onboard.
Then,
after
that
the
subcontractor
or
the
principal
now
generate
another
POA
for
the
device.
So
after
getting
receiving
the
that
POI
from
the
subcontractor,
the
device
now
can
onboard
so
step
us
a
C
and
C
A
and
B.
J
It's
the
the
device
is
sending
these
POA
along
with
some
other
onboarding
credentials
to
the
network,
onboarding
component,
so
it
or
as
usual
it
verifies
everything
and
or
it's
sent
to
a
certifying
Authority
and
then
there's
a
CA
verifies
and
then
send
back
a
certificate.
J
It
is
this.
This
can
change
according
to
the
use
case.
So
in
this
use
case,
yes,
we
have
a
CA
and
with
the
certificate,
along
with
the
certificate
and
other
network,
onboarding
credentials
are
sent
to
the
subcontractor,
the
principle
yeah.
That's
that
protocol
flow.
Maybe
next
slide,
please
Yep.
This
is
how
the
PO
looks
like
it's.
J
We
implemented
it
as
a
Json
web
token,
so
the
body
the
body
have
the
public
keys
of
the
agent,
the
principal
and
the
resource
owner,
which
is
that
which
can
be
the
target
Network
or
onboarding
onboarding
controller,
and
we
have
that
a
Time
expiration.
The
important
another
property
is
the
transferable.
The
transferable
is
nothing
but
the
one
that
ulo
mentioned.
We
support
multi-level
other
authorization,
which
means
from
One
agent
to
another
region.
You
can
even
transfer
the
POA
so
that
they
can
also
do
it
do
their
own
body.
J
So
that's
the
transferable:
it's
just
a
parameter
in
it's
an
integer,
so
it's
like
0,
1
2
depends
on
the
value.
You
can
the
number
of
levels
it
is
yep.
So
next
slide,
please
yeah,
so
we
could
implement
it
as
a
library
like
an
open
source
Library.
We
have.
We
have
that
and
also
Feature
work
like
we
have
a.
We
can
do
it
as
a
Docker
image
or
another
interesting
implementation
is
the
integration.
J
That
is
that
we
have
done
next
slide
this.
So
we
we,
this
is
how
we
can
integrate
with
the.
M
J
So,
as
you
can
see
the
the
principal
the
agent,
these
are
the
two
entities
that
we
took
from
the
POA
part
and
others
are
from
the
oil.
So
the
principle,
the
agent
is
here
a
device
as
I
mentioned
earlier,
it's
it
can
be
a
semi-autonomous
or
autonomous
device,
and
we
send
the
the
POI
is
only
one
POI
in
this
in
this
case
that
sent
generated
by
the
principal
and
sent
to
the
device
yeah.
So
that's
how
we
integrate
next
slide.
Please
yep!
That's!
So
that's
already
done
work.
J
The
future
work
is
to
implement
a
Docker
image
and
and
also
security
analysis
of
the
of
the
proposed
work
next
slide.
Please.
J
The
last
one,
oh
yeah,
so
yeah
we
have
our
draft
the
it's
available
and
the
source
code
for
the
library
that
I
mentioned
it's
also
available
in
the
GitHub
and
the
oil
po
integration
part.
We
have
submitted
a
paper,
but
it's
not
yet
published
so
yep
yeah.
So
that's
a
code
for
that
is
also
available
in
the
GitHub.
So
if
you
have
any
comments
and
questions,
okay,.
D
Thank
you
for
that
presentation.
I'm
going
to
entertain
people
I
have
three
people
in
the
queue
so
far
and
I'm
going
to
start
with
wixia.
But
here's
a
reminder:
please
introduce
yourself
and
your
affiliation
when
you
come
to
the
mic.
A
P
A
J
Yeah,
it's
we,
a
mutual
authentication,
is
done
by
our
certificates,
so
right.
J
P
Yeah
it
is,
there
is
a
trust
chain
in
the
beginning,
for
example,
there's
often
a
trust
in
in
subcontractors.
Basically,
so
that's
you
only
give
poas
to
stuff
that
you
trust.
A
Goodness,
I
just
remember
those
questions.
My
second
question,
which
is,
which
is
how
do
you
see
this
work,
relates
to
the
you
know
the
goal
of
this
group
how
this
relates
to
centralization
or
mitigating
centralization,.
P
N
Yes,
hi
Jensen
Kaiser.
Thank
you
for
this.
This
is
pretty
much
exactly
what
I've
been
doing
as
well,
so
I
think
we
should
talk.
The
only
question
I
have
is:
have
you
considered
explicit
verification
at
this
point
because
it
might
issue
a
POA
and
then
decide?
Actually
that's
not
longer
no
longer
what
I
want
to
do.
J
Yeah
poets
time
limited
so
after
certain
time
it
get
expired,
and
so
it's
it's
basically
the
principal
who
who
generates
the
POI
and
decide
how
many,
how
long
it
need
to
need
to
be,
for
example,
how
long
the
task,
how
long
the
task
will
take
take
time,
how
long
it
will
be
so
the
principal
assume
that
one
and
then
put
that
now
as
a
number
in
the
in
the
poi.
N
Yeah,
that's
that's
also
how
I
started,
but
you
might
issue
a
POA
that's
valid
for
a
week
and
in
that
week
something
happens
and
you
no
longer
want
to
issue
it.
So
you
can't
really
take
it
back
anymore.
Once
it's
given
out
that's.
P
Why
I'm
saying
No?
This
is
a
very
good
point
and
it's
a
central
as
as
long
as
you're
decentralized,
it's
the
same
with
public
keys
right.
How
do
you
revoke
them?
Make
sure
that
it
doesn't
reside
anywhere
like
in
in
the
community,
so
actually
adding
some
centralization
there,
like
the
the
repository,
could
help
in
revocation.
But
that's
your
point.
Okay,.
L
There
are
Ronald
Bliss,
curity
same
point:
revocation
certificates
are
quite
easy
unless
you
consider,
revocation
that
makes
it
much
more
complex
and
that's
just
you.
You
made
my
point
thanks.
Yeah.
B
Yeah
just
quickly
and
thanks
a
lot
for
bringing
this
work
to
linaji
I
just
want
to
point
out
that
you
got
some
really
good
questions
in
the
in
the
chat,
and
so
we
won't
have
time
today
to
answer
all
of
those.
But
we
recommend
looking
at
those,
and
maybe
we
can
follow
up
on
the
main
list.
B
P
D
And
we'll
we'll
tend
to
capture
them
for
the
notes
for
the
meeting
as
well.
Okay,
thank
you
both
very
much.
Thank
you.
O
Hello,
my
name
is
Rick
foreign
we've
been
working
in
a
group.
Sometimes
we
call
it
upper
two.
Sometimes
we
call
the
internet
y
project,
but
we
we
work
on
decentralization
for
a
few
years.
Much
of
what
we've
done
is
actually
already
technology
and
it's
it's
running
code.
So
that's
a
bit
concrete
for
a
research
group,
but
there
are
what
we
found
when
we
talk
to
different
protocol
groups.
Always
we
need
to
tell
the
entire
story,
because
there's
a
big
story
behind
it
and
that's
what
we'd
like
to
present
here.
O
The
economy
is
one
of
the
starting
points.
We
also
had
the
economy
economy
of
skill
is
and
and
if
definitely
there,
but
we
do
have
a
strong
belief
in
hosting
profiles
because
we
do
see
people
find
it
quite
normal
to
pay
a
few
Euros
a
year
of
pounds
whatever
to
a
hosting
provider
and
get
some
basic
services
for
it,
and
they
sometimes
do
that
together
with
an
email
servers
with
Gmail,
for
example,
with
Yahoo
and
all
the
hosting
providers
have
limited
resources,
I
mean
they
generally
do
just
a
few
protocols.
O
We
believe
that
when
they
get
together,
they
together
form
a
very
good
counter
voice
for
the
few
very
large
silos
that
that
we
are
having
now
and
what
we
came
up
with,
and
that's
just
how
we
see
things
is
hopeful
discussion
is
thus
we
we
believe
it's
helpful
to
take
the
hosting
providers
and
consider
two
different
roles
for
them,
either
in
the
same
or
in
different
parties,
and
one
of
them
would
be
an
identity
provider.
O
Apologies
covering
things
like
dnsack,
Dane
and
identity,
provisioning
and
the
other
would
be
a
service
provider,
and
it
might
be
a
web
service
provider
might
be
an
email
provider
or
sip
or
XMP
I,
don't
care,
but
they
would
be
plugins
to
each
other
thanks
to
open
protocols.
This
is
very,
very
well
possible
and
without
all
protocols
is
pretty
much
impossible,
so
it
very
much
aligns
with
the
way
we
do
things
in
the
ITF
I.
Think
next
slide.
Please.
O
So
I'll
basically
already
mentioned
what
we
believe
the
thing
two
things
should
do
and
how
do
you
get
these
two
together?
Well,
there
are
some
technical
detail
like
what
host
names
are
going
to
be
used.
What
IP
addresses
need
to
be
assigned
so
the
way
we
envision?
This
is
a
Surface
provider
publishes
and
I
can
probably
an
XML
file.
That's
pulled
into
the
identity
provider,
which
it
says:
oh
hey,
dear
user,
we
just
got
a
new
contract
for
you.
This
is
the
Privacy
conditions.
O
Those
are
the
costs
that
are
going
to
be
charged
and
so
on
and
so
on.
Do
you
agree
with
all
that
and
if
that's
the
case,
there's
some
form
of
acknowledgment
going
back
and
from
that
time
on
there's
a
contract
between
the
identity
provider
and
service
provider
that
serves
as
plugin
into
the
DNS
page,
it's
published
with
Dina
sectane
TLS,
all
those
things
that
are
needed
and
the
big
issue
we
believe
it's
it's
been
called
solved.
I,
don't
think
when
you
get
to
the
details.
Authentication
is
completely
solved,
but
we've
been
looking
into.
O
How
can
we
trust
an
identity
from
another
domain
given
existing
protocols,
because
that's
what
we
get
into,
then
you
run
up
to
your
server.
It
might
be
just
as
a
plug-in
server
and
the
identity
provider
belonging
to
to
the
same
domain
might
be
running
somewhere
else.
There
needs
to
be
some
form
of
a
trust
relationship
both
when
you
address
your
own
server,
like
your
own
IMAP
server,
for
example,
or
when
somebody
else
runs
up.
O
Maybe
to
your
SMTP
service,
says:
I
want
to
authenticate
before
I
deposit
it
before
I
can
launch
an
email
towards
you,
so
Trust
basically
becomes
the
the
Central
Point.
We
usually
take
a
new
new
term
so
that
we
don't
get
into
conflict
with
existing
terms.
So
we
coined
term
realm
crossover
and
we've
identified
three
technologies
that
cover
many
many,
if
not
all,
not
all,
but
most
protocols,
and
especially
the
modern
ones.
O
Cecil
is
the
Paramount
one.
It's
just
about
anywhere
just
name
a
protocol
and
probably
does
it
and
Kerberos
has
its
own
protocols
every
now
and
that's
a
bit
older,
usually
nowadays,
it's
it's
in
comparison
to
social,
but
some
protocols
do
require
Kerberos
and
we
found
realm
Christoff
Technologies
for
both
and
certificates,
of
course,
are
a
common
common
facility.
That's
being
used
so
I'd
like
to
get
into
these
three
and
how
we
envision
that
these
can
be
can
be
used
without
making
many
changes
at
all.
So
next
slide,
please!
O
Oh
yeah,
it's
also
it's
there
already
so
for
Sasso,
which
is
pretty
much
everywhere
already.
Social
has
mechanisms
that
you
can
just
very
easily
create
new
new
mechanisms.
For
so
we
we
designed
one
that's
called
sxo
plus
and
what
that
does.
Basically,
it's
an
end-to-end
wrapper
for
for
that
encrypting
end-to-end
wrapper
for
a
novice,
Sasso
mechanism
runs
inside
of
that,
and
you
know
the
best.
The
best
way
to
shows
with
the
next
slide,
I
think
with
with
just
a
small
image.
O
So
imagine
a
protocol
client
using
an
identity
provider
of
his
own
domain
and
accessing
a
server
that
has
never
heard
of
that
domain
before.
Basically,
what
it
does
is.
It
starts
an
end-to-end
S6
over
plus
service
and
the
nice
thing
of
acetalk
plus
it
mentions
the
domain
as
whom
the
client
wants
to
authenticate.
So
the
foreign
server
can
forward
that
message
to
the
identity
domain
for
the
client
and
basically
it
starts
bouncing
back
and
forth
these
these
encrypted
packets.
O
Without
knowing
what
goes
on
until
the
identity
domain
reports
back
it
says:
hey
I
got
the
user
ID.
You
know
my
domain
name,
you
verified
it
with
DNS,
SEC
and
Dane
and
TLS,
and
whatever
I'm
the
one
who
can
now
vouch
for
a
username
underneath
that
domain-
and
here
you
have
it
now,
you
have
a
user
domain
name
kind
of
identity,
and
the
interesting
thing
is
Sasol
is
flexible.
O
It
can
negotiate
a
mechanism
so
as
soon
as
this
is
supported
on
the
client
in
the
server
it
can
do
just
about
can
work
for
just
about
any
protocol,
given
that
the
software
also
has
the
flexibility
to
take
all
the
mechanism.
Of
course,
we
didn't
need
to
change
any
of
the
existing
protocols.
That's
the
nice
thing.
They
are
used
as
they
are
I'm
at
XMP.
No
changes.
O
Oh
yeah,
sorry!
So
what?
If
we
change
this,
we
use
diameter
between
the
form,
server
and
and
the
identity
provider.
We
only
need
to
Define
three
different
address
value
pairs
for
the
token
for
well
a
few
few
simple
things
and
we
needed
to
Define
this
new
Cecil
mechanism,
and
that
was
it
since
we
got
started.
We
also
added
subtle
to
http
we're
presenting
that.
O
Actually,
next
Friday
in
the
HTTP
based
group,
it's
proving
to
be
battle
because
HTTP
is
well
they're,
afraid
that
browser
manufacturers
will
be
will
be,
will
feel
threatened
by
it
and
that
sort
of
thing
but
I,
think
there's
many
use
case
with
this
is
really
useful.
O
We
have
it
working
by
the
way
we
have
a
plugin
for
Firefox,
it's
just
an
independent
JavaScript
bit
of
code,
and
we
have
this
working
and
we
have
it
on
the
server
side
for
Apache
for
nginx.
So
this
stuff
really
works.
O
Actually
you
can
add
it
to
add
the
two
pen
module
for
studio
and
containers
and
that
sort
of
thing
Kerberos.
Another
story:
cobras
actually
already
does
realm
crossover.
If
you
get
a
ticket
or
if
you
ask
for
a
ticket,
you
could
get
a
reference
back
and
that
reference
basically
says.
Oh
I,
don't
know
about
the
host
you're
asking
for
the
surface,
go
and
ask
that
one
and
you
continue
sending
your
tickets
requests
to
the
other
server.
O
Normally,
a
KDC
will
only
do
that
if,
if
it
has
a
pre-arranged
key
between
the
two
candies
she's,
the
client
can
see
the
surface
KDC
and
all
we
had
to
do.
There
is
have
the
kdcs
to
show
the
realm
controls.
The
identity
controls
for
the
realm
only
had
to
make
those
communicate
and
exchange
your
key.
O
Since
that
only
means
a
change
at
the
Domain
level.
It
means
that
the
client
doesn't
have
to
change.
Clients
can
already
do
this
because,
generally
they
follow
follow
up
on
these
instructions,
so
we
Define
a
protocol
for
the
kg
to
KDC
exchange,
and
initially
it
was
not
safe
to
specify
this
host
belongs
to
that
Kerberos
realm
in
DNS,
but
we
have
DNS
Tech
now,
so
we
can
now
safely
do
that.
So
we
made
a
drop
for
that
as
well,
so
basically
Kerberos
with
Dynamic
ROM
crossover.
O
We're
actually
also
here
talking
about
the
TLs
mode
that
does
cobras
together
with
Diffie
hellmann
diffie-hellman
for
the
the
freshness
of
the
secrets
and
covers
for
having
something
that
can't
be
detected
with
a
quantum
computer.
So
the
two
really
form
a
very
good
Bond.
O
So
that's
the
Kerberos
variant
now
for
certificates.
There
are
two
two
ways:
officially
ldap
is
supposed
to
be
used
for
for
storing
certificates
and
now
that,
given
the
domain
has
a
standard
DNS
as
of
E
Record,
where
you
can
find
it
so
and
there's
the
the
format
of
searching
for
the
objects
for
a
certain
user
under
a
given
domain
are
also
pretty
much
standardized.
O
So
it's
quite
quite
clear
how
you
can
look
for
an
identity
there,
x59
certificates,
as
well
as
PTP
keys,
can
be
stored
in
there
under
your
own
domain
name
and
your
own
control,
or
at
least
at
your
own
identity
provider,
the
guy
you're
paying
for
for
doing
it
properly.
The
way
you
want
it
done
and
I
think
most
people
now
using
the
silos
have
given
up
on
on
privacy
on
account
of
apathy.
I
can't
do
anything
else,
don't
know
what
to
do.
O
I
think
it's
important
to
have
other
options,
and
this
is
one
of
them.
Something
else
we're
going
to
talk
to
during
this
conference.
I
think
is
in
the
dance
group
which
does
client,
Dane
I'm
a
modern
dancer,
so
I
very
much
look
forward
to
going
there.
O
The
client
Dean
basically
could
also
basically
just
have
a
root,
say
ca
for
a
given
domain,
announce
it
in
the
under
DNS
SEC
security
and
basically
State
whatever
this
thing
signs
is
going
to
be
a
valid
client
underneath
this
domain,
so
that
will
be
yet
another
way
of
assuring
the
security
of
the
of
the
client
identity.
O
I
think
it
was
more
like
yeah
there's
many
more
slides
because,
as
I
said,
we
have
specifications,
we
have
a
block
actually
and
and
a
lot
of
code,
so
there's
plenty
to
play
around
with
it's
better
sort
of
level,
but
you're
quite
welcome
to
play
with
it
and
feedback
whatever
you
want
to
share
about
it
and
plus
this
is
sponsored
by
the
ngi
pointer
project
as
well
as
Nomad.
O
The
European
Union
likes
this
kind
of
Direction,
because
it's
very
much
in
line
with
the
gdpr
and
the
Privacy
consideration
that
the
European
Union
has
maybe
there's
also
something
political
like
we
don't
want
to
hand
over
or
control
to
America
I,
don't
know
about
that,
but
the
European
Union
definitely
likes
this
kind
of
this
line
of
work.
Okay,
thank
you.
Any
questions.
Thank.
D
You
are
there
other
slides.
So
when
you
download
this
presentation
from
the
research
group
meeting
materials
you'll
see
the
other
slides.
So
thank
you
for
that
questions.
Comments.
A
Okay,
I
do
have
a
question,
but
I
think
another
discussion
has
to
go
on
to
the
Middle
East.
Now
I
didn't
figure
out
exactly
how
this
across
realm
trust
relation
gets
established.
M
B
B
Yeah,
thank
you
Mark,
okay
yeah.
This
was
a
pretty
interesting
meeting
so
far
with
many
diverse
topics
and
I.
Think
a
kind
of
nicely
reflects
like
the
broad
spectrum
that
we
have
in
the
group
and
so
I'm,
not
sure
you
notice,
but
the
Charter
text
that
we
have
on
the
dinner
G
data
tracker
site
is
a
little
bit
outdated,
and
so
we
thought
now
could
maybe
could
be
a
good
time
to
revise
this
and
say
better
formulate
what
we
actually
want
to
get
out
of
this
group.
B
What
could
be
say,
outcomes
what
could
be
good
ways
of
working,
and
this
is
what
we
want
to
get
out
of
this
discussion
now.
So
so
this
and
I
have
thought
a
little
bit
about
this.
But
so,
of
course
we
didn't
want
to
preclude
too
many
things.
So
this
is
just
a
discussion
starter
and
we
hope
to
get
some
feedback
today
and
during
the
week
and
then
also
at
this
side.
Meeting
on
on
Wednesday
that
mentioned
yeah
next
slide,
please
yeah
right.
B
So
the
the
current
energy
Charter
was
developed
several
years
ago
when
there
was
yeah
lots
of
interest
in
essay
decent
flashing.
Technologies
specifically,
and
so
it
covers
a
really
broad
spectrum,
including
you
know,
decentralized,
apps
and,
and
all
these
things
and
yeah
over
time,
I
think
we
all
gained
a
bit
better
understanding.
So
what
could
be
used
for
contributions
in
this
ietf
irtf
environment?
B
What
are
really
depressing
issues,
so
I
think
we
learned
this
really
well
also
through
these
workshops
that
we
had
so
the
last
year
workshop.
For
example,
if
you
haven't
seen
the
the
report,
I
highly
recommend
checking
that
out,
and
so
we
had
seen
like
also
today
like
the
different
types
of
presentations.
So
now
people
talking
about
the
like
problem
analysis
right,
so
you
know
what
how
does
how
is
Canon
simulation
be
characterized?
How
can
it
be
measured?
B
Perhaps
we
also
had
this,
but
then
also
say
some
more
architectural
thoughts.
So
what
could
be
say,
technical
reasons?
Of
course
we
know
that
there
are
many
economical
reasons,
as
we
also
discussed
today,
but
then
sometimes
we
also
like
today.
We
get
interesting
proposals
that
fall
under
the
fall
into
this
this
topic,
and
so
we
thought,
okay,
let's
think
a
bit
about
what
could
we?
How
could
we
structure
this
work
next
slide?
Please
so,
maybe,
first
of
all,
we
should
probably
talk
a
bit.
B
B
So
what
Lisha
mentioned
earlier
is
that
I
think
we
are
in
a
really
good
position
here
and
I
have
a
good,
really
good
opportunity
to
yeah
make
the
energy
the
the
place
in
the
say,
internet
ITF,
ITF
Community,
where
we
would
discuss
internet
centralization
and
the
corresponding
problems
and
threats,
but
potentially
also
do
something
about
it,
but
I
mean
first
of
all,
there's
of,
as
we
have
also
seen
today.
B
There's
still
lots
of
interest
and
and
also
need-
and
we
assume
in
you
know,
analyzing
things
further
and
pointing
out
the
the
problems
further
and
so
on,
and
so
we
think
that
that
that
should
definitely
and
continue,
and
we
should,
you
know,
keep
on
going
basically
and
perhaps
trying
to
formulate
some
some
intended
outputs
so
like
what
could
be
these
useful
insights.
So
what
could
be
useful
recommendations
and
maybe
also
what
could
be
technology
components
that
we
may
be
able
to
to
offer?
B
And
yet
so
so,
before
doing
this,
we
think
we
should
continue
like,
for
example,
talking
about
measurements
and
analytical
work
on
the
existing
internet
and
then
also
create
this
base.
This
base
of
knowledge
and
explore
Technical
Solutions
for
say
doing
things
differently
or
facilitating
decentralized
system
development,
and
so
one
question
is
also
a
little
bit.
What
is
the
audience
of
of
our
work
or
what
are
the
consumers
of
our
great
ideas
and
I
mean
private?
So,
first,
firstly,
of
course
we
are
in
the
internet,
ITF
iitf
community,
so
I.
B
We
assume
that
we
could
make
useful
contributions
here,
but
then,
in
this
particular
topic,
there's
also
the
question
you
know:
could
other
bodies,
other
actors
somehow
pick
this
up
and
you
know,
learn
something
from
our
work.
So
we
are
thinking
about
basically
providing
input
for
our
Regulators,
for
example.
B
So
not
in
terms
of
you
know
telling
them
what
to
do
but
say
giving
them
say:
better
information,
maybe
also
explaining
better
technical
alternatives
to
to
certain
aspects
of
so
topics
that
we
have
seen
today,
for
example-
and
so
this
is
this
was
our
like
first
list
of
objectives
that
we
came
up
with
and
then
next
slide.
Please
we
thought.
Okay,
maybe
we
could
you
know
just
to
explain
better
what
we
are
doing
and
also
maybe
structuring
the
activities.
B
A
bit
say
assume
we
have
like
like
two
main
strengths
in
our
work
so,
like
maybe
one
is
more
analytical,
so
characterizing
centralization,
assessing
it
and
so
on,
and
also
the
the
the
consequences
that
are
associated
and
then
maybe
a
second
strand
would
be
then
more
on,
say
the
exploration
of
a
decentralized
systems,
application
design,
and
so
here
of
course,
we
also
had
this
discussion.
I
think
today,
in
the
chat
I
saw
that
so
what
do
we
actually
mean
by
that?
B
So
that
clearly
needs
to
be
so
we
would
have
to
explain
this
better
in
the
in
the
in
a
complete
Charter,
and
so
we
think
decenteration
is
a
lot
about
decentralizing
control,
Power,
and
so
we
have
decentralized
systems
that
are
technically
decentralized,
but
not
from
a
control
Power
perspective,
and
this
seems
to
be
the
main
issue,
and
so
we
would
so
for
the
shadow
discussion.
We
need
to
clarify
this,
but
from
a
topic
perspective
yeah.
B
We
think
that
this
could
host
like
experimental,
Solutions,
experimental
work,
maybe
also
some
say
continuous
work,
say
developing
something
like
a
specification
if
we
find
like
a
particular
technology,
this
really
really
important
and
but
also
yeah
having
a
bit
this.
B
You
know
space
where
we
can
exchange
ideas,
for
you
know
developing
future
elements
of
the
internet,
but
perhaps
not
only
the
internet
but
also
the
web,
so
I
think
we
should
also
be
able
to
discuss
this
in
in
this
group
here
and
I.
Think
you
have
another
slide
if
you
can
just
write,
and
so
what
we
thought
is
okay,
we
could.
B
B
I,
don't
think
this
should
be
defined
top
down,
so
we
we
are
seeing
many
many
good
ideas,
and
this
needs
to
be
Community
a
German
thing,
and
we
need
to
eventually
identify
things
that
we
we
deem
important
enough
or
interesting
enough
and
yeah.
So
we
would
certainly
continue
like
inviting
relevant
research
presentations
like
like
today.
B
Like
you
said,
just
you
know,
open
up,
New
Horizons
or
just
give
us
new
ideas
that
could
help
us
identifying
future
work
and
for
our
meetings
like
today,
I
was
mentioned
three
strands
there,
but
so
I
mean
we.
We
can
be
fairly
flexible,
how
we
run
it.
So
we
sometimes
we
may
have
like
workshops
that
focus
on
one
very
particular
topic.
B
B
We
think
it
will
be
good
if
we
could
identify
research
communities
and
relevant
groups
we'd
like
to
work
with,
and
so
here
we
are
also
hoping
a
bit
to
get
more
suggestions
from
from
the
group.
B
Also
so
not
only
in
terms
of
topics,
but
also
you
know
co-locating
meetings
and
so
I
think
that's
something
we
definitely
want
to
do
so
meeting
also
outside
the
iitf
iitf
Cycles,
and
so
this
is
what
we
had
prepared
so
far,
so
we
deliberately
kept
it
on
this
level
and
we
didn't
think
it's
worthwhile
to
discuss
lengthy
shutter
text
at
this
point
and
so
now
we'd
like
to
open
the
floor
for
our
comments,
feedback,
better
ideas.
D
D
Thank
you.
Dirk
I'd
like
to
open
up
the
floor
for
questions
or
comments
about
this
I'm,
going
to
be
rude
and
insert
myself
in
the
queue.
D
Okay
and
Lexia
wants
to
go
too
that
folks,
in
the
front
of
the
room,
I'll
take
the
prerogative
of
controlling
the
slides
here
for
a
moment,
yeah.
D
Asked
a
couple
questions
here
in
terms
of
objectives
and
I
I
just
want
to
make
three
very
quick
comments.
The
first
was
you
asked
about
the
audience
for
the
work
that
comes
out
of
dinrg
and
I.
Think
I
think
it's
possible
that
the
entire
Community
can
benefit
from
the
work
that's
going
on
here
and
by
that
I
mean
that
some
of
the
work
that
comes
out
of
dinrg
can
inform
work
that
goes
on
in
the
ietf,
but
I
also
think
that
some
of
the
work
that's
going
on
here
can
inform
work.
D
That's
going
on
in
the
IAB,
so
I
think
that
there's
actually
the
the
audience
is
quite
broad
for
the
work
that's
going
on
here.
You
said
Dirk,
you
said
something
really
interesting
in
your
slides
about
measurement
and
in
fact
it
appears
on
this
slide
and
then
measurement
appears
on
this
slide
as
well.
In
the
second
bullet
and
I.
H
D
Don't
we
don't
want
to
duplicate
that
work?
I.
Think
that's
really
important.
My
my
third
comment
is
is
about
your
last
slide.
I
think
the
two
strands
are
pretty
interesting
and
I,
while
I'm
very
interested
in
centralization
and
the
effects
that
it
has
on
the
internet
and
on
the
the
internet,
ecosystem.
I
think
the
measurement
part
is
just
as
important
and
so
I'm
going
to
on
the
mailing
list,
I'm
going
to
make
suggestions
around
that
I
promise.
That
I
would
only
have
three
comments,
but
my
fourth
comment.
D
My
fourth
comment
is
that
anyone
who
has
been
interested
in
this
has
taken
a
look
at
the
dinrg
charter
and
you'll
find
that
it's
very
long.
It's
it's
one
of
the
longest
Charters
I've
ever
seen
and
I
I
think
some
editing
needs
to
go
on
there
and
focused
on,
like
you
said
in
your
third
slide
on
the
objectives.
So
that's
just
one
person
comments
I'm
going
to
go
to
elixia,
then
Mallory,
then
Arnold,
okay,.
A
I
think
everyone
need
to
limit
the
comments.
I'll
do
myself
two
minutes.
First
of
all,
you
mentioned
about
input
into
IB.
That's
actually
exactly
what
I
wrote
down
there
I
think
that
we
should
develop
a
topics
for
future
workshops
and
there
could
be
potential
suggestions
to
view
workshops.
This
is
a
very
important
problem
area.
A
My
second
thing
is
regarding
the
measurement
I
think
the
measurement
research
group
is
perhaps
more
into
the
methodologies
of
measurement
and
for
this
group
fundamentally,
we
want
to
decide
what
we
want
to
measure
to
demonstrate
the
factual
things
about
centralization.
What
have
been
centralized,
how
much
has
been
centralized?
We
need
those
kind
of
a
harder
evidence
as
a
potential
input
into
the
future
regulations.
A
Policy
makers,
because,
like
I
mentioned
earlier,
in
a
talk
that
personally
I
do
not
believe
Technical
Solutions
alone
well,
can
completely
address
the
centralization
problem,
which
has
economy
of
skill,
the
big
factor
as
a
big
Dragon
Force.
A
My
third
thing,
adding
into
the
charter
region,
is
that
this
group
should
produce
documentations,
helping
the
entire
Community
to
fully
understand.
You
know
the
the
problem
space
like,
for
example,
marks.
The
taxonomy
I
think
is
a
great
starting
point
to
Define
the
terminologies
characterize
the
centralizations
in
the
different
sub
domains
whatever
so
that
we
have
the
responsibility
to
actually
articulate
and
clarify
the
entire
problem.
Space
not
like
currently
I
think
we
have
a
broad
trading
that
internet
get
decentralized,
I
mean
I,
think
we
need
to
go
more
qualitative
and
quantitative
as
well.
D
Okay,
Mallory,
let
me
let
you
have
the
microphone
and
then
our
note
after
you,
you
have
to
push
our
node
out
of
the
way
is
what
you
have
to
do.
H
O
Q
Hey
everybody
Mallory
Noodle
from
the
center
for
democracy
and
technology,
so
I
actually
remember
the
first
time.
I
came
to
one
of
your
meetings,
it
was
in
London
and
it
was,
however,
many
years
ago
that
was
what
2018
and
at
the
time
I
was
super
interested
in
it,
because
I
knew
folks
from
UCL
who
came
with
their
work
around
a
distributed,
Ledger
technology
and
I
was
you
know,
working
with
someone
there
at
the
time
and
I
I
thought
I
think
we
all
thought.
Q
Maybe
then
that
the
distributed
Ledger
technology
and
the
blockchain
and
all
that
was
going
to
solve
a
lot
of
interesting
problems,
or
at
least
attempt
to
I
was
I,
would
I
would
be
proud
to
call
myself
a
skeptic
even
back
then,
but
I
wonder
how
much
of
this
major
and
I
would
call
this
like
a
major
shift
in
Charter
and
mandate
has
to
do
with
two
things.
One
is
the
word
distributed
is
very
ambiguous.
It's
been
used
in
a
lot
of
different
ways.
Q
Q
I
don't
want
to
knock
it
down,
but
I
think
there
was
a
lot
of
Promise,
then
that
this
would
be
a
really
rich
space
for
the
ietf
and
the
irtf
in
particular,
to
research
and
we're
not
seeing
maybe
as
much
of
that
and
so
I
think
those
two
Trends
mean
that
there's
been
a
lot
of
Charter
creep
and
I.
Just
wish
there
were
I
would
ask.
Maybe
this
is
a
request
instead
of
just
ranting
about
it,
maybe
ask
for
folks
who've
been
involved
in
this
work.
Q
A
lot
more
consistently
than
I
am
I
have
been
to
connect
the
dots
a
little
bit
more
explicitly
between
blockchain
stuff
and
solving
consolidation
and
competition
and
centralization
of
the
internet,
because
those
are
really
there's
a
bunch
of
space
in
between
those
things.
For
me
still
I.
A
H
Yep,
very
quick,
in
fact,
it's
very
strange
for
the
first
time
Mallory
we
agree
on
something
so
I
have
the
same
issue:
yeah
I
think
there
is
a
methodology
issue
between
connecting
the
dots
and
I
I
would
I
would
urge
that
you
don't
have
two
problems
to
resolve
quickly
like
measurements
and
the
other
one,
but
you
need
to
have
a
methodology
that
assumes,
if
you
would
have
enough
analytics
and
they
would
be
good
and
you
should
have
enough
data
on
a
number
of
things.
So
how
does
it
connect
to
centralization?
H
So
again,
my
point
is
that
maybe
you
could
look
at
another
part
which
is
not
here,
which
is
the
design
issue.
How
does
design
influences
up
to
the
other
Associated
issues
you
have,
including
the
centralization
piece
and
going?
You
know
for
me
speaking
going
other
areas
than
our
area,
because
I
don't
think
we
in
I.T,
Telecom
and
so
on
are
going
to
give
the
answer
in
history.
H
You
can
see
a
number
of
things
in
other
societies
in
the
20th
century,
where
people
tried
things
on
the
real
good
intention
and
it
failed,
because
the
leaders
realized
what
it
would
create
at
the
upper
level.
So
go
back
to
design
look
at
what
is
the
theory
of
design
look
at
how
it
is
influencing
up
to
society,
legal
ethics,
anthropology,
Society
and
so
on,
and
you
will
find
many
examples,
and
this
could
help
you
to.
H
This
is
how
you
connect
the
dots
and
then
you
can
put
all
the
materials
you
want
to
attach
that
methodology.
That's
my
feedback!
Thank
you.
Okay,
okay,.
I
Colin
Perkins
I
think
there's
a
bunch
of
really
nice
ideas
for
and
I
think
there's
a
basis
for
a
really
nice
restructuring
of
the
chart.
So
here
what
strikes
me
is
that
it
the
the
way
this
is
written
reads
like
some
internet
measurement
protocol
people
wrote
it
and
I
suppose
that
makes
sense.
Since
you
are
internet
measurement,
protocol,
people
there's
not
perhaps
as
much
focus
on
economics
or
societal
issues
and
understanding
those
aspects
as
the
prevalent
domain
might
require.
I
E
O
D
B
Yeah
so,
first
of
all,
thanks
a
lot
everybody.
It
was
really
good
feedback
and
the
points
are
really
taking
so
well.
I
I
got
I,
understood,
Mallory's
points
and
Collins
points,
so
that
was
exactly
the
plan,
so
we
just
we
just
put
this
out
now
to
get
this
kind
of
feedback,
and
so
responding
to
Colin
also
is
especially
on
this.
B
A
more
constructive
elements
of
of
the
work
and
I
mean
we're
not
in
a
rush
here
right,
so
we
can
really
take
time,
discuss
this
in
in
a
like,
orderly
way
and
then
get
out
something
that
is
really
really
useful.
B
So
what
we
are
going
to
do
now
is
collect
the
feedback
today
and
analyze
it
and
follow
up
on
it
for
for
this
Wednesday
meeting,
and
so
we
hope
that
and
then
make
the
next
say
more
concrete
proposal
of
this,
and
we
hope
that
many
of
you
can
can
make
it
to
that
meeting
and
then,
let's
just
continue
working
on
this.
B
Thank
you
very
much.
It
was
a
great
meeting
thanks
everybody
for
bringing
their
work
and
for
the
really
good
discussion,
also
in
the
chat
I
really
enjoyed
that.
Thank
you
very
much.