►
From YouTube: IETF106-RATS-20191122-1000
Description
RATS meeting session at IETF106
2019/11/22 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
A
So
Kathleen
and
then
who
are
the
co-chairs,
our
remote,
so
continuing
on
everybody
should
be
familiar
with
the
note.
Well,
so,
let's
proceed
on
I
want
to
thank
Peter
you
for
taking
awesome
notes.
He
will
be
one
of
our
note
takers.
You
may
not
see
his
notes
on
etherpad,
so
Frank.
If
you
could
put
some
of
the
notes
on
etherpad
I
think
it
would
be
great,
encourage
others
to
also
observe
and
augment,
as
you
see,
on
the
ether
pad
as
well
and
Akira.
A
Are
you
okay
being
Jabbar
scribe?
Okay,
great
thanks
so
with
those
logistics
out
of
the
way
I
just
want
to
do
a
quick
plug.
I,
don't
see
Hannes
here,
no!
Okay!
That's
why
he
asked
me
to
do
the
plug
okay.
So,
since
there
are
interdependencies
between
teep,
soot
and
rats,
we
thought
it
would
be
good
to
begin
some
joint
hackathons.
So
there
is
a
plan
to
do
just
that
in
Berlin
in
the
February
time
frame,
the
slides
should
be
there.
You
can
upload
them,
but
mainly
for
more
information.
A
A
So
if
you
might
have
noticed,
if
you
were
tracking
the
agenda
through
the
week,
we've
modified
this
so
that
we
can
focus
on
work
that
we
should
look
forward
in
getting
adoption
so
that
we
can
actually
formally
track
the
issue
and
have
a
working
document
on
to
work
against.
So
with
that,
what
we're
going
to
do
is
begin
with
the
security
considerations
for
remote
integrity,
verification
draft
guy
is
remote,
then
we're
gonna
have
deep
site
sealer
on
behalf
of
the
new
Zion
slash
editorial
team
for
the
architecture
draft
go
through
that.
A
So,
given
that
this
is
new
work,
that
team
has
met.
I
know
quite
a
few
of
you
joined
during
the
week,
so
we've
allocated
45
minutes.
For
that,
then
we
want
to
discuss
and
get
to
some
questions.
Visa
vie
the
draft
titled,
the
basic
module
so
I
want
that
discussion
to
be
scoped
more
on
getting
us
guidance
as
to
what
we
want
to
do
with
the
document.
What
the
group
wants
to
do
visa
Vee
adopting
game
as
a
data
model
and
then
Wang
will
be
substituting
for
Frank
to
present
the
pub/sub
model.
A
So
even
though
Frank
is
here,
he's
lost
his
voice,
so
Frank
has
asked
for
his
co-author
to
present
so
I'd
like
to
have
the
discussion
for
adoption
throughout,
but
I've
left
some
time
at
the
end,
to
do
conclusions
or
to
do
further
questions
if
needed
at
the
end,
and
hopefully
hopefully
we
might
have
a
couple
minutes
at
the
end.
So
with
that
any
orders
of
business
that
I
might
have
missed
going
once
twice:
okay,
let's
move
on
so
yeah
guy.
C
C
C
C
There
were
questions
about
the
scope
of
Rev
and
I.
Think
what
you
know
we
have
not
tried
to
put
this
in.
In
you
know,
standards
compliant
text,
but
basically,
at
the
moment
the
scope
of
Rev
is
things
as
in
IOT
things.
Not
you
know,
embedded
systems
that
have
a
TPM
that
use
yang
and
that
don't
sleep.
C
C
Similarly,
sleep
sleep
modes
can
be
handled
with
the
TPM,
but
it's
a
little
complicated,
so
I
postponed
that
until
we
have
a
good
reason
to
want
to
do
it
next
slide,
please
the
information
flows
again.
This
is
unchanged.
The
the
verifier
and
relying
party
issue,
a
request
to
the
tester
and
expect
of
response.
C
On
this
slide
between
the
the
combination
of
verifier
and
ruling
party
and
the
a
testing
device,
next,
please,
okay,
so
this
is
the
start
of
the
new
material
for
this.
This
work
in
security
considerations,
I've
we've
we
factored
in
key
mitigations
for
key
compromise,
counterfeit
devices,
man-in-the-middle
attacks
and
replay
attacks,
and
let's
go
through
what
each
one
of
those
would
be
next.
D
C
C
A
C
One
of
the
tenets
of
TPM
design
is
that
keys,
which
are
generated
inside
the
TPM,
cannot
be
exported.
So
this
is
not.
This
is
not
a
rule
of.
Unless
you
have
the
right
privileges,
they
cannot
be.
A
secret
keys
cannot
be
exported
unless
you
can
find
a
bug
or
or
mount
a
physical
attack.
A
very
challenging
physical
attack
so
for
most
purposes
we'd,
say
secrets
cannot.
Secret
keys
cannot
be
exported
from
the
TPM,
and
that
is
the
the
fundamental
premise
in
how
we
defend
against
against
compromised.
C
C
Defence
against
counterfeit
devices,
if
you're
going
to
attest
something
you'd
like
to
know
that
you're
attesting
the
thing
you
think
you
are
testing
in
the
case
of
riff.
That
has
been
accommodated
simply
by
expecting
that
the
manufacturer
will
install
device
credentials
when
they
before
they
leave
the
factory.
So
if
a
manufacturer
provisions
an
initial
device
ID
using
a
doe
2.1
AR,
then
that
provides
the
serial
number
and
a
certificate
which
is
signed
by
the
manufacturer.
C
That
is
not
fundamental
to
RIF,
but
as
far
as
getting
this
to
work.
For
let's
say
ordinary
enterprises
we're
trying
to
make
it
as
close
to
an
out-of-the-box
experience
as
possible.
That
is,
you
know
this
aerial
number
you
provision
the
serial
number
in
your
own
management
system
and
beyond
that,
the
rest
of
it
just
plug
the
box
and
it'll
figure
it
out
itself.
C
One
of
the
there
are
a
couple
of
issues
to
deal
with
here.
The
identity
of
course
depends.
The
identity
of
the
box
depends
on
the
device
ID,
which
has
a
key,
which
we
keep
inside
the
TPM,
but
the
attestation
evidence
which
shows
which
you
know
what
the
what
software
is
running
on
the
box,
that
attestation
evidence
also
is
collected
inside
the
TPM
and
signed
inside
the
TPM.
C
What
we
do
not
want
is
for
the
attestation
evidence
to
be
signed
by
a
key
that
can
sign
anything
else,
and
this
is
to
prevent
the
case
where
a
a
system
which
has
been
compromised
could
make
up
a
quote
or
showing
a
particular
software
configuration,
get
the
TPM
to
sign
it
and
send
that
back.
So
as
long
as
attestation
is
done
using
a
separate
key,
then
that
cannot
happen.
That
block
say
a
thing
which
was
has
been
called.
The
ISO
can
attack
RFC
681
three
which
in
which
a
faulty
device
compromised
device.
C
Proxies
to
a
good
device
to
get
attestation
results
and
then
sends
those
back
as
its
own.
If
you're
not
careful
about
which
key
is
which
then
the
verifier
could
be
duped
into
accepting
the
bogus
results
that
were
effectively
created
by
a
man-in-the-middle,
that
is
the
device
that
is,
has
been
compromised.
C
So
that
is
what
leads
us
to
ask
for
separate
device,
ID
and
edited
station
keys
to
ensure
that
those
keys
come
from
the
same
TPM.
We
have
asked
that
the
attestation
certificate
should
contain
the
same
identity
information
as
the
dev
ID,
so
that
means
the
same
serial
number
and
the
same
manufacturer's
signature
on
those
two
certificates
and
at
that
point,
on
the
receiving
end
in
the
verifier,
you
can
look
at
the
two
certificates
see
that
they
are
signed
by
the
manufacturer.
C
C
C
It
includes
a
nonce
which
comes
from
the
verifier,
so
the
evidence
coming
back
from
the
TPM
for
a
decision
includes
the
nonce
which
came
from
the
verifier
again,
proving
that
the
result
is
fresh
is
his
current
there's
an
alternate
approach
called
to
do
that.
Hank
has
worked
on
that,
doesn't
require
as
many
back-and-forth
exchanges,
but
that
currently
is
not
part
of
Grif
could
be,
but
not
at
the
moment.
C
The
result
of
this,
the
the
implication
of
this
this
statement
is
that
the
TPM
data
structures
really
have
to
be
transmitted
unmodified,
and
that
has
been
a
that
has
been
accommodated
in
the
yang
model
as
it
is,
but
we
we
need
to
preserve
that
property
as
we
go
forward
with
this,
and
with
that
I
think
I
have
covered
the
points
I
wanted
to
cover
Nancy.
If
there
are
questions,
of
course,
I'm
quiet,
yes,.
A
E
E
It
sounds
like
we
need
a
new
term
for
that
or
and
I
wondered
if
there
is
one
and
given
that
it
is
signed
by
the
manufacturer
of
the
TPM
or
the
device,
I'm
not
really
clear
on
that,
but
it
has
to
have
the
same
info
on
it.
I
would
like
to
have
some
additional
as
a
user
of
an
eye,
dev
ID
in
my
protocol.
I
would
like
to
have
some
understanding
of
the
certificate
path
relationship
with
the
thing.
That's
doing
that
part,
and
it
almost
sounds
to
me
like
my
eye.
C
C
By
scoping
this
to
embedded
devices,
that
means
that
there's
a
relatively
clear
manufacturer
and
that
the
the
manufacturer
has
some
control
over
how
the
software
works
on
the
thing
is
well
I
shouldn't
mean
to
say
this
is
fundamental,
but
as
a
way
to
think
about
it
for
a
router,
we
build
the
router
when
we
manufacture
the
router.
We
solder
down
the
TPM
and
before
we
ship
the
router,
we
configure
an
IDE
EV
certificate
in
it
and
sign
it
with
a
key,
that's
traceable
to
the
since
I
work
for
juniper
to
the
juniper
root.
C
A
F
F
C
Yeah
there's
a
gray
area
when
so
for
bios
and
loader.
That's
that's
completely
true
for
OS
level
attestation.
It
gets
a
bit
grayer
because
I
mean
we
we
are
assuming.
This
is
based
on
something
like
ima
and
ima
continues
to
run
through
the
life
of
the
product,
but
the
life
of
the
boot.
But
once
the
thing
I
think
your
point
is
once
something
has
been
launched.
It
measures
at
launch
and
after
that
it's
you
know,
the
riff
is
out
of
the
out
of
the
picture.
So
it's
not
intended
to
provide
runtime.
C
A
Okay,
so
I
guess
the
question
is,
and
I
will
pose
it
to
the
group
I'm.
Sorry
now
so,
since
we're
talking
about
this
topic,
so
it
seems
like
what
I'm
hearing
you
say
and
what
I've
heard
from
some
of
the
feedback
is
that
there
is
value
in
what
you're
describing
potentially
as
a
use
case
or
potentially
as
an
influence
to
what
may
be
in
the
architecture.
B
A
B
If
I
could
just
inject
kind
of
one
more
thing
before
we
start
talking
just
as
a
reminder
based
on
how
thing
how
we
wrote
up
some
things
in
the
chartering
use
cases,
we're
gonna
specify
the
use
cases
to
document
and
achieve
consensus,
but
we
do
not
expect
to
publish
them
per
se
just
to
remind
everyone.
That's
what
grows
you
set
out
so.
E
Richardson
so
having
read
the
document
and
and
felt
that,
yes,
it
was
very
useful
input
into
the
architecture
in
the
use
case
pieces.
What
I
assumed
that
was
going
to
happen
to
the
document
was
the
document
was
going
to
net
then
proceed
onwards
to
stake
some
claims
and
write
some
normative
language
and
become
a
standards
track
profile
of
the
thing
of
the
architecture?
Okay,
so
that
if
I
wanted
to
buy
a
product
that
had
Riv
in
it,
I
would
specify
this
standards
track
document,
which
would
then
refer
to
the
architecture
and
the
N
eat.
E
If
that
was
appropriate
or
whatever
that's
what
I
assumed
that
this
was
going.
This
document
is
going
to
that.
Yes,
it
only
describes
a
use
case.
Right
now
is
because
they
don't
have
a.
We
haven't,
told
them
how
to
describe
this.
The
solution
based
on
the
architecture,
but
that
that
would
come
late
that
would
come
afterwards
there
and
that
the
part
that's
there
now
motivates
the
rest
of
the
piece
of
the
implementation
right.
Sorry,.
E
Piece
of
the
document
that
we
have
now
was
you
know
saying
this
is
what
our
problems
problem,
that
we
want.
We
don't
know
how
to
solve
it
yet,
but
so
please
build
an
architecture
so
that
we
can
solve
it
and
once
you've
told
us
that
we'll
explain
how
we're
using
the
architecture
to
solve
it.
That's
what
my
understanding
of
the
doctrine
was,
but
maybe
that
doesn't
match
other
people's.
G
Taylor
I
agree
that
all
four
of
those
mean
the
three
that
Roman
mentioned
and
the
one
that
Michael
mentioned
our
options.
I
don't
have
enough
information
to
choose
between
those.
Yet
I
have
comments
in
the
document,
but
I
don't
have
enough
information
and
so
I
think
Michaels
comment
was
similar
that
he
doesn't
know
whether
they
intend
is
to
be
standards
track
or
not,
depending
on
what
the
working
group
wants
to
do.
G
What
the
authors
want
to
do
with
this
document,
I
will
say
that
I
think
that
the
title
of
the
slides
was
actually
work
there
than
the
title
of
the
document,
and
so
what
is
the
scope
right?
Is
the
scope
going
to
include
claims?
Is
it
just
the
informational
stuff,
which
is
what
guy
was
talking
about?
If
you
stick
with
what
guy
said,
meaning
it
does
not
include
any
normative
content
that
Michael
was
talking
about
then,
probably
somewhere
between
option
two
or
three
I'm
fine
with
either
of
those
I.
G
G
Sorry,
okay,
I,
don't
1
or
3
I,
don't
have
a
preference
between
those
two.
As
long
as
the
scope
was
right,
I
don't
have
enough
information
to
actually
have
an
opinion
between
those
and
I
would
say.
Michaels
option
is
actually
a
third
one,
which
is
one
three
or
four,
but
not
to
to
I
think
it
should
be
so.
The
architecture
document
should
be
very
generic,
and
this
has
a
bunch
of
specific
things
in
there.
There
are
pieces
of
this
that
actually
do
do
reflect
and
are
already
in
the
two-sample
architecture.
Documents
and
Hank
is
nodding.
H
H
I
So,
just
to
clarify,
if
this
is
adopted,
as
informational
I,
just
want
to
make
sure
I
heard
what
Roman
said
correctly.
It
wouldn't
get
published
anyway,
and
are
we
looking
at
the
architecture
in
use
case
is
not
getting
published.
B
I
All
right,
no
I
I
think
this
goes
a
little
bit
more
into
detail
than
the
use
cases.
So
without
any
hats,
I
do
support
it
being
adopted,
informational
or
getting
merged
somehow,
but
I
think
I
also
agree
with
Dave
that
it
doesn't
quite
fit
this
specificity
of
it
into
the
architecture
document.
But
it's
good
work.
H
Yeah
I
think
I
have
to
agree
that
the
community
shouldn't
lose
the
content
and
and
Micah
I
think
both
are
very
good.
This
is
option
4.
We
have
the
option
to
create
profiles
that
are
information,
implementation,
specific
refinements
of
the
architecture
that
help
you
to
actually
implement
all
the
parts
for
a
specific
domain.
This
concept
is
called
the
profile
of
the
article
a
better
term
of
this.
It
is
literally
using
the
building
blocks
to
define
a
complete
solution
for
your
domain
of
application,
and
that
is
very
helpful.
H
A
So
I
think
we're
done
with
this
discussion
since
I
said
four
minutes
we're
new
into
five.
So
what
I'm
hearing
from
the
working
group
is
that
more
clarity
on
the
intent
of
the
document
from
the
authors
is
needed
so
guy
in
just
maybe
we
can
take
it
offline,
but
I
still
encourage
feedback
on
the
document
from
the
group,
but
recommendation
and
guidance
guy
in
and
Jess's
that
help
the
group
get
more
clarity
onto
the
intent
moving
forward
with
the
draft
okay.
A
C
G
A
So
for
those
who
may
not
have
been
monitoring
the
mail
list
closely,
we
up
until
anyway
for
a
few
weeks,
we
have
had
a
lot
of
discussion
on
the
mailing
list,
because
there
are
now
two
different
drafts
that
speak
to
a
rat
architecture.
It
appeared
from
the
chairs
view
that
we
were
not
going
to
reach
consensus.
So
from
that
standpoint,
as
chairs,
we
defined
an
editorial
slash,
design
team
to
come
up
with
an
architecture
draft
with
a
new
architecture
draft
that
can
be
used
for
the
frets.
A
So
in
the
design
team
we
have
Dave,
Thaler,
hey
Burke,
Holtz,
Michael,
Richardson
and
then
Smith,
so
they
have
met
and
they
I
think
to
three
side
meeting
at
Street
this
week,
and
so
I
asked
them
to
report
out
on
the
progress
and
path
forward,
and
so
Dave
I
guess
you're
the
short
straw
and
is
presenting
the
results.
Okay,
Thank
You,
Nancy.
G
Yeah
so
we
met
once
during
the
hackathon
and
we
met
on
Tuesday
morning
and
then
again
on
Thursday
morning.
So
Thursday
morning
we
actually
went
over
these
slides
I.
Don't
think
that
they've
changed
other
than
the
editors
are
that
the
people
in
the
design
team
that
sent
me
Corrections
I,
think
are
all
in
here
and
so
let's
go
ahead
and
start
where
you
got
to
go
into
full
screen
mode
and
see.
G
So
the
first
question
is:
is
the
architecture
document
intended
to
be
informational
or
standards
track
because
they're
actually
across
different
working
groups
or
exist
precedents,
both
ways?
And
so
we
asked
the
chairs,
and
at
least
one
of
the
chairs
said
informational,
please,
because
the
dot
that
charter
doesn't
actually
say,
and
so
this
is
a
question
for
the
working
group.
If
there's
any
objections
to
that
list,
no,
but
otherwise
the
editors
you're
in
agreement,
and
so
that
is
what
we're
working
with
right
now,
unless
we're
told
otherwise.
G
Okay
after
we
got
past
that
which
was
in
the
sunday
meeting,
then
the
next
question
was
well,
and
this
is
kind
of
a
question
that
Jurgen
raised,
which
is
I,
see
2119
language
in
a
document
that
I
thought
might
be
informational.
Is
that
appropriate?
And
so
we
actually
had
this
discussion
that
says
well
who
actually
want
to
use
normative
language
in
this
architecture
document,
given
us,
informational
or
not,
because
again,
there's
multiple
precedents,
both
ways
across
different
architecture,
documents
of
the
groups?
G
Okay,
and
so
in
that
discussion,
when
talking
about
2119
language,
you
know
must
should
may
one
of
the
questions
is,
if
you
use
it,
then
who
is
your
audience
of
these
mustards
mays
that
are
meant
for
implementers
or
are
they
meant
for
say
admins
that
deploy
it
or
are
they
meant
for
spec
writers,
okay,
and
so
usually
you
pick
one
or
perhaps
more
that's
a
little
bit
more
complicated
of
those,
and
so
after
a
bunch
of
discussion,
our
straw
man
proposal,
which
happens
to
match
the
same
discussion.
We
have.
G
We
can
save
the
same
things
and
just
not
use
the
must
should
make
language.
What
can
you
say
the
same
things
in
just
normal,
English,
okay,
and
so
this
is
what
we
propose
as
the
answer
to
your
against
question.
Unless
there's
any
objections,
we're
just
going
to
do
this.
Okay,
all
right!
This
is
the
process
that
we're
planning
to
follow
for
creating
the
new
architecture
document
based
on
the
two
previous
ones
and
any
contributions
we
receive
from.
G
You
know,
lisps
or
poor
requests
or
whatever
we
have
already
created
a
github
repository,
Thank,
You,
Nancy
and
Hank
did
the
first
straw
man
check
in
at
the
first
skeleton
check
in
it.
So
the
process
is
as
follows,
and
if
you're
a
tea
person
who
happens
to
be
in
the
room,
this
is
the
same
process
that
we've
been
following
in
tea
for
two
years
or
something:
okay,
different
working
groups
work
differently
in
github,
given
the
overlap
between
tea
and
rats.
G
We're
proposing
use
the
same
process
that
we're
using
in
the
teep
working
group,
which
is
anyone,
can
file
issues
in
github.
Okay,
if
you
want
to
make
sure
we
don't
lose
it,
you
can
post
it
to
the
list,
but
if
you
want
to
make
sure
we
don't
lose
it,
it's
helpful
to
file
a
github
issue.
Otherwise
the
authors
or
editors
can
file
those
for
you,
which
can
also
happen.
So
it's
not
an
obligation
that
you
can't
submit
feedback
without
following
an
issue.
No,
no
we're
just
gonna
use
that
as
the
tracking
mechanism.
G
G
This
is
true,
but
at
least
we
don't
miss
anything
so
yeah,
that's
why
feel
free
gave
us
feedback
if
you
don't
like
this
process,
but
this
is
so
for
poor
requests,
the
authors
or
anybody
else.
Anybody
in
this
room
or
listening
or
reading
the
minutes
is
welcome
to
file
pull
requests,
which
then
allows
people
to
review
it
and
comment
on
specific
lines,
far
more
easily
than
tracking
stuff
and
email,
where
it's
harder
to
figure
stuff
out
and
track
things.
So
it's
a
great
tracking
process.
G
The
authors
think
those
four
people
will
review
the
pull,
requests
and
merge
if
the
author's
agree,
but
the
github
issues
will
be
closed
by
chair
is
once
they
verify
that
yep.
They
think
the
that
the
editor
is
did
the
right
thing
or
at
least
followed
the
right
direction
and,
of
course,
new
issues
can
always
be
filed
after
that
right,
but
so
authors,
poor
authors,
merge
and
chairs
close
and
so
in
future
rats
meetings
will
just
reference
issues
by
github
numbers
where
they
exist
to
make
things
easier
track.
Okay,.
J
G
Going
to
give
you
the
teep
answer
and
the
hopes
that
that
it
would
be
representative
of
what
the
chairs
would
say
for
rats,
the
teep
answer
is:
it
happens
here
at
the
chairs,
close
github
issue
step
and,
of
course,
the
check
on
that
is
eventually,
as
a
working
group.
Last
call
that
would
be
after
that
that
new
issues
can
come
up,
and
so
consensus
happens
when
working
group
last
call
says,
if
there's
consensus
on
the
document,
okay,.
J
J
J
G
Design
team
proposal
right,
okay
and
so
the
the
chairs
can
say:
do
they
believe
it's
consensus.
They
could
choose
to
keep
an
issue
open
for
multiple
IETF
meetings
and
whatever
they
want.
That's
up
to
the
chairs,
okay,
and
so
the
authors
would
just
merge
and
leave
it
to
the
chairs
they're,
showing
consensus,
Michael
Michael.
E
The
my
experience
is
that
github
is
awesome
for
the
design
team
discussion
because
we
can
share
the
share
of
screen
in
our
in
our
group,
discuss
it
and
we
can
actually
bash
the
text
in
front
of
her
eyes
and
agree
on
that
thing.
I
find
it's
less
you
Foles
great
when,
when
there's
a
end
users,
people
not
in
the
design
team,
opened
the
issues
to
record
them.
A
G
Elliott's
not
on
the
mic,
but
I
think
that
the
part
of
Michael's
main
point
if
I
got
it
right,
which
I
agree
with
right,
is
that
for
back
and
forth
discussion
on
the
list
to
get
consensus
on
text,
that's
better
done
across
email,
rather
than
as
a
bunch
of
comments
inside
the
github
issues.
It's
okay
either
way,
but
Michaels
saying
is
actually
better.
Yeah
I
asked
normal
list
discussion
and
that's
the
part
that
I
said.
I
actually
agree
with
that,
and
so
thank
you
for
summarizing
that
way.
Yeah.
F
G
Among
editors,
and
so
if
you
have
a
request,
we
are
listening
just
between
the
four
of
us.
We
didn't
actually
ask
that
question
as
to
how
often,
how
often
do
we
want
to
publish
another,
submit
an
internet
draft
versus
working
off
at
the
github
copy,
great
question:
I,
don't
have
an
answer
personally.
I
would
concur
with
the
chairs
and
go
along
with
what
other
people
want.
So
all
right,
and
since
that
was
a
question,
that
a
request
to
follow
a
process
I
want
to
keep
going.
G
You
can
see
examples
and
things
there
that
are
solutions
specific,
that
it
walks
through
they're,
actually
two
different
sections,
and
so
the
question
is:
should
the
architecture
document
include
either
those
two
categories
right
and
so
the
precedents
from
both
of
the
individual
submissions
are.
As
that
category
one
is
included
in
the
architecture
document.
Category
two
is
not
included
in
the
architecture
document.
Okay,
and
so
this
is
a
question
because
by
default
we
will
follow
the
same
thing
since
all
the
editors
were
kind
of
used
to
that.
G
Neither
document
unless
the
working
group
wants
a
different
answer,
and
that
gives,
if
you
don't
want
category
one
in
the
architecture
document
at
all,
let
us
know
Nancy
did
suggest
moving
the
use
cases
to
an
appendix
in
both
of
the
contributions
there
in
the
main
body
towards
the
top
were
open
to
that
discussion,
as
well
again
by
default,
will
default
to
what
the
editors
did
in
the
source
documents.
But
if
the
working
group
has
direction,
this
is
not
a
technical
issue
right,
so
we
should
time-boxed
any
comments,
and
this
one
but
yeah.
H
Easy
time
watching
hi
this
is
Hank
I
just
wanted
to
highlight
that
Nevada
I
wanted
to
have
use
cases
early
on
next
to
the
terminology
and
not
in
the
appendices
in
order
to
catch
the
readers
eye.
So
that
is
easy
for
a
new
leader
for
the
document
to
identify
itself
with
the
architectural
document.
With
same
goes
with
the
message.
Roll
on
diagrams
we
have
in
order
to
create
is
feeding
okay.
If
I
can
find
myself
in
here
again.
This
is
just
one
information
at
all.
H
G
Those
are
our
three
options:
keep
it
where
it
is
in
the
body,
move
the
appendix
or
have
them
not
me
draft.
Currently
they
are
in
the
body,
I,
don't
know
if
we
want
even
asked
the
question
right
now
or
just
say:
if
you
have
opinions,
please
send
it
to
the
list.
I
would
just
moving
on.
Let's
actually
get
to
the
technical
topics
here,
okay,
in
attestation,
you
have
entities
that
need
to
trust
other
entities,
and
that
means
you
have
to
have
some
way
of
provisioning
that
initial
trust
relationship.
Okay.
G
Currently,
the
establishment
of
the
trust
relationship
is
not
a
cessation
itself,
and
so
the
solutions
for
establishing
that
are
currently
treated
as
being
out
of
scope
of
threats,
working
group
to
the
solutions,
but
the
existence
of
trust
establishment
and
the
relationship
to
attestation
how
you
provision
it
is
in
scope.
You
have
to
describe
the
intent
thing
in
the
architecture,
and
so
the
current
belief
is
that
we
should
talk
about
it
in
the
architecture,
but
not
going
to
solution
details.
There's
no
solution.
Documents
goes
out
of
scope
for
the
working
group.
G
Well,
we
at
least
have
to
describe
the
relationship
and
the
expectations
around
what
would
be
there?
Okay
and
so
here's
examples
of
things,
that's
in
the
trust
model
section
and
the
failure
architecture
as
to
who
trusts
whom-
and
this
is
the
style
of
stuff
that
would
be
in
the
architecture
document
when
we
combine
stuff,
so
you
can
see
so-and-so,
trust,
so-and-so
and
who,
let's
see,
there's
a
term
here
on
other
slides
and
stuff,
we've
been
using
the
term
a
searcher,
but
a
bunch
of
people
who
are
claiming
that
a
searcher
was
confusing.
G
This
is
just
a
rename
of
this
term
to
that
term,
because
a
searcher
was
found
to
be
confusing
between
things
that
generate
assertions
could
be
other
those
rules,
and
this
is
and
so
on,
and
so
that's
just
a
highlight
that
we're
planning
to
change
that,
and
so
the
endorser
formally
the
ax
tester
right
is
often
a
manufacturer
that
imprints
key
material
into
the
tester.
But
it
could
also
be
some
other
entity
that
prohibitions
key
material
later
on.
G
I
I
G
That
is
the
proposal.
Okay,
all
right,
so
I'm
gonna
keep
going
then.
Thank
you
all
right
next
topic.
This
is
all
right.
So
there
was
a
bunch
of
previous
discussion
around
background
check
and
passport
models
and
of
course,
we
should
keep
in
mind
that
models
are
just
models,
there's
no
intent.
That
models
is
like
prescriptive
or
by
way
of
limitation.
There
are
useful
way
to
describe
things
so
that,
when
we're
talking
about
things,
we
have
some
reference
things.
Just
like
the
the
interaction
model.
G
An
example
of
another
case
that
that
may
have
happened
is
yeah,
so
the
health
may
have
changed
since
it
was
less
attested,
maybe
it
rebooted
or
what
something
got
installed
or
whatever.
So
this
is
agnostic
as
to
whether
it's
TPM
based
or
anything
else,
it's
saying,
I,
gotta,
reach
out
and
say,
hey
did
something
change.
What's
your
current
status,
something
was
odd.
Second
example:
is
the
network
hasn't
noticed
anything
that's
odd,
but
it
wants
to
go
off
and
do
that
anyway.
Maybe
does
it
periodically
or
maybe
the
networks
definition
of?
G
What's
healthy
has
changed,
you
know,
so,
if
you're
using
reference
values,
maybe
you're
said
if
reference
values
changed
and
now
you
need
to
go
and
wreak
worry
Andry.
Compare
that
kind
of
thing.
Okay,
and
so
those
are
two
examples
of
where
you
might
want
to
do
attestation
that
was
initiated
by
somebody
other
than
you
test
her.
She
got
to
reach
out
to
the
administer.
So
that's
the
case
here
in
my
document.
The
o1
version
added
this
picture,
which
was
derived
off
of
a
picture
in
roof,
and
so
in
this
example
right.
G
The
tester
talks
to
a
relying
party
which
talks
to
a
verifier
which
then
needs
to
go
and
get
the
evidence
via
some
other
mechanism
and
Garett
some
result.
This
is
just
one
of
many
variations
again.
This
is
not
prescriptive.
Your
variation
may
vary
from
this
picture.
Okay,
so
the
point
is
that
the
well
first
of
all,
there's
this
notion
of
Auto
band
conveyance
or
in
band
conveyance,
or
pick
your
favorite
term
right
so
in
band
conveyance
means
attestation
is
communicated
across
whatever
other
protocol
between
the
ax
tester
and
the
relying
party
is
already
using
right.
G
So
for
a
tester
is
trying
to
use
HTTP
or
OPC
UA
or
co-op
or
whatever
it
is
in
ban
means
you're
doing
at
SAS
station
across
the
same
protocol,
whether
you're
passing
evidence
or
attestation
results.
Maybe
re
right.
You
just
passing
claims
across
some
existing
message
that
would
be
in
band.
Okay
out
of
bands
means
you're
using
some
other
protocol
than
the
one
that
you're,
naturally
using
to
access
the
relying
party
okay.
So
the
next
two
slides
show
four
different
categories
of
solutions
with
example,
diagrams
again
before
I
go
on
the
next
slides
right.
G
The
diagrams
are
not
synonymous
with
the
categories.
Each
diagram
is
an
example
of
something
in
the
category.
Everybody
got
that
okay,
so
the
definition
is
the
retexe.
Not
the
diagram.
Don't
beat
me
up
on
the
diagrams
here
examples
of
categories:
okay,
okay,
great!
Yes,
you
not
a
thank
you.
Okay,
now
I
can
actually
show
the
diagrams
focus
on
the
text.
So
the
diagrams
are
in
case.
You
don't
understand
the
text.
Okay
here
we
go.
First
example
is
the
verifier
queries
the
ax
tester
over
IP
right
so
net
comp
is
an
example
of
this
right.
G
So
the
verifier
sends
off
the
message
to
a
tester
and
comes
back
and
of
course,
this
is
at
some
point
in
time.
You
know
other
things
are
happening
too,
but
the
main
focus
is
the
exchange
over
here
right,
the
verifier
reaches
out
and
touches
the
ax
tester,
okay
and
as
well
go
through
these
you'll
see.
None
of
these
categories
are
perfect
right.
G
Every
category
has
some
disadvantage,
which
is
going
to
motivate
a
there's
is
no
one-size-fits-all
okay,
so
the
first
one
that
the
example
is
well,
it
doesn't
work
if
there's
like
a
firewall
or
something
inside
here
that
the
verifier
can't
just
reach
out
and
touch
the
attest
right.
This
assumes
that
you're
actually
have
a
server
piece.
That's
actually
reachable
on
the
ax
tester
okay.
But
if
you
do
that,
then
of
course,
yes,
this
category
works.
Fine
second
category
is
where
the
verifier
can
reach
out
and
touch
the
ax
tester
underneath
IP.
G
So
maybe
there's
some
eat
messages
or
something
as
this
is
just
showing
you
got
some
long
yeah
low-level
channel,
but
it's
sending
the
same
type
of
messages
across
okay
and
of
course
this
doesn't
work
on
all
link
layers.
It
only
works
on
link
layers
that
use
that
particular
you
know
below
IP
mechanism
right
that
second
category.
G
Here's
the
third
category
which
says
the
relying
party
just
gives
like
a
referral
or
a
notification
that
says:
hey,
please
reach
out
in
contact,
verify
your
X
you're
not
going
to
get
any
farther
until
you
pass
the
information
to
him,
okay,
and
so
in
this
case.
Well,
this
doesn't
necessarily
work
with
all
these
protocols,
because
this
depends
on
you
be
able
to
pass
this
referral,
which
may
be
an
extra
message
that
didn't
exist
or
something
right.
G
A
G
It
could
be,
for
example,
and
ever
these
diagrams
are
examples.
It
should
be
one
two,
three
four
or
it
could
be
one
message,
two
three
four
there's
lots
of
different
variations
of
this
right,
but,
yes,
sorry,
my
bad,
that
little
arrow
should
be
between
their
two
all
right
and
the
fourth
category
is
the
attest.
Er
keeps
some
persistent
connection
open
with
the
verifier
over
IP,
such
as
you
know,
a
WebSocket
or
pick
your
favorite
protocol,
which
is
a
connect
on
the
outbound
direction.
G
G
G
J
G
J
G
Of
these
are
in
the
outer
band,
okay,
section,
okay,
none
of
these
are
the
regular
in
band.
Ones
is,
what's
shown
in
the
classic
slides
for
a
background
check
and
passport
model
beause
the
in
band
ones.
These
are
other
variations
of
the
auto
band
variations.
We
have
more
of
a
triangle,
type
relationship
which
the
RHIB
document
does
have
one
of
these
triangle
relationships
and
there's
many
different
variations
across
different
solutions.
G
You
could
construct
that's
fits
in
this
category,
so
that
would
be
useful
to
have
this
tile
style
of
discussion
in
an
architecture
document
taking
into
account
whatever
feedback
have
for
us.
Whatever
feedback
people
have
for
us,
okay,
buddy,
okay,
all
right
I
want
to
keep
going
in
all
right
next
topic.
K
G
E
Michael
David
liquors
to
me
as
you're,
discussing
the
in
band
and
out
of
band
mechanisms.
It
occurred
to
me
that,
whether
or
not
to
ask
whether
or
not
there
we
need
we
want
to
distinguish
between
cooperative
and
uncooperative
in
band
solutions,
ones
where
essentially,
we
we
can
and
the
protocol
owners
wish
to
extend
their
protocol
to
add
communications
for
attestation
and
ones
where
we
have
to
do
things
like
stuff
via
hide
the
attestation
and
in
you
know,
a
certificate
extension
that
the
protocol
doesn't
really
know
it's
carrying
and
sort
of.
E
It's
uncooperative
right,
but
the
two
ends
are
gonna,
probably
pull
it
out
and
do
something.
It's
like
a
I,
don't
know
what
the
right
word
is:
hiding
hiding
it's
an
encapsulation,
but
it's
a
you
know
we're
it's
a
hack,
it
really.
Okay
and
so
I
wonder
whether
that
is
a
worthwhile
attribute
to
a
use
case
to
say
well
we're
having
to
work
around
an
existing
protocol
and
that's
why
we
might
do
something.
Weird
I,
don't
know
if
that's
worth
a
comment
or
a
category
I,
don't
know
just
throwing
that
out
there.
No.
G
Thank
you.
Yes,
I
understand
the
distinction
that,
yes,
the
distinction
is
important,
I,
don't
know
yet
whether
it
belongs
the
architecture
so
far.
What
I'm
hearing
from
you
makes
me
lean
towards
yes,
but
I
have
to
think
more
and
see
if
there's
any
reason
for
no,
because
yes,
I
understand
the
distinction,
and
it's
been
useful
for
protocol
discussion,
say
in
the
Microsoft
document
series
to
have.
We
actually
have
terms
for
the
difference
that
you
had
there.
G
A
G
Has
been
opinion,
let
the
editors
know:
okay.
Moving
on
to
the
next
topic
relationship
among
formats.
Again,
many
of
this
discussion
has
already
happened,
but
this
is
our
attempt
to
say
we
believe
the
architecture
document
needs
to
have
a
discussion.
This
is
the
style
of
discussion
that
we
think
is
high-level
enough
to
belong
in
the
architecture
document.
Are
we
on
the
right
track?
Right?
G
That's
the
intent
of
me
showing
this
is
to
not
really
tell
you,
hopefully
things
that
you
don't
necessarily
already
know,
but
to
say
this
is
what
we
believe
belongs
in
the
architecture
document.
Is
this
style
of
information?
Okay,
evidence,
attestation,
results
and
endorsements
are
three
types
of
conceptual
messages:
they
can
all
have
different
claims
formats
and
so
I'm,
just
gonna
show
I'm
not
going
to
show
the
endorsements
in
the
slide
because
it
wouldn't
fit,
and
so
between
a
testers
and
verifiers.
G
There
can
be
many
different
formats,
and
this
is
only
showing
ones
that
are
either
standard,
or
at
least
potential
standards
from
different
organizations
right
now
and
on
the
right
between
here
fires,
relying
parties
same
thing
and
again,
there's
dot
dots,
because
there
exists
many
proprietary
formats
that
are
not
in
here
right
now.
So,
for
example,
Intel's
SGX
format
is
not
a
standard
and
would
go
in
this
table.
So
that's
an
example
of
a
proprietary
format,
and
so
the
point
is
there's
many
of
these
there's.
G
G
Okay,
this
continues
on
from
the
previous
slide
and
so
saying.
If
we're
going
to
use
attestation
with
existing
protocols
right
because
the
things
on
the
left
in
some
cases,
evidence
might
be
in
banned
in
some
variations
and
other
variations
attestation
results
might
be
in
banned,
so
evidence
is
in
band.
G
In
the
background
check
model
attestation,
results
is
in
bound
in
the
classic
passport
model,
and
so
all
those
are
possible,
and
so
it
says,
if
you
are
using
in
band
like
in
an
existing
protocol,
then
this
affects
how
we
explain
things
as
well
as
some
constraints
on
things
that
solutions
have
to
take
into
account
if
doing
in
band.
Okay.
So,
for
example,
since
you
need
to
be
conveyed
inside
an
existing
protocol,
this
is
what
Michael
was
just
talking
about.
You
convey
it
in
a
way
that
that
protocol
is
aware
of
like
you're
extending
the
protocol.
G
G
You
can
pick
better
terms,
those
the
terms
that
we're
using
right
now
inside
Microsoft
for
those
two
concepts,
and
so
some
existing
protocols
constrain
the
set
of
formats,
and
so,
if
you're
going
to
use
it
as
a
transporter
encapsulation.
So
as
an
example
of
one
that
constrains
OPC
away
only
supports
you
got
to
make
it
look
like
an
x.509
or
encapsulated
inside
of
an
x.509
or
two
passes,
okay
and
though
so
what
that
means
is
that
any
particular
solution
fits
into
one
of
three
categories,
at
least
I
couldn't
think
of
a
fourth.
G
So
the
first
one
is
to
say
whatever
the
native
protocol
uses
right,
you
use
that
format
for
claims.
Okay,
so
if
it
passes
x.509
you,
it
is
x.509
extensions.
If
you're
using
HTTP,
you
can
put
it
in
a
bearer
token,
you
can
use
a
JWT
or
a
CW,
T
or
whatever,
because
that's
native
right
second
category
is
I,
could
take
the
clings
in
whatever
format.
I
want
and
then
encapsulate
them.
G
The
other
format,
all
right
so
I
could
add
an
x.509
extension
that
has
a
CW
t
or
a
cadet,
a
CW
t
claim
and
as
a
JWT
or
I
could
add
a
JW
cleaky
clean
that
has
a
TPM
thing
or
whatever
it
is.
So
that's
the
encapsulation
mechanism.
This
one
is
we're
problematic
for
constrained
nodes,
because
you
need
multiple,
parsers
right
and
so
people
have
talked
about.
I
want
to
do
this,
all
with
only
one
parser
and
my
constrain.
G
The
third
category
is
to
do
out-of-band
right,
which
is
used
some
other
protocol
to
acquire
the
claims.
Okay,
and
so
this
just
requires
multiple
protocols,
more
messages
and
latency
or
typical
amount
of
bands.
Maybe
you
can
find
ways
to
optimize
that,
and
so
out-of-band
ones
might
be
more
problematic
for
constrained
networks
or
notes.
H
This
is
thank
token,
preferring
from
the
Jabbar
multi-vitamin
highlights
that
this
is
this
working
group
is
intended
to
be
recharter
if
our
phase
two
and
this
in
this
second
phase-
yeah,
okay,
now
I
trust
the
hardware.
Now
let
me
check
your
similar
software
and
then
do
the
attestation.
So
there's
this
this
this
role
of
the
endorser.
That
is
a
little
bit
of
background.
H
G
F
F
A
G
F
A
A
G
F
G
This
presentation,
that's
a
charter
discussion.
All
right
next
topic
is
about
claims
profiles
which
we
have
talked
about,
the
need
for,
but
there's
nothing
that
actually
specifies
any
requirements,
the
existence
of
it
in
a
document,
and
so
we
said,
the
architecture
document
should
explain
the
concept
of
a
claims
profile
and
any
architectural
expectations
around
the
creation
of
claims
profiles.
Okay
and
so
the
point
is,
there's
many
different
use
cases
or
relying
parties
different.
G
Relying
parties
expect
different
things
and
different
claims,
so,
for
example,
in
teep
the
tam
is
a
relying
party
that
has
very
specific
claims
that
are
necessary
or
expected
by
the
Tam.
So
therefore
it
needs
a
claims
profile
and
so
a
claims
profile
there's
a
short
sentence
on
the
slide
here,
proposing
a
strawman
definition
and
a
process
that
we
have
talked
about
in
a
previous
IETF
I.
Think
last
time
we
said
that
claims
profile
should
be
done
by
the
group
that
owns
the
use
case.
G
Well,
that's
this
group
or
T
or
some
other
working
group,
because
there's
different
use
cases
and
there's
various
precedents
in
terms
of
how
DHCP
options
and
yank
modules
and
stuff
is
done.
So
we
could
do
a
claims
profile
in
here,
but
other
groups
over
time
will
do
your
own
claims
for
false
as
our
expectation,
and
so
we
would
say
something
like
this
New
York
detector
document.
Unless
there's
a
more
natural
place.
G
To
put
it
certainly
existence
the
claims
profiles,
the
process
may
or
may
not
belong
in
here,
I,
don't
know
yet:
okay,
okay,
a
testing,
multiple
components.
This
is
a
topic
that
also
came
up
last
IETF
where
were
in
Montreal,
and
so
we
believe
that
the
architecture
document
needs
to
have
a
discussion
about
testing,
multiple
components
and
how
different
I'm
going
to
use.
G
The
word
claim
sets
because
I
don't
know
a
better
term
for
the
sake
of
this
discussion,
a
particular
piece
of
evidence
or
as
a
station
results
or
whatever
may
have
claims
from
multiple
components
in
the
same
device.
There
are
concepts,
a
testing
and
attested
environments
that
have
been
discussed
a
lot
that
I'm
not
going
to
repeat
now,
because
I
think
we're
familiar
with
those
terms,
but
these
can
be
chained
or
layered.
It's
so,
for
example,
in
a
dice
certificate
chain
right,
the
hardware
attest
the
firmware,
which
then
attest
the
OS,
which
then
attest
the
app.
G
Another
example
is
where
so.
This
is
a
linear
relationship
example.
Then
there
are
one-to-many
relationships
and
here's
a
bunch
of
examples.
Here
of
a
case.
We
have
a
single
environment
that
a
tests
multiple,
what's
the
term
that
we
used
on
Wednesday,
so
sub
mods,
or
something
as
an
example,
and
so
there's
a
bunch
of
examples
here.
G
So
this
notion
that
you
have
a
root
and
various
links
between
things,
as
opposed
to
just
a
test:
Jenny,
environment
and
a
test
did
environment,
okay
can
be
more
complex
relationships,
and
so
in
general,
you
have
this
tree
of
components.
Each
entry
in
the
tree
of
components
and
the
evidence
or
attestation
results
can
have
its
own
claim
set
with
its
own.
You
know
information
in
it.
G
The
substance
of
the
claims-
ok
good
point:
let's
make
sure
that
pairs
in
a
minute,
so
I
don't
have
to
listen
to
a
recording,
or
at
least
between
the
editor
is.
One
of
us
will
remember
that.
Okay,
thank
you
alright.
E
Thanksgiving
Thanksgiving
was
in
October,
so
what's
the
problem
so
so
I
think
we
need
a
week
to
regroup,
have
an
edit
and
start
a
frequent
editorial
design,
meaning
so
next
week
is
Thanksgiving
right.
Okay,
so
that's
already
done
so.
I
would
say
that
we,
what
I
imagine
is
that
we
would
post
absolutely
a
new
Rev.
You
know
a
week
or
two
middle
of
December,
okay
and
then
probably
post
a
new
document
every
month
or
so.
Okay,
because
integers
are
cheap.
That.
C
A
H
Hi
Hank
had
a
room,
hello
group.
This
is
an
update
about
the
feedback
from
the
listen.
What
we
do
adage
about
its
respect
to
the
yang
module.
I
am
the
presenter
for
a
lot
of
people.
The
list
as
large
as
you
can
see,
so
there
was
some
need
for
clarification.
How
why
and
in
which
form,
we
are
using
the
yang
module
in
the
other
yang
in
general,
in
the
concepts
and
the
scope
of
rats.
H
The
remote
authorization
procedures
here
to
give
a
click
overview,
yang
modules
and
generals
are
written
data
models
as
a
specific
language
to
write
them.
These
data
models
describe
data
arrests,
but
they
also
come
with
a
certain
set
up
the
api's
for
conveyance.
In
this
case,
we
use
them
for
remote
attestation.
H
This
module-
we
have
here,
uses
a
specific,
secure
element.
This
the
TPM,
the
TPM,
is,
has
a
very,
very
defined
interface
that
is
by
this
so
popular,
and
that
is
why
is
often
used.
Please
let
me
highlight
that
a
TPM
is
not
always
a
physical
TPM
and
it
can
be
a
so-called
F
TPM,
which
is
a
basically
a
TPM
running
and
a
te
or
some
other
shielded
execution
environment.
It
is
to
really
complete
and
its
basic
all
the
firmware
TPM.
H
Also
there
can
be
virtual
TPMS
those
run
in
hypervisor
Tom's
and
are
accessible
for
VMs,
for
example,
so
they
are
all
using
the
same
interface.
They
can
all
then
have
the
source
for
the
data
store
as
as
a
yang
module.
This
is
important
backgrounds
here
it
would.
We
would
like
to
be
a
little
bit
more
agnostic
about
this
and
not
using
only
this
interface,
but
it
is
super
common,
as
even
other
stos
tend
to
use
the
TPM
interface,
because
this
is
there
and
it
maps
to
the
needs.
H
H
The
yin-yang
module
always
comes
with
an
English
description,
so
every
is
like
a
tree
and
it
is
trees
are
statements,
the
yankles
all
these
elements,
statements
every
statements
requires
you,
it's
mandatory
to
have
a
semantic
description
of
the
statement.
Otherwise
you
cannot
host
it
as
a
coherent
yang,
while
you
and
the
data
tracker
as
a
union
yang,
sign
because
written
says
no.
This
is
not
good.
You
forgot
description
text
and
finally,
I
was
already
talking
about
api's.
There
are
a
lot
of
encodings
here,
they're
called
encodings
in
yang.
H
Some
people
call
them
civilizations
for
the
protocols
that
are
already
used.
They
are
using
all
the
same
operations
same
api's
abstractedly,
but
they
can.
The
conveyance
civilization
is
xml,
Jason
LC
bore
the
corresponding
protocols
are
called
Netcom,
fresco
and
cork
on
at
the
moment.
So
there
was
one
big
item
about
conveyance
of
the
various
formats
that
we
create
here
and
the
most
prominent
said
invent
opened
agnostic
forma
that
we
have
is
eat.
H
It
is
a
CWT
with
a
could
be
a
very
big
set
of
our
claim
sets
to
express
both
at
station
evidence
and
potential
other
profiles
later
on,
as
they
was
highlighting
and
architecture
slide
before.
So
we
propose,
as
it
was
requested
on
the
list,
to
have
a
very
simple
and
opaque
conveyance
mr.
metha
method,
in
our
yang
module
for
eats.
That
is
relatively
easy.
The
only
thing
to
proof
is
a
pointing
your
Supra
freshness,
so
we
have
an
RPC
tiny
X
in
front
of
this
tree.
Representation
represents
an
RPC.
H
This
RPC
would
input
a
nonce
that
will
be
reused
in
the
creation
of
a
each,
so
we
assume
the
eat
is
always
created
recently
and
freshness
is
proven
by
the
inclusion
of
the
nuns
this
cryptograph
resigned
into
Z.
This
is
a
rather
simple
PC,
so
to
speak,
but
yang
wise
speaking,
I
was
speaking
to
yang
doctors
and
they
are
there.
If
this
is
an
additional
thing
to
other
all
semantics,
you
always
have
the
other
RPGs.
This
is
okay.
E
H
A
E
A
typo,
no
okay,
I
was
like
oh
yeah,
another
document
I'm
all
for
another
document.
Okay,
that
may
realize
that
wasn't
what
you
proposed
so
given
that
it
is
another
RPC
and
and
want
to
make
sure
that
people
in
the
room
understand
that
that
yang
describes
mostly
RPC
type
things.
E
But
some
of
us
hang
on,
but
some
of
some
of
us
are
more
familiar
with
using
it
to
describe
data
at
rest,
but
that's
not
how
it
was
originally
envisioned
and-
and
this
is
in
this-
is
an
RPC
mechanism-
not
a
data
at
rest
mechanism-
okay,
I'm,
just
an
important
point
to
make
for
Peter.
That
may
have
come
to
hang
in
different
ways.
So
my
question
is:
does
the
the
resulting
challenge-response,
which
is
the
eat
thing?
E
H
E
H
H
H
It
will
not
be
the
consensus.
The
tendency
on
the
list
was
not
to
do
this
information
model
mapping,
because
it
would
be
complicated
and
would
require
an
information
model
that
is
not
only
in
one
document
but
would
be
a
global
one,
because
this
semantic
overlap
we
are
describing
here
is
just
one
sitting
in
this
module
now
and
would
span
across
a
lot
of
things.
We
can
do
this.
This
is
up
to
the
group
to
decide.
I
personally
am
very
agnostic
to
this.
F
Smart's,
so
this
looks
pretty
good
to
me
if
you
had
a
device
that
does
each
style
at
a
station
and
not
TPM
style,
it
seems
like
this
would
be
what
you
need
if
you
wanted
to
talk
to
it
with
yang.
So
this
looks
pretty
good
to
me.
The
only
addition
I
could
see
there
is
on
the
input
side
is
being
able
to
select
which
claims
you
want
in
the
eight
yeah.
H
G
G
I,
don't
to
call
it
information
low,
I'd,
like
to
see
more
overlapping
claims
like
Michael,
is
asking
when
I
got
up
here
to
ask
unless
you
have
another
slide
on
it
is
how
does
the
color
know
which
RPC
to
call?
How
does
the
caller
know,
which
are
pieces,
the
network
management
station
or
whatever?
That's
that
the.
G
H
G
G
G
Is
the
expectation
for
the
courier
is
he
supposed
to
know
I
preached
making
the
call
as
he
supposed
to
know
whether
there
is
a
TPM
or
an
Eaton?
He
has
to
make
the
right
call.
How
do
you
know
which
one
of
those
two
is
in
the
other
end,
it's
my
question.
Ok,
the
document
doesn't
talk
about
it
because
this
one
isn't
in
there
yet
right.
It.
H
G
H
G
H
L
Can
you
hear
me
yes,
I
want
to
answer
Dave's
question
I,
think
it
makes
sense
to.
There
are
two
ways
to
do
it,
one
they
can
use
other
models
like
the
platform,
our
inventory
model,
to
figure
out
whether
the
device
supports
TPM
based
artist
or
eat
smith's
at
the
station
and
call
the
pc
accordingly,
which
is
complex
or
keep
the
eats
and
TPM
based
our
pcs
in
two
separate
models
so
that
the
advertising
device,
which
says
support
for
a
specific
model
itself
will
be
sufficient
to
determine
which
RPC
to
call.
G
H
A
H
Yeah,
having
said
that
so
from
the
list,
but
probably
derived
from
the
list,
is
that
one
of
the
things
that
were
came
up
with
the
call
for
adoption
is
that
how
is
this
inclusion
of
the
switchers
actually
going
to
work,
and
this
question
basically
is
yours:
how
is
it
going
to
work
now
with
another
RPC?
How
do
we
know
what
can
we
request
actually
from
device?
What
is
there?
So
this
is
not
about
the
concept
it
is
more
about.
H
H
G
Stall
for
a
second
we
enjoy
spent.
My
comment
is
actually
a
comment
for
a
rib,
in
other
words,
I
believe
there's
some
ones
not
answered
in
your
document
and
I.
Believe
it's
okay
to
not
answer
in
your
document,
which
is
how
do
you
know
the
dress
of
the
device
to
query?
Okay,
I,
don't
believe,
that's
responsive!
We
have
your
document,
but
it
is
the
response
from
the
other
one
to
say
how
this
fits
into
a
workflow,
which
is
their
stuff.
That
happens
that
you
get
the
larger
context,
so
hey
rib
document
people.
H
To
the
basically
last
point
here,
we
had
a
discussion
about
is
the
title
appropriate
because
again,
it's
very
illustrative
at
the
beginning,
the
lot
of
this
using
the
TPM
interface.
Now
as
we
are
introducing
the
each
conveyance
mechanism,
also,
the
Contra
comment
on
the
list
was:
maybe
the
name
should
stay
so
actually
we
are
talking
about
content
adoption
here,
how
we
added
the
title
of
the
draft.
It
can
be
decided
by
the
workgroup
at
anytime
before
working
group.
H
G
G
H
At
my
assumption
is
that
there
will
be
no,
there
will
be
a
zoo
of
other,
let's
call
them
representations
or
encoding.
We
want
to
push
the
opaque.
Our
PC
could
be
easily
enumerated
identities,
it
can
be
vendor
specific.
We
can
add
that
and
then
we
are
done
with
eat
and
yang
here
and,
and
we
have
identities
for
other
formats
that
can
be
vendor-specific
augments
to
this
draft
and
we
are
literally
extensible.
Then
there
is
a
standard
yang
method.
This
is
frosty.
We
have
netted
yet
because
the
obviously
is
kinda
new.
G
A
A
So
from
all
of
the
feedback,
and
now
the
discussions
and
the
proposals
that
Hank
and
the
authors
have
made
I
think
it
is
appropriate
to
leave
it
as
the
base
yang
module.
So
with
that
I
didn't
hear
any
well,
not
here,
I
didn't
read
any
strong
objections
to
the
draft
itself.
A
Michael
Steele
correctly.
E
A
E
E
A
Gonna
add
the
other
stuff,
okay
right,
because
the
original
call
for
adoption
was
based
on
the
first
set
of
feedback,
which
was
this
draft
is
two
PM
specific.
So
perhaps
it
should
just
be
titled
as
the
yang
module
specific
per
tip.
So
with
that,
if
we
leave
the
title
and
knowing
that
what
Hank
has
proposed
with
the
addition
of
how
you
can
incorporate
it
as
an
encoding-
and
we
know
that
there's
more
work,
that
needs
to
be
done
much
like
what
we
said
with
eat
is.
A
A
A
A
M
Hi
everyone,
my
name,
is
Wei
pan
from
Huawei.
This
is
a
new
draft
from
Franken
me
and
we
want
to
bring
the
Netcom
pops
up
and
the
mechanism
to
the
rats
to
use
it
to
extend
as
an
interaction
procedure
in
the
action
model.
So
for
the
interaction
model
we
now
usually
have
the
classic
mode
on
the
challenge
in
a
response
mode.
It
means
that
the
world
of
I
will
first
send
a
request
to
the
a
tester
and
the
band
that
has
to
respond
with
the
evidence
to
the
verifier.
M
But
it's
it's
kind
of
on
demand
remote
attestation,
so
it
may
not
be
suitable
for
a
very
large
network.
So
we
push
we
bring
the
young
pops
up
and
push
mechanism
here
to
see.
The
other
model
is
a
published
in
a
subscription
push
model
and
the
first,
the
verifier
key
just
a
subscriber
to
many
devices
to
say
that
it
wants
to
know
the
to
do
the
remote
attestation
with
these
devices
and
then
the
devices
can
periodically
or
unchanged
to
respond
to
sender.
M
M
M
Next
is
a
is
a
periodic
push
the
device?
A
pastor
can
periodically
push
his
evidence
trying
times
to
the
verifier
it
more
suitable
for
the
general
and
a
non
critical
information
collection.
We
think
the
third
is
the
unchained
push
or
in
ventricle
push
it's
more
suitable
for
monitor
to
monitor
the
critic
or
integrity
evidence
when
change
happens.
For
example,
like
the
new
line
cards
are
plugging
and
like
some
switchover,
I'm
kind
of
thing
like
that.
M
The
next
day
is
about
the
subscription
parameter
is
handling
the
the
remote
attestation
subscription
parameters.
Parameters
are
appearing,
Abel,
the
dynamic
negotiation
with
the
tester
about
what
information
the
verified
need
and
how
to
construct
them
together.
It's
already
native
from
the
challenging
parameters,
and
generally,
we
think
the
most
of
the
parameter
is
carried
in
a
subscription
message.
M
M
The
nas
is
to
ensure
that
we
need
to
ensure
that
and
announce
carried
in
every
notification
message
is
different
for
the
security
purpose
and
the
post
a
tester
and
that
the
verifying
can
know
the
correct
values
in
advance.
We
have
some
possible
solutions,
for
example,
the
time
stamp
or
counter
and
the
same
Orangina
seed
in
a
run
in
same
random
function
at
both
sides.
Also,
we
consider
the
rat
student
mechanism,
but
it's
not
very
complementary
or
complete
here.
It's
just.
We
thought
in
the
preeminent
preliminary
stage.
M
About
next
steps,
we
know
that,
as
the
solutions
may
not
very
complete
and
may
not
quite
suitable
for
every
cases,
but
we
want
to
keep
on
updates
to
complete
it,
and
we
want
to
get
feedbacks
from
the
group
are
interesting.
Are
you
think
it's
a
good
direction
to
we
to
solve?
The
problems
are
valuable
work.
G
Think
they
were
on
your
points
about
freshness,
I
only
stood
understood.
Half
of
that
you
talked
about
a
counter
and
orangey
and
I
didn't
understand
how
those
provided
freshness,
I,
get
the
timestamp
point
which
I
understand
which
recorder,
synchronize,
clocks
and
so
on,
but
I
didn't
understand,
counters,
don't
give
you
freshness
unless
they're
using
some
mechanism,
that's
not
explained
in
the
slide.
Oh.
G
If
that
sequence
number
always
use
three
days
ago
or
something
that
doesn't
actually
give
you
freshness,
is
my
point:
okay,
okay,
but
the
timestamp
would,
and
so,
if
you're,
only
using
mechanisms
that
in
meaning
protocol
mechanisms
that
yang
already
has
and
you're
saying,
oh
yeah
Yong
has
this
pub/sub
model.
It
has
a
way
to
do
that
and
here's
how
to
apply
it.
To
that
then
I
might
ask.
Is
this
a
sort
of
thing
that
could
be
combined
into
the
basic
yang
module
document
because
used
to
saying
the
data
model?
Is
the
same?
G
It's
saying
here's
a
way
to
do.
Some
other
yang
features
in
the
following
way,
and
it
could
just
be
a
section
in
that
document
is
what
I'm
trying
to
figure
out,
because
the
use
of
pub/sub
sounds
fine,
especially
if
yang
just
sports
that
right
and
saying
here's
what
it
means
and
here's
how
you
do
the
freshness
point
which
might
require
synchronized
clocks
and
you
had
unless
you
have
some
other-
are
pcs
to
get
the
nonce
or
something
like
that.
Getting
in
the
way,
I
could
have
envisioned
doing
that
and
I'm
looking
at
Hank
right.
H
Yeah,
thank
you,
yeah.
That's.
A
levy
of
three-year
push
drafts
are
basically
intended
to
be
put
into
what
the
data
some
modules
that
have
the
we
are
doing,
a
subscription
to
a
data
store,
I
think
and
this
data
so
subscription.
We
already
up.
We
have
the
three
that's
correct.
We
can
apply
that
there
will
be
a
lot
of
imports
and
some
specific
identities
that
potala
a
to
the
rats
comb,
but
this
is
basic.
The
standard
Verkhoyansk
yes,
so
this
is
intended
to
do
exactly
proposed.
G
Right,
so
thank
you
for
Hank
for
answering
so
based
on
that
answer,
I
would
say:
I
think
this
is
interesting.
I
think
it
would
be
interesting
if
the
author's
would
both
think
that
makes
sense
for
the
concepts
of
pub
side
being
pulled
into
the
same
document.
We
just
talked
about
adopting
now
for
the
freshness
issue.
H
I'm,
creating
a
yang
module
for
today
is
super
easy.
First
of
all,
so
I
think
subscriptions
are
yeah.
This
was
after
the
last
discussions
of
the
last
half-year.
True,
that
was
not
my
greatest
priority,
but
we
will
keep
up
that
again
and
I.
Think
it's
a
hybrid
here.
You
can
initiate
the
subscription
stage
with
a
single
month
and
go
from
there
because
of
the
subscription
state
establishment
is
the
yang
push,
is,
is
a
handshake
and
then
from
there
you
can
start
with
probably
the
time
stamp
based
telemetry.
That
is
our
assumption
at
the
moment.
G
G
C
G
Can
put
in
the
same
one
in
the
same
document,
which
would
be
my
preference
you
might
have
heard
so
far.
But
that
means
there's
needs
this
discussion
of
freshness
because
the
query
response
mechanism
doesn't
even
a
sort
of
gets
it
for
free
and
this
would
be
adding
a
new
constraint.
That's
not
there
in
the
base
document,
and
so
that's
why
we
means
to
discuss
this
right.
E
Michael
I
think
that
the
nonce
issue
is
in
fact
the
issue
for
the
pub/sub
okay,
and
so
you
know
document
should
that's
essentially
what
does
I'm
I
don't
have
a
specific
solution,
but
the
the
the
the
method
mechanism
I
was
imagining.
Is
that
the
I'm
going
to
say
the
observer,
the
the
thing
collecting
the
data
or
the
things
collecting
the
data?
That's
may
be
an
interesting
variation
as
well
arm
would
announce
a
new
challenge
to
every
all
the
nodes,
and
that
would
be
mixed
in
with
something
else.
E
That's
unique
to
the
node,
and
that
would
become
the
knots.
Okay
and
the
unique
to
the
node
is
essentially
becomes
a.
You
know
a
one
to
one
secret
and
I.
Don't
know
how
to
do
that
exactly
yet.
But
what
I'm
saying
is
that
that
that's
the
thing
I'm
imagining
somehow
is
there,
and
maybe
we
don't
actually
need
to
mix
too
many
things,
but
that
the
that
the
the
challenge
would
be
somehow
broadcast
on
a
frequent
enough
basis
that
you
now
it
has
something
which
is
a
little
bit
essentially
like
having
a
secure
time.
E
It
just
doesn't
increment
it's
it's
the
result
of
some
other
yeah,
so
so
I
don't
know
the
exact
answer
to
that.
But
I
think
that
that's
the
space
that
a
document
once
adopted
by
the
working
group
has
to
kind
of
shop
around
for
some
solution
like
that.
Okay,
we
have
to
agree
that
we
want
to
solve
I.
Think.
E
A
B
A
A
Do
we
believe
that
the
draft
should
be
incorporated
into
the
yang
module
draft?
Or
do
we
not
address
this
at
all
so
as
you're
providing
feedback?
Please
do
that
over
the
mail
list
and
we'll
get
more
feedback
in
okay
and
an
idea
and
guidance?
Okay,
all
right?
Okay.
So
with
that
look
at
that,
we
actually
have
10
minutes
because,
as
I
said
earlier,
I
was
going
to
fold
my
15
minutes
for
call
for
adoption.
So
this
is
great.
We
we
have
a
little
bit
of
guidance
to
provide
to
the
authors
of
the
Rif
draft.
A
A
A
Already
has
access
so
they're,
okay.
So,
but
thank
you
for
that
clarification
Michael.
So
it
will
become
part
of
the
the
rats
organization
into
github,
so
orders
of
business.
We
have
good
momentum.
We
now
have
a
lot
of
a
lot
three
drafts
that
we
can
start
working
on
potential
and
the
architecture
and
yang.
That's
three
right.
I
think
I
can
count
three
yeah,
okay,
so
the
I'm
going
to
advocate
for
a
minimum
of
one
virtual
interim.
Is
there
interest
to
have
to
I
see
a
lot
of
nods,
so
I
will.
A
Know
yeah,
so
what
I'll
do
is
is
confer
with
my
co-chairs
and
we'll
put
out
doodle
polls
for
the
two
virtual
interns
I'm,
presuming
that
the
first
one
should
likely
start
in
January.
Although
Dave
you
have
a
question
or
comment.
Dave.
G
G
A
A
F
A
Know
I
will
try
to
put
out
the
doodle
poll
in
the
next
week
or
two
so
that
we
know
dates:
okay,
but
I
need
to
confer
availability
of
co-chairs
as
well,
okay,
so
that
was
the
last
order
of
business
that
I
had
any
other
any
other
business
going
once
going
twice.
Wow
we're
finishing
six
minutes
early,
it's
Friday!
Thank
you!
Everyone,
so
troublesome.