►
From YouTube: IETF-RATS-20220912-1500
Description
RATS meeting session at IETF
2022/09/12 1500
https://datatracker.ietf.org/meeting//proceedings/
A
Get
started
so
thanks
everybody
for
joining
the
virtual
interim.
We're
at
this
is
being
recorded.
A
And
just
a
reminder
in
terms
of
the
note
well
that
we're,
I
think,
everyone's
familiar
with
the
with
the
ip
rules
for
this
meeting,
so
they
they
apply
and
we're
going
to
jump
into
the
agenda.
A
A
B
A
C
B
Did
you
post
the
the
link
for
the
sorry,
my
brain
is
still
foggy
for
the
notes.
A
C
This
is
russ.
I
will.
B
A
Okay,
so
back
to
the
agenda,
we
basically
have
two
items
on
the
agenda.
One
is
to
review
what
what
we
think
are
potentially
the
eat.
Blocker
list
the
chairs
went
through
the
archive
and
found
issues
that
potentially
are
blockers.
A
Maybe
they're,
not
maybe
they've
been
addressed
already,
but
we're
going
to
want
to
go
through
that
list,
and
then
we
have
five
five
minutes
for
an
update
on
the
milestones
and
then
five
minutes
for
open
mic
time.
D
Yeah
I
put
together
put
a
together
a
presentation
where,
like
a
status,
update
presenter
was
that
on
the
agenda,
can
you
present.
A
It's
not
on
the
agenda.
If
we
have
time
we
can
go
through
that.
A
A
Yeah,
maybe
we
get
through
the
list
quickly
and-
and
we
have
some
time
for
that-
okay,
so
so,
if
you're
anyone
that's.
D
A
I
I
did
look
at
it
and
you
know
I
think
it
makes
sense
to
just
work
through
the
mail
archive
so
that
we
can
be
focused
on
you
know.
What's
in,
what's
there
what
the
threads
are
and
and
and
we
can
all
work
from
that
context,
if
that's
okay.
C
Yes,
yep
and
just
to
add
to
that
lawrence,
I'm
sure
you'll
have
some
comments
to
add
as
the
chairs
take
consensus,
and
so
it
would
be
important
to
hear
your
comments
as
well
as
everyone
else's
just
so
that
the
working
group
understands
that
there's
a
fair
process
and
that
the
chairs
are
assessing
consensus.
So
that's
why
ned
will
lead
this.
A
Okay,
so
so
everyone's
on
the
same
page,
there
was
a
an
email
that
was
posted
to
the
list
on
september
9th,
which
is
titled
possible.
Blocking
issues
for
eat,
working
group
last
call
and
there's
basically
just
you
can
see.
There's
a
you
can
a
listing
a
numbered
listing
of
of
you
know,
items
that
had
been
posted
to
the
list
and
we
wanted
to
go
through
that
list
and
and
assess
consensus.
A
So
if
you
can
open
up
that
one
open
up
that
window
and
bring
that
message
up,
that
would
be
helpful.
A
So
the
first
on
our
list
is
is
has
to
do
with
you
a
ueid
uniqueness
guarantee.
This
was
from
our
security
director
review.
A
C
A
C
A
So
the
so
there's
if
you
go
to,
if
you
follow
the
link,
then
it'll
take
you
into
the
document
there
and
there's
it's
basically
broken
down
into
paragraphs
so
about
the
third
fourth
pair.
Let's
see
fifth
paragraph
down,
there's
a
discussion
about
the
ueid
guarantee
and-
and
the
question
here
is
you
know
the
documents
seems
to
imply
that
relying
parties
need
a
guarantee
that
the
uad
is
unique.
There's
a
there's,
an
appendix
that
reports
to
calculate
the
collision,
probability
of
the
of
the
uead
based
on
the
number
of
bits.
A
A
A
A
So,
and
the
summary
is
that
the
the
document
says
that
the
entity
may
make
security
claims
about
itself,
another
entity
can
sign
those
claims.
A
third
entity
can
verify
the
signature
it's
difficult
to
fathom
the
ex
the
expected
use
environment,
though,
why
should
a
third
party
assume
that
the
signer
is
trustworthy?
Why
is
the
trustworthy?
A
Why
is
it
trustworthy
for
evaluating
the
claims
for
the
first
party?
What
what
are
the
responsibilities
of
the
signer?
How
does
the
relying
party,
let
the
other
parties
know
what
attributes
it
needs
and
how
are
these
trust
relationships
discovered
maintained,
updated
revoked
et
cetera,
so
that
was
the
concern.
A
A
So
the
so
the
question
is:
does
the
rats
are
the
issues
that
are
being
brought
up?
Are
they
completely
addressed
by
the
rats
architecture
or
is
there
something
else?
That's
that's
not
addressed,
and
the
it
starts
out
saying
starts
out
with
asserting
a
concern
about
the
the
ability,
the
idea
that
a
claim
can
be
self-asserted.
A
C
And
this
makes
sense
he's
having
a
hard
time
following
the
issues
without
seeing
the
text
on
the
screen.
So
could
we
go
to
the
text
that
describes
the
issue
to
help
the
discussion?
Okay,
thank
you.
F
Yeah,
I
don't
know
if
you
can
hear
me.
I
just
tried
to
reset
my
browser
so
now.
Thank
you
for
sharing
that
part,
but
I
was
kind
of
responding
to
ned
you're
asking.
Do
we
doc.
F
The
review
was
on
draft
13
and
I
don't
know
how
to
answer
that.
Do
we
think
that
it
is
fine
without
having
the
text
that
changed
between
13
and
15
on
the
screen?
That's
what
I
meant
to
be
talking
about,
and
so
that's
what
I
don't
know
I've
not
seen
lawrence's
slides.
I
don't
know
if
that's
actually
what
was
in
lawrence's
presentation,
but
I
don't
know
how
to
answer.
Your
question
is
what
I'm
trying
to
say.
D
D
So
my
perception
of
what
happened
here
with
this
comment
was
the.
I
think
hillary
wasn't
familiar
with
rat's
architecture.
D
D
D
A
So
given,
given
that
that
the
there
was
there
were
changes
between
13
and
15,
does
it
make
sense
to
for
for
the
work
group
to
take
to
review
that
again
and
and
agree
that
that
you
know
the
wording?
That's
in
the
e-document
is
aligned
with
the
wording,
that's
in
the
rats
architecture
and
that
addresses
this
this
concern.
D
E
D
One
sentence,
and
maybe
two
the
what
I
just
said:
the
e-document
doesn't
discuss
the
attestation
trust
model,
see
the
rats
architecture.
A
Okay,
so
I'm
gonna
move
on
so
there's.
F
F
D
A
B
D
F
For
the
problem,
for
us
is
that
you
can't,
because
draft
15
isn't
posted
if
15
is
posted,
you
can
do
that,
but
right
now,
if
you
want
the
diffs
between
the
github
editors
copy
and
the
13
posted
one,
you
can't
get
that
from
the
data
tracker.
F
A
Okay,
so
well
that
while
nancy's
working
on
that,
let's
go
to
the
next
item,
so
this
is
say
so
further
down.
There's
a
question
about
the
security
level
claim,
and
this
this
also
appears.
This
issue
appears.
C
A
Down
on
the
on
the
list
as
well,
basically,
the
question
is
the
the
concern
is
there's
no
clear
meaning
about
what
this
about
security
level
and
and
that
the
three
possible
values,
little
medium
and
high,
seem
vague
and
so
about.
Lawrence
replied
in
in
to
the
email
for
for
item
number
three
same
thing:
that
security
level
is
being
removed
in
draft
15..
So
is
that
the
right.
A
A
Rather,
it's
appears
to
be
a
format,
and
so
I
guess,
there's
potentially
wording
that
uses
the
word
protocol
or
asserts
that
there's
a
protocol
involved
in
the
e-draft,
and
so
so.
The
clear
the
clarification
here
is
that
this
was
addressed
in
draft
14,
but
there's
other
improvements
planned
for
15..
A
So
can
you
speak
more
to
that?
What
what
other
improvements
and
what
was
done
in
14
and
what
is
planned
for
15,
lawrence
or
or
one
of
the
other.
D
D
I
don't
remember
the
number
802
the
the
or
is
it
the
tcg
standard,
one
of
the
one
of
the
it's
not
dice,
it's
the
other
one,
I'm
not
remembering
I'm
sorry
so,
and
it
was
just
the
the
text
is
not
normative
or
part
of
the
introduction
or
anything
like
that,
and
I
believe
the
text
is
revised
to
say
you
know,
eat,
defines
a
message
format
for
conveying
claims
to
a
relying
party
now
and
it
it's
like.
D
I
said
it's
not
it's
just
part
of
an
appendix
of
trying
to
you,
know,
compare
and
contrast
eat
to
another
protocol
or
another
scheme
attestation
scheme.
D
C
D
A
D
It's
comparison
to
eat,
right,
ieee,
802,
dot,
one,
a
r
and
a
dev
id.
D
Yeah,
exactly
that's
the
point
I
I'm
trying
to
make
is
that
it
does
define
a
well
it's
not
really.
I
think
we
can't
really
call
it
a
protocol.
I
don't
think
that's
right.
I
think
he's
right.
You
know
the
the
comment
is
is
accurate
in
that
that
it's
not
a
protocol.
So,
okay,
I
switched
to
calling
it
a
message,
format
and
also
don't
say
anything
about
proving
trustworthiness
to
a
relying
party
right
now.
I
think
it's
it's
much
softened
there
and
you
know
the
the.
D
A
F
So
the
sentence
quoted-
and
I
think
it's
is
it-
hillary-
is
the
first
name
beforehand,
hillary
clinton.
So
I
think
that
the
sentence
the
hillary
quotes,
which
talks
about
a
network
protocol
for
proving
that
was
changed
in
draft
14,
because
I'm
looking
at
draft
14
right
now
to
a
message.
Format
for
approving
some
of
this
protocol
isn't
there.
F
But
the
sentence
that
I
copied
into
text
is
in
the
next
is
like
two
paragraphs
down
below
that
which
still
says
it
defines
a
network
protocol,
and
so
as
long
as
the
second
sentence
is
changed
to
the
message
for
sentence
in
terms
of
format
or
mesh
format
or
whatever
sorry
defines
a
message
format
instead
of
a
network
protocol.
That
would
be
consistent.
If
that's
in
draft
15,
then
I
think
draft
15
will
be
fine,
but
I've
not
seen
15
yet.
So
I'm
just
thinking.
C
F
C
A
Okay
and
nancy
says
in
text:
she
can't
see
a
15.
A
So
apparently
there
isn't
a
15
available
in
github,
yet
either.
D
A
D
I
make
a
comment
on
draft
15
sure
so
I
mean
this
was
the
bulk
of
my
presentation
that
we're
about
halfway
through
or
maybe
three
quarters
of
the
way
through
constructing
draft
15.
D
A
Yeah,
ideally
we
can
we
we
can
disposition,
you
know,
understand
what
the
blockers
are
and
and
have
that
have
them.
You
know
taken
care
of
in
you
know
the
next
draft
or
the
following
draft.
A
Okay,
so
those
were.
Those
are
the
four
issues
that
I
that
the
chairs
could
glean
from
from
hillary
orman's
feedback.
A
Then
the
next
feedback
was
from
the
iot
directorate,
and
so
I've
got
a
list
of
those
or
a
link
to
link
to
the
the
issues
that
were
raised
there,
and
so
I
think,
they're
pretty
much
in
order.
A
A
A
So
that
is,
I
know
that
the
the
group
has
discussed
profiles
in
the
past
and
it
seems
as
though
there
was
a
consensus
that
profiles
were
necessary,
but
it
seems,
though
it
seems
as
though
that
we're
lacking
in
in
being
able
to
to
describe
that
in
such
a
way
that
that
other
readers
are
able
to
to
capture
that.
F
Waiting
to
see
if
my
mic
will
work,
so
I
don't
really
agree
with
elliott
here
about
contour
cultural
to
the
ietf.
There
are
other
popular
examples
of
where
the
ietf
does
define
a
framework
that
there
are
protocols
for
sorry
profiles.
For
an
example
is
the
pre-c
framework,
which
is
where
you
have
interoperability.
Profiles
are
used
for
different
things
like
a
profile
for
passwords,
a
profile
for
usernames
and
that
type
of
stuff,
as
well
as
the
ability
for
you
to
create
additional
profiles
for
other
specific
cases.
F
I
see
each
as
being
very
similar
to
that,
and
so
I
think
it's
perfectly
fine
for
the
working
group
to
take
a
position
just
like
the
pre-c
working
group
chose
to
do
now.
Of
course,
the
interoperability
is
at
the
level
of
the
profile.
Not
the
level
of
of
each
right.
Just
because
two
things
have
eat
doesn't
mean
that
you're
interoperability,
interoperable
right
the
profile
does,
and
so
it
just
means
that.
Yes,
we
need
some
good
profiles.
F
You
know
where
we
have
some
profiles
right,
t-pas
one,
I
think,
there's
at
least
three
profiles
that
have
been
discussed
in
this
working
group
already.
So,
in
that
sense,
no,
I
I.
I
don't
think
that
elliot's
concern
is
really
warranted
in
terms
of
being
counter
cultural
to
the
ietfs.
That's
the
part
I
disagree
with.
It
does
mean
that
we
got
to
have
good
interoperable
profiles.
That's
all
I'm
saying
so.
F
Well,
it
certainly
should
be
addressed
someplace
else
in
in
profile
documents.
I
don't
know,
I
need
anything
else.
F
F
Interoperability
is
at
the
level
of
a
neat
profile,
and
so
each
profile
should
be
should
have
all
the
you
know
mandatory
stuff.
I
think
it's
in
there
right
now,
but
I
have
to
go
back
and
and
verify,
but
when
I
look
at
the
document
and
I'm
familiar
with
profiles
and
and
what
needs
to
be
interoperable-
and
this
didn't
chip
out
to
me
this
problem-
I
don't
know
if
there's
some
wording
that
could
be
improved
someplace.
That
would
help
elliott.
A
And
so
lawrence
mentioned
that
there
were
changes
in
draft
14
and
that
there
are
a
plan
for
improved
wording
in
15.
Is
that
correct
lawrence.
D
D
One
thing
I
want
to
point
out
is
that
the
the
variability
in
the
protocol
or
the
variability
in
e
is
actually
the
same
variability
that
exists
in
cwt.
It's
not
really
that
different
and
what
he
did
is
propose
a
introduce
a
profile
mechanism
to
deal
with
that
variability.
D
C
C
D
Jose
the
the
text
in
14
tries
to
explain
a
lot
of
this
background
of
like
why
there's
variability,
and
you
know
that
he
has
chosen
to
have
a
profile
mechanism
to
address
it.
The
text
in
15
will
introduce
eat
more
as
a
framework
for
defining
attestation
token
formats
and
less
than
the
less
the
definition
of
a
specific
attestation.
Token.
For
me,.
C
So
I
guess
lawrence
you've
just
explained
to
me
why
I
have
a
problem
with
profiles.
If
eight
has
the
same
level
of
profile
and
variability
as
seat
caught,
then
I'm
not
sure
what
the
eat
document
actually
does.
At
that
point
right
we
could
just
write
profiles
and
refer
to
cot
and
we
wouldn't
need
a
document
in
between
and
so
that's
the
problem
I
have.
I
really.
I
really
would
like
to
see
the
profiles
much
less
emphasized.
C
I
want
to
see
the
majority
of
the
common
claims
well
defined
in
this
document,
such
that,
in
most
cases
we
have
would
have
you
know
a
three
or
four
sentence
profile
in
something
and
the
way
that
I'm
seeing
is
that
people
are
having
to
gonna
have
to
write
four
to
ten
page
long
profiles
in
their
documents.
C
To
do
this,
and-
and
I
see
this
as
a
sort
of
like
sort
of
some
claims-
seem
to
just
be
sitting
on
the
fence-
they're,
not
saying
anything
specific
for
that
and
that's
what
I
would
like
to
remove
right.
I
would
like
to
remove
the
the
would
like
the
claims
to
be
very,
very
semantically,
clear
and
if
they're
not
clear
enough
that
they
can
be
reused,
then
maybe
they
don't
belong
there
and
that's
my
problem.
I
I
just
don't
want
to
see
a
you
know.
C
F
Yeah
dave
taylor,
so
I've
written
a
neat
profile.
It's
in
the
teep
working
group
like
I
said.
I
think
we
actually
have
three
different
profiles
that
they're
that
are
in
documents
that
have
been
sent
around
to
the
rats
list.
I
think
psa
is
one
and
I
think,
there's
a
third
one.
That's
which
escapes
me
right
now.
The
one
that
we
did
in
teep
is
basically
one
page
in
a
larger
document.
F
Okay,
and
when
I
wrote
it,
I
found
what's
in
the
eat
document
around
e
profiles
and
claims
to
be
very
useful.
It's
exactly
what
I
wanted,
because
it
let
me
do
it
in
only
one
page
by
saying
here's
a
bunch
of
claims
that
you
can
use
in
profile,
so
I
don't
have
to
not
have
to
define
any
claims.
I
only
had
to
answer
the
questions
that
it
says.
F
Profiles
have
to
answer
to
create
a
profile,
so
in
that
sense
I
gave
it
a
big
thumbs
up
as
far
as
what
it
said
you
had
to
do
in
profiles
and
giving
sufficient
building
blocks
to
construct
a
profile
out
of,
and
so
I
did
not
have
any
negative
feedback
there.
Only
it
had
exactly
what
I
was
looking
for.
That's
my
feedback.
So
thanks.
D
Yeah,
michael
just
to
clarify
a
couple
things
there
so
cwt
doesn't
have
any
profiles.
It
doesn't
define
a
profile
or
anything
like
that,
but
cwt
does
have
variability
in
it.
In
that
the
you
can
use
different
kinds
of
sibor
encoding,
it
has
variability
in
different
types
of
cose
security.
D
You
know
algorithms,
encryption
or
non-encryption
sign
versus
sign.
One
and
cwt
has
variability
in
which
claims
are
included
or
required,
or
not
required.
So
the
the
that
variability
is
all
is
all
there.
D
So
I
I
am
with
you
on
the
idea
that
the
claims
individual
claims
should
be
very
clear
and
that
the
there
shouldn't
be
any
variability
in
the
individual
claims
that
requires
a
profile
to
sort
out,
but
the
major
part
of
the
a
major
part
of
the
reason
that
there
are
profiles
in
eat
is
because
of
the
variability
in
sibor
and
the
variability
in
cose
and
the
variability
in
which
claims
can
exist
and
which
don't
exist.
D
The
you
know
fact
that
eat
includes
jason
and
gwt
that
and
there's
some
very
there.
A
So
is
there
maybe
just
to
make
a
suggestion
if
we
have
text
that
describes
the
you
know
the
the
opportunity
for
having
interoperability
without
a
profile
if
that
exists,
sort
of
as
a
least
common
denominator
approach,
could
you
know?
Does
it
make
sense
to
to
focus
on
that
in
the
description
of
profiles
in
that
section?
In
other
words,
you
know
focus
on
where
interoperability
can
happen
without
the
need
for
a
profile.
If,
if
that
is
the
case
and
then
explain
the
the
cases
where
it
makes
sense
to
introduce
profiles.
A
A
A
F
No
because
one
side,
for
example,
just
take
one
of
the
many
axes
that
were
launched
just
to
walk
us
through
one
side
could
say
I'm
going
to
support
cwts
and
their
side
says
I'm
going
to
support
jwts.
You
have
no
interoperability
right,
that's
just
one
of
like
10
different
axes.
That's
in
there
right,
so
you
got
to
say
which
one
or
ones
of
those
is
mandatory
to
implement
right,
because
it
says,
there's
multiple
options
right,
you
can
do
cwt
or
jwt
or
both
right
and
same
thing
for
each
of
the
different
axes.
F
F
Just
because
you're
going
to
pick
this
five
and
the
other
one's
going
to
pick
three
of
those
plus
two
of
the
other
ones
or
whatever
it
is
or
something
that's
gonna
make
one
mandatory
that
was
optional,
another
profile,
whatever
it
is
right
and
then
here's
the
set
of
axes
around
you
know
cwt
and
cos
a
and
cbor
and
things
you're
gonna
choose
what
makes
sense
for
your
scenario,
and
then
that
becomes
the
profile
right.
So
it's
a
basically
a
cookbook
for
creating
profiles.
E
Yeah,
can
you
hear
me
yeah?
Can
you
hear
me
yeah?
Okay?
I
mean
he
he's
not
on
the
call
to
film
offend
himself,
but
I
think
one
of
the
things
that
elliot
did
not
acknowledge-
and
I
mean
particularly
this
is
with
respect
to
the
underlying
specifications
that
he
builds
upon.
Cwt
is
an
rfc.
It
was
approved.
It
was
approved
in
the
ace
working
group
which
is
authentication
for
constrained
environments.
E
I
believe
the
comment
ultimately
boils
down
to
asking
eat
to
fix
an
issue
that
the
underlying
spec
did
not
that
at
least
one
of
the
underlying
specs
did
not,
and
I
can
make
the
same
thing
for
jots
too,
but
I
think
you
know
I
can
just
focus
on
cots
because,
ironically,
it
was
approved
in
a
working
group
that
is
focused
on
iot
products
and
there's
in
from
a
practical
perspective.
E
It's
not
feasible
for
a
for
a
large
class
of
iot
receivers
to
design
to
be
designed
to
accept
a
token.
That's
infinitely,
extensible
and
and
every
claim
is
optional.
So
I
think
that
should
also
be
kind
of
considered
when
taking
elliot's
elliot's.
E
Into
account,
I
think
he
was
viewing
eat
in
a
vacuum
rather
than
the
underlying
specs
that
he
builds
upon.
A
F
Okay,
yeah
thanks
thanks
gary
and
sorry
for
trying
to
jump
in
so
just
to
comment.
I
don't
think
that
rats
in
the
early
design
decisions
made
any
wrong
choices
as
far
as
doing
eat
in
profiles
as
a
direction.
F
I
think
I
did
exactly
the
right
thing.
I
think
it's
it's.
I
can
point
to
other
examples
of
itf
working
groups
that
followed
exactly
the
same
process
that
that
that
rats
followed
for
the
same
reasons
right.
So
if
you
think
about
dhc
right,
dhcp
options
right,
you
think
about
pre-c
that
I
mentioned
before
you
think
about
taps,
and
so
on.
The
point
is
once
you
have
cases
that
there's
many
different
heterogeneous
use
cases.
F
Then
you
can
either
say
I'm
going
to
develop
a
solution
for
every
single
use
case,
that's
different,
and
then
I
have
15
different
solutions
or
I
can
define
a
framework
with
a
set
of
options
and
profiles
that
can
do
that
right.
So
exactly
the
way
that
eat
works
here
with
profiles
you
could
you
could
argue
that
it's
the
same
way
that
things
like
you
know,
dhcp
options,
work
for
implementations,
although
they
may
have
less
formal
notion
of
profiles,
and
they
could
have
done
better
there
granted,
because
that
was
a
long
time
ago.
F
Praise
c
filed
this,
so
I
think
it's
doing
the
right
thing.
I
think
that
each
is
done
correctly.
That's
sorry
that
the
document
is
organized
correctly
as
far
as
defining
a
framework
for
profiles,
of
course
we're
not
going
to
get
interoperability
until
we
also
standardize
profiles
right.
So
it's
really.
I
think
we
should
get
this
one
done
and
then
get
profiles
done
as
soon
as
possible.
F
You
know
at
least
one
maybe
two,
maybe
three
whatever
it
is,
because
that's
really
where
you'll
start
getting
interoperability,
but
I
don't
think
there's
anything
wrong
in
what
rats
or
eat
did
as
far
as
defining
profiles.
So
that's
the
part
I
I
disagree
with
elliot
on
and
I
think
it
is
itf
culture
when
you
try
to
have
solutions
that
can
be
tailored
to
many
different
use
cases
that
it
actually
does
do
profiles.
F
Terminology
until
we
came
up
with
is
really
these
three
roles
or
whatever
the
point
is,
there's
so
many
different
things
already
out
there
and
it's
still
early
in
innovation.
There
may
be
more,
and
so
we
really
needed
a
cookbook
here
and
that's
the
same
kind
of
approach
that
like
pricey,
had
when
dealing
with
it
with
that.
So
I'm
just
trying
to
defend,
I
I
don't
see
any
problem
here
other
than
just
email
addressing
to
eliot.
D
Yeah,
in
my
view,
cwt
has
all
the
same
interoperability
issues
that
eat.
Does
it
just?
Doesn't
it's
just
not
honest
about
it
or
it's
not
up
front
about
it.
It
has
all
the
same
variability
and
on
interoperability
issues
I
mean
two
cwts
are
not
guaranteed
to
interoperate
because
they
might
use
different
crypto
algorithms
or
different
seaboard
encoding.
D
C
D
Cwt
and
proposed
a
solution,
and
so
the
decision
about
profile
or
no
profile
well,
really
what
what
really
happened
was
the
decision
to
use
cwt
and
cose
and
cbor.
That's
where
the
interoperability
issues
root
from,
and
then
he
made
the
decision
to
add
profiles
to
kind
of
wrestle
with
that
issue,
or
you
know,
provide
some
solution
to
that
issue.
A
So
maybe
dave's
suggestion
is
to
add
a
line
or
two
that
brings
that
thought
into
the
document.
More
clearly.
A
Okay,
all
right,
so
I'm
gonna
move
on
unless
there's
what
more
to
say
about
it
and
we
have
we're
not
gonna
get
through
the
list.
It
looks
like
we
have
about
five
minutes
left.
If
that.
A
So
but
let's
try
and
get
at
least
one
more
item
here,
so
the
section
four
one
so
referring
to
the
nonce
claim
he's
saying,
the
knots
must
have
64
bits
of
entropy
as
fewer
bits
are
unlikely
to
be
secure,
a
maximum,
not
size,
set
to
limit
the
memory
required
for
an
implementation.
A
And
so
lawrence
mentioned
in
his
email
to
the
list
that
elliot
missed
the
text
that
addresses
this.
When
you
comment
when
he
made
his
comment,
the
text
has
been
there
since
draft
nine.
Can
what
can
you
summarize
what
the
text
is
saying
here
that
addresses
his
concern?
Lawrence.
D
Yeah,
it
does
a
calculation
of
the
maximum
size
and
says
what
the
maximum
size
that
the
receiver
needs
to
handle
is.
A
All
right,
so
I'm
gonna
take
a
pause
here
and
and
asked
nancy
if
this
is
if
it
makes
sense
to
do
milestones
now
or
do
we
want
to
maybe
take
a
few
more
minutes
to
do
one
more
issue.
C
A
So
elliott
asserts
that
all
implementations
must
be
able
to
receive
uads
that
are
33
bytes
long,
no
uad
longer
than
33
bytes
should
be
sent.
I
don't
understand
the
parenthetical,
which
I
am
not,
which
is
basically
asserting
that
between
section
421
and
422
there's
a
particular
use
case
that
that
he's
not
understanding
where
he
says.
A
If
a
system
integrated,
resells,
a
bunch
of
components
that
have
been
tied
together,
what
guidance
is
given
as
to
which
ueid
or
suvid
should
be
exposed,
and
for
what
purpose
does
the
consumer
consume
a
full
array
of
each
of
these
things?
What's
the
intent,
so
it
sounds
like
it's
just
the
example
is.
Concern
is
with
the
example,
but
it's
not
understandable.
A
D
D
To
address
that
comment,
I
I
don't
have
them
off
the
top
of
my
head,
but
they
are
in
draft.
D
A
Okay,
all
right,
so
any
any
more
conversation
on
that.
B
Do
you
mind
putting
up
the
slides
then.
B
B
Meanwhile,
since
we
rechartered,
I
noticed
that
a
lot
of
our
milestones
had
gotten
dropped
because
we
had
to
insert
the
new
charter.
The
new
charter
only
included
the
the
basically
just
the
co-rim
draft
that
we
wanted
to
adopt.
So
with
that.
What
I
wanted
to
do
is
just
list
the
current
drafts
and
their
status,
and
so
let
me
just
go
through
them
really
quick.
B
The
architecture
is
still
going
through
the
comment,
isg,
evaluation
and
comment
review
and
I
think
that's
continuing
to
proceed
the
chara
and
the
profile,
remote
integrity.
Verification
are
in
the
rfc
editor's
queue,
so
eric
and
guy,
I
think
most
of
the
gating
items
have
gone
through.
It's
just
up
to
the
rfc
editors
to
come
back
and
give
you
the
the
off
48.
I
think
that's
where
we
are
with
those
two
drafts
we
just
went
through,
there's
still
a
few
more
issues.
B
I
think
net
didn't
get
to
cover,
and
so
we'll
expect
and
we
can
re-review
once
we
see
a
version
15.
the
at
the
station's
results
for
secure
interactions
is
currently
in
version.
Three
from
what
I
noticed
on
the
github.
There
are
still
some
open
issues.
B
I'll
get
to
dave
in
to
the
bottom,
just
a
minute,
so
let
me
just
keep
going
through.
We
just
recently
adopted
both
the
media
types
and
the
co-rims.
So
it's
good
to
see
that
some
of
the
feedback
have
been
reflected
in
the
github
issues.
Direct
anonymous
attestation
haven't
really
gotten
an
update
there.
It's
still
under
version
one.
It
would
be
good
if
we
had
more
reviews
and
figured
out
whether
it's
mature
enough
to
do
an
early
working
group
last
call.
B
B
The
co-authors,
including
myself,
are
still
working
on
it.
We
should
get
it
mature
sometime
soon,
I
need
to
caucus
with
the
co-authors.
There
interaction
models
we're
up
to
version
six
on
that
I
didn't
see
any
open
issues,
so
we
need
to
reach
back
to
the
authors
to
see
if
we
should
issue
an
early
working
group.
Last
call
on
that
we've
had
discussions
on
the
trust,
anchor
stores
and
the
e-collection
types
I
put
out
a
call
for
interest.
B
We
received
enough
interest,
especially
for
the
trust,
anchor
stores.
What
I
was
really
hoping
for
was
to
have
discussion
also
whether
the
group
felt
that
it
should
be
up
level
to
another
working
group
versus
rats.
There
was
only
one
positive
feedback
that
we
needed
to
move
on.
This
draft
and
rats
was
as
good
a
group
as
any.
So
with
that.
If
we
have
time
ned,
we
can
do
a
poll
to
see
if
we
can
do
a
call
for
adoption
on
that
draft
here,
and
then
we
can
confirm
on
the
mail
list.
B
I
don't
know
if
thomas
is
on
the
call,
I
think
yeah
he's
not
on
call
he
mentioned
he
would
be
providing
some
feedback
on
the
e-collection
types
as
well,
which
we've
had
a
few
comments
on
it,
but
I'd
like
to
gauge
better
interest.
So
please,
chime
in
on
the
mail
list
on
interest
on
the
collection
type
before
I
engage
and
feedback
on
the
draft.
Whether
it's
ready
to
be
adopted
is
what
I
mean
so
before
we
do
the
call
for
adoption.
B
So
my
proposal
is
to
push
those
out
march
and
I'm
putting
all
of
the
current
drafts
that
we're
working
on
to
see
if
we
can
do
a
proposed
working
group
last
call
in
november.
B
So,
authors
of
those
drafts,
if
you
feel
you
won't
be
ready,
let
the
chairs
know-
and
then
I
just
gave
it
six
months
from
the
working
last
call
to
react
to
those
comments
before
we
can
go
to
iesg
publication
and
then
the
two
drafts
that
we've
been
discussing
that
still
need
adoption
are
the
the
concise
trust
anchor
school
stores
in
the
collection.
B
So
maybe
what
I'll
do
since
we're
out
of
time
is
I'll
put
the
call
for
adoption
on
the
trust,
anchor
stores
and
please
everybody
respond
in
favor
or
or
not,
and
provide
feedback
on
the
trust,
anchor
stores
with
that
I'll
pause
and
see
if
go
ahead
and
then.
F
Process
point
for
nancy:
by
the
way
I
I'm
a
huge
fan
of
the
concise
trust
anchor
stories
I
wanted
adopted.
I'm
just
I
was
the
one
that
said,
I'm
not
sure
this
working
group
is
the
best
place
for
it.
If
it
is
here,
that's
okay,
but
my
current
reading
of
the
charter
is
it
required
or
a
charter
update,
it's
actually
a
lesson
scope
than
the
co-rim
one
which
I
didn't
think
required.
F
A
charter
update,
but
roman
did,
and
so
before
you
put
out
the
call
before
you
conclude
the
call
for
adoption,
you
may
want
to
check
with
our
ad
and
see
if
we
want
to
update
the
charter.
If
that
one's
going
to
be
adopted
in
this
working
group,
because
my
reading
is
you
can't
actually
adopt
in
this
working
group
without
the
charter
change.
B
Thanks
for
that,
clarification,
dave
so
I'll
have
to
go
back
and
reread
the
recharter
to
double
check
on
scope.
But
that's
a
great
point.
Thanks.
A
Okay,
so
I
we'll
close
the
meeting
then.