►
From YouTube: IETF-MODELT-20220405-2000
Description
MODELT meeting session at IETF
2022/04/05 2000
https://datatracker.ietf.org/meeting//proceedings/
A
Hey
guys
and
welcome,
we
will
get
started
in
a
few
minutes.
Let's
give
people
some
time
to
join
in.
I
think
we
had
10
plus
ish
people
agreeing
that
this
time
would
work
for
them.
It
didn't
work,
unfortunately,
for
everybody,
but
let's
wait
a
few
minutes
to
make
sure
that
everybody
who
will
come
is
here
actually.
A
Yeah
maybe
this
is
this
is
actually
who
we're
gonna
get
actually
recon
did,
and
so
there
was
10
people
signing
up,
and
I
know
one
of
them.
Martin,
unfortunately,
could
not
make
it,
because
some
other
things
came
up,
so
nine
that
we
have
now
is
actually
what
we
should
have.
So
I
think
we
are
complete
from
that
sentence.
A
A
Thank
you
for
joining,
and
I
don't
have
a
huge
agenda
for
this
meeting.
It
was
basically
just
to
go
over
two
separate
areas
of
work
that
we've
been
discussing
since
december,
and
one
area
was
this:
what
we
call
the
principal
documents?
These
are
documents
that,
for
instance,
the
iab
has
published
in
in
recent
years
that
talk
about
some
aspect
of
internet's
evolution
and
then
discusses
some
some
guidelines
or
recommendations.
What
we
need
to
do
in
order
to.
A
D
Yeah
yeah,
that's
right
so
hi
everyone
I
sent
around
notes
earlier
today
about
our
january
meeting.
I
did
update
my
own
draft,
but
I
think
when
we
get
around
to
talking
about
it
yari,
I
think
my
draft
isn't
really
along
the
lines
that
we
agreed
in
january,
and
so
even
though
I
did
update
it
and
I
really
updated
it
in
front
of
113.
C
A
A
If
we
go
to
the
principles
documents.
I
guess
I
guess
the
the
feeling
is.
Is
that
there's
been
some
progress
there,
so
this
couple
documents
draft
thumbs
on
tmi
and
then
draft
arco,
iab
data,
minis
minimization
and
both
of
them
have
been
reviewed
at
least
a
little
bit,
not
enough,
but
somewhat
and
there's
been
revisions.
A
Maybe
the
the
key
thing
is
is
for
us
in
in
this
group,
the
model
team
members
and
you
guys
on
the
call
to
to
do
more
reviews
of
these
documents.
Where
are
we
with
them?
Do
we
do?
We
agree
on
what
what's
being
said
and
and
so
on,
and
just
as
a
sort
of
a
reminder?
What
we
are
talking
about.
These
are
indeed
very
narrow
documents.
A
That's
not
supposed
to
be
covering
the
entire
space
of
a
threat,
landscape
changes
and
so
forth,
and
they
are
supposed
to
look
at
a
very
specific
issue
and
make
some
recommendations
with
respect
to
that.
So
my
document,
for
instance,
is
simply
taking
the
well-known
principle
of
only
only
provide
information
on
a
need
to
know
basis
and
describe
how
that
applies
to
the
current
situation
situation
and
make
some
recommendations
on
how
to
take
that
into
account
in
protocol
design
and
deployment.
A
It's
really
somewhat
obvious,
perhaps,
but
but
unfortunately,
we
are
in
a
situation
where
some
of
these
things
need
need
to
be
said,
and
we
we
do
have
a
fair
bit
of
data
collection
going
on
the
on
the
internet
and
we
need
to
make
sure
that
we're
not
unnecessarily
divulging
information
that
we
should
not
be
sending.
And
that's
that's
the
essence
of
that
draft.
A
There's
been
some
revisions
of
it.
It
was
originally
a
little
bit
more
broad
and
with
martin's
input.
It's
it's
now
more
focused
on
this
data
minimization
aspect
and
this
need
to
know
basis
principle
and
then
martin's
document
talks
about
a
different
topic
which
is
about
intermediaries
in
protocol
design
and
deployment
and
how
we
need
to
limit
the
use
of
intermediaries
and
make
a
very
explicit
decision
when,
when
you
are
using
an
intermediary
and
what
information
you
give
to
it
and
what
roles
you
give
you
give
to
it,
and
it's
also
yeah.
A
D
D
The
reason
I
say
that
is,
I
think,
that
we've
all
sort
of
come
to
an
agreement
very
gradually,
but
sort
of
all
come
to
an
agreement
that
the
best
way
to
go
about
this
work
is
to
find
tightly
constrained,
topics
on
which
to
make
coherent
and
useful
statements
and
practical
and
useful
statements
right
and
so
the
architecture.
The
principles
documents,
I
think,
are
very
valuable,
especially
when
they're
tightly
focused
and
constrained,
and
I
think
they
could
be,
and
we
we
did
some
work
about
a
year
ago.
D
There
are
some
individual
drafts
that
are
focused
on
threats
related
to
individual
technology,
so
there's
sort
of
a
matching,
a
matching
pair
of
documents
that
could
be
easily
put
together
in
the
threatmost
series
which
I'll
talk
about
later.
I
would
be
happy
to
be
one
of
the
volunteers
to
do
a
review
in
in
the
next
in
the
coming
weeks.
That's
certainly
certainly
something
I'd
be
happy
to
help
with,
but
in
terms
of
the
documents,
I
there's
two
things
that
I
really
like.
D
The
second
thing
is,
I
think,
these
two
particular
topics
fit
well,
both
in
terms
of
principle
statements
and
also
an
analysis
of
how
they
change
the
threat
model
in
rfc,
and
I
think
I'll
come
back
and
talk
about
that
later.
Obviously,
so,
I'm
very
supportive
of
these
two
documents,
as
not
just
supportive
of
them
as
two
documents,
but
supportive
of
them
as
a
way
to
move
the
model,
t
work
forward
into
something
that's
practical
and
and
useful.
E
E
A
And
just
remember
that
these
two
documents
were
yeah
written
by
their
authors,
and
you
know
who
who
felt
strongly
about
the
particular
thing
that
they
were
writing
about.
That
doesn't
mean
that
they
would
be
the
only
possible
set
of
things
to
discuss
or
document
or
only
possible
principles
that
we
should
highlight
so
that
it's
possible
that
there's
some
other
ones.
A
F
G
A
F
Okay,
so
I
like
I
I
I
I'd
say
martin's
document,
at
least
from
my
perspective-
needs
a
little
bit
of
work.
I
think
people
have
a
misunderstanding
of
intermediaries
in
a
lot
of
ways
and
there's
so
many
more
of
them
than
I
think
even
martin
realizes
and
and
he's
usually
the
brightest
person
in
any
room
that
he's
in
so
you
know
I
just.
I
think
that
document
could
go.
It's
an
there's,
an
exploration,
that's
hiding
there
right.
F
If,
if
you
look
and
you
see
how
and-
and
it
relates
a
little
bit
to
mark's
document
on
centralization
right-
I
was
talking
about
this
there
and
I
don't
want
to
get
into.
I
think
you're
having
a
meta
discussion.
I
could
get
into
the
meat
of
this,
and
I
I
maybe
that's
this
isn't
the
right
time
for
that.
But
I
do
like
the
you
know.
The
idea
of
you
know
attack
going
on
two
tracks.
F
Right
one
is,
I
think
we
talked
about
focus
issues,
and
maybe
we
keep
it
at
focus
issues,
but
the
problem
with
being
too
focused
is
that
things
get
scattered
everywhere.
We
end
up
with
these
onesie
2z
documents
and
then,
when
we
try
to
hand
that
back
to
the
ietf
or
something
like
so
here,
here's
a
dozen
documents
make
sense
of
them.
A
Yeah
it
turns
out
the
chapter
room
doesn't
exist,
I
don't
know
if
anybody
knows
how
to
fix
that,
but
anyway
so
elliot.
Thank
you
for
that.
I
I
think
we
could
get
into
the
meat
of
this.
This
is.
This
is
a
perfect
opportunity
to
get
into
not
just
the
meta
discussion,
but
also
the
nitty-gritty
details.
A
I
do
agree
that
the
one
question
around
martin's
document
is
is
on
the
definition
of
an
intermediary,
and
we've
had
some
discussion
already
on
that
on
the
list.
I
think
the
new
version
is
pretty
good
about
that,
but
but
that
that's
the
area
where
it
is
relatively
easy
to
get
into
our
arguments
or
or
discussions
of
you
know,
have
we
nailed
the
definition
well
enough
and
or
even
if
there
is
an
exact
definition
to
begin
with.
F
A
Yeah
he
I
think
he
he
would
appreciate
feedback.
So
I
I
don't
think
you
should
hold
back
how
we
all
realized
that
he's
not
here.
He
was
unable
to
make
it
because
some
other
commitment
set
like
a
inappropriate
time
for
for
him.
So
if
we
do
have
feedback,
then
then
by
all
means
bring
it
up
and
and
we'll
write
it
down
and
record
and.
F
A
F
All
right,
here's
what
I
will
commit
to
to
send
some
comments
to
the
list
about
it,
but
but
that
that's
that
one
that
much
you
can
have.
I
would
just
rather
give
back
the
time
we
can
do
that
on
the
list,
so
that
so
so
that
he
has
a
you
know
an
opportunity
to
to
really
participate
in
the
dis
in
a
back
and
forth.
If
that's,
okay
with
people,
okay,.
C
C
A
G
So
I
do
have
hi
everybody
by
the
way.
I
do
have
one
question,
so
we
have
this
principles
for
intermediates
and
we
have
the
minimization
and
then
the
iab
also
has
adopted.
This
document
for
past
signals
collaboration
with
your
nasa
yari,
and
I
think
there
is
some
overlap
between
all
these
three
documents.
A
G
A
A
Yeah
but
there's
also
important
distinctions.
So
what
one
thing?
That's
that
that's
the
case
for
for
the
data
minimization
document
and
and
the
past
signals-
is
that
the
past
signals
really
is
about
like
well.
How
do
you
communicate
with
elements
on
the
path
or
some
intermediary
type
type
things
that
you
need
need
in
order
to
perform
your
you
know
whatever
function
you're
doing,
but
the
data
minimization
draft
actually
talks
about
like
the
primary
protocol
participant.
So
it's
it's
about.
Data
means
minimization,
not
success
to
that
towards
the
networks,
but
also
to
the
server.
G
G
The
data
minimization
is
is
a
very
nice
principle
and
I
think
there
was
already
feedback
on
the
list
that
you
could
bring
the
draft
even
more
to
the
point,
because
that's
kind
of
a
very
basic
signal
principle,
which
is,
as
you
said,
to
end
points
but
like
to
everybody.
You
talk
to
it,
doesn't
matter
if
it's
intermediate
or
an
endpoint
or
whatever
it's
a
general
principle,
and
I'm
I'm
I'm
happy
to
publish
that.
G
F
So
I
actually
do
have
some
comments
on
your
document
and
and
one
of
the
I
have
a
question
and
and
it
it's
really
not
just
for
you,
it's
it's
a
good
question
for
the
room
right,
which
is
you
you
talk
about
data
minimization
and
the
principle
of
least
privilege.
Now
I
think
everybody
here
can
buy
into
the
principle
of
least
privilege
the
privilege.
But
the
question
then,
is:
does
principle
of
least
privilege
translate
directly
into
data
minimization?
F
The
reason
I
ask
the
question
is
because
some
of
us
actually
have
to
operate
this
stuff
and
when
you're
trying
to
operate
things
go
wrong
and
then
the
question
becomes.
Do
you
have
enough
information
to
figure
out
what
the
problem
is,
and
I
I
had
this
question
just
today
we
were,
we
were
designing,
a
an
interesting
federated
protocol,
and
so
we
could
have.
We
were
talking
about
what
we
wanted
to
return
in
in
well.
We
have
this
blue
id,
that's
sort
of
hanging
out
there.
F
Should
we
provide
that
and
and
and
should
we
provide
certain
values
I
said?
Well,
if
we
don't
right,
people
are
going
to
go
chasing
these
things
down
and
you
won't
have
you
know
you?
You
won't
have
the
information
that
you
need
when
you
want
to
debug
things,
and
there
was
another
instance
where
the
information
could
have
changed
in
flight,
and
so
I
know
this
sounds
a
little
all
over
the
map.
But
what
the
conversation
turned
into
was
a
question
about
principle
of
leave.
F
Did
we
violate
the
principle
of
least
privilege
by
providing
information
back
and
the
answer
was
no,
we
didn't,
but
we
provided
a
lot
of
information
back,
but
the
person
we
provided
that
information
was
entitled
to
have
that
information.
So
the
question
is:
should
we
be
talking
about
about
data
minimization,
or
should
we
be
talking
about
data
authorization.
F
G
F
Okay,
so
yes,
but
do
you
know
at
the
time
what
you
need
to
minimize
right?
This
is
again
sometimes
the
operational
experience
is.
What
tells
you
what
you
need
right,
and
this
is
this-
was
especially
tool
and
go
back.
You
know
eons
ago.
That's
why
we
have
so
much
information.
The
smtp
headers
is
because
we
needed
it
right,
but
we
didn't
know
what
we
needed
when
we
needed
it,
because
the
the
paths
were
so
circuitous
and
things
just
broke,
and
this
doesn't.
C
Yeah,
so
I
think
the
answer
there
is
make
a
way
to
take
it
out
and
then,
if
you,
when
you
find
you
don't
need
it
so
that
you
can
minimize
later
a
second
an
answer.
There
is
think
through
how
long
the
information
needs
to
exist
on
the
receiving
side
and
are
there
ways
to
aggregate
it
and
depersonalize
it.
So
it's
no
longer
really
pii
in
the
system.
Those
aren't
really
protocol
questions
necessarily,
but
they
are
questions
that
need
to
be
answered.
F
Yeah
I,
like
that
point
russ.
I
think
that's
a
great
one
to
capture
that,
if
you
need
to
provide
information
for
debugging,
make
sure
that
make
a
make
sure
that
you
can
and
especially
the
application
layers,
it's
a
big
struggle,
always
to
do
things
below
the
application
layer,
but
at
the
application
layer
for
sure
right.
F
G
Yeah
and
like
my
understanding
of
the
document,
is
that
it's
basically
saying
the
opposite,
so
you,
instead
of
just
like
broadcasting
all
kind
of
information,
information
and
figure
out,
if
you
need
them
or
not,
and
then
try
to
remove
them
later.
You
should
really
piece
by
piece
figure
out
what
you
need
and
then
provide
this
information
and
like
what,
in
whatever
way
you
provide
it.
G
You
want
to
design
a
protocol
to
be
extensible
and
whatever,
so
you
can
provide
more
information
if
needed
later
or
you
can
have
some
negotiation
but
like
this
is
a
different
document.
So
this
document
is
really
arguing
against
just
like
providing
a
broad
set
of
information
without
knowing
what
you
need
it
for.
F
Right,
I
think
that's
a
very
fair
point
miriam.
So
all
I'm
suggesting,
I
think,
is
to
understand
you
know.
What's
what's
what
is
it
occam's
razor
find
the
solution
that
is
is
simplest,
but
it
is
as
simple
as
possible,
but
no
simpler
right
find
the
amount
of
information
that
you
you
need,
but
you
know
don't,
provide
less
and
provide
and
maybe
provide
a
way
to
have
more.
A
Yeah-
and
I
agree
with
where
this
discussion
is
sort
of
heading
to
and
and
russia's
comments
and
and
so
forth,
and
comes
races
and
so
on.
I
think
that
theory
is
pretty
clear
that,
like
you,
you
should
give
enough
information
for
somebody
to
do
their
job,
the
whole
job
and
not
just
sort
of
the
immediate
step,
but
also
all
the
operational
stuff
that
goes
with
it,
but
that's
only
the
theory
and
then
in
practice.
We
will
get
into
arguments
about
well.
Do
you
really
need
that
piece?
A
And
you
know
how
valuable
is
your
your
additional
debugging
thing,
and
should
you
really
have
it
or
should
we
do
it
instead
and
so
on?
So
the
practice
is,
is
the
difficult
piece
but
but
yeah
extensible
protocols
and
being
able
to
provide
more
information
and
making
explicit
decisions
about
those.
Those
things
that
you
provide
is,
I
think,
the
key
here
I
am
looking
at
the
clock,
though
we
have
some
room
for
more
people
to
comment
on
this
topic.
If
other
people
who
haven't
commented
yet
have
thoughts
on
the
principles
then
speak
up
now.
G
A
D
Thank
you,
I'm
happy
to.
Let
me
do
a
little
bit
of
scene
setting
and
then
I'll
sort
of
open
the
floor.
I
think
back
in
december,
we
agreed
to
sort
of
break
up
into
two
design.
Teams
is
too
too
fancy
a
term
for
it,
but
two
groups:
it's
two
small
groups
of
people,
to
focus
on
two
different
tasks
for
model
t
one
was
a
set
of
architectural
principles
and
we've
just
been
talking
about
a
couple
documents
that
fit
under
that
rubric.
D
And
then
there
was
another
group
of
people
who
were
very
interested
in
talking
about
the
internet
threat
model,
as
it's
currently
documented
in
rfc
3552,
but
also
in
other
documents
as
well,
and
what
should
be
done,
if
anything,
if
anything
should
be
done,
and
so
that
second
group,
I
agreed
to
bring
people
together
and
we
got
together
at
the
end
of
january
to
have
a
call
about
that,
and
so
that
call
was
about
75
minutes
long.
It
was.
It
was
pretty
productive
and
I
sent
around
some
notes.
D
But
let
me
sort
of
tell
you
what
the
four
main
takeaways
were.
First
of
all,
there
seemed
to
be
general
agreement
that
the
threat
model-
that's
in
rfc
3552
deserves
some
sort
of
analysis.
You
know
some
thought
it
shouldn't
just
be
left
alone,
but
there
was
also
agreement
and
and
pretty
broad
agreement
that
it
would
be
very
difficult
in
the
current
landscape
to
do
a
biz
on
3552
to
actually
do
a
wholesale
change
of
a
wholesale
revision
of
that
document
to
reflect
the
current
internet
threat
model.
D
There
are
all
sorts
of
reasons
given
for
that.
You
can
look
through
the
notes
to
see
the
discussion,
but
what
was
really
interesting
was
there
also
emerged
sort
of
a
general
agreement
that
one
of
the
reasons
that
it
would
be
hard
to
ever
do
a
replacement
for
3552
is
because
the
threat
model
is
always
changing
that
we're
seeing
both
the
endpoints
and
the
connectivity
on
the
internet
evolve
evolve
to
meet
new
needs,
evolved
to
meet
new
use
cases
and
so
forth,
and
so
the
threat
model
evolves
all
the
time.
D
Instead
do
a
much
shorter,
more
focused
architectural
statement,
which
says
something
along
the
lines
that
the
internet's
threat
model
is
constantly
evolving
and
it's
in
the
reason
that
it's
evolving
and
give
some
examples.
The
reason
that
it's
evolving
is
because,
of
course,
we're
inventing
new
protocols.
We
have
new
use
cases,
we
have
new
mechanisms
by
which
we
connect
endpoints,
together
and
so
forth.
D
D
Develop
and
talk
about
a
short
document
that
talked
that
was
an
architectural
statement
that
talked
about
how
the
threat
model
is
constantly
evolving.
So
this
is
not
about
the
principles
this
is.
This
is
directly
about
the
threat
model,
and
so-
and
I'm
I'm
so
happy
that
there
are
people
from
the
iab
here,
because
we
can
just
ask
them
to
their
face
what
they
think
about
such
an
idea.
D
Now
it
runs
into
one
of
the
problems
mira
talked
about
which
is
well.
How
do
you
get
them
all
to
work
together?
How
do
you
make
sure
that
they
don't
overlap,
and
there
are?
There
are
problems
like
that,
but
there
was
general
agreement
that
it
would
be
useful
and
much
easier
to
address
the
threat
model
on
by
particular
components
or
particular
particular
chunks
as
it
were,
and
some
people
on
the
january
call
suggested
that
maybe
even
spanish,
spinning
up
a
research
group
would
be
the
right
thing
to
do.
F
D
You
can
find
it
under.
You
can
find
it
in
the
data
tracker.
If
you
look
for
my
name,
I
think
there's,
I
think
they're
still
active
anyway,
if
they're
not
I'll,
revive
them,
but
I
think
for
this
fourth
thing
of
breaking
up
the
threat
model
into
component
parts.
That's
the
part
where
I'd
like
to
have
a
little
discussion
today.
D
D
That
the
two
things
I'm
hoping
for
is
perhaps
this
group
of
10
or
12
people
that
we
have
here
maybe
talk
about.
First
of
all,
do
people
feel
comfortable
with
this
idea
that
we're
taking
the
model
t
problem
and
breaking
it
up
into
sort
of
component
manageable,
focused
chunks.
That
would
be
the
first
thing
and
any
iab
person
that
was
willing
to
say
something
about
whether
or
not
making
an
architectural
statement
about
the
internet's
threat
model.
D
G
The
other
thing
we're
doing
is
writing
these
kind
of
recommendation
documents
and
usually
these
recommendation
documents
are
kind
of
a
little
bit.
Some
lesson
learned
about
protocol
design
or
what
we
have
experienced
in
the
itf
and
and
writing
it
down
in
a
clear
statement,
helps
to
improve
protocol
work
in
the
future
and
making
a
statement
about
just
noting
that
the
threat
model
is
involving
yeah.
That
might
have
some
architectural
impact,
but
it's
not
clear
what
the
what
the
aim
of
this
document
would
be.
What
do
you
want
to
achieve?
D
D
G
Yeah
to
some,
to
some
extent
I
mean
like,
I
think.
The
reason
why
we
have
this
program
is
because
there
is
a
feeling
in
the
iab
that
there
is
a
need
to
work
on
this,
like
that,
exactly
as
you
said
that
the
threat
model
as
we
have
it
is
outdated
and
work
is
needed,
and
that's
like
why
we
have
this
program
and
why
we
we
try
to
foster
some
discussion
in
the
community.
G
I
don't
know
if,
like
having
a
more
formal
statement
or
whatever
would
actually
change
the
discussion,
because
the
end
goal
you
want
to
achieve
is,
I
think
you
want
to
update
the
threat
model
and
you
want
to
make
sure
that
we
continuously
update
this
red
model
right.
So
whatever
we
do
here
is
just
an
immediate
step,
and
it
doesn't
sound
to
me
like
having
an
rc
which
is
kind
of
something
that
is
written
in
stone
and
stays
there
forever
right
might
be
the
right
tool
for
that.
G
D
And
I
I
think
some
of
us
will
go
away
and
try
to
solve
that
problem
about
you,
not
having
text
in
front
of
you,
I'm
interested
to
hear
from
other
people
too
about
the
other
on
the
other
idea,
because
there
would
be
some
work
to
go
on
there
so,
and
that
is
the
idea
of
breaking
the
threat
model
into
components
and
then
doing
work
on
the
components
rather
than
a
much
more
general
approach.
That
was
done
20
years
ago.
F
A
Now
I
so
I
I
I
kind
of
agree
with
media
about
the
the
general
statement.
It's
it's.
We
need
to
write
one
first
before
we
we
can
say
I
I
personally
do
see
a
difference
between
saying
that
the
you
know
something
is
evolving
and
it's
it's
not
static
and
then
specifying
exactly
what
it
is
now,
and
I
think
you
were
looking
for
the
former,
not
not
for
the
latter
and
part
of
the
problem
in
nailing
down
the
ladder
in
any
rfc.
A
Is
that
by
the
time
we
get
it
get
the
nailing
done.
It's
already
changed
so
that
that's
not
that's,
not
easy,
so
so
that
that's
why
a
more
general
statement
would
be
useful,
but
but
to
see
if
that
would
actually
be
reasonable
in
an
iap
document.
Let's,
let's
see
some
text.
I
personally
feel
that
this
component
approaches
is
maybe
the
most
promising
angle.
Of
course
the
devil
is
in
the
details.
A
But
some
more
specific
efforts
might
be
more
more
feasible
and,
of
course,
the
the
details,
then
matter.
So,
let's,
let's
see
the
details.
We
also
talked
about
a
third
category
that
you
did
not
mention,
and
I
don't
know
if
that
that's
in
in
the
interest
of
this
group
or
interested
the
people
at
the
idf
or
iab,
but
we
talked
about
sort
of
documenting
the
the
actual
changes
that
are
happening
in
the
in
the
environment
without
sort
of
claiming
that
as
a
result
of
those
changes.
A
This
is
what
the
fed
model
should
be,
but
just
documenting
the
the
actual
changes
that
we're
seeing
out
there
in
the
world
and
we've
had
a
number
of
documents
in
this
this
category,
but
we
felt
that,
in
order
to
have
something
that
could
be
published,
this
feels
almost
a
little
bit
more
like
an
academic
exercise.
It
should
be
done
in
survey
style
and
should
not
focus
on
on
a
narrow
piece
of
thing
that
the
authors
are
interested
in.
A
I
I
myself
have
written
some
of
those
documents
that
I've
had
a
narrow
focus
to
narrow
focus,
but
if
one
did
a
survey
type
of
thing,
let's
say
by
some
academic
that
would
have
more
chance
of
surviving,
of
course,
that
type
of
document.
That's
how
the
issue
that
it
is.
It's
also
changing.
Well,
the
situation
is
changing
all
the
time,
so
you
can
only
do
it
like
a
snapshot.
A
D
Well,
this
is
helpful.
I
think
I
I'm
I'm
conscious
of
what
time
it
is.
So
I
think
the
takeaway
here
is
that
to
get
more
specific
comments,
people
would
like
to
see
more
specific
text,
so
that
message
has
been
received.
That's
fine.
I
also
seem
to
have
the
takeaway
here
and
that
people
do
think
that
the
specific,
more
focused
approach,
if,
if
there
is
going
to
be
a
model
that
succeeds,
that's
probably
the
model
that
succeeds
anything
that's
written
ought
to
address.
Miria's
comment
about.
D
How
do
you,
how
do
you
make
it
practical
and
useful
I'm
I
apologize
for
putting
words
in
her
mouth,
but
that's
the
way.
That's
what
I
actually
wrote
down
in
my
notes.
The
idea
here
is
that
it
shouldn't
duplicate
other
things
that
it
shouldn't
represent
sort
of
a
a
statement
of
here's.
What
things
are
like
at
this
moment
in
time,
but
it
also
needs
to
do
more
than
say,
oh,
that
this
is
in
flux
and
these
things
change,
and
so
I
know
I.
I
know
that
as
a
takeaway
as
well.
A
H
To
be
honest,
I
I
I
came
with
this
specific
problem
of
dealing
with
not
coming
from
intermediaries
but
from
the
end
points,
because
I
think
that
sometimes
even
for
the
minimization
there's,
there's
no
need
to
consider
whether
you
actually
need
intermediaries
to
protect
you
from
points.
But
apart
from
this,
I
I'm
happy
with
the
approach
it
was
proposed
of
breaking
it
down
and
discussing
specific
points,
so
I
can
contribute
maybe
on
what
is
more.
I
mean
near
to
my
problem.
H
A
Okay,
I
don't
see
anybody
else
on
the
queue
so
I'll
I'll.
Let
you
rush
conclude,
but
from
my
perspective,
the
the
situation,
at
least,
is
that
we
discussed
the
two
two
areas
of
documents,
principles
and
the
threat
model
documentation
for
the
principal
documents,
we're
calling
for
more
reviews.
People
committed
to
do
that.
That's
great!
Thank
you.
We'll
revise
her
those
reviews
and
comments,
and
after
revision
we'll
go
to
architect,
discuss,
we
will
broader
list
things
and
possibly
adopt
later
in
iab.
A
If
that
makes
sense,
we
heard
good
feedback
today
on
the
specifics,
so
we'll
try
and
address
that
on
the
thread
model
side,
there
seems
to
be
agreement
that
this
holistic,
full
scope,
documentation,
is
very
difficult
and
maybe
but
more
specific
documents
on
the
specific
components
could
be
possibly
done,
but
we
need
to
see
the
document.
So
I
think
that's
the
next
step
on
that
side
and
we
heard
some
commitments
to
publish
a
document
so.