►
From YouTube: IETF112-SAAG-20211111-1600
Description
SAAG meeting session at IETF112
2021/11/11 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
The
clock
has
just
ticked
over,
but
I
don't
think
we
have
a
hugely
packed
agenda,
so
I'm
not
gonna
quite
be
in
a
hurry
to
start,
I
think,
we've
neck
is
only
showing
about
70
people.
A
I
think
the
suggestion
of
working
group
theme
songs
might
be
something
we
have
to
talk
about
in
the
future,
maybe
at
the
open
mic.
I
just
saw
in
the
chat.
A
A
B
All
right,
so
we've
we're
up
to
86
people
now,
I'm
showing
so
might
as
well
go
ahead
and
get
started.
So
I'm
ben
caduck
and
my
co-id
is
also
sending
everything
so.
A
B
Romeo
yeah
here
are
the
security
ids.
So
this
is
the
security
area,
advisory
group,
the
open
meeting
and
let
us
get
started.
So,
of
course,
this
is
the
itf
meeting
and
we're
under
the
note.
Well,
it's
already
thursday.
So
hopefully,
this
is
not
new
to
anyone,
but
we
have
a
number
of
authoritative
bcps
that
lay
out
the
sort
of
ipr
regime
for
which
that
applies
to
the
itf
meetings
idea
contributions.
So
please
note
them
well
next
slide.
B
You
know
the
the
itf
guidelines
for
conduct
that
we
want
to
aspire
to,
so
if
we
can
always
make
sure
to
be
respectful
and
courteous
to
other
participants
and
to
remember
that
you
know
the
the
background
and
the
assumptions
that
we
bring
to
the
table
are
not
going
to
be
universal,
like
different
people
are
coming
in
with
different
environments
that
they
run
in
and
different
needs
for
their
technical
situations,
and
so
we
want
to
acknowledge
that
there
are
going
to
be
different
assumptions
and
perspectives
coming
in
and
we
want
to
try
and
understand
those
and
work
to
the
best
solution.
B
Overall,
all
right
next
slide.
B
So
again,
this
is
the
thursday
session
which
is
supplementing
what
we
had
on
tuesday
so
down
the
bottom
of
the
slide,
we're
going
to
have
the
usual
mistrivia
agenda,
bashing
and
then
working
reports,
the
ed
reports
and
a
talk
from
the
tls
chairs.
A
B
B
So
we've
tried
to
get
links
into
the
slides
when
they
exist
to
mail
archive,
so
ace
is
all
set.
Let's
keep
going
acme,
I
think
just
met
earlier
this
morning.
Cozy
did
meet.
Hopefully
we
can
get
a
report
from
them
or
or
just
to
mention
the
mic
today,
as
we
keep
going
gene
app,
I
think,
met
earlier
today
as
well.
B
C
B
Suit
is
good
chaos.
We
had
a
good
session,
we'll
be
hearing
from
the
chairs
again
as
well.
C
D
Provide
a
quick
summary
on
ohio.
We
spent
most
of
the
time
reviewing
the
proposed
starting
point
drafts
and,
I
think
we've
we
did
an
adoption
call
at
the
end
of
the
meeting,
which
was
pretty
favorable,
confirming
that
adoption
call
on
the
list
right
now.
B
B
So
I
think
we
can
go
to
the
next
slide.
Yeah
actually
just
barely
slip
over
onto
two
slides
of
groups,
not
reading.
But
if
you
go
back
to
the
first
one,
I
tried
to
remember
a
few
notes
on
that.
So
curdle
is
probably
going
to
close
once
the
last
document
gets
through
the
rfc
editor
it's
in
the
queue
there
and
I
think
many
of
these
groups
are
holding
interims,
whether
dedicated
or
periodic
regular
interims.
B
So
it's
not
like
they're
they're,
not
doing
any
work
at
all
and
then
back
to
slide
two.
The
second
event
group
is
probably
also
going
to
be
closing
scene.
There
was
we
finished
the
chord
drafts
some
time
ago,
and
then
there
was
energy
to
work
on
one
more
related
draft
and
we
should
either
finish
that
up
or
just
to
declare
victory
and
close.
B
E
Yeah
hi,
as
ben
noted,
we
had
an
in
room
for
mls.
I
did
just
like
seconds
ago
send
an
update
to
the
mailing
list,
so
people
can
see
it.
The
the
nutshell
here
is
that
we're
about
done
with
the
protocol
draft.
The
next
version
is
going
to
probably
enter
working
group
last
call
sometime
in
december
and
then
hopefully
we'll
get
enough
reviews
on
the
architecture
draft.
So
we
can
work
into
a
blast,
call
that
and
so
then
we
can
send
both
to
the
isg.
You
know,
hopefully
in
the
first
quarter
of
2022.
B
B
So
this
is
a
opportunity
if
anybody
knows
much
about
some
related
work,
whether
or
not
it's
listed
on
this
slide,
please
feel
free
to
to
jump
up
to
the
mic.
I
think
sam
weiler
also
sent
just
now
an
update
from
the
w3c,
which
has
quite
a
bit
of
potentially
interesting
work,
going
on
just
just
skimming
the
email
lisa
so
that
as
well.
A
While
we
have
folks
coming
up
to
the
mic
to
talk
about
some
of
the
some
of
these
activities
here,
I
want
to
mention
we
did
hold
the
priv.
I
think
it
was
quite
successful.
There
was
quite
a
lot
of
support
voiced
for
it
also
what
it
was
positive
out
of
it.
B
And
I'm
not
seeing
anybody
training
the
queue
either,
so
I
guess
we
can
keep
going
and,
of
course,
we'll
have
the
open
mic
at
the
end
of
the
meeting
as
well.
If
there's
more
to
cover,
so
I
guess
I
can
say
a
few
words
about
my
two
80
sponsored
drafts
here.
The
security
txt
is
in
the
rc,
editor
queue
and
it's
actually
still
waiting
on
me.
B
We
had
been
preparing
to
go
forward
with
some
very
generic
abnf
for
the
file
format,
but
I
got
some
updated
abnf
from
murray
that
actually
can
represent
the
full
pgp,
clear
sign,
header,
footer
and
whatnot,
and
so
I
need
to
actually
go
and
validate
that
and
get
another
review,
and
then
we
should
be
able
to
to
go
forward
with
security.
Txt
numeric
id
set
considerations
is
still
a
little
bit
stalled.
I
didn't
really
make
any
progress
on
that
since
itf
111.
A
Yeah,
so
for
my
documents,
the
the
updated
ers
asn
kind
of
one
modules
are
with
the
rfc
editor.
I
think
it's
all
quite
straightforward
from
there
and
then
I
just
started
processing
the
update
to
6931
the
best
document
to
get
the
new
uris
for
for
all
the
various
xml
security
kinds
of
things.
That's
really
new
with
in
terms
of
being
in
revised
kind
of
aed.
I
I
expect
we
can
probably
get
that
button
up
relatively
quickly.
A
We
do
do
still
need
w3c,
concurrence
and
kind
of
feedback
on
it
before
you
know
we
get
we
get
to
ietf.
Last
call
thanks
all
right.
Other
things
to
note
from
ben
and
my
kind
of
perspective.
The
first
thing
we
just
wanted
to
call
out
is
earlier.
A
This
week
we
updated
the
wiki
that
talks
about
the
security
area
to
refresh
the
content
and
make
it
hopefully
a
little
more
accessible
to
understand
how
to
bring
new
work
and
for
others,
perhaps
not
steeped
in
all
the
different
sec
area,
kind
of
processes
about
how
sector
works
and
how
you
know
this,
this
venue
kind
of
sag
works.
So
please
take
a
look
if
you
think
we're
missing
content.
You
know
by
all
means
kind
of.
Let
us
know
we'd
like
this
to
be.
You
know
something
that
is
a
resource
and
is
accessible
to
folks.
A
Other
highlights-
and
this
is
this
is
a
repeat
that
we
do
really
every
time
we
we
meet
here
in
sag.
Is
we
just
like
to
reiterate
that,
based
on
the
work
done
by
sector
and
the
process
that
ben
and
I
go
through
in
all
the
ad
and
telechat
reviews
that
there
are
recurring
issues
that
do
come
up
fairly
commonly?
We
do?
Have
those
documented
and,
as
you
know,
in
augmentation
as
folks
go
are
getting
already
published.
Their
documents
or
as
working
groups,
are
ready
to
send
things
to
itf
last
call.
A
We
would
strongly
urge
them
to
consult
that
list
to
make
sure
that
it
does
not
manifest
itself
in
in
that
document.
Also,
in
the
spirit
of
transparency.
You
know
this
is
not
a
new
feature,
but
you
know
it.
It
constantly
actually
kind
of
comes
up
that
folks,
don't
realize
that
this
is
possible.
If
you
want
to
know
what
ben's
queue
looks
like-
or
my
cue
looks
like,
you
know,
where
we're
holding
documents,
what
the
rest
of
the
sec
area
kind
of
looks
like
in
terms
of
processing
after
it
exits
the
the
working
group.
A
So
in
iesg
review,
or
in
last
call
you
can,
you
can
use
those
two
urls
to
get
that
status,
information
and
then
the
other
thing
we
wanted
to
highlight
is
one
of
the
actions
we
are
holding
is
the
continued
thread
on
what
we
do
with
post
quantum
agility.
A
So
since
that
does
come
up
and
it
came
up
in
the
the
sag
session
kind
of
in
session
one,
we
did
make
a
summary
page
that
you
see
referenced
there
that
pulls
together
all
the
different
conversations
that
we've
had
and
we
still
have
an
open
thread
on
the
main
list
to
give
us
more
feedback
on
that
proposed
charter.
So
we
know
how
to
to
move
forward.
A
A
There's
been
some
changes
in
where
we
stand
with
working
groups.
I
know
we
we
often
kind
of
talk
about
broadly
in
the
itf.
How
has
coved
impacted
you
know
the
creation
of
new
work
so
from
the
sec
area
perspective.
Since
the
last
time
we've
met,
we
have
spun
up
three
new
security
focus
working
groups.
We
we
talked
about
ohi
in
the
in
the
in
the
working
group
reports.
A
Dance
is
going
to
be
meeting
for
the
first
time
tomorrow
and
skim,
which
is
not
in
the
security
area,
but
highly
related
to
kind
of
security
based
on
historical
reasons,
is
still
staying
in
art
and
that
reopened
and
met
earlier
this
morning.
A
For
the
first
time
in
terms
of
work
closing,
so
the
trans
working
group
concluded
since
the
last
time
we
met
and
in
terms
of
major
rechartering
suit
is,
is,
is
now
actively
kind
of
talking
about
how
to
how
to
do
a
little
bit
more
based
on
the
based
on
the
the
the
work.
That's
already
that's
already
getting
ready
to
move
outside
the
working
group
on
the
core
manifest
and
now
we're
talking
about
extensions.
A
And
you
know
ben,
and
I
can't
reiterate
enough
the
help
that
the
sector
provides
and
that
should
read
since
we
last
got
together
in
ietf
11.
those
reviewers,
you
know
provided
detailed
things
for
itf
last
call.
They
provided
detailed
feedback
for
the
telechat
and
these
these
contributions.
These
reviews
directly
impact
the
quality
and
the
security
properties
of
those
documents,
and
it's
tremendous
that
it's
done.
We
thank
you
so
much
for
making
it
all
possible
to
us
really
contributing
to
making
the
internet
a
more
secure
place,
because
you've
invested
your
time.
A
Okay,
so
with
that
we're
ready
to
switch
over
to
our
first
and
only
formal
agenda
item,
so
the
the
tls
chairs
are
going
to
talk
to
us
about
what
recommended
guidance
looks
like
so
joe.
Are
you
briefing
or
sean
we'll
get
your
slides
up.
F
Yeah
I
can,
I
can
present
perfect.
Do
you
want
me
to.
F
Okay,
let
me
figure
out
which
one
this
is.
That
must
be
this
one.
F
All
right
here,
we
are
thanks
everybody
for
joining
good
afternoon
evening
morning,
so
we're
going
to
talk
about
8447
bits
and
the
inftls
recommended
column.
Many
of
you
may
be
aware
that
rfc
8447,
which
is
iana
considerations
for
tls,
defined
a
recommended
column
for
most
tls
registries,
and
this
has
been
populated
with
either
the
character
y
or
the
character
n.
F
The
character
y,
meaning
generally,
this
parameter
is
generally
recommended
for
implementations
to
support
and
n
is
generally
a
record
for
an
implementation
not
to
support-
and
this
says
you
know-
probably
most.
F
Driven
by
cipher
parameters,
you
know
crypto
parameters
such
as
cipher
suites
and
groups,
and
things
like
that.
But
it
applies
to
other
things
such
as
you
know,
extensions
and
other
tls
parameters
as
well,
the
in
order
to
get
something
assigned
and
why
it
requires
ietf
standards.
Action.
F
So
part
of
the
feedback
we
received
is
that
maybe
two
values
aren't
enough,
because
n
could
result
from
various
different
situations.
One
could
be
just
that
we
haven't
evaluated
it.
So
we
get
many
requests
for
ciphers
that
that
we
often
will
allow
that
really
may
not
have
been
out
evaluated
by
anybody
in
the
ietf
or
or
in
the
in
the
in
our
in
our
community,
and
so
it's
hard
to
make
any
statements
about
them,
and
it's
not
something
that
we
could
necessarily
do
to
evaluate
all
these
things.
Nor
maybe
should
we.
F
F
So
in
the
latest
version
of
rfc
40
84
47
this
we
took
the
approach
of
adding
an
additional
state
here.
So
there's
yes
is
recommended
for
general
use
as
it
was
before.
No,
the
parameters
are
discouraged
for
general
use
and
then
there's
you
know,
a
lack
of
any
character
at
all
would
be.
The
parameters
are
unevaluated.
This
is
saying
this.
The
ietf
hasn't
evaluated.
This
there's
no
statement
to
be
made
here
by
the.
G
F
Now
in
the
tls
working
group
on
tuesday
morning,
we
also
presented
this
as
as
part
of
the
artist
that
changes
in
rfc,
8447
bis
and
the
additional
feedback
that
we
got
was
that
hey.
Perhaps
there
should
be
more.
F
F
What
would
be
good
values,
what
what
should
be
be
communicating
here,
because
it's
something
that
maybe
other
working
groups
would
pick
up,
and
so
that's
where
we
are
so,
if
you'd
like
to
come
to
the
mic
and
and
chat
that
would
be
wonderful,
I
don't
know
sean.
Do
you
have
anything
to
add.
F
H
I
Okay
yeah,
so
I
I
think
this
is
like
slightly
more
complicated
than
perhaps
it
needs
to
be,
but
like
in
particular,
I
think
we
could
put
together
n
and
d
into
one
thing,
but
I
also
don't
really
care
very
much.
You
know,
I
think
I
think
I
think
it'd
be
fine.
I
think
I
guess
what
I
would
say
is
it
seems
like
some
of
these
are
gonna
require
some
sort
of
like
explanation,
like
particular,
especially
like
the
n,
and
so
like
a
major.
I
I
I
don't.
I
don't
think
that
I
don't
think
n
should
be
used
in
the
one
thing
I
do
feel
strongly
about
is.
That
is
that
we
should
not
use
n
with
a
meaning.
I
You
have
it
here
and
the
reason
is
because
it
already
has
an
existing
meaning,
which
is
the
thing
you
have
with
with
blank
space
now,
and
so
it's
like
I,
I
don't
care
if
we
rename
it
in
the
field
and
then
we
can
rename
them
or
whatever,
but
like
just
don't
keep
the
thing
called
recommended
and
have
end
mean
something
and
now
means
like
it
didn't
used
to
be.
It's
like
my
my
thesis.
I
F
J
Yeah,
I
I
I
think
the
current
state
of
play
is
where
it
is
better.
I
don't
think
any
any
of
these
changes
are
improvements,
in
particular
the
one
on
screen
here.
J
J
I
don't
care
if
it's
called
n
or
any
other
set
of
characters,
but
anything
beyond
that
is
going
to
waste
lots
more
time
for
people
above
the
itf,
and
I
don't
personally
believe
that
there's
any
additional
clarity
by
having
n
blank
d
or
l
or
or
any
anything
more
than
one
negative
value
is,
is
useless.
In
my
opinion,.
K
Hi
and
very
early
in
the
slide
deck
you
talked
about
or
you
had
different
rules
for
behaving
and-
and
you
talked
about
like
people
have
different
perspectives,
work
on
the
internet,
but
then
there
are
all
sorts
of
deployment
circumstances
and-
and
one
thing
that
I
noticed
is
there's.
K
Of
course
the
web
is
quite
important
to
everyone,
but
dls
is
used
outside
the
web
space
and
and
there
often
kind
of.
K
To
those
other
uses
be
outside
the
web,
and
that's
that's
why
it
gets
tricky,
because
some
of
the
extensions
we
work
on
are
used
in
those
spaces
and
they
they
are
used
on
on
millions
and
billions
of
devices,
but
they
are
just
not
the
web,
and
so
people
treat
them
as
not
fit
for
general
use
because
for
them
the
channel
uses
the
web
only
right.
K
They
don't
care
about
these
other
users,
and
that's
that's
the
that's
why
we
have
dedicated
documents
that
talk
about
the
applicability
of
dls
in
other
domains
and
for
whatever
reason
we
try
to
sum
all
of
this
up
in
a
in
an
entry
in
a
table
in
the
iron
registry.
If
nobody
would
look
at
that,
it
wouldn't
be
a
problem,
but
but
of
course
people
don't
read
the
documents
they
just
look
at
the
table.
F
Now,
honestly,
one
question
would
would
it
help
if
we,
I
don't
believe
we
link
to
documents
just
like
if
we
were
to
have
something
that
was
limited
or
deprecated
with
that
help,
with
having
a
link
to
the
document
that
described
why
or
or
made
that
statement.
K
A
L
I
I'm
also
a
to
two
stater.
I
think
that,
basically
we
should
we
should
not
distinguish
between
stuff.
We
don't
recommend
and
stuff
we
haven't
evaluated.
L
We
should
just
have
a
list
of
the
stuff
that
we
have
looked
at
and
recommend,
and
the
only
thing
that
will
do
for
anything
else
is
give
it
a
code
point,
and
the
reason
for
that
is,
I
specifically
don't
want
to
get
into
the
business
of
itf
evaluating
crypto.
I'm
I'm
not
sure
who
I
mean.
The
only
mechanism
that
we
know
of
to
evaluate
a
crypto
algorithm
is
a
crypto
competition
that
takes
four
or
five
years,
and
that's
just
what
that's
our
mechanism,
whether
it's
this
that
runs
it
or
cfrg
and.
L
Somebody
at
itf
looking
through
a
bunch
of
papers
and
not
seeing
something
bad.
That's
not
a
crypto
algorithmless
view,
so
I
just
don't
want
to
get
anywhere
close
to
that.
So
I
I
want
to
have
a
small,
a
number
of
recommended
algorithms
as
possible,
preferably
no
more
than
two,
the
one
that
we
use
and
the
one
and
the
backup
and
everything
else.
I
I'd
even
like
to
see
a
separate
table.
L
Put
the
code
points
in
a
separate
table,
and
anybody
who
wants
to
first
come
first
served
if
we
start
to
run
out
of
code
points
find
a
hack
that
allows
people
to
use
annoyed
in
its
place.
C
I
I
I
agree,
we're
very
much
with
what
thomas
said
about
different
use
cases.
I
think
it's
important
to
differentiate
between
these.
I
don't
know
I
just
read,
read
the
beast
document.
I
I
see
nowhere
here
that
it
says
general
use
or
that
the
recommended
column
has
anything
to
would
use.
It
seems
to
still
be
support.
Is
that
something
new
that
has
been
added
recently
or.
C
C
A
So
yo
I'm
gonna
jump
in
ahead
of
you
just
to
do
jabber
management
here.
Robin's
comment
because
there
was
no
audio
is
for
any
value
other
than
why?
Yes,
implementers
will
want
or
need
to
know
why,
in
which
case
they
should
read
the
rfc.
So
an
extra
one-byte
value
in
the
fields
doesn't
add
anything.
M
I
pretty
much
want
to
agree
with
that,
so
one
of
the
things
that
8447
did
that,
I
think
is
wrong-
is
that
they
made
the
same
column
for
all
the
ayanna
registries
for
tls.
So
this,
yes,
no
or
unknown,
is
very
fitting
for
the
cypher
suites,
because
we
can
say
that
yeah
asgcm
is
yes.
Rc4
is
no
this
new
cipher
coming
out
of
the
ukrainian
government.
I
don't
know
so
that
makes
sense
but
extensions.
When
are
you
ever
going
to
do
a
no
extension
and
we'll
just
not
standardize
it?
M
If
we
don't
like
the
extension
so
yeah,
I
know
we
can
find
example
where
we
didn't
like
an
extension
anymore.
So,
in
my
opinion,
there's
the
yes,
the
the
things
that
we
don't
want.
People
to
use
everything
else
has
new
ones
like
deprecated
or
limited
use.
It's
good
for
this.
Everything
else
is
nuanced.
So
go
read
the
document
that
describes
the
extension
or
cipher
suite
or
whatever
to
know
whether
it's
applicable
or
not.
So
I
think
yeah
three
values
of
yes,
no
and
go
read
the
document
or
what
we
really
need.
F
N
Oh
yeah,
my
I
think
we
need
to
handle.
Oh,
this
was
you
know,
recommended
and
then
there's
you
know,
one
of
those
silly
die
die
die
drafts
came
out
and
we
need
to
change
that
value
from
you
know.
We
need
to
change
the
value,
so
I
don't
care
what
the
value
is.
As
commented
on,
the
chat.
A
space
as
an
indicator
is
a
bad
idea.
N
In
terms
of
you
know:
accessibility,
readability,
understandability,
pick
some
character,
make
it
a
shrug,
make
it
a
poop
emoji
whatever,
but
my
biggest
concern
is
whatever
set
of
parameters
or
values.
We
pick
it
should
be
possible
to
unambiguously
and
without
judgment
calls
decide
what
they
are,
because
otherwise
it's
going
to
come
to
it'll,
be
written
in
the
rfc
and
that
may
show
up
via
the
ise
path,
which
doesn't
really
have
you
know,
doesn't
reflect
ietf
consensus
or
you'll
defer
it
to.
N
You
know
the
designated
experts
which
are
currently
me
yov
and
nick,
and
I
don't
want
that
so
as
long
as
you
can
describe
an
algorithm
that
is
determinable
and
and
not
halting,
I
don't
care
what
letters
you
can
we'll
just
follow
those
directions.
F
Okay,
thanks
watson.
O
Watson
live
cloudflare,
I'm
I
see
there's
a
lot
of
discussion
about
wanting
to
use
non-recommended
extensions
and
ciphers
as
sort
of
some
of
the
motivation
for
changing
this,
but
we
haven't.
I
haven't
really
heard
specific
examples
or
where
we've
had
debates
in
tls
working
group
about
depreciation
people
saying
well,
we
can't
declare
scientists
depreciate
because
it's
still
in
use
and
really,
I
think
we
should
be
doing
changes
here
as
the
start
of
the
depreciation
process.
O
I
like
the
idea
of
explicit
depreciation
mark,
although
I'm
not
sure
what
the
exact
difference
between
d
and
n
is
and
again,
I
I
think
a
space
is
not
a
great
idea,
that's
where
we
could
put
in,
but
I
also
don't
think
we
should
be
limited
to
single
letters.
I
think
something
like
not
evaluated
can
fit
perfectly
fine.
H
So
as
background
I'm
cool
also
on
75
25,
the
tls
recipe
and
now
75
25
best.
H
F
H
At
the
moment,
it's
coordination
issue,
I'm
not
sure
we
should
be
deprecating
things
or
I
think
70
75
25
did
it
well
and
was
well
accepted
for
the
things
it
did
and
we
could
use
the
same
mechanism.
Perhaps
five
years
between
versions
of
75
25
is
too
much,
perhaps
not,
but
I
think
it's
a
discussion
we
need
to
have,
rather
than
just
running,
to
processes
in
parliament.
F
I
All
right
I'd
like
to
make
several
points
first,
like
we
absolutely
do
need
this
column
for
for
extensions.
There
are
lots
of
extensions
which
are
not
defined
by
the
itf
and
we're
just
reserving
code
points
for
to
give
you
some
examples.
The
three
tlmsp
ones
which
I
had
to
approve,
which
involved
reading
like
a
ton
of
specs
about,
like
you,
know
about
like
auto
stuff,
which
I
didn't
read
ticket
pinning
password
salt
password
protect
password
clear.
I
So
these
are
all
things
which,
like
need,
copper
reservations,
but
we
do
not
think
or
like
we
have
no
opinion
on,
or
probably
maybe
secretly
think,
are
bad
and
so
like.
We
absolutely
need
to
call
them
for
these
things.
I
So
now
I
think
the
question
now
becomes
what
is
the
conscious,
decal
and
and
for
all
for
all
of
these,
and
I
think
there
are
several
you
know
the
so
I
think,
like
obviously
we
need
y
and
I
think
it's
impossible
have
included,
we
didn't
look
and
we
think
this
is
bad
right.
Those
are
the
two
things
that,
like
that,
like
n,
basically
means
and
or
or
I
think
also
like
and
I'll
get
back
to
this
limited
use
case
thing
so
now,
but
separately.
I
So
it's
got
a
bunch
of
things
that
have
ends
on
them
and
then
separately.
We
are
on
publishing
documents.
I
That
say
this
thing
is
actually
bad
like
we
published,
you
know,
md5
die,
die,
die
or
sha
one
die
die,
die
right,
and
so
I
I
do
think
it's
in
value
to
have
a
a
way
to
indicate
that
the
itf
is
like
after
we
looked
at
this
thing
and
now
things
just
like
actively
bad
and
did
not
be
used,
and
so
I
think
that
motivates
some
sort
of
bad
thing,
and
I
understand,
like
the
concerns,
there's
gonna
be
a
lot
of
like
debate
about
that,
but
I
don't
think
there
actually
has
to
be
because,
like
we
didn't,
we
didn't
have
like.
I
We
already
had
that
debate
about
how
to
publish
the
documents
in
the
first
place,
and
so,
like
you
know,
the
the
the
the
point
of
this
column
in
this
case
is
merely
as
rich
says,
to
memorialize
the
decision.
The
items
already
made,
which
these
protocols
are
bad
right,
so
I
don't
think
that
actually
requires
a
lot
of
litigation
beyond
that.
I
So,
like
the,
what
I
propose
is
a
is
a
minimum
three
states,
one
of
which
is
good,
which
requires,
I
guess
specification,
one
of
which
is
we
haven't
looked
at
it,
which
requires
nothing
and
one
of
which
is.
This
is
bad,
which
also
requires
anti-specification
and,
as
I
say
since
we're
already
doing
all
those
things
anyways,
it's
a
mechanical
transformation
from
from
the
from
from
the
work
we've
done
now,
the
one
that
is
like
slightly
difficult,
I
think,
is
a
sort
of
limited
use.
I
One
and
iron
mcdonald
raised
this
a
little
bit
in
in
the
chat
and
and
the
cases
for
those
under
used
ones
and
yes,
dkg
right.
There
should
be
reference
the
case
of
them
in
used
ones.
Is
there
a
bunch
of
cases
where
we've
had
to
make
unpleasant
compromises
about
the
security
of
the
system?
I
Because
because
of
some
case
we're
like
like,
like
you
know,
there's
there's
like
a
lesbian
with
less
cpu
or
something
like
that,
right
and,
and
so
like
a
good
example,
is
ccm8,
and
so
I
think
you
know
what
we
could
try
to
stuff
that
into
the
yes.
You
know.
I
Yes,
you
know
no,
no
opinion
a
bucket,
which
I
suppose
in
those
cases
would
go
in
no
opinion,
but
I
think
you
know
we
all
really
are
like
optimal
cases
right
and
so
I
think,
there's
some
arguments
he
made
to
allow
them
to
have
some
yeah.
As
you
have
said,
microsoft,
environment,
these
algorithms
use
less
memory.
I
So
I
think
there's
like
some
cases
to
have
like
their
own
marker,
but
like
also
willing
to
have
like,
I
think,
if
we
simply
had
a
freeform
field
that
went
in
no
opinion,
that'd
be
okay
as
well,
but,
as
I
said,
I
do
think
we
need
to
use
those
three
states,
because,
because
I
think
we
it's
kind
of
weird
for
us
to
go
around
it's
like
because
mandy's
an
n
are
like
we
haven't,
looked
and
conflating
that
we
looked
in
this
is
terrible.
I
F
Yeah
sure
I
mean
what
I
can
definitely
see
that
you
know
from
from
the
discussion
like
what
we
have
here.
We
like
n
and
space
could
be
combined.
I
think,
because
they're
really
there's
more
states
than
I
think
we
than
anybody
has
asked
for
so
we'd
have
and-
and
I
think
there
is
reason
to
do
deprecated-
I
think
we
could.
There
still
could
be
debate
about
that.
But
I
think
some
of
the
concerns
of
how
do
we
determine
something's
deprecated
deprecation,
like
recommendation-
requires
some
sort
of
document
action.
F
But
I
I
didn't
I
I
don't
haven't
followed
exactly
what
dkg
said.
So
if
you
have
that.
G
G
And
don't
don't
not
raise
your
hand
and
just
raise
your
hand
for
the
one
of
the
three
that
you
prefer
or
if
you
prefer
more
than
one,
you
could
raise
your
hand
multiple
times,
and
then
we
get
a
count
of
who's
going
for
who
wants
to
keep
it
at
two
options?
Who
wants
to
go
to
three
and
who
thinks
that
more
than
three
is
important.
F
Evaluated
yes,
and
not
yes,
right,
okay,
and
then
three
would
be
yes
and
not
yes,
and
definitely
no.
F
G
F
And
then
there
would
be,
then
the
question
would
be
for
more
so.
F
Candy,
do
I
can
I
run
the
to
the
thing
or
do
the
chairs
have
to
run
that?
I
think
the
chairs
have
to
run
the.
A
N
B
B
B
B
Okay,
I
guess
we'll
call
that
pretty
stable,
so
that's
32
for
the
the
three
option
case
and
then
the
the
third
thing
we're
gonna
vote
for
was,
I
guess
more
and
three
options
or
requires
further
discussion
about
what
they
are.
B
Okay,
so
I
guess
I
will
just
run
the
same
thing
again
because
we
closed
it
too
quickly.
Sorry
about
that!
No
it
happens.
A
B
B
So
I
guess
my
my
own
personal
stance,
which
I'll
take
because
I
already
have
my
gone-
is
that
it
sort
of
seems
like
we
have
enough
support
to
say,
like
let's,
actually
write
up,
write
a
draft
for
this
three
option
case
and
try
and
get
more
feedback
on
that.
B
F
B
Okay,
so
is
that
enough
of
the
feedback
that
you
wanted
from
from
this
presentation,
slot.
E
That's
this
is
excellent.
I
guess
you
know
it's
the
tls
working
group
doing
this
thing,
but
if
others
are
other
working
groups
are
adopting
it
or
are
thinking
about
it
that
they
should
think
along
the
same
lines,
possibly
right.
E
From
my
perspective,
I
don't
have
any
problem
if,
if
like
a
document
is,
is
defining
the
use
of
something
that
it
points
you
know
can
get
pointed
to
from
the
registry.
You
can
always
include
more
references
there.
Typically,
you
know,
most
of
the
things
we're
talking
about
have
been
out
have
been
cipher
suites,
which
maybe
there's
a
whole
lot
of
references
get
added
that
way.
E
But
if
it's,
this
particular
extension
that
comes
in
you
know,
automotive
use
case
or
whatever
is
the
one
that
was
being
discussed,
I
mean
the
extension
comes
in
there's
a
reference
column
for
what
that
is,
and
it
gets
an
n
and
that's
okay.
People
can
go
read
why
the
n
is.
We
do
have
to
expect
it's.
I
mean.
I
know
that
a
lot
of
this
problem
is
that
people
that
aren't
reading
the
documents
that
are
referenced
in
the
iana
considerations
section,
but
that's
why
it's
there.
O
B
B
But
as
we
prefaced
into
that
talk,
that
was
the
the
the
tls
recommended
column
was
the
only
schedules
as
united.
We
have
so
we're
into
the
open,
might
open
mic
section.
B
E
E
They
get
pulled
in
that
way.
So
there
would
already
be
a
hey,
it's
not
useful
here
and
then,
if
people
really
wanted
to
know,
they
could
figure
out
that
way
with
an
extension
it's
slightly
more
direct
and
that
the
reference
is
right
there
for
whatever
the
extension
is.
If
there
was
one
defined
specifically
for
the
automotive
use
case
or
whatever
use
case.
There
is.