►
From YouTube: IETF111-UTA-20210728-2130
Description
UTA meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
hello,
everybody,
it's
half
past
midnight,
my
local
time
and
your
local
training
differ.
So
it's
using
tls
in
applications,
hooking
group
session
and,
let's
start.
A
Level
issues
on
the
idea
so
meeting
details
chairs
leave
your
hands
on
is
is
not
able
to
attend.
So
I'm
your
chair
today
and
our
responsibility,
differences
and
here
links
for
meeting,
slides,
notes
and
gems
and
we
need
to
perform
some
administrative
tasks,
so
we
should
circulate
it
automatically.
A
But
we
need
volunteers
for
describing
correct,
subscribe
in
german
one
job
describe
and
two
more
takers.
So.
B
B
I
can
take
minutes
in
the
other
pad,
although
I
have
some
comments
on
some
of
the
presentations,
so
maybe,
if
you
can
find
another
person
to
just
cover,
thank
you
elixir.
A
A
A
A
Okay,
let's
go
so.
This
is
a
quick,
quick
update
of
document
status,
so
we
can
group
draft.
So
we
have
three
drafts.
Currently
it's.
The
first
draft
is
71.25
piece
it
has.
A
It
has
been
developed
with
a
good
base
and
on
github
I
can
see
that
there
were
99
closed
issues
and
I
think
that's
the
also
things
that
the
draft
is
close
to
the
working
group
platform
and
another
draft
is
jls
details,
1.3
profile
for
internet
of
things,
and
it
was
also
it
has
been
developed
quite
well
recently-
probably
not
not
with
such
a
great
withhold
and
I'm
I'm
a
bit
concerned
with
a
good
discussion
on
the
list
but
anyways
the
draft
is
it's
been
developed
and
the
third
working
group
draft
is
5125
piece
and
it
is
it
it
becomes.
A
It
was
adopted
not
long
ago
and
first
it
was
a
modest
intention
just
to
change
a
common
name,
a
common
name,
relatively
distinguished
name
from
certificates,
representation
in
tls
to
subject
alternative
names.
It
is
proper,
more
proper
way
of
representing
jvs
names.
But
then,
following
our
ad
advice,
the
group
decided
to
replace
to
update
6125,
rfc,
6125
and
hopefully
well.
A
A
So
we
have
well
the
first
presentation
presentation
is
for
6125
b's
draft,
so
I
will
share
slides
just
a
moment.
D
Thank
you.
Success
miracle
can
hear
me
all
right.
My
name's
on
here,
because
I
did
the
slides,
but
peter
and
jeff
as
valerie
said,
are
being
co-authors.
Jeff
is
out
on
leave
vacation
until
september,
but
actively
participated
in
some
of
the
discussions
we
had
before
then
so
next
slide.
Please
all
right
changes.
We
made
kind
of
repeating
what
valerie
said.
It's
now,
a
complete
replacement,
not
a
diff
document.
D
The
peter
and
jeff
agree
to
be
co-authors,
grateful
to
them
and
to
for
that,
the
current
draft
matches
the
older
adopted
document.
I've
made
some
changes,
push
them
out
and
that's
what's
currently
in
the
data
tracker.
D
So
I
have
a
few
ideas
for
things
like
to
float
past
the
committee,
the
working
group
and
some
discussion.
So
next
slide.
Please
all
right!
These
are
the
planned
editorial
changes.
There
were
a
couple
of
paragraphs
on
the
directory
as
about
it
being
the
underpinning
of
rfc,
5280
and
pkix
certificates.
D
I
think,
while
it
was
the
theoretical
underpinning,
it's
really
not
anymore,
nobody
considers
a
global,
interoperable
directory
a
requirement
or
even
used.
So
I
want
to
remove
the
directory
text
that
also
takes
out
some
rather
ponderous
cross
references
to
iso,
and
you
know
iso
documents.
A
B
Quick
clarifying
question
so
the
text
about
directory
it
does
two
things
it
sort
of
has
a
bit
of
history,
which
is
probably
not
relevant,
but
it
also
explain
dns
and
common
names.
And
all
of
this
do
you
want
to
keep
the
part
that
explained
the
common
names,
because
I
think
the
idea
was
that
you
don't
have
to
go
and
to
dig
into
ldap
documents
to
figure
out
what
they
are.
If
you
are
not
familiar
with
context.
D
D
B
A
B
Okay,
I
suppose
I
would
like
to
see
how
it
it
looks
in
the
change.
Okay,
all
right.
G
D
D
D
All
right,
the
next
bullet.
If
this
is
a
standard,
the
previous
document
6125,
was
the
standard.
I
misinterpreted
it.
I
thought
it
was
a
bcp
document,
but
I
think
there's
a
lot
of
simplifications
we
can
do
to
the
text.
Certainly
float
them
past
the
you
know
the
working
group
before
doing
it,
there's
a
lot
of
constructs
like
if
a
specification
is
using
this
standard,
then
blah
blah,
blah
or
a
standard
may
use
this
and
then
do
other
things.
I
I
think
we
should.
D
Basically,
you
know,
want
to
narrow
this
down
to
use
the
subject
alternate
alternate
names
field
and
that's
the
rule
we'll
discuss
that
on
the
list,
but
I
think
it's
it
may
not.
Just
I
can
see
where
some
people
may
not
see
it's
just
editorial,
but
that's
also
something
I'm
planning
on
doing
in
future
versions
of
the
draft.
Assuming
the
working
group
agrees.
D
There's
some
discussion
about
block
block,
quote
formation
about
implementation,
notes
and
security
concerns.
I
I
think
those
could
either
be
inlined
or
just
removed,
but
again
these
are
things
I've
I'd
like
to
do.
I
have
sample
text
it's
in
the
form
of
pull
requests,
but
I
will
post
them
to
the
list.
A
A
D
This
is
an
editorial
change
and
I
hope
we
can
figure
out
what
to
make
at
the
level
of
bike
shedding.
I
guess
that's
a
lot
of
words.
H
You
can
you
can
truncate
tls
down
to
just
tls.
We
got
that
added
in
the
rfc
editor's
queue
of
short
of
things,
but
I
don't
know
I
can
help
you
with
the
rest
of
it.
D
Yeah
great
sure,
any
anything
I
recognize
it's
very
accurate.
D
D
So
these
are
things
that
definitely
need
consensus
about.
I
think
we
have
consensus
around
the
first
one,
but
you
know
I
I
guess
the
chairs
call
it.
Nobody
was
opposed
to
just
making
it.
You
know
the
asterisk
is
the
the
wild
card
character
is,
can
be
only
the
first
component
of
a
dns
name
as
opposed
to
you
know,
star,
foo
or
star
www.sample.com.
D
Do
I
just
go
ahead
and
make
that
change?
Do
we
need
to
do
it?
I
mean
how
how
do
I
handle?
How
do
we
handle
that.
A
From
what
I
see
from
the
discussion
on
the
list,
I
think
that
there
is
a
consensus
and
because
nobody
opposed
and
for
for
different
reasons.
Well,
everyone
agreed
to
feelings
and
we
can
issue
a
formal
consensus
call.
But
actually
I
don't
see
a
need
for
this
unless
someone
strongly
prefer
to
have
some.
I
don't
know
formal
procedure,
but
actually
I
think
there
is
a
consensus
for
for
wild
cards
and
what
about
okay
and
what
about
standard
strike
and
bcp
yeah
opinion.
D
Yeah-
that
was
my
mistake.
It
was
originally
you
know,
it
was
an
ad-sponsored
standards
track
document
peter
had
reminded
me
of
that.
D
So
I
think
the
second
bullet
is
is
moot
it's
the
third
one
is
there's
a
there's.
A
fair
amount
of
discussion
about
pinning
and
pinning
is
when
an
application
for
ideally
presents
to
the
user.
Oh,
this
cert
has,
for
whatever
reason,
expired
or
has
a
different
name
than
this
than
the
server
you're
trying
to
connect
to
should
I
still
use
it
and
the
steps
for
processing
include
if
you
find
a
match,
if
you
don't
find
a
match
and
something
is
pinned
or
if
you
find
a
match
and
there's
nothing
pinned.
D
What
do
you
do?
So
I'm
curious
what
the
working
feels
about
the
pinning
putting
pinning
in
here,
given
that
we're
mainly
focused
on
verify
what
to
do
and
how
to
verify
names
inserts.
B
I
J
I
Pinning
creates
problems,
I
I
think
we
should
drop
it.
I
think,
even
better.
We
should
explicitly
recommend
against
it
the
number
of
times
that
it
creates
issues.
It
creates
problems,
especially
when
pinning
the
publicly
trusted
search
or
creates
issues
for
being
able
to
distrust
ca.
It's
not
not
a
great
situation.
G
I
also
support
pinning
as
out
of
scope
for
this
document.
It
should
only
specify
how
to
verify
a
cert
if
you
want
a
pin
that
can
be
specified
elsewhere
or
not
at
all,
doesn't
belong
here.
D
Yeah,
the
other,
I'm
also
opposed
to
it
because,
like
watson
said
it
does
create.
D
A
So
please
continue
discussion
on
the
list
and
we
have
very
likely
discussions
recently
and
I
think
this
documentary
in
progress,
which
will
be
oh
victor,
please
go
ahead.
G
So
I
think
we
closed
that
discussion.
There
was
some
conversation
around
maybe
getting
rid
of
wild
cards
entirely,
and
I
think
the
consensus
ultimately
was
that
we
can't,
but
maybe
a
few
words
of
caution
can
be
added
to
say
that
wild
cards
should
be
avoided,
if
at
all
possible
that
while
they
have
their
uses,
they
should
not
be
used
casually.
D
Sure
they
do
have.
There
is
a
particular
specific
section
in
the
security
considerations
and
there's
forward
references
to
it
about
some
of
the
security
issues
around
wild
card
certs-
and
I
wasn't
you
know
we
shouldn't
get
rid
of
that.
But
maybe
if
you
get
a
chance
to
take
a
look
at
that
and
see,
if
there's
more
words,
we
need
to
add.
D
A
K
So
peter
hey,
I
have
a
question
the
clarifying
question
for
victor
in
the
chat
he
said
we
were
talking
about
standards
in
bcp
and
he
said
standard.
So
I
was
curious
if
he
meant
that
we
he
thinks
we
should
actually
go
from
proposed
standard
to
standard
and
advances
on
the
maturity
level.
G
G
K
Yes,
thanks
for
making
the
time
for
us,
I
think
yaron
and
tomas
might
be
here,
but
it's
late
for
them,
so
I'm
presenting
next
slide.
K
So
we
we
had
a
bit
of
a
hiatus
jaron
and
ralph,
and
I
had
a
bunch
of
activity
around
this
like
18
months
ago
and
then
sort
of
dropped,
the
ball
and
and
so
we
had
a
tomas
as
a
co-author
that
has
helped
us
move
things
along.
We
addressed
a
bunch
of
issues
that
we
identified
several
attacks,
things
like
that
and
I'll
summarize
those
briefly
for
you
all,
and
then
we
can
talk
about
some
of
the
open
issues
that
we
would
like
some
feedback
and
further
discussion
on.
So
next
slide.
K
K
If
you
are
looking
for
things
that
don't
exist
in
tls
1.2
very
easily,
you
know
we
have
some
things
about
that
on
the
next
slide:
cha,
cha,
20
and
so
on.
We're
not
trying
to
sort
of
get
people
to
do
those
things.
Tls
1.2,
we're
suggesting
that
people
move
forward,
tls
1.3
for
those
sorts
of
things,
but
rationales
for
all
these
things
are
all
these
document
updates
are
in
the
document
and
we
always
try
to
provide
a
rationale
for
the
things
that
we're
suggesting
in
this
spec.
K
K
So
a
few
things
as
I
hinted
just
now
that
we,
the
authors,
went
back
and
forth
on
and
didn't
really
have
consensus
amongst
ourselves
to
make
these
changes
specifically
chacha
20,
poly
1305
and
an
ec
dsa
cypher
suite
for
tls
1.2.
Again
this
is
1.2
and
you
know
where
we
we
did
some
research
we
poked
around.
We
asked
people
who
have
maybe
some
numbers
on
this
and
we
didn't,
especially
with
regard
to
chapter
20,
paulie
1305.
K
We
did
not
get
a
definitive
read
that
these
things
were
widely
enough
used
to
really
call
this
best
current
practice
or
try
to
push
people
in
this
direction
for
tls
1.2,
and
so
we
would.
We
were
kind
of
curious
from
the
folks
in
the
working
group
whether
they
think
these
are
things
that
we
should
go
ahead
and
try
to
suggest.
But,
as
the
authors
we
went
back
and
forth
on
this
and
didn't
have
enough
evidence
that
we
could
really
push
for
this
in
25
bits.
K
K
I
think
the
feedback
we
got
on
list
was
those
might
or
might
not
be
good
things,
but
just
taking
someone's
word
on
it
from
the
nsa
isn't
necessarily
the
the
right
thing
to
do,
and
if
we
do
think,
though,
that
some
of
these
are
important,
we
should,
as
we
do
for
everything
else,
provide
a
rationale
and
some
evidence.
K
So
I
see
deb
is
here
and
that
would
be
helpful
feedback,
but
I
think
some
of
the
things
that
some
of
the
feedback
we
got
was
you
know
these
look
interesting,
but
maybe
we
need
to
do
a
little
bit
more
investigation
and
write
up
some
text.
That
says,
if
we're
going
to
take
these
on,
why
they
are
sort
of
best
current
practice
now,
so
I
will
defer
to
the
to
the
queue.
E
I
haven't
done
this
yet
this
time,
so
I'm
happy
to
help.
If
you
want
to
take
advice
out
of
my
draft,
I'm
happy
to
provide
rationale.
I'm
happy
to
provide
advice.
You
know
whatever
you
want.
I
don't
follow
utah
very
much,
so
I
didn't.
I
hadn't
seen
that
message,
but.
I
K
K
K
You
that
that's
very
that's,
I
appreciate
your
your
offer
and
we
it
just
sort
of
came
to
our
attention
recently,
and
so
we
haven't
delved
into
it
as
the
authors,
and
maybe
I
will
start
an
email
thread
either
on
the
utah
list
or
or
with
you
so
we
can
get.
You
know,
get
a
better
understanding
of
some
of
these
recommendations.
A
I
Watson
lad,
the
my
concern
with
you
know:
recommend
bigger
rsa,
fine
recommend,
bigger
dhe,
fine
when
it
comes
to
ecdh8.
There
is
a
huge
performance
in
impact
with
moving
to
p38
or
it's
not
as
well
optimized
as
p256
harder
to
optimize
for
various
reasons
you
don't
need
to
get
into
and
there
would
need
to
be.
I
need
to
see
significant
security
justification
which
isn't
in
the
cnsa
profile.
I
don't
think
it's
a
great
basis
for
adopting
it,
and
I
think
you
know
increasing
the
rsa
side.
Increasing
dhe
size
may
be
more.
K
Justifiable
yeah
thanks
swanson,
I
think
the
other.
K
What
I
was
seeing
from
the
list
discussion
was
some
of
these,
like
you
say,
even
the
rsa
and
dhe
things
maybe
point
toward
that,
but
not
don't
necessarily
say
that
you
should
do
this.
Yet
I'm
not
sure
where
we
haven't
finished
that
discussion
on
the
list,
but
I'm
not
sure
that
we're
quite
there
yet.
K
Not
seeing
anyone
else
in
the
queue
I
I
don't
think
that
maybe
it's
just
one
other
slide.
I
can't
even
remember,
but
there.
G
K
Tomas
and
yaron,
and
I
have
tried
to
be
pretty
thorough
about
what
we
have
updated
so
far
and
trying
to
address
a
number
of
the
attacks
that
are
out
there
and
so
on
else
might
come
up,
but
I
think
we,
as
the
authors,
feel
that
this
is
now
pretty
complete,
based
on
the
current
understanding
of
how
people
are
using
tls
in
the
field
right
now
again
best
current
practice.
You
know
this.
K
We
think
we've
kind
of
summarized
everything,
and
so,
if
folks
have
other
things
that
they
want
us
to
address
attacks,
we
haven't
heard
of
things
like
that.
It
would
be
great
to
try
to,
I
think,
get
that
done
in
the
next
few
months,
so
that
we
can
maybe
request
working
group
last
call,
as
I
say
here,
maybe
around
ietf
112,
before
or
after
that,
probably
a
little
after.
I
don't
know
I'll
leave
that
up
to
the
chairs,
but
I
think
we
feel
that
this
document
is
now
in
pretty
good
shape,
modulo.
A
A
So
it
is
not
clear
for
me,
for
example,
whether
we
need
to
profile
to
add
some
recommendation,
some
specific
cypher
suite
recommendation
for
tms
1.2,
and
probably
we
need
to
consult
this
working
group.
What
would
they
what
they
think
about
this,
whether
it's
a
good
idea
or
whether
we
need
to
encourage
people
to
switch
to
1.3
and
not
use
one
for
two
impossible?
K
I
haven't
seen
anyone
write
a
draft,
yet
that
says:
don't
use
tls
one
to
two,
so
I
think
the
the
specific
focus
for
yaran
and
tomas,
and
I
is
simply
that
if
you
want
some
of
these
features
that
you
might
get,
for
instance,
chacha,
20
and
poly3
13.05.
If
you
want
those
things
use,
tls
1.3,
don't
try
to
sort
of.
K
You
know,
update
your
implementation,
your
1.2
implementation
or
1.2
deployment
to
get
those
necessarily
1.3
is
the
place
to
get
those
so
that's
kind
of
where
we've
ended
up
for
as
the
authors
of
this,
but
that
we
think,
is
a
sensible
way
to
go.
But
if
the
group
says
you
know
we're
seeing
a
lot
of
implementation
of
the
deployment
of
these
in
the
field
with
1.2,
and
that
might
be
something
that
we
want
to
say.
K
This
is
a
best
practice
for
1.2
and
then
five
years
from
now
or
whatever
we've
got
a
new
update
to
this
document.
That's
and
there's
another
document
out
there
that
says:
stop
using
1.2.
You
know,
then,
this
this
document's
going
to
have
to
change,
but
this
is
kind
of
a
you
know.
What
do
we
do
about
1.2
right
now
and
rich
is
in
the
queue
so.
D
Yeah
I
I
totally
agree
with
your
reasoning.
I
mean
if
you
how
to
configure
a
stock
1.2
and
then
saying,
and
if
you
want
these
things,
which
are
highly
desirable,
upgrade
to
1.3,
I
mean
that's,
I
think
that's
the
least
friction
way
to
get
people
who
have
existing
enterprise
or
other
embedded
deployments
to
get
their
security
stronger.
D
Yes,
many
of
the
1.2
implementations
have
cha
cha
poly
already,
but
many
probably
don't
because
they
oh
it's
a
new
feature.
I
don't
need
it.
So
here's
how
to
make
those
basic
features
more
secure
and
if
you
really
want
better
security,
go
to
1.3
and
so
yeah
your
rash.
Your
reasoning
makes
a
great
deal
of
sense
and
I
fully
support.
A
It
and
oh,
and
what
about
the
second,
the
second
concern
and
suggestion
from
I
think
that
I
agree
that
there
must
be
some
reasoning,
some
justification,
because
just
citing
jimmy
say,
recommendations
well
looks
strange
because
it's
a
national
national
standards
that
are
applied
to
united
states
and
unless
we
have
some
justification
well,
I
understand
that
if
they
used
not
only
in
the
united
states
but
everywhere,
but
I
think
it's
having
a
justification
from
there,
so
she
agrees
to
help.
A
A
D
Yeah
in
the
chat
there's
been
discussions
about
the
rsa,
the
dhe
things
are
fine,
p80
p384
might
have.
Some
has
concerns
about
efficiency
and
stuff
and
again
I
think
we
can
address
that.
The
same
way
p384
was
in
tls12,
255.19
and
448
were
not
and
say.
Look
if
you
want
this
level
of
security
by
the
way
go
over
there
and
do
the
other
you
know,
upgrade
your
protocol
but
yeah.
I'm
not
sure
what
you
want
to
say
about
the
you
know.
P384
specifically,
but
I
think
stronger
key
links
is
you
know.
B
Steven
wanted
us
to
relate
to
the
mic.
Has
anyone
looked
at
the
docs
referencing
this
pcp
to
check?
If
there
is
anything
we
might
break
by
accident,
sorry
cannot
send
audio
at
the.
K
Moment
just
to
speak
on
behalf
of
myself
as
a
co-author,
I
and
I
don't
think,
I'm
speaking
out
of
term
with
for
yaron
and
tomas.
We
have
not
done
an
investigation
of
this,
as
yaran
said
in
the
chat.
There's
a
huge
number
of
documents
that
reference
this
they're,
both
inside
the
ietf
and
outside
the
itf,
and
you
know
we
could
go
to
yachty's
tool
and
sort
of
look
at
the
itf
ones.
But
you
know
we
should
do
a
little
bit
of
that.
K
I
think
I
couldn't
promise
that
it
would
be
comprehensive,
since
there
are
a
lot
of
documents
out
there
that
reference
this,
but
I'd
also
be
curious,
maybe
from
stephen.
If
he
has,
when
you
say
break
things,
do
you
have
specific
concerns
in
mind
with
regard
to
that.
G
I
had
to
drop
off
for
a
while.
So
I'm
sorry
if
my
comment
is
due
to
a
misunderstanding
and
missing
part
of
the
slides,
but
I'm
seeing
here
in
the
slide.
That's
currently
up
talk
of
raising
the
floor
on
rsa
and
you
know,
ec
to
30,
72-bit
and
384,
and
so
on,
and
my
take
is
that
this
is
quite
unwise
if
quantum
resistance
is
a
factor
it'll
just
as
easily
break
these
as
it'll
break
the
current
2048
and
and
256.
G
And
otherwise
you
know
the
various
extant
route
cas
are
signed
with
2048-bit,
rsa
and
they're
good
for
decades
and
are
unlikely
to
get
updated
quickly
and
the
performance
impacts
are
quite
noticeable
and
I
don't
see
the
ecosystem
moving
to
30
72
bit
or
to
p384,
which
is
barely
used
anywhere.
F
A
comment
to
to
stephen's
question
and
I
don't
want
it
to
sound
like
we
are
being
reckless-
on
the
contrary,
we're
quite
conservative
with
the
changes
we're
making,
but
we
don't
have
the
same
kind
of
we
don't
have
full
backward
compatibility
requirements
in
a
bcp.
F
So
so
we
would.
It
is
an
opportunity
for
us
to,
as
as
victor
said
before,
to
raise
the
flow.
A
So
I
see
nobody
in
the
queue
and
certification
sent
to
your
own
70
tons
and.
K
What
I'm
hearing
valerie
just
the
interrupt
sorry,
is
that
we've.
I
K
A
lively
discussion
in
the
chat-
and
you
know
we
might
want
to
sounds
like
we
might
want
to
bring
some
of
that
to
the
list
just
to
to
get
some
closure
on
things,
and
that
would
help
us
close
out
some
of
these
open
issues
that
we
have
up
here.
A
Okay
sure
this
brings
us
to
the
list.
I
just
didn't.
K
Yeah,
of
course,
no
we
can
go
over.
We
can
go
over
the
you
know
the
the
chat
chance
transcript
and
you
know,
pull
out
tease
out
some
things,
and
I
can
promise
to
do
that
and
then
you
know
start
some
or
start
or
restart
some
threads
on
the
email
list
to
try
to
get
closure
on
these
okay.
A
H
Hi
so
this
might
be
flame
date,
but
I
just
thought
I'd
ask
anyways.
After
this
current
crop
of
documents
is
done.
Do
we
see
that
this
working
group
will
close.
A
I'm
not
sure,
well,
I
I
think
it
should
be
discussed
with
our
responsible
ag
and
we
discussed
a
little
bit
at
the
time
francesca
step
up
as
and
their
overall
opinion
was
that
this
group
may
remain
as
a
maintenance
growth,
because
we
have
we,
we
see
an
adoption
of
tvs,
1.3
and
we
are
anticipating
adoption
of
details
1.3
and
we
think
that
some
issues
with
these
protocols
may
erase,
and
so
there
might
be
a
need
to
update
documents
recommended
and
protocols
should
be
used
in
applications.
A
But
anyway
it's
questioned
mostly
to
our
id
responsibility
and
well
now
we
hadn't
have
no
plans
to
close
the
group.
Well,
not
me,
I
mean
francesca
and
the
chairs
have
no
plans
to
close
the
group
immediately
after
the
documents
are
shipped.
B
Thanks,
it
depends.
C
Hi
hi-
this
is
honest,
hope
you
can
hear
me.
I
want
to
briefly
talk
about
the
iot
version
of
the
draft
which
we
didn't
didn't
have
on
the
agenda,
but
you
mentioned
it
briefly
at
the
beginning
of
the
session,
I
I
will
post
or
I've
added
the
link
into
the
meeting
minutes
and
I
will
post
it
into
the
chat
window,
but
there
are
three
open
issues
and
one
relates
to
a
discussion
in
the
dls
working
group
and
and
also
in
some
of
the
iot
groups
on
the
ae.
C
Aead
limits
that
john
madison
sort
of
brought
forward-
that's
something
maybe
in
the
cfrg
group
that
would
be
worthwhile
to
discuss
thomas
also
filed
an
issue
on
the
respective
cfrg
document
hasn't
been
addressed.
Yet
so
maybe
that's
a
discussion
there
with
the
conclusions
being
folded
in
into
the
document
in
this
group
there
was
also
another
issue
that
came
up
in
the
dls
working
group
on
how
to
do
the
certificate
revocation
in
long
lasting
connections
so
previously
in
in
1.2.
C
There
was
the
session
resumption
and
some
people
use
that
to
then
sort
of
like
kind
of
recheck
certificate
status,
and
so
I
think
we
need
to
add
some
text
in
explaining
that
some
of
those
features
have
changed
and
their
approach
for
doing
their
certificate.
C
Checking
of
connections
that
stay
up
very
long
needs
to
be
done
differently
than
before,
and
then
the
last
open
issue
that
I
know
of
is
the
setting
of
the
retransmission
timers
for
dtls
in
particular,
because
in
1.2
the
mechanism
for
dealing
with
lost
packets
was
different
than
it
is
now
in
1.3.
So
it's
more
fine-grained
from
a
coronal
narrative
point
of
view
in
1.3
and
there
we
might
actually
need
to
do
some
some
experiments
to
see
what
the
what
the
implications
are.
C
I
just
wanted
to
make
you
guys
aware
of
this
and
and
all
these
issues,
and
if
you
have
some
comments,
just
drop
a
mail
to
the
list
or
send
us
a
mail.
A
So
please
bring
them
to
the
list
so
that
discussion
can
be
started.
K
This
is
peter
just
hello,
hannes,
to
follow
up
on
your
first
question
there
we
did
talk
with
the
authors
of
that
cfrg
draft
and
they
are
going
to
incorporate
some
aead
updates
to
the
text,
but
this
was
with
regard
to
the
issue
that
we
raised
for
7525
bis.
I
have
not
personally
looked
at
the
iot
profile
thing
in
a
while,
so
I
will
endeavor
to
do
that.
C
Yeah
thanks
a
lot
yeah,
it's
the
aed
limits
document
in
cfrg
is
is
quite
good
indeed
that
obviously
references
the
the
literature
there
and
in
nutshell,
we
had
a
discussion
with
john
and
he
believes
that
the
inaudible
analysis
or
the
the
summary
of
those
papers
is
incorrect.
C
A
I
Hello
watson
here
I
agree
with
that
honey
there
might
that
there
might
be
more
work,
I'm
just
not
sure
that
we
still
would
need
uta
like
it
might
be
at
the
most
appropriate
venue
to
continue
this
after
we
publish
these.
Two
documents
would
be
back
in
tls
now,
tls
1.3
is
out
and
dtls
1.3
is
out,
and
it
shifted
back
to
the
pattern
was
before
the
start
of
creation
of
tls.
It's
sort
of
weird
to
have
two
groups
devoted
to
tls.
A
Well,
thank
you
for
your
opinion.
Well,
I
think
it
can
be
discussed
and
I
think
that
it
is
francesca
who
francesca
who
decided.
J
A
A
A
I
think
we
have
finished
all
of
the
agenda
items,
so
we're
done
15
minutes
ahead
of
time.
A
So
I
encourage
everybody
who
had
presentations
today
to
bring
open
issues
to
the
list
to
to
have
a
discussion
on
the
list
because
for
quite
a
lot
of
time
risk
was
quite
low.
But
recently
recently
we
have
very
lively
discussions
on
the
documents
of
6125ps
and
it's
a
good
intricate
thing.
So
you
continue,
and
so
I
think
that's
all.