►
Description
Internet Threat Model (Model-t) Program Meeting, 2020-02-14
A
B
Yeah,
so
we
have
been
discussing
exactly
how
to
progress.
This
work
in
terms
of
organization
and
I
don't
want
to
take
up
too
much
time
at
the
top
of
the
call
for
this
point,
because
we
have
some
actual
technical
stuff
to
discuss
that's
more
interesting,
but
we
would
like
to
get
organized
slightly
more
than
we
are
and
sort
of.
Currently,
the
the
situation
is
that
we
have
this
very
informal
way
of
working,
which
is
I,
think
great
and
exactly
matches
this
situation.
B
B
B
It's
maybe
a
little
bit
bad
as
well,
and
Steve
and
I
have
discussed
this,
and-
and
we
also
discussed
with
the
IAD
and
basically
seemed
to
us
that
work
should
continue
in
this
exploration,
mode
and
informally.
For
now,
we
would
like
to
have
some
organization.
You
know
whether
that's
a
working
crew,
workout
I
mean
a
working
group
lot,
the
IAB
program,
something
else,
but
if
we
had
something
like
that
and
the
practicalities
would
take
care
of
themselves,
maybe
visible.
B
There's
a
link
on
the
slide.
If
you
can
see
my
slides
now,
I
know,
but
there's
a
link
to
the
github
page
with
their
folder
I.
Don't
want
to
show
the
whole
thing
here
on
the
slide,
but
I
have
a
slight
previous
versions
just
to
go
through
the
main
points.
So
the
idea
here
is
to
have
an
IEP
program
and
you
IB
program
there'll,
be
an
open
menu
analysis
of
the
fed
model
situation
and
it
would
produce
a
potential
update
to
CP
72
would
better
match
the
reality
today,
as
we
see
it,
of
course
is.
B
B
So,
if
you
want
to
do
you
know
a
lengthy
description
of
situation
or
analysis,
then
that's
probably
separate
document,
so
we
might
produce
also
background
materials
and,
of
course,
since
we
are
talking
about
things
like
we
trust
these
or
those
endpoints,
there's
probably
going
to
be
different
trade-offs
in
different
people's
minds,
and
the
idea
here
is
not
to
dictate
that
yeah
forever
will
prefer.
You
know
these
end
points
over
others
or
whatever
silly
thing
that
somebody
might
think.
Rather,
it's
just
to
call
attention
to
for
the
protocol
design.
Is
that
hey?
B
You
have
to
think
about
these
things,
we're
not
the
ones
to
our
be,
therefore,
for
decisions
like
what's
what's
more
important
this
or
that,
but
one
has
to
consider
these
things
as
well
as
protocol
design
and
I
would
hope
that
there's
interest
in
this
you
know,
regardless
of
your
particular
perspective,
on
some
trader.
That's
interesting,
noting
that
this
is
a
consideration
and
one
final
thing
about
the
sort
of
practical
things,
so
this
would
be
indeed
open
program
open
to
all
interested
parties.
B
Not
all
IAB
programs
have
been
like
that,
but
this
this
would
need
to
be
like
we
are
currently
and
we
have
a
mailing
list,
as
you
know,
announce
our
meetings
publicly.
We
would
only
do
this
for
six
months
at
the
beginning,
it's
not
supposed
to
be
a
like
a
for
a
program,
and
then
they
expect
it
out
it's
basically,
this
potential
suggestion
for
the
IETF
for
a
change
and
then
some
supporting
supporting
documents-
I,
don't
know
if
Stephen,
you
want
to
add
anything
to
the
proposal.
At
this
point.
C
Hi
Thank
You
Ari.
Yes,
it
was
just
a
quick
comment
because
you
are
I
used.
The
word
trust
which
is
which
is
fine
it.
It
always
rings
a
small
bell
when
I
hear
it
you
know.
Do
we
trust
this
endpoint,
because
at
some
point
in
the
document
we
will
have
to
make
clear
and
to
be
fair.
It
may
already
exist.
I
have
to
make
clear
what
we
mean
by
by
trust
there,
and
usually
it's
simply
a
matter
of
completing
the
phrase.
B
C
D
C
No,
no,
it's
not
not
news,
but
if
we
are,
if
we're
trying
to
describe
a
threat
model
and
we're
touching
it
in
terms
of,
for
instance,
a
reduction
in
the
extent
to
which
we
feel
we
can
trust
endpoints,
all
I'm
saying
is
that
we
should
probably
specify
what
it
is
that
we
are
trusting
endpoints
to
do
or
not
do,
and
that
may
be
as
general
a
statement
as
this
endpoint
cannot
be
trusted
to
to
fulfill
the
function
you
expect
of
it.
Well,.
D
D
The
purpose
of
this
exercise,
which
has
been
going
on
for
quite
some
time
now,
which
is
to
update
the
threat
model
in
some
ways
that
it
produces
an
adequate
I'm
trying
to
understand
well
in
what
way
this
is
supposed
to
be
like
what
light
and,
what's
like,
like
I've,
heard,
a
lot
of
talk
about
how
like
somehow
the
situation
is
different
and
then
points
are
less
trustworthy
and
I'm
going
to
figure
out
what
is
supposed
to
be
news.
In
this
conversation,
you.
B
Item
I:
don't
we're
saying
that
there's
a
new
person
I
mean
in
theory.
All
of
this
is
well
known,
but
I
think
there's
a
new
situation
in
sense
that
perhaps
in
the
past
getting
communication
security
right
was,
you
know
hugely
important
now,
when
that's
in
a
lot
of
case,
it's
much
better
handled,
and
we
have
some
other
issues
to
tackle
and
alerting
people
to
the
fact
that
hey
in
protocol-
and
you
also
have
to
consider
these
these
aspects
that
that's
the.
D
B
Opinion
is
that
the
current
text
in
3552
so
seems
to
discourage
the
you
know,
thinking
two
months
into
the
these
issues
and
I
would
rather
change
that
text.
I
I'm,
not
asking
for
a
huge
change.
I've,
also
recognized
that
you,
like
you,
commented
on
the
mailing
list.
I
think
that
there
are
other
other
topics
that
you
would
like
to
change
in
3552.
If
you
had
a
chance
not
suggesting
that
those
would
not
be
principal
changes
either
perhaps
be
changed.
D
Okay,
well
I
guess
I'd
like
to
understand
what
people
think
that
means,
because,
like
I,
think
the
text
there
is
correct,
which
is
to
say
that
the
situation
is
essentially
hopeful
to
an
end
point
is
how
washed
and
hung,
and
so
like
I
guess,
I
I
feel
this
is
me
going
for
some
time
that
I've
heard
this
argument
may
try
to
be.
But
you
owe
people
a
number
of
times
and
try
understand
what
actual
text
change
you
want
to
make
because
like
if
you
think
that
chess
is
incorrect.
D
B
E
F
D
D
Yes,
yes
and
then
I
guess
very
occasionally.
We
worry
about
things
like
case
filtration
versus
non
case
filtration,
but
like
these
are
like
Oh
like
I
mean
this
is
getting
very
deep
into
white
I
got
some
very
deep
technical,
like
come
tech
stuff.
That
is,
you
want
to
make.
Do
you
want
to
talk
about
a
case?
You
guys
wasn't
you
want
that
PCs
and
people
PFS
like
what
you
you
want
to
make
sorry.
A
B
A
Think
we
could
make
proposals
that
would
fill
tens
of
pages
of
text,
but
I
don't
think
that
would
be
useful,
so
I
think
the
challenge
for
me
teams
is
to
try
and
see.
Is
there
something
that
we
can
reduce
and
make
it
generic
enough
that
it
would
be
useful
but
I,
I
I,
don't
think,
there's
a
problem
with
saying
that
there
you
could
add
an
awful
lot
more
to
that
one
paragraph:
that's
in
BCP
72
today.
A
B
Actually
did
send
at
the
top
of
the
call
a
proposal
for
three
different
options,
like
you
know
this
very
minimal
thing,
essentially
a
single
sentence
and
another
chain,
or
that
and
some
additional
things,
or
a
very
lengthy
guideline
about
stuff,
like
like
some
of
the
things
that
you
talked
about
a
cur
appeal
and
so
forth,
but
I'm
more
on
the
minimal
side.
Personally,.
B
B
And
I
think
that's
largely
the
plan
and
maybe
there's
been
too
much
emphasis
on
on
the
words
on
on
the
update.
I
think
the
analysis
part
is
is
equally
important,
but
I
think
that,
like
the
core
of
the
question,
I
mean,
of
course
the
situation
is
that
the
consider
noncoms
COMSEC
issues,
that
that
is
the
primary
advice.
B
D
Guess
like
maybe
it
may
be
helpful
to
actually
think
of
an
example.
It
is
not
this
or
a
10.1
which
here,
from
my
perspective,
probably
the
major
like
the
major
change
in
the
environment
on
the
past
ten
years
has
been
I've,
been
the
sort
of
the
rise
of
commercial
surveillance
to
be
a
web.
Cracking,
that's
probably
the
biggest
like
understated
change
that
we
didn't
understand
that,
even
when
you
understand
like
the
dole
of
young
model
like
it's,
not
what
you
would
have,
but
he
would
not.
D
Otherwise
that
was
gonna
happen
and
like
I,
think
that
would
be
really
good
materials
like
what
would
we
say
about
that.
D
A
A
I
Correlating
data
visible
only
across
many
different
flows.
So,
if
you
think
about
the
communication,
security
on
a
per
flow
basis,
you'll
be
missing.
This
class
of
attacks
and
I
think
that's
something
that
we
we
definitely
can
explore
and
I
think
it's
very
difficult
in
that
situation.
To
think
about
what
the
abuse
is,
because
the
the
attack
itself
is
the
the
data
leakage
and
then
what
somebody
does
with
the
attack
is
the
abuse
and
I
think
that's
or
what
somebody
does
with
leaked
data.
D
Maybe
years
I
made
this
point,
the
sharp
initially
so
it
should
be.
But,
like
you
know,
the
dole
of
your
threat
model
assumes
like
complete
access
and
it
work
everywhere
on
the
network.
So,
like
I
mean
it's
like
not
okay,
yeah,
like
I'm,
understand
like
how
much
people
think
the
duration
has
changed
as
how
most
people,
when
the
text
is
not
good.
For
example,
people
think
they're
like
material,
but
we
now
we
have
to
cover
like
those
are
like
all
the
different
things
and
like
I
guess,
maybe
you're
I
had
a
conversation.
B
D
Right
because
in
there
like
one,
could
imagine
writing
like
a
page
and
a
half
about
like
how
web
tracking
works
and
how
it's
a
privacy
threat
and
like
how
you
think
about
that
and
reason
about
that.
When
you're
building
systems
and
like
that
will
be
like
a
very
appropriate
like
piece
of
material
for
someone
for
someone's
on
boron
and
if
it
got
filled.
Yet
the
appropriate
material
for
this
forum,
because
I
will
help
me
guide.
My
banking.
B
Yeah
I
think
that
that's
a
topic
and
the
similar
things
that
that
could
be
dealt
in
an
analysis
document
I
think
there
might
be
some
people
who
think
that
we
should
go
download
material
in
you
know
35:52
type
document
I'm,
not
one
of
those
persons.
I
I
only
want
to
change
the
emphasis
there
a
little
bit.
It
seems
to
discourage
currently
some
of
the
avenues
for
for
issues
and
I'd
like
to
change
that
personally,.
B
But
if
I
try
the
discussion
on
the
organization
piece,
then
I
didn't
hear
a
lot
of
objections
for
this
IAF
I
did
hear
discussion
about.
Do
we
focus
on
on
the
analysis
and
gathering
data
and
advice,
and
so
on
versus
this
3552
thing?
That's
that's
all
very
game
for
discussion.
So
maybe,
if
somebody
screams
the
organization
part
go
ahead
and
then
we
would
actually
move
forward
in
this.
This
call
to
the
technical
discussion
which
we
in
practice
have
already
been
having.
So
even
how
would
you
like
to
continue
the
that
part
I.
A
A
I
guess
the
expected
output,
so
we
have.
We
talked
a
bit
about
possible
updates,
PCP,
72,
I,
think
other
documents,
perhaps
on
the
nature
of
the
kind
of
when
you
mentioned
about
web
tracking,
could
be
good
outputs
and
whether
we
produce
RFC's
or
just
into
a
trance
that
wither
away
kind
of
justify
or
try
to
explain
or
explore
threat
models.
I
think
there's!
You
know,
there's
scope
there
for
explanatory
kind
of
material.
A
That
would
be
just
too
verbose
and
too
specific
for
PCP
72
and
that's
like
most
of
the
text
in
the
draft
Gary
and
I
wrote
so
I
guess
I'd
like
to
ask:
do
people
feel
that
they
would
work
on
these
kind
of
outputs?
And
let
me
ask
that
in
Vancouver,
bunch
of
people
said
yes
and
the
holidays
happened
and
not
much
happened
on
this
topic.
A
So
is
this
a
reasonable
set
of
things
on
which
to
try
and
get
us
to
work
and
again
just
another
point:
I
think
as
I've
kind
of
a
mode
of
operation
I
think
it
would
be
horrifying
for
people
that
work
independently
and
later
on.
We
can
see
how
much
the
formality
there
is
and
whether
document
to
be
marriage
or
whatever
I,
don't
think
we
could
be
trying
to
just
work
on.
One
document
at
this
point
does
not
set
of
expected
output
like
a
useful
thing.
D
On
this
sort
of
like
72
and
new
threat
level
question
and
like
but
I,
don't
see,
but
I
don't
like
that
seems,
but
I
just
got
a
little
bit
like
the
thing
I
think
is
most
interesting,
which
is
like
actually
explaining
what
the
implications
are
in
the
current
environment
is
like
not
that
discussion
so
like
so
like
no
I,
don't
think
this
is
I.
Think
focusing
updates
at
72
is
like
the
most
important
thing
is
wrong
back
then
right
in
to
do
this.
D
Focus
on
actually
describing
the
threat
environment
and
then
includes
not
just
threaten
all
the
little
what
people
are
actually
doing
in
the
world
and
and
then
once
we've
done,
that
we
can
determine
whether
or
not
some
updated
video
is
required
and.
A
A
D
C
J
So
this
is
all
beginning
to
sound
to
me.
Like
a
you
know,
listening
to
all
the
issues
in
the
planes
and-
and
you
know,
it
sounds
almost
like
a
program
that
a
lot
of
people
think
is
too
big
and
I-
think
that
one
of
the
easiest
ways
around
that
would
be
to
structure
the
charter
or
whatever
we
call
the
program
text
such
that
it
really
becomes
sort
of
a
phased
type
approach
right.
J
If
you
want
to
concentrate
on,
let's
define
the
environment
first
and
then
come
back
and
figure
out
how
to
update
you
know:
BCP
72,
with
with
a
model
afterwards,
I
think
that
sounds
like
a
really
good
approach,
but
I
would
search
her
the
bullets
that
way
so
that
we
walk
through
stuff
and
maybe
included
an
example
on
you
know.
If
the
web-based
example
is
a
good
one
to
start
thinking
about
include
that
is
a
such
as
to
try
and
get
a
more
structured
flow.
J
D
I
guess
my
perspective:
what's
happened,
is
that,
like,
like
you
know,
we
have
sort
of
a
set
of
we
have
a
set
of.
You
know
underlying
assumptions
that
you
know
people
historically
made
about
the
way
that,
like
that's
the
reason
of
security
and
then
two
things
have
happened,
one
is
for
the
operating
environment
in
which
those
assumptions
have
to
be
a
clause
like
change
radically
from
135
to
two
is
read
both
in
terms
of
you
know,
the
rise
of
the
web
and
the
rise
of
cloud
computing
is
a
centralized
and
decentralized
operation
or
I.
D
Guess
me
centralized,
but
but
but
my
commitment
to
distributed
the
same,
you
know
the
weight
of
us
is
that's
the
first
thing.
The
second
thing
is,
we
got
a
much
clearer
understanding
of
how
to
actually
reason
about
the
security
poverty
of
the
system,
just
formulas
first
principles,
and
that
goes
back
to
life.
You
know
it's
things
like
PC
@pf
assets
like
billions
from
this
is
written
and
TCS
million
dollars
that
are
all
just
written
and
things
like
append
only
logs
and
like
just
had
a
reason
about
those
things.
D
I
think
those
are
the
two
things
in
life.
Is
it
really
changed?
I'm
like
actually
like
you
know
when
you
call
it
threat
level
or
not,
really
really
could
do
with
some
explanations:
we're
cooler
they're,
clearly,
not
probably
Rises
I
mean
we're
in
contemplate,
so
it
reminds
that
those
are
the
things
it's
like.
I
would
like.
If
we're
gonna
do
something
I
would
most
like
to
seek
it
out
in
the
table
because
it
actually
helps
more
people
reading
it
might
be
like
hey.
D
D
Yeah
I'd
be
willing
to
the
two
things
I'm
going
to
do
is
I'm,
going
to
write
up
like
I'm,
going
over
some
material
on
like
web
tracking,
a
page
or
two
and
I'm
going
to
write
up
a
page
or
two,
though
I'm
actually
gonna
try
to
draft
Chris
to
help
me
with
this
come
on.
You
know,
sort
of
like
modern
reasoning
about
protocol
security,
especially
based
on
things
again
find
compromise,
but
also
based
on
thinking
about.
D
Like
you
know,
you
know
how
we
like
how
we
reason
about
what
the
statements
do
we
want
to
make
about
security.
I
think
you
know
it's
pretty
clear,
like
certainly
just
elaborate
that
for
one
second,
if
I
really
clearly
like
the
way
we
designed
TLS
one
three
and
the
way
we
design
emls
like
radically
different
way
to
like
you,
know,
I
sentry,
three
or
a
slang
word
azide
and
they
come
out
of
prison
principles,
a
different
operation
and
other
things,
people
people
we
benefit
from
knowing
so
I'm
like
I,
would
like
right.
D
A
Okay
and
then
just
trying
to
put
on
a
little
bit
I
mean
who
else
on
the
call
who
was
either
asked
the
meeting
of
Vancouver
or
not
or
sorry
in
Singapore
or
not
or
wasn't
things
that
they
would
be
able
to
work
on
something
along
these
lines.
Let's
say
between
now
and
and
Cooper,
noting
that
the
deadline
for
dead
drafts
is
March,
9th
I.
A
That
was
Chris.
Thank
you
and
yeah
Robin
says:
does
work
on
the
reviewer
comments,
I'm
assuming
everybody
would
comment,
probably
but
more
I'm,
more
assume
asking
who
would
write,
text
or
update
drafts
and
so
I
think
yeah.
You
already
put
up
the
list
of
things
that
we
said
in
Singapore.
I
think
it'd
be
good
to
know
how
many
of
these
might
be
updated
between
now
and
Vancouver.
A
K
I
A
C
A
H
H
This
is,
this
is
Jim
one
thing:
that's
maybe
a
little
bit
orthogonal
to
all
of
this.
That's
been
kind
of
a
sore
point
with
3552,
for
me
is
that
people
put
normative
requirements
in
there.
I
would
like
the
security
requirement
section
to
be
just
descriptive
of
the
protocol
that
was
previously
described
and
not
try
and
put
normative
apartments
and
they're,
just
because
I'm
afraid
that
they're
going
to
be
missed.
D
A
A
H
A
B
Certainly
agree
with
your
sentiment
a
at
least
personally,
but
I
also
I
could
even
that
this
is
probably
outside
our
scope.
We
could
deliver
some
suggested
text
for
one
technical
thing
for
for
the
IETF
if
the
IETF
wants
to
update
a
full
RFC
and
take
care
all
all
issues-
and
that's
that
seems
like
a
another
task
interest
in
this
technical
aspect
here.
D
D
I
Think
one
of
the
things
that
that
is
probably
in
the
category
of
the
people
who
know
this
know
it
very
well,
but
the
people
who
don't
know
this
don't
realize
it's
common.
Is
that
there's
it's
very,
very
common
right
now
for
there
to
be
more
than
one
routing
plane
involved,
not
just
at
the
there's
MPLS,
encapsulating
your
IP,
but
the
service
function.
Chaining
has
kind
of
radically
altered
how
flows
travel
in
a
lot
of
situations
and
I.
I
Don't
think
that
has
a
bunch
of
implications
for
the
COMSEC,
but
it
does
mean
that
if,
if
you
have
any
illusions
that
something
about
your
path,
selection
is
protecting
you
from
anything,
you
are
almost
certainly
wrong.
Who
is
your
visibility
into
the
path?
Selection
is
almost
certainly
limited
to
one
of
those
routing
plans.
I,
don't
think
that's.
D
I
So
it's
it's
something
I've,
you
know
when
you,
when
you're
thinking
about
routing
security,
part
of
the
problem
is
how
do
you
work
out?
What's
the
interaction
among
the
routing
security
at
sort
of
service
function,
chaining
levels
and
at
MPLS
or
or
IP
layers,
because
the
interactions
among
them
are
controlled
by
different
parties
and
often
the
person
who
manages
the
service
function.
Chaining
doesn't
have
any
control
over
the
the
IP
routing
as
an
example,
or
vice
versa.
So
there's
definitely
a
thing.
I
M
E
I
think
in
this
field
in
general,
we
try
to
differentiate
between
miss
routing
interference
with
routing,
etc,
etc
and
gaming.
The
routing
protocols
themselves
and
I
think
some
of
the
some
current
work
is
the
latter
and
is.
I
E
Part
of
let's
try
it
from
the
tasks
level.
Part
of
what
we
would
ask
of
a
protocol
is
protection
against
it
being
gained
in
a
service
chaining
situation,
though
I'm
fear,
I'm
just
descending
to
a
thousand
meters.
I,
don't
want
to
really
get
into
details,
but
all
I'm
saying
is
differentiate
between
misusing
the
protocol
and
the
protocol
itself
having
a
problem,
that's
being
attacked.
B
That's
one
of
the
things
that
is,
but
I
think
we
can
agree
very
easily
that
the
attack
surface
for
for
this
routing
type
things
has
increased
significant.
So
previously
we
had
essentially
one
or
a
couple
eat
the
cure
systems,
and
now
we
have
many
and
and
they're,
also
differentiated
in
different
ways
in
the
control
of
other
parties.
So
so
the
surface
has
increased
both
in
terms
of
what
layer
it
is
and
what
technical
part,
but
also
in
terms
of
you
know
whose
hands
it
is
in.
C
So
this
kind
of
comes
back
to
a
question
I
put
in
the
chat
little
earlier,
which
is
whether
I
mean
up
until
now
lost
the
discussion
has
been
about
endpoints
and
untrustworthy
endpoints,
and
this
this
is
more
about
untrustworthy
intermediary
points.
Isn't
it
and
therefore,
whether
you
can
build
a
trustworthy
service?
If,
for
the
sake
of
argument,
you
trust
the
endpoints,
but
you
don't
trust
any
of
the
points
in
between.
C
B
Seems
to
be
covered
by
existing
things
to
a
large
extent
and
IIIi
guess,
because
you're
homesick
and
because
denial
service,
we
knew
that
that's
a
possibility.
Of
course
I
mean
this
is
an
interesting
case
of
an
intermediary.
It's
not
like
your
typical
firewall,
but
it's
just
that
infrastructure
is
more
complex
and
error
prone
today.
That
was
perhaps
in
the
past
and.
C
B
So
so,
in
that
sense,
the
this
some
of
these
attacks
do
translate
to
endpoint
constraints
as
well,
but
I'm,
not
sure
they're,
very
different
from
other
concerns
with
endpoints
that
you
could
also
have
a
virus
and
therefore
your
your
thing
might
and
might
actually
work
the
way
that
you
were
expecting
it
to
work.
Yeah.
C
That's
interesting
so
I'm
Yuri,
another
thought
about
that
is
I
noticed
in
some
of
the
working
groups,
there's
quite
a
lot
of
relatively
recent
attention
being
paid
to
information,
centric,
networking
and
or
trusted
content
networks,
where
there's
more
processing
going
on
at
the
nodes
to,
for
example,
build
a
reputation
profile
for
a
particular
route
or
a
particular
node
in
a
route.
Sorry
route.
C
So
so,
looking
at
this
the
other
way
around
one
approach,
this
group
might
be
to
look
at
the
the
risk
assessment
or
the
the
requirements
expression
by
those
trusted
working
or
trusted
content,
networking
groups,
sorry
information,
centric
or
trusted
content.
Networking
groups
to
see
whether
we
think
their
requirements,
analysis
and
risk
assessment
make
a
sentence
and
whether
they
are
covering
things
that
we
hadn't
thought
of,
or
whether
we
thought
of
things
they're
not
covering
I.
G
Yeah
and
you
think
of
a
useful
answer:
hey
so
Robin
I
think
these
are
really
interesting
questions
so,
for
example,
also
the
mabe
so
they're
two
things.
So
one
is
so
if
you
had
a
more
say,
empowered
forwarding
model.
What
would
that
change
in
the
relationship
of
endpoints
and
networks
and
then
the
other
question?
G
What
are
the
also
potential
additional
risk
that
you
introduce,
but
honestly
I
think
this
is
way
beyond
the
scope
of
this
discussion
here
and
then
there
are
many
interesting
research
questions,
but
really
that
would
mean
a
much
longer
running
IB
program,
I'm,
not
sure
we
should
go
into
this
year.
I'm.
C
B
Think
it's
useful
for
us
to
look
at
things
in
the
sense
of
like
if,
if
we
are
missing
something,
but
I
also
hope
that
if
we
do
some
dinner
on,
you
know
what
kinds
of
things
should
we
consider
in
designing
protocols
that
we
are
not
in
charge
of
applying
that
to
every
working
group
that
that
should
be
the
working
groups
asked.
Hopefully.
C
It
seems
to
me
to
crop
up
again
and
again
is:
if
you,
you
change
something
about
the
way
the
network
works.
So,
for
instance,
if
you
place
more
reliance
on
information,
centric,
networking
nodes,
for
instance,
do
you
open
up
new
ways
in
which
the
network
infrastructure
can
be
gamed,
and
are
you
therefore
changing
the
basis
on
which
you
trust
the
way
that
the
network
behaves.
G
Yes
and
on
the
other
hand,
well
there's
basically
this
trade-off
in
a
sense
that
if
you
empower
the
network
to
do
more
useful
things,
but
also
mean
potentially,
you
have
you
relying
less
on
overlay
functionality,
which,
in
some
people's
thinking
is
also
say
one
of
the
problems
in
the
end
of
discussion
in
these
days.
On
the
other
hand,
well,
if
you
have
more
functionality,
you
also
probably
need
to
have
more
information,
more
say,
visibility
into
some
metadata
or
something,
and
this
could
again
lead
to
other
threats.
So,
but
it's
it's
it's
a
long
discussion
there.
G
N
C
A
A
A
J
K
This
is
a
leak
I
think
when
we
talk
about
privacy,
it's
a
huge
scope
but
I
think
what
would
be
significant
or
protocol
designers
is
to
be
aware
of
threats
to
privacy
and
that
when
they
design
protocols,
they
should
be
conservative
in
collecting
data
and
minimizing
the
exposure.
That's
the
kind
of
general
guidance
which
I
think
is
referred
to
already
in
the
existing
text,
but
we
could
try
to
emphasize
that
without
going
into
the
trust
topics
too
much
specifically
for
protocol
designers,
because
a
lot
of
things
are
a
lot
of
privacy.