►
From YouTube: IETF113-DANCE-20220325-0900
Description
DANCE meeting session at IETF113
2022/03/25 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
A
E
C
But
I
didn't,
I.
A
Well,
so
my
my
camera
is
weird
because
it's
actually
upside
down
and
then
I
video
process
it
to
turn
it
right
side
up
in
order
to
keep
the
boom
for
the
camera
out
of
the
way
of
my
vision,
I'm
I'm
very
strange
like
that.
You
know
only
geeks
could
do
crazy
stuff,
like
that.
So.
B
A
One
just
just
the
one,
so
I
don't
even
remember
what
that
one
was,
but
let's
go
ahead
and
get
started.
It
looks
like
numbers
are
getting
fairly
stable.
There's
nobody
standing
at
the
back
of
the
room.
This
probably
won't
be
a
two-hour
meeting,
so
we
have
plenty
of
time,
but
so
welcome
to
the
dane
authentication
for
network
clients
everywhere
dance.
A
We
need
music,
a
meeting,
so
your
chairs
today
are
west
hartiger
paul
has
taken
over
as
the
are
you
the
a.d
paul
for
the
for
the
group.
Now.
A
Okay,
so
paul's
taking
over
as
the
aed
newly
indoctrinated
into
the
aesg,
and
I'm
really
happy
that
joey
is
offered
to
help
us
as
my
co-chair
for
dance.
Thank
you
joey.
A
The
goal
of
this
group
is
to
shut
down
before
I
can
no
longer
find
icons
to
put
on
the
titles
page
of
all
of
our
meetings.
So
this
is
the
latest
one.
The
good
news
is
the
internet
needs
keeps
creating
new
stuff.
So
that
probably
isn't
a
problem.
A
The
note
will,
I'm
sure,
all
of
you
have
read
and
processed
the
note.
Well,
the
essential
notes
are
be
aware
of
what
you're
saying
at
a
microphone,
or
else
you
know,
lawyers
get
involved,
and
nobody
wants
that.
There's
a
bunch
of
bcps
that
talk
about
it.
A
The
iutf
has
a
code
of
conduct
that
we
all
live
by,
which
includes
treating
people
with
respect
speaking
slowly
and
limiting
the
use
of
slang
and
terms
that
people
don't
understand
dispute
ideas
by
reasoned
argument,
not
by
violent
disagreement
and
use
best
engineering
judgment.
Finding
the
best
solution
for
the
whole
of
the
internet
is
the
goal
of
the
ietf
and
then
contributing
to
ongoing
work
within
the
etf.
A
This
is
the
working
group
information
for
dance.
We
have
a
data
tracker.
Of
course
we
have
a
purpose.
The
mailing
list
is
dance.etf.org,
I
assume
everybody
is
probably
on
it,
but
if
you're
not
there
is
the
url
to
join.
We
now
have
three
active
drafts
to
consider
two
of
which
are
adopted
and
the
other
one
is
not
as
we'll
talk
about
in
a
minute.
A
E
A
Mini
client-
or
I
think
that
there's
supposed
to
be
a
scannable
url
in
the
room,
I
actually
don't
know.
I
hope
you
guys
do
if
you're
in
the
room
the
agenda
today,
as
I
said,
you
know
this,
and
this
probably
will
not
take
two
hours
unless
we
dive
into
a
whole
lot
of
discussion,
we'll
take
10
minutes
for
sharing
related
stuff.
A
We
already
have.
This
is
meeting
number
two.
We
had
two
buffs
and
then
this
is
meeting
number
two
and
we
already
have
an
implementation.
So
I'm
super
happy
to
hear
that
that
the
hackathon
actually
had
an
implementation
of
dance-related
stuff.
So
we'll
get
a
presentation
from
them.
Look
what
it
did
to
the
font.
That's
fun.
The
architecture
document
we'll
talk
about
a
little
bit
and
the
solutions
to
solutions
documents.
Of
course
we
will
talk
about
and
then
we'll
have
a
little
bit
of
time
at
the
end
for
open
mic.
A
If
people
want
to
talk
to
things,
remember
one
of
the
things
we
agreed
to
er
in
the
in
framing
the
charter
was
these
were
sort
of
the
target
documents
to
start
with.
There
are
some
other
potential
uses
of
of
dance
technology
that
we
were
deliberately
putting
off
until
these
sort
of
got
out
the
door.
A
So
we're
happy
to
talk
about
those
but
they're,
not
within
scope.
Until
we
get
essentially
these
documents
dunish,
so
we
did
have
a
call
for
adoptions.
I
started
it
on
february
28th
issued
it
for
three
weeks,
which
ended
the
last
week.
A
The
authors
have
recently
published
updates
to
those
documents,
so
they
are
now
draft
ietf
instead
of
draft
hue,
and
the
good
news
is
that
there
seem
to
be
very
good
support
for
all
of
them,
so
those
are
now
official
working
group
documents.
Thank
you
for
everybody
that
helped
respond
with
your
willingness
to
participate
and
help
with
those
documents.
A
I
will
say
that
the
mailing
list
has
been
generally
quiet.
If
you
look
at
the
activity
level
on
the
mailing
list,
there
is
generally
been
very
low
volume
of
of
notes.
So
you
know
that
brings
me
a
little
bit
of
concern.
You
know
we
do
want
things
to
continue
and
I
realize
we're
early
on
and
the
documents
are
made.
E
A
A
point
where
we're
ready
to
discuss
the
minutiae
of
them.
I
hope
we're
getting
to
that
point.
But
if
you
look
at
the
message
chart
on
the
right-hand
side,
you'll
see
that
there's
not
been
a
whole
lot
of
messages.
Most
of
the
ones
in
february
were
responding
to
me
saying.
Yes,
I
agree
to
help
with
the
documents,
so
you
know
our
thoughts
on
well.
How
can
we
increase
discussion
on
the
mailing
list
and
get
more
work
done
would
be
you
know,
please
have
more
discussion
on
the
mailing
list
about
the
documents.
A
Remember
that
providing
early
review
and
feedback
is
a
good
thing
for
the
documents
so
that
we
don't
wait
for
all
the
discussion
to
happen
during
last
call
and
then,
of
course
discussing
you,
know,
use
cases
and
things
like
that
is
always
a
good
thing
to
do
too.
So
I
am
if
anybody
wants
to
speak
to
why
there's
not
been
a
huge
amount
of
discussion,
I'm
I'm
certainly
willing
to
listen
to
arguments
and
and
things,
but
in
the
meantime,
we'd
like
to
see
that
pipe
up
so.
A
And
then
back
to
the
agenda,
so
I
think
we're
up
to
hackathon
implementation
results,
I'm
not
quite
sure
of
the
couple
of
people
who
was
going
to
present.
Who
is
that
this
morning,.
A
A
F
A
Yes
and
tim
is
taking
notes,
thank
you,
tim
for
being
willing
to
take
notes
and
let
me
get
your
slides
up.
Are
you
doing
it.
F
All
right,
thank
you,
so
hello,
everyone,
gay
bartomina
from
ethnic.
I
will
present
you
briefly.
The
implementation
results
that
we've
done
during
the
academ
and
also
the
use
case
that
we
have
using
laura
one
in
iot
next
type,
please.
F
F
So,
for
the
first
draft,
we
based
on
our
implementation
on
an
existing,
dane
library
by
schumann,
so
we
didn't
re-implement
the
whole
day
in
validation.
F
F
Also.
We
have
support
for
authorization
rules
so
that
we
can
process
the
client
id
and
according
to
whatever
rules
or
you
want
well
accept
the
connection
or
reject
it.
The
one
we
did
like
the
most
basic
one
we
and
the
one
that
was
sufficient
for
us-
was
just
accepting
all
client
id
on
a
well
on
a
given
domain,
so
our
authenti
being
like
sub
domain
of
a
given
domain
list.
We
accept
them
and
we
reject
everything
else
next
type,
please.
F
F
It
seems
that
the
client
id
where
the
client
is
actually
sending
the
extension
first
and
then
the
server
is
responding
because
it's
using
like
client,
hello
and
server
low,
but
ts1213
is
using
message
certificate,
request,
message
and
certificate
message,
so
it
is
the
server
starting
the
well
send
sending
the
extension
first
and
then
the
client
and
this
causes
issues,
because
at
the
clientele
part
we
still
don't
have
like
this
version
like
a
negotiation.
F
So
we
we
don't
know
whether
or
not
to
to
to
use
ts12013
on
the
for
the
server
side.
So
if
someone
like
want
to
clarify
that
now,.
D
Right,
it's
honest:
normally,
you
should
be
using
this
extension
in
the
in
the
same
way
in
1.2
and
1.3
when
it
comes
to
the
use
of
client
and
server
hello.
So
there
should
be
no
difference
whatsoever.
F
So
you're
you're
saying
that
we
should
always
use
clientele
in
serverless
and
not
the
certificate
request
and
certificate
message
unless
you
have
a
very
good
reason
to
do
so.
F
According
to
the
draft,
it's
just
that
incorrect
in
cs103
we're
using
like
certificate
request
and
certificate
message,
and
that
this
has
the
advantage
to
like
not
send
the
client
id
and
clear
text.
D
D
G
Yeah,
so
that
is
a
good
point,
so
the
reason
is
yeah.
Normally
they
should
be
the
same.
The
reason
they're
slightly
different
is
because
of
the
need
to
encrypt
the
client
extension,
because
there
are
privacy
concerns
and
there's
no
way
to
do
that
in
tls
1.2,
because
it
has
to
be
sent
in
the
client
hello
in
in
tls
1.3.
G
You
can
send
the
extension
as
part
of
the
certificate
request
message,
but
you're
right
that
comes
after
the
certificate
has
been
prompted
by
the
server
side
in
the
certificate
request.
G
G
So
I
think
there
were
some
folks
recommending
that
you
know
this
may
be
a
new
application
or
a
greenfield
application,
and
maybe
we
should
only
support
tls
1.3,
but
in
the
end
I
think
we
decided
that
there
may
be
a
kind
of
a
deployed
field
of
clients
that
use
tls
1.2
and
we
would
have
to
support
1.2
as
well.
D
That
is
honest
again,
but
it
could
still
be
useful,
then
to
send
use
the
fluxes,
then
flex
extension
in
in
the
client,
hello
of
tls1.3,
to
indicate
the
support
of
this
specific
extension
so
that
when
the
server
sends
this
later
on
in
exchange,
the
client
is
not
suddenly
surprised
and
see
stuff
that
it's
not
supposed
to.
G
Sure
yeah,
that's
fair.
It
could
send
an
empty
extension
in
in
the
client
hello
just
to
signal
that
it
plans
to
use
it
sure
I
mean
if
the
support
for
doing
that,
we
could
enhance
the
draft.
F
Okay,
thank
you
so
yeah.
That's
all
I
needed
to
do
here
to
decide
in
this
slide
so
yeah.
Thank
you.
We
can
move
on
to
the
next
one.
So
a
bit
of
context.
I
know
the
this
is
what
this
was
kind
of
what
I
had
to
say
about
the
implementation.
I
would
just
now
speak
about
the
use
case
that
we
have
so
next
slide.
Please,
and
I.
E
F
You
can
go
to
the
next
one
right
now,
okay,
so
in
the
context
of
lower
one,
we
have
like
devices
that
are
provided
by
manufacturer
and
to
to
have
like
the
security
between
the
device
and
the
application
server
we're
using
pressured
key,
so
the
manufacturer
inject
a
key
in
the
device
and
then
share
it
with
whatever
well
actor.
That
is
involved
next
slide
please.
F
So
this
sharing
key
sharing
can
be
done
in
different
ways,
either
by
using
nfc
the
device
is
compatible
or
just
printing
back
on
the
back
of
the
device
or
send
by
may
whatever
next
slide,
please
so
during
the
device
onboarding
the
device.
So
first
sorry,
the
network
is
divided
into
parts
like
the
radio
frequency
space
and
the
iep
space,
and
when
the
device
want
to
join
a
network,
so
it
will
send
a
join
request
and
that
will
be
intercepted
by
the
network
servers.
So
the
little
cloud.
G
F
On
the
picture,
so
the
network
server
will
then
resolve
the
address
of
the
join
server.
So
we're
using
like
service
discovery
to
to
know
the
join
server
associated
with
a
a
device
and
the
joint
server
will
well
say
if
yes
or
no,
the
device
is
allowed
to
to
join
the
network
and
then
using
the
pre-shared
key,
we
we
will
establish
encrypted
session
between
the
device
and
the
application
server.
F
So,
on
our
use
case,
we
will
not
be
focusing
on
the
radio
frequency
space
and
we'll
see
that
in
a
moment,
but
just
on
the
ib
space
next
slide,
please
so
yeah
the
if
you,
if
you
want,
if
we
wanted
like
to
achieve
end-to-end
security
so
including
the
radio
frequency
space
using
like
asymmetric
key
or
certificate
architecture,
we
would
not
be
able
to
do
that
due
to
the
very
constrained
network
that
we
are
having
on
the
radio
frequency
space.
F
As
of
right
now,
a
compressed
certificate
will
be
like
146,
bytes
and
the
size
of
the
packets.
The
maximum
size
of
packet
is
like
52
bytes.
Yes,.
D
There's
a
common
misconception,
but
when
people
refer
to
some
radio
technology
is
that
they
look
at
the
mdu
at
the
specific
layer
and
then
say
it's
x,
bytes
and
then,
if
you,
the
perception
is,
if
you
want
to
send
something
larger,
it's
not
possible.
Of
course
it's
possible
because
it
just
used
fragmentation,
sure.
F
This
is
a
fair
point
in
number
one.
We
have
a
very,
very
slow
emission
rate,
so
it's
like
one
message
in
a
few
seconds
or
minutes.
So
if
we
were
to
use
fragmentation
here,
it
will
just
take
a
very
long
time.
So
that's
why
we
rather
not
want
to
do
fragmentation
here.
F
So
because
of
the
constraint
or
on
the
radio
frequency
space,
we'll
just
like
be
focusing
on
the
ip
space
right
now
and
maybe,
if
we
have
in
the
future
or
a
better
way
to
encode
certificate
or
not
or
just
public
keys
or
on
very
constrained
well
packet
size
will
do
end-to-end
encryption
from
the
device
to
the
application
server
using
public
key
right
now,
we'll
stick
to
pre-shot
key
and
only
focus
on
the
ip
space
for
mutual
authentication
here.
So
the
ib
space
is
a.
F
We
have
like
different
kind
of
servers,
so
I
speak
about
the
networks
that
are
joined,
server,
application
server.
Those
are
servers
that
can
be
managed
by
different
stakeholders.
So
at
some
point
we
want
to
add
some
trust
in
that
and
we're
doing
that
using
mutual
authentication
and
a
private
pki
next
slide.
F
So
the
issue
that
we
have
like
with
a
common
like
pka
I
like
the
web
pair,
is
that
we
don't
have
like
us
to
see
a
bundle
available
in
all
for
the
server
to
to
use
directly
and
even
if
we
had
that
available
well,
using
as
a
certificate
that
is
like
signed
by
a
common
ca,
have
some
cost
and
even
the
the
free
solution
like
let's
encrypt,
have
some
issue,
because
we
have
like
constraint
on
the
name
that
is
not
allowed
by
let's
entry.
F
So
this
is
like
our
architecture
or
right
now,
like
we
have
like
a
root
ca
that
is
distributed,
intermediate
c
that
are
assigning
a
certificate
for
each
entity
then,
and
on
the
bottom
of
the
slide,
you
have
like
the
dns
configuration
because,
as
I
said,
we're
using
service
discovery
based
on
the
device.
So
on
the
joining
us
zone,
you
have
like
one
record
per
device
that
is
either
pointing
to
directly
at
the
address
of
the
joint
server
or
a
cname
to
the
address
of
the
joint
server
and
the
net.
F
Because
I
wanted
to
highlight
the
fact
that
we
already
have
the
need
for
a
dns
well
zone
having
one
and
try
per
device
and
network
server
next
time,
please
so
because
we
have
already
one
entrepreneur
device
and
network
server.
We,
it
doesn't
really
have
a
lot
of
friction
to
add
a
second
one
for
the
tlsa
record.
So
this
is,
I
think,
it's
important
because
it
doesn't
have
any
more
friction
like.
F
So
that
doesn't
really
matter
so
now,
with
dane
we're
just
like
doing
the
ultimate
mutual
authentication,
so
the
network
server
will
send
the
client
id
or
the
dane
client
id
using
the
tls
extension,
and
we
have
like
the
tlsa
record
on
the
net
network
server
zone
and
on
the
same
the
other
side,
we
have
like
the
joint
server
having
a
telescope
recall
on
the
joint
service
area,
and
we
are
basing
on
trust
that
every
record
all
right.
This
was
my
last
night
anyway,
so
every
record
is
into
the
same
zone.
F
D
F
Is
between
the
network
server
and
the
join
server?
Okay?
Well,
right
now,
the
implementation
that
we
use
is
using
a
single
server
for
both
the
join
server
and
the
application
server.
But
ultimately
it
is
really
between
the
join
server
and
the
network
server.
We
didn't
expand
it
now
to
other
well
communication,
so,
for
example,
like
network
server
to
network
server
and
so
on,
and.
D
But
so
the
the
net
in,
if
I
recall,
laravan's,
sort
of
architecture
correctly,
was
it
not
that
the
network
server
and
the
churn
server
actually
belong
to
the
same
domain
like
the
admin
same
administrative
domain
or
yes,
they
could.
F
F
D
I
think
the
roaming
part
is
something
I
I
read
through
the
specifications
last
year,
but
my
understanding
was
that
they
made
an
update
to
the
specifications
to
support
roaming.
But
then
there
were
some
other
entities
involved
that
you
didn't
show,
and
I
don't
know
where
that
specification
actually
went
to
whether
that's
actually
common
these
days
or
whether
that's
they
abandoned
that
effort,
maybe
where's.
Why?
Just
from
from
a
for
the
sake
of
sort
of
having
the
the
scenario
and
the
entities
properly
lined
up.
E
F
How
well
we
implemented
it
and
I'm
not
sure
how
is
the
state
of
the
implement
of
the
specification.
D
Right
now:
okay,
sorry,
I
think
it
would
be
interesting
to
have
the
dane
client
on
on
a
iot
device
because
in
some
sense
there's
very
little
about
iod
in
this
scenario,
because
you're
not
running
it
like.
D
Running
in
the
on
the
network
side
between
two
servers-
and
it
would
be
nice
to
have
it
the
link
client
on
an
iot
device,
because
that's
where
the
constraints
would
show
up.
That's
where
you
would
see
some
of
the
maybe
interactions
with
some
low
power
networks
or
whatever
that
could
be
interesting.
Yeah.
F
D
Okay,
yeah,
not
we
don't.
G
Yeah
I
can
go.
Can
you
hear
me
yeah
yeah?
So
thank
you
for
doing
the
implementation
of
the
drafts.
I
was
already
planning
to
extend
my
library
to
support
looking
up
a
generalized
tlsa
record
name
to
support
this.
So
thanks
for
beating
me
to
it
and
one
more
question
I
had:
does
the
go,
tls
library
still
support
no
hooks
or
api
to
implement
extensions.
I
see
you
had
to
fork
the
entire
go
tls
library,
which
seems
a
little
heavyweight,
but
I
assume
that's
probably.
The
reason
is
that
right.
F
E
F
It,
but
I
didn't
really
really
have
another
way
to
do
that.
G
Okay,
got
it
yeah,
so
I
I
guess
it
might
be
worth
chatting
with
the
go
folks
to
see
if
they
are
planning
to
implement
a
generalized
api
to
for
for
people
to
be
able
to
write
new
extensions
rather
than
having
to
fork
the
whole
thing.
So
that
might
be
something
worth
looking
into,
because
I
know
openssl
and
other
libraries
do
have
apis
to
create
extensions.
A
D
Hi
stannis,
like
from
my
experience,
it's
unavoidable
to
incorporate
the
functionality
of
the
extensions
into
the
core,
because
the
extensions
often
require
changes
internal
to
the
dls
stack.
So
I
don't
so
if
I
guess
you
will
have
no
other
route
than
sort
of
contributing
your
extension
back
into
the
the
core,
and
you
would
have
to
do
the
same
for
empathy
ls
for
wolf,
ssl
and
for
open
ssl
for
that
matter.
D
But
they
are
all
these
folks
are
welcoming
extensions
in
general
they're,
very
open
for
contributions.
G
In
the
past,
I've
been
able
to
implement
the
functionality
of
an
extension
just
using
their
api
to
create
a
new
extension
and
they
have
callbacks
for
the
tls
verification
side
on
the
server
where
you
can
add
functionality
so
but
you're
right
in
the
general
case,
you
may
have
to
modify
the
cuts
in
the
library.
F
A
With
that,
I
don't
see
any
more
questions.
Thank
you
very
much
for
both
the
implementation
and
the
discussion
based
on
it.
Fascinating
work,
awesome
to
see
it
implemented
so
so
quickly.
It's
thank
you
for
good
progress.
So
thanks
very
much
all
right.
Next
up
in
the
agenda
is
only
with
a
discussion
about
the
architecture
document
or
any
of
the
authors
that
want
to
talk
about
it.
I
believe
you
are
there.
You
are
yep
fire
away.
A
He's
he's
enjoying
the
audio
a
couple
of
times,
but
it's
not
actually
transmitting
audio.
Somehow
I
don't
know
if
it's
a
device,
selection
problem
or
joey
joey's
right.
You
could
leave
me
echo
and
come
back
and
try
again,
but
it
could
be
a
device
configuration
in
the
upper
right
hand,
corner.
A
Yes,
always
could
be
permissions,
we'll
give
a
minute.
I
think
we
have
time,
but
otherwise
we
can
switch
and
go
on
to
schumann
with
the
solutions
documents.
A
All
right,
why
don't
we
do
that?
So
will
you
continue
playing?
Why
don't
we
switch
to
schumann
and
you
can
talk
about
the
solutions
documents
in
the
meantime.
A
G
Okay,
all
right,
so
this
is
just
an
update
on
the
status
of
the
protocol
documents.
As
you
know,
I've
presented
these
drafts
in
detail
at
a
number
of
earlier
meetings,
so
I'm
not
planning
to
go
through
the
entire
protocol
this
time.
So
this
will
be
quite
brief.
G
Even
though
I
see
I've
been
given
40
minutes
for
this,
and
you
might
recall
also
that
these
documents
have
existed
for
quite
a
number
of
years
long
before
the
dance
working
group
was
even
engaged.
So
next
slide.
G
And,
as
you
may
have
seen
on
the
mailing
list
and
what
wes
mentioned
these
two
documents
were
formally
adopted
and
just
yesterday,
I
renamed
them
with
the
working
group
document
titles
and
pushed
out
the
dash
zero,
zero
versions
of
each
of
them,
and
they
are
the
dane
tls
client
authentication
document
and
the
pls
extension
for
conveying
a
client
stain
identity.
G
Next
slide.
Please,
and
there
was
really
only
one
change
that
was
made
since
the
last
revision,
and
that
was
to
the
tls
dane
client
identity
draft.
G
The
client
is
only
allowed
to
send
the
extension
in
its
certificate
message
if
it
has
seen
the
corresponding
extension
in
the
certificate
request
message
from
the
tls
server
side,
so
it
can't
really
be
optional
on
the
server
side.
So
the
text
in
the
draft
has
been
modified
to
fix
to
address
this.
So
folks,
if
you
could,
please
give
a
careful
read
and
make
sure
we
got
all
the
language
right
in
in
the
draft
on
this
point.
That
would
be
appreciated.
G
G
C
G
Other
comment
on
the
list
during
the
adoption
call
about
the
content
of
the
draft
specifically,
and
that
was
from
michael
richardson,
who
says
that
the
introduction
is
weak
in
the
client
authentication
draft,
so
that
was
kind
of
intentionally
intentional.
This
is
mainly
a
protocol
specification
document
and
didn't
go
into
a
great
deal
amount
of
detail
about
application
use
cases
specifically,
but
I
think
I
do
agree
with
michael's
later
comment
that
integration
of
this
draft,
with
the
treatment
of
that
latter
subject
about
use
cases
in
the
architecture
document,
will
likely
address
that.
G
But
you
know
if
there's
additional
text,
that
anyone
feels
should
go
into
the
protocol
specifications
document.
You
know,
please
bring
it
up
and
we
can.
We
can
discuss
and
decide
what
to
do
about
that
and
yeah
I'd
be
happy
to
fix
the
capitalization
of
iot
to
conform
to
the
existing
and
ones
in
that
space
and
the
next
slide.
G
To
sum
things
up,
we
think
the
protocol
documents
are
largely
done
and
we're
looking
for
feedback
about
anything,
that's
missing
from
them
or
needs
to
be
clarified
or
expanded,
as
you
just
saw.
One
issue
already
come
up
came
up
earlier
today
from
the
conversation
with
hannes
and
kyle
about
whether
even
in
tls
1.3,
we
should
send
an
mp
extension
in
the
client,
hello
message.
So
I
guess
we
should
have
a
chat
about
that
and
decide
if
that
should
go
into
the
document.
G
That
actually
was
one
of
the
I'm
reminded
one
of
the
original
rationales
for
existence
of
the
client
id
draft,
and
that
came
from
a
discussion
actually
with
many
years
ago,
with
with
victor
duchovny,
to
deal
with
the
use
case
in
the
smtp
transport
security
community,
where
you
couldn't
actually
prompt
on
the
server
side.
You
couldn't
prompt
the
client
for
a
certificate
message,
a
client
certificate
unilaterally,
because
there
were
lots
of
broken
tls
stacks
in
use
by
in
the
smtp
client
arena
where
they
would
get
confused
by
that.
G
So
the
server
would
need
an
explicit
indication
from
the
client
that
it
wanted
to
do
dain,
authentication
and
only
then
would
the
server
actually
prompt
the
client
for
a
certificate
right,
I
mean
that's
dealing
with
broken
behavior,
so
I
wasn't
a
big
fan
of
that,
but
that
was
one
of
the
one
of
the
reasons
well,
one
of
the
original
rationales
for
the
client
id
extension.
So
you
know
down.
G
Other
reasons
came
up,
such
as
you
know,
surgically
picking
out
a
client
identity
from
a
certificate
or
supporting
tlsa
with
raw
public
key
authentication
anyway,
and
so
I
do
think
the
plan
work
on
the
architecture
document
may
inform
other
things
that
need
to
be
added
to
the
draft,
but
I
don't
know
what
those
might
be
at
the
moment
and
the
same
goes
for
implementation
experience,
and
I
think
we've
already
had
a
little
bit
of
discussion
about
that
today
and
with
that
I
think
I'll
stop.
G
So
I
have
some
filler
slide
at
the
end
for
people
who
aren't
familiar
with
the
entire
protocol.
They
can
go
through
that,
but
I'm
not
planning
to
talk
about
that
today
unless
discussion
points
arise
so
I'll
stop
here.
A
D
A
A
A
So
you
don't
have
slides,
so
you
just
want
to
chat
about
where
we
are
with
respect
to
the
document.
It's
from
a
chair's
point
of
view.
It's
grown
greatly
and
you
know
it's
it's
neat
to
see
so
many
use
cases
spelled
out
in
it
but
go
ahead.
H
H
As
a
working
group,
we
should
properly
take
that
and
sort
it
out.
I
forwarded
to
the
mailing
list
this
morning.
I
understand
if
people
haven't
followed
up
on
everything
on
mail
today,
but
we
had
an
earlier
discussion
in
november
about
the
structure
of
documents
and
based
on
that,
I
think
we
need
to
include
the
dancing
rules
in
the
architecture
document.
That
means
helping
people
that
write
implementation.
Documents
like
I
potentially
could
do
for
sip
or
webrtc
and
others.
H
A
Thank
you
for
bringing
that
up.
I
want
one
point
is
ashes,
unfortunately,
has
had
to
move
away
from
his
role
in
editing
these
documents,
and
there
is
sort
of
a
replacement
author
kind
of
stepping
in
as
well.
But
if
you
know
it
would
be
beneficial
if
the
author
teams
wish
it
would
be
beneficial
to
find
additional
editors
to
help
push
these
forward,
especially
the
architecture
document
is
fairly
large.
Please
do
reach
out
to
the
chairs
and
we
can
negotiate
whether
whether
more
help
is
needed.
D
Yeah
I
had
participated
in
earlier
discussions,
but
then
sort
of
like
got
lost
in
other
activities
and
so
just
help
me
to
provide
a
little
bit
of
get
a
little
bit
of
context.
So
the
architecture
document
is
that
still
an
individual
document
is
that's
the
one
you're
referring
to
or
is.
Are
we
talking
about
something
else
here.
H
D
Okay
and
like
so
I
hear
you've
got
I'm
saying.
Essentially
you
want
to
sort
of
cut
that
architecture
into
pieces
and
and
have
a
sort
of
like
classical
architecture
document
but
then
implement.
There's
guidance
document
for
individual
areas
like
iot
sip,
and
you
mentioned
other
things-
is
that
is
that
yeah.
H
That
that
was
what
we
discussed
in
november,
saying
that
the
architecture
document,
which
was
really
the
document
we
had
at
the
both,
should
be
slimmed
down
to
more
classical,
as
you
say,
architecture
document,
but
also
include
rules
and
requirements
for
implementers
that
want
to
write
documents
for
the
various
other
areas
like
iot,
like
sip
or
other
things.
Yes,.
A
Point
of
order
from
what
we
agreed
to
during
the
charting
to
chartering
discussion
was.
We
would
start
with
the
two
existing
solution
documents
and
we
would
add
an
architecture
document
to
help
lay
out
the
framework
and
that
additional
protocols-
and
things
like
that
would
be-
you
know,
subject
to
rechartering
at
some
point
in
the
future.
After
we
got
stuff
done
so
you're,
absolutely
right,
there's
a
contention
between
how
much
you
know
individual
protocols
can
be
put
into
the
architecture
document.
I
think,
defining
the
use
case.
Examples
is
a
safe
way
to
do
that
right.
A
H
H
D
You
had
all
this.
I
remember
we
had
these
discussions
during
the
chartering
process
and
there
was
an
iot
use
case,
which
was
pretty
fancy
and
and
I'm
hoping
to
see
some
of
that
sort
of
being
sort
of
picked
up
somewhere
and
showcased
and
so
on
or
like
hackathon,
wise
and
then
described
also
in
some
architecture
document.
I
think
that
would
be
pretty
cool,
but
I
understand,
like
obviously
like
the
eap
use
case
and
other
use
case,
which
are
more
like
nuances
of
the
architecture
and
yeah.
A
So
the
reason
one
of
the
other
things
that
came
out
of
the
chartering
discussion
was
to
push
especially
the
solutions
forward
without
letting
them
languish
behind.
So
that's
actually
the
reason
I
did
the
call
for
adoption
for
them.
A
First,
they
were
really
ready
to
go
if
the
architecture
document,
if
people
feel
that
it
is
ready
to
be
adopted,
we
will
certainly
call
a
call
for
adoption,
and
I
would
let
only
in
the
the
authors,
actually,
you
know,
discuss
or
dictate
when
that
might
be
when
a
good
time
to
to
do
that
might
be.
I
know
jim
is
asking
in
chat
as
well.
Why
hasn't
it
been
adopted?
Last
I
checked.
There
were
still
sections
that
weren't
fully
fleshed
out.
H
Yeah,
so
we
probably
need
to
take
a
stab
at
cleaning
up
a
bit
before
for
that,
but
I
I
can
come
up
with
a
proposal
on
that
for
discussion.
H
C
A
Right,
so
let
me
ask
a
different
question:
is
there
any
objection
to
doing
a?
I
will
call
for
a
call
for
adoption.
Anybody
actually
think
it
would
be
a
bad
idea
to
adopt
it
as
is
or
ollie.
Are
you
okay
with
it?
If
we
issue
it
now,
absolutely
I'm.
Okay,
all
right,
there's
a
lot
of
agreements
and
plus
ones
and
in
chat
so
joey,
and
I
will
probably
start
but.
A
You
know
barry's
100
right,
it
does
not
need
to
be
finished.
It
just
needs
to
be
the
point
where
the
working
group
thinks
that
the
the
rough
layout
outline
is
very
put
is,
is
in
good
shape
and
last
I
looked
at
it.
I
think
it
is
so
excellent.
I
think
we
will
issue
that
next
week,
then
great
okay,
anything
else
from
you,
nope
nope,
okay.
A
That
actually
brings
us
to
the
end
of
the
agenda.
As
I
said
you
know
I
was
debating
when
I
was
selecting
a
room.
We've
always
filled
two
hours
before
with
discussion,
and
we
did
not
this
time.
So
I
think
you
know
next
time
unless
we
think
that
there's
a
lot
more
content,
we'll
probably
shoot
for
a
one
hour
slot
to
leave
these
larger
slots
open
for
for
more
discussion.
A
So
do
keep
that
in
mind,
and
I
think
next
time
I
will
default
to
one
hour
unless
people
you
know
feel
like.
We
have
a
lot
more
based
on
discussions
on
the
mailing
list
and
stuff
as
well.
So
anybody
have
anything
for
open,
mic
or
other
solutions
that
you
want
to
discuss
with
respect
to
dance
related
technologies.