►
From YouTube: IETF-EMU-20230104-1700
Description
EMU meeting session at IETF
2023/01/04 1700
https://datatracker.ietf.org/meeting//proceedings/
A
All
right,
I
think
we
can
get
started.
The
the
basic
agenda
here,
I
think,
is
to
one
just
remind
everybody
that
we're
all
under
kind
of
ietf
participation
roles
here,
note
well
and
all
that
and
then
I
think
the
main
agenda
here.
What
I
think
we
want
to
spend
our
time
today
doing
is
going
through
the
tip.
A
Errata
I
set
up
a
couple
interim
meetings
here
so
that
we
have
a
couple
more
days
and
times
to
go
through
some
of
this,
and
if
we
need
to
schedule
more,
we
can
do
that.
But
today,
I
think
what
we
want
to
do
is
focus
on
the
Errata.
Alan
has
kind
of
gone
through
and
and
looked
at
those
so
I'll
have
him
kind
of
go.
Take
us
through
the
Errata
so
far
that
he's
looked
at
and
have
the
proposal,
so
we
can
hopefully
move
forward
with
the
resolutions
to
those.
A
A
Okay,
Alan:
do
you
want
to
take
control
of
the
screen
sure.
B
Hopefully
everything
should
be
online.
What
I'll
do
is
I'll
start
with
the
actual
errata
and
go
from
there.
That's
okay,
so
I'll
post
a
link
to
each
a
rata
that
we're
we're
talking
about
and
just
see
if
we
have
sort
of
consensus
on
that.
So
if
you
give
me
a
bit
for
each
one,
so
that's
the
initial
Errata
we're
gonna.
We
can
take
a
look
at
if
people
want
I
can
post
links
to
the
commits.
B
So
if
you
look
at
the
actual
list
of
commits
what
I've
done
is
I
put
the
erratic
ID
in
each
of
the
commits
which
addresses
that
errata
so
go
back
and
forth
and
verify
that
each
Errata
has
been
addressed
in
the
commit.
So
if
we
go
to
5765
in
the
commit,
we
can
see
that
that
one's
been
changed
and
what
I'm
going
to
do
is
I
think
I'm
just
going
to
go
through
each
one,
and
if
people
have
comments
they
can
stop
me
and.
B
Okay,
we'll
do
that
I
will.
Let
me
pull
everything
out.
Yes,
that
would
be
sense.
I
just
have
to
rearrange
everything
here
and
presentation
view
or
let
go
ask
to
share
screen
all
right.
Our
requests
sent
to
I've
asked
to
share
a
screen,
so
I
think
that
she
shows
you
to
pop
up
for
that.
B
When
no
there
we
are,
do
we
see
that
or
no
no,
it
says:
okay.
B
How
about
you
just
do
a
Joe
from
those
from
those
links,
I'll,
post
the
links
and
we'll
go
from
there,
and
it's
not
worth
debugging
things
with
a
bunch
of
people
on
the
call.
B
A
C
B
B
A
little
bit
of
fighting
later
we're
back
like
so,
let's,
let's
go
back
for
a
second
five,
seven,
six
five!
This
one
is
pretty
straightforward.
B
Okay:
next
one
is
five
six
one,
five,
seven.
B
This
is
also
verified.
Status
field
is
one
octet.
B
B
B
B
And
I've
looked
at
the
the
code
that
Alex
was
working
on.
This
is
what
it
does.
This
is
interoperable
with
Windows,
so.
D
B
B
Okay,
noted!
Thank
you.
B
A
Elliot,
do
you
have
a
comment.
E
Good
evening,
good
afternoon
and
good
morning
to
everyone,
first
of
all,
thank
you,
Alan
for
for
taking
this
on.
It's
a
lot.
E
I
and
I
was
saying
to
a
colleague
today
that
the
the
pace
of
this
work
is
likely
to
be
blindingly
fast
for
when
I
have
perspective,
but
that,
having
been
said
in
this
meeting,
you're
going
just
a
little
bit
too
fast
for
me
to
follow
sure
going
on
and
is
I
I
think
I
need
help
from
the
chairs
just
a
little
bit,
which
is
it's
really
difficult
for
me
to
follow?
What's
on
your
screen?
Is
it?
E
C
C
A
box
at
the
top,
where
it
says
you
know
257,
kilobits
per
second
and
then
a
pause
and
then
there's
two
buttons
that
will
expand
the
video
or
make
it
full
screen
and.
D
G
B
A
balance
one
way
or
the
other,
but
yes
that
that
does
look
better.
Thank
you.
So
my
two
cents
for
people
following
along
I
mean
we
have
an
hour
to
go
through
10
or
12
Errata,
and
a
bunch
of
changes
which
are
not
in
there.
So
I
will
try
to
push
it
somewhat.
B
My
two
cents
is
have
follow,
along
with
the
actual
errata
and
I
will
be
going
back
and
forth
a
bit
between
the
changes
that
Joe
suggested
in
in
the
tip
errata
repository,
and
then
my
commits
in
the
actual
7170
Biz
document.
B
The
initial
few
Errata
are
relatively
straightforward.
Typos
this
that
and
the
other
thing
I
do
expect
that
some
of
the
other
ones
are
going
to
be
pretty
horrific.
Unfortunately,
with
lots
of
discussion.
B
Sorry,
51.28
try
and
post
yeah
I'll.
G
B
Less
opening
and
closing
of
Windows,
because
I
think
that
also
is
a
problem
so
5128
I
do
have
commits
for
that.
B
Let
me
go
there.
I
believe
I
do
have
to
update
them,
because
the
current
text
still
has
comma,
60.
and
I.
Don't
believe
that's
correct,
but
I
will
have
to
go
double
check
that
against
the
implementations.
So
if
we
change
the
previous
one
to
have
this
0x000x40.
B
Then
I
suspect
this
one
has
to
do
the
same
thing.
Alex
you've
looked
at
this
recently
I
think.
Does
this
ring
a
bell
or
or
is
it
not
pushed
off
your
stack.
B
Maybe
maybe
not
okay,
so
I
need
to
make
a
note
to
update
that.
B
B
The
issue
is
that
7170
is
a
little
ambiguous
about
whether
you
send
intermediate
result
after
a
successful
authentication,
and
so
this
text
clarifies
it
that,
yes,
you
should
send
intermediate
results
after
every
inner
method.
B
B
B
Do
we
want
to
rewrite
things
a
bit
or
do
we
want
to
just
do
what
the
Errata
suggests
suggests
and
just
say,
epauthentication
method
to
make
it
excruciatingly
clear?
What's
going
on
for
Eep
foreign.
B
The
the
issue
is,
there's
a
lot
of
text
about
how
inner
authentication
works
and
that's
repeated
both
for
Eep
sequences
and
for
password
and
so
either.
We
leave
it
alone
and
just
clarify
that
eat
method
is
Eep
authentication
method
or
we
do
a
little
more
in-depth
work
and
pull
all
the
common
text
into
a
new
section
which
would
say
for
any
inner
authentication.
Here's
what
you
do
and
then
the
Eep
sequences
and
then
in
fact
the
Eep
would
not
be
in
each
sequences.
B
It
would
just
say
how
Eep
works
and
the
password
would
not
be
a
password
sequence.
It
would
just
say
how
password
works
and
all
the
sequencing
information
would
be
in
a
comment
section
right,
because
there's
no
particular
reason
why
you
couldn't
do
machine
authentication
with
a
client,
cert
and
user
authentication
with
a
password.
B
E
At
least
all
of
these
issues
are
so
intertwined
that
it
gets.
It
gets
a
little
hairy
to
to
pick
them
apart
and
I.
Think
what
you
just
described
would
be
a
pretty
major
reorganic
and
my
suggestion
would
be
to
not
go
there
and
I
may
differ
from
my
colleague
Oleg
a
little
bit
on
this
and
we'll
see
what
a
couple
of
key
points
that
that
I
think
I
would
make.
E
First,
we
if,
if
we
just
deal
with
the
E
path
and
equation
functions
here,
that
leaves
us
open
to
have
the
the
a
separate
discussion
about
what
to
do
with
the
pkcs
10K
cs7
tlbs
and
then
also
how
to
handle
off
basic
auth.
The
other
point
is
that,
no
matter
what
we
do
here,
we
have
to
separate
out
what
to
do
about
an
imck
for
cases
where
you're
not
running
an
Eep
method
and
I
do
think
running.
B
Yeah,
we
could
always
add
a
sentence
or
two
before
this,
because
these
are
sub
subsections.
We
could
add
a
sentence
or
two
before
this,
going
by
the
way
you
can
mix
and
match
even
basic
password.
It's
fine
in
in
the
interest
of
just
having
minimal
changes
to
the
document
that
would
work.
E
Yeah
and
and
and
I
think,
the
key
thing
there
is
just
to
be
clear
as
to
and
I
think
7170
actually
got
this
one
at
least
part
of
this
right,
which
was
when
you're
the
when
you're
derive
in
the
imck
to
derive
it
from
the
last.
E
You
know,
if
you
have
this
this
array
of
IMC
case,
which
the
only
issue
is
to
make
clear,
and
we
should
make
sure
that
the
text
is
clear
about,
if
you're
going
from,
say
an
eat
method
to
basic
auth
and
we're
at
and
we're
and
we're
calculating
I
an
imck
for
that.
If,
in
fact,
we
are
what
it
is
that
means
and
and
what
it
means
for
the
for
the
the
intermediate
result
and
the
crypto
binding
that
follows
yeah.
B
One
of
the
other
Errata
and
and
some
of
the
text
from
Joe's
tea
Parada
comments
on
ads
explicit
text
that
for
basic
password
authentication,
the
inner
imck
must
be
treated
as
20
octets
of
zero.
F
B
G
I
want
to
add
that
today
we
have
three
different
terms
in
the
document
about
what
happens
in
space
inside
phase
two.
It
could
be
inner
deep
method
and
the
second
is
inner
method.
That
implies
that
it
could
be
naughty,
but
something
else,
and
inner
authentication
I
think
that
it's
worth
to
use
a
single
term
for
all
three
of
them
and
change
every
occurrence
in
the
document
just
to
make
it
very
clear
to
the
implementer
that
they
are
the
same
between
them.
The
same.
B
B
Yeah
I'll
make
a
note
what
I've
also
tried
to
do
is
I
think
this
is
also
one
of
the
other
Errata
there's
a
bunch
of
text
outside
of
these.
This
Eep
sequences
section,
which
talks
about
eat
method
where
it
refers
to
the
inner
authentication
and
I've,
tried
to
change
those
to
Inner
authentication
method
in
order
to
just
avoid
the
subject
of
what
it
is,
it's
Eep,
it's
passwords,
it's
whatever
and
then
the
only
text
which
should
refer
to
the
inner
Eep
authentication
method
is
this
Eep
sequences
section.
G
B
The
the
basic
password
section
also
mentions
that
you
can
do
sequences
of
basic
passwords
and
then
there's
various
bits
and
pieces
scattered
around
where
it
talks
about.
You
know,
crypto
binding
or
all
this
or
it
references
the
the
various
imcks.
A
A
Should
be
roughly
the
same,
we
don't
necessarily
need
to
put
all
of
this
in
one
section,
because
that
would
reach
be
a
major
restructure
like
Elliot
said,
but
we
should
make
sure
that
that
behavior
is
clear.
B
B
Okay,
let
me
make
some
notes
for
me:
okay,
let's
scroll
down
five,
seven,
six,
eight!
B
The
issue
of
do
we
hard
code
it
to
so
we
we
create
an
inner
Mac
or
there's
an
inner
Mac,
and
then
we
do
things
based
on
TLS
one
two
and
the
document
says
it's
20
octets,
and
this
also
comes
up
later
in
the
crypto
binding
tlv,
which
says
that
the
compound
Mac
is
20
octets.
B
B
There's
a
couple
of
different
options:
the
code
I
looked
at
and
I
posted
a
comment
to
the
mailing
list
earlier
today:
host
AP,
for
example,
just
hard
codes
them
to
20
octets
and
that's
hard-coded
in
the
source
code,
and
it
only
supports
TLS
1.2.
So
the
question
is:
if
we
support
TLS
1.3,
do
we
want
to
say
that
these
Macs
are
variable
size
or
do
we
want
to
truncate
them
to
20
octets?
B
If
we're
going
to
change
the
size
of
those
Macs
and
change
the
size
of
the
crypto
binding
tlv
and
the
current
implementations
do
not
support
variable
size,
which
is
what
it
looks
like
then,
in
order
to
support
TLS
1.3,
it
might
be
simpler
just
to
Rev,
rather
than
trying
to
say
oh
for
tls13
support.
This
thing,
which
used
to
be
fixed
size,
is
now
variable
size
or.
B
A
Which
has
its
own
set
of
it's?
Not,
maybe
not
the
worst
thing
to.
G
F
A
B
Okay,
so
some
of
the
text
I
put
in
the
document
change
this
TLS
1.2
reference
to,
for
example,
TLS
1.2,
because
we
don't
want
to
hard
code
a
requirement
of
tls12
in
this
and
then,
if
we
have
time
we'll
get
into
some
of
the
other
errata,
which
also
discuss
whether
you
truncate
this
or
whether
the
compound
Mac
is
sort
of
crypto
binding
tlv.
The
compound
Max
are
variable
sized.
E
Yeah
thanks
I
I
think
the
issue
here
would
be
if
we
would
even
be
able
to
pass
the
security
area.
The
area
director
is
gonna
and.
F
E
There
would
be
good
reason
to
be
concerned
right
if,
if
what
we're
doing
essentially
is
weakening
TLS
1.3
somebody's
going
to
say
well,
you
better
go
into
a
lot
of
detail
as
to
why
you
aren't
increasing
the
correct
surface
in
in
this
regard,
and
I'm
not
going
to
be
the
guy
who.
F
E
H
D
I
think
when
I
was
talking
to
host
AP
and
Windows,
10
and
100
is
actually
the
same
and
all
the
implications
are
truncated
into
20
bytes,
so
I
I
think
we're
stuck
with
truncation.
Aren't
we.
A
We're
stuck
with
truncation
and
unless
we,
until
we
rev
the
protocol
or
rev,
the
I
think
the
crypto
binding
tlv
may
have
a
separate
version
on
it
or
we
could
create
a
different
crypto,
binding
tlv
right
that
that
you
know
just
a
different
tlv
number
that
could
have
an
extensible.
B
Or
or
another
option
is
simply
Define
it,
as
currently
with
truncation
for
TLS
1.2
and
then
say
by
the
way,
if
you
negotiate
TLS
one,
not
three.
The
crypto
binding
field,
crypto
binding
TLD
and
the
compound
Max
are
now
variable
sized
and
that
would
be
compatible
with
existing
implementations
because
nothing
implements
TLS
1.3
for
t
and
you
just
go
yep
whatever
they
do
for
TLS
1.2
that
gets
blessed
we're
not
going
to
change
it
and
for
TLS
1.3.
B
We
can
fix
it
later
or
not,
but
at
least
we
have
the
options
and
it
won't
break
anything
I.
Think.
B
Okay,
hickey
also
had
a
comment
about
eat
notification
and
knack
I.
Think
in
terms
of
Knack.
That's
all
just
Eve
discussions,
negotiation.
B
B
For
each
notification,
yes,
eat
notification
exists,
I'm,
not
really
aware
of
much
of
anything
that
uses
it,
but
it
might
be
useful,
necessarily
Thinking
Out
Loud
here
one
of
the
common
problems
for
any
kind
of
Wi-Fi
deployment
data
2
on
X
deployment
is
there
is
essentially
no
feedback
from
the
server
to
the
supplicant
through
to
the
end
user.
I
try
to
log
in
and
I
get
no.
What
happened?
Yeah
I,
don't
know.
Sometimes
I
might
get
certificate
errors.
B
There
is
no
way
to
get
any
kind
of
notice
back
through
to
the
end
user
saying
you
know
please
come
down
to
security,
your
account
has
been
canceled
or
what
whatever
yeah
so
so
just
thinking
out
loud,
given
that
we
have
a
prompt
for
the
basic
password,
it
might
be
useful
to
add
a
suggestion
saying
that
eat
notifications
should
get
sent
to
the
end
user.
B
This
is
a
change
from
7170,
but
it's
new
functionality
and
if
nobody
implements
it
right
now,
that's
fine,
I!
Guess.
The
question
would
be:
what
do
implementations
currently
do
if
they
get
a
eaten
notification,
instead
of
anything
else,.
G
B
B
B
B
Yes,
I
made
no
changes
to
the
document
and
instead
left
a
to-do
going.
We
have
to
discuss
this
and
figure
this
out,
so
this
Errata
has
no
solution
right
now,
foreign.
F
B
B
Yes,
I
do
believe:
okay,
yeah
I
believe
those
changes
mostly
got
pulled
in
I'll
double
check,
maybe
not
I'll
also
check
offline,
but
those
are
yeah.
We.
A
Should
still
validate
this
because
it
is
a
little
bit
of
a
tricky,
we
definitely
should
make
sure
it's
not
changing
anything
that
affects
implementations,
because
I
I
don't
think
it
would,
but
we
it
would
be
good
to
validate
that.
B
So
this
is
a
complicated
one.
Might
you
sense
would
be
table
this
one
for
now
and
move
on,
because
some
of
the
other
ones
are
pretty
straightforward,
and
this
way
we
can
make
progress
in
sort
of
not
90
of
them.
But
let's
do
that?
Okay,
let's
close
that
and
go
back
to
the
Errata
five
seven
five.
B
E
Yoni's
text
does
do
zeros
because
we
looked
at
this
and
actually
that's
what
we
borrowed,
what
we
did
we
sort
of
worked
that
text
in
order
to
get
something
going
when
we
were
doing
the
the
pkcs7pkcs
10
requests
that
having
been
said,
I'm,
not
sure
it's
the
right
answer
from
a
cryptographic,
standpoint
and
I
wrote
a
pretty
lengthy
message
about
this
now
and
then
we
had
a
nice
discussion,
actually
a
timely
discussion
right
between
Alexander
and
myself,
and
you
Joe
about
this
just
over
the
last
24
hours,
and
so
it
boils
down
to
what
what
sort
of
crypto
binding
is
needed
for
the
authentication
method.
E
What
sort
of
crypto
binding
is
needed
for
pkcs7pk,
cs10,
tlds
and
and
whether
whether
it's
whether
this
stuff
should
be
protected
in
any
case
and
there's
one
wrinkle,
we
didn't
get
into
an
email
which
is,
if
we're
going
to
bind
to
as
you
wrote
Joe
if
we,
if
we're
going
to
make
use
of
the
TLs
secret
information
for
this,
that
there
is
one
possible
man
in
the
middle
that
we
might
want
to
sort,
and
we
have
to
be
a
little.
E
We
should
give
a
little
thought
to
this,
which
is
when
the
Eep
server
is
not
the
ra
right
or
and
and
or
not
the
CA,
and
therefore
is
it
needs
to
basically
forward
things
on
to
an
Raca,
and
so
one
example
might
be
if
you're,
using
something
crazy.
Like
I,
don't
know
if
it's
so
crazy
if
you're
using
something
like
ESP
on
the
back
end,
for
instance.
Well,
then,
how
to
how
does
the
secret
information
from
TLS
get
all
the
way
to
the
ra?
E
You
have
to
have
essentially
a
proprietary
mechanism
to
do
it,
and
is
that
what
you
really
want
and
that
proprietary
mechanism
is
essentially
the
code
that
you
would
have
in
a
in
a
in
an
integral
implementation
of
the
server
and
the
ca.
So
so,
there's
a
little
bit
of
hair
around
that
that
we
haven't
yet
uncovered
I
feel
so
one
answer
is
that
we
do
away
with
the
password
components
here
and
we
just
use
the
crypto
binding
tlvs.
E
For
all
of
this.
That's
one
possibility.
Another
possibility
is
we
say
screw
it?
You
have
to
bind
to
the
the
you
have
to
have
this
integral
CA
capability,
but
that
might
have
some
pretty
interesting
deployment
implications
and
we
need
to
sift
through
that
a
little
bit
and
so
I
think
it
from
for
a
today's
standpoint.
Right
I'd
be
interested
to
hear
what
Alan
has
to
say.
E
I'd
actually
be
interested
to
hear
what
both
Oleg
and
Michael
have
to
say
in
terms
of
the
deployment
View
and
what
other
people
have
to
say,
and
maybe
we
close
this
out
on
the
next
call.
B
For
me,
I
no
worries
for
me.
I,
don't
have
a
lot
of
comments
on
this
I
I
see
the
cmk
derivation
is
a
bit
separate
from
some
of
the
other
issues
and
until
we
get
into
some
more
actual
implementations,
I'm
not
sure
I
want
to
sort
of
stick
my
neck
out
one
way
or
the
other.
Then
maybe
Alex
has
some
more
theories.
B
D
Foreign,
hey
I,
I'm,
wondering
about
if
you
are
talking
to
when
you
say,
EST
you're
talking
about
device
right,
I'm,
not
not
familiar
with
the
language.
Sorry.
A
E
To
say
it's
RFC
7030,
and
there
are
some
amendments
to
that:
some
updates
to
it.
Basically,
it's
a
restful
interface
to
do
pkcs10pk,
CS,
7
exchanges.
D
Yeah
I
am
I
would
have
trying
to
paste
that
in
I
would
have
I
I
I
would
have
thought
that
rest
API
would
let
you
submit
crypto
calculations.
D
It's
an
RFC
I
would
need
to
read
and
dig
around
I
don't
know.
I
would
expect
you,
because
the
the
HVAC
functions
or
the
prf
functions
are
sort
of
box
box,
standard,
high
level,
low
level
crypto
functions
that
you
should
be
able
to
submit
and
then
receive
a
reply
back
of
the
hash,
whilst
the
other
end
gets
to
retain
all
the
Keen
material
and
not
leak
it.
E
Just
just
to
follow
up
the
issue
here
is
that
the
Eep
server,
the
authentication
server,
has
the
the
appropriate
King
material
from
the
from
the
TLs
secret,
because
it's
got
the
TLs
connection,
which
is
shared
with
the
the
enrollee
right.
It's
just
that
the
back
end
CA
doesn't
have
that
information
and.
E
The
complication,
and
so
we
need
we
need
a
I
think
we
just
I
I,
think
we
just
need
to
give
it
a
little
bit
of
thought.
I
mean
there's
a
this
is
a
a
it's
a
little
bit
of
hair
but
I,
don't
think
it's
insolvable,
and
if
it
is,
the
simple
answer
is
screw.
It
don't
worry
about
trying
to
do
something
like
EST
on
the
back
end,
at
least
for
T
version
one.
We
just
keep
going.
A
Yeah
so
I
think
there
there's
the
the
issue
you're
mainly
raising
is
around
the
use
of
the
the
pkcs
10
tlbs
right
to
do
enrollment
and
so
I
think
we
do
want
to
take
a
close
look
at
that.
A
I
think
if,
if
I
remember
correctly,
when
when
we
did
this
like
either
Dan
or
somebody
had
recommended
the
text
that
we
put
in
the
pkcs
10
request
in
that
tlv
but
I
don't
know
if
that
was
in
mind
to
be
interoperable
with
s
or
to
provide
the
same
functionality
as
s
or
I
I'm,
not
I'm,
not
sure,
but
we
certainly
should
take
a
look
at
that,
because
I
don't
think.
A
If,
if
there's
a
better
implementation
route
there,
we
I
don't
think
anybody's
really
implemented
those
tlvs
as
far
as
I
know,
and
so
we
we
could,
you
know,
make
changes
there
and
to
kind
of
improve
that
and
I
also
think
we
can
cut.
We
may
be
able
to
address
the
inner
method
kind
of
binding
issues
separately.
I,
don't
I,
don't
know
that
those
two
things
have
to
be
linked.
A
B
Yeah
I
mean
if
we
go
back
and
forth
to
the
either
the
Errata
pushed
by
by
Joe
or
the
commits
to
the
southern
one,
Sony
Biz
document
and
just
look
for
five,
seven,
seven,
five
we'll
get
all
the
updated
text
there.
So
I
think
that
should
be
good
for
this
one.
B
Five:
eight
eight
four,
that's
relatively
straightforward:
a
bunch
of
the
diagrams
have
to
be
updated
to
show
that
there
is
either
an
intermediate
result,
tlv
of
success
or
failure.
Every
time
we
do
an
inner
any
Authentication.
B
B
No
controversy
moving
on
yes,
this
is
largely
duplicate
again.
D
B
B
No
no
worries
you
had
a
comment.
I
was
like:
oh
God,
put
it
in
the
document
before
the
meeting,
so
yeah,
there's
I,
don't
know
30
or
40
commits
in
the
7170
Biz
repo,
but
the
goal
there
was
to
have
each
commit
relatively
simple
and
understandable
and
referring
to
either
the
Iran
or
Joe's
comment
turbo.
B
B
So
yeah
I
think
the
consensus
is
crypto.
Binding
should
be
sent
along
with
intermediate
result,
tlv
and
result
tlv
and
the
crypto
binding
is
checked
before
you
look
at
result.
Tlv.
B
Let
me
just
check
what
I
did
because
I
made
lots
of
changes.
Let
me
see
type
Natalie
here.
B
No
I
think
that
should
be
accepted
because
there
should
be
some
additional
text.
I
think
the
the
the
change
noted
here
is,
except,
as
noted
below,
which
is
where
you
send
failure,
I
believe.
So,
if
you
send
failure,
then
you
don't
need
to
send
crypto
binding
because
you
have
no
msks,
but
you
can
still
send
an
inner
result
of
failure
which
is
protected
by
the
TLs
wrapper
and
you'll
have
no
crypto
binding.
B
But
well
you
can't
do
crypto
binding
if,
if
authentication
failed
and
then
the
rest
of
the
text
here
just
needs
to
be
double
checked.
E
B
E
E
If
the
text
is
close
to
Accurate,
we
can
verify
it,
but
for
some
of
these
more
complex
ones,
we
can
simply
hold
for
update
right
like
if
we
go
back
to
57.70.
If
we're
really
going
to
work
hot
and
heavy
on
getting
all
this
stuff
on
getting
the
this
current
draft
out,
then
you
might
as
well
hold
for
update.
We
work,
don't
worry
about
the
Errata
as
a
as
a
verification
we
just
we.
We
just
hold
for
update
and
work
on
it
in
in
Alan's
text.
A
Yeah
I
think
we'll
we'll
have
to
look
and
I
think
once
a
change
gets
to
be
where
you're
having
to
modify
multiple
places.
In
order
to
understand
the
change,
then
it
really
becomes
something
I
think
we
need
to
hold
for
update
if
there's
a
change
that
we
can
make
in
the
Errata
in
in
one
or
two
places
that
make
it
easier
for
an
implementer
who's.
A
Just
looking
at
this
document
to
get
something,
that's
interoperable,
we
could
consider
like
a
subset
in
the
in
in
the
Errata
if
it's
complete
enough
to
to
address
the
issue,
so
I
think
we'll
have
to
look
at
the
scope
of
the
change,
because
if
you
get
too
too
many
things
in
too
many
places,
then
it
just
gets
confusing.
B
Sure
this
one
is
really
this
text.
B
There's
now
a
sub
subsection
saying
by
the
way,
if
Ms
chap
is
not
used,
it's
the
Eep,
fast
Ms,
chat
and
I
think
this
is
the
biggest
interoperability
issue
that
people
ran
into
and
when
we
got
closure
on
this,
that
sort
of
what
what
triggered
the
the
timing
for
for
these
changes
so
I
think
that
should
be
either
verified
or
hold
for
update
Because
the
actual
text
and
the
update
will
be
different
from
this
I
can
pull
it
up
if
people
want,
but
it
doesn't
really
matter
a
lot.
How.
D
A
B
A
Propose,
as
we
keep
our
meeting
next
week,
and
we
try
to,
we
in
the
meantime
try
to
raise
some
of
those.
We
have
two
things
to
do
on
the
list.
One
is
raise
some
of
the
try
to
resolve
any
of
the
open
issues
and
get
the
for
things
that
we
want
to
put
into
an
Errata
I'll
work
on
getting
some
Errata
text
together,
based
on
Allen's
changes
to
see
which
ones
we
can
include
in
the
Narada
and
which
ones
we
would
hold
for
updating.
B
Yeah
there's
a
couple
other
changes
I
made
based
on
comments
on
the
list
and
things
I
found
like
the
one
that
I
remember
is
the
basic
password
was
not
marked
as
mandatory.
But
if
you
didn't
support
it,
you
were
supposed
to
send
a
error,
tlv
a
fatal
error,
and
that
was
not
allowed,
and
so
it
should
have
been
marked
as
mandatory
and
then
there's
a
couple
other
small
ones.
But
it's
one
of
these
things
that
I,
don't
think,
there's
a
lot
there,
that's
controversial.
B
B
A
Right:
okay,
we're
we're
at
the
end,
so
thank
you.
Everybody
for
participating,
we'll
we'll
hold
the
the
meeting
again
next
week
to
try
to
close
off
any
remaining
ones
and
then,
if
we
need
additional
ones,
we
can
we
can
schedule
them
at
that
time
or
after
that
meeting.