►
From YouTube: ACE WG Interim Meeting, 2021-04-13
Description
ACE WG Interim Meeting, 2021-04-13
A
So
again,
thank
you
all
for
coming
a
usual
guru
supply
for
our
interim
meeting
and
also
we
already
have
the
agenda.
A
So
we'll
have
a
update
from
ben
first.
B
I
don't
see
him
so
maybe
we
can
start
to
see
so
please
register
your
name
to
the
the
ether
pad.
So
all
the
coding-
and
we
are
also
willing
to
have
some
volunteers
for
the
mini.
B
B
B
So
please
go
ahead.
Logan.
A
So
we
have
the
first.
I
believe
we
have
a
presentation
for
the
first
draft,
which
is
ace,
co-op
transport
mohit.
Are
you
ready.
B
D
I
got
some
comments
from
the
from
the
working
group
and
mostly
the
comments
are
around
so
so
I
think
in
in
so
there
is
one
more
version
of
cmp
protocol
in
progress
which
I
think
started
after
I
I
submitted
my
draft,
so
I
have
to
look
at
that
and
make
sure
I'm
not
missing
anything
in
the
cmp
v3,
which
is
a
work
in
progress,
and
there
were
some
comments
around
the
around
the
versioning
that
I
should
not
use
a
particular
version
and
it
should
be
generic,
so
I'm
making
those
changes
in
the
draft
and
removing
the
support
for
version,
one
which
I
believe
is
obsolete
now
and
then
there
were
some
comments
around
service
discovery
and
I
think
in
the
last
working
group
meeting
we
had
a
comment
around
the
dtls
to
tls
proxy.
D
So
so
that
is
one
more
section
where
I
will
add
more
clarification.
So
so
so
I
am
working
on
it.
So
I
was
supposed
to
submit
the
draft
the
next
version
of
the
draft
before
before
this
entry,
but
due
to
some
other
reasons,
I
could
not
finish
it.
So
I'm
hoping
I
will
submit
it
by
in
one
week
from
now.
B
So
basically,
well,
my
understanding
is
that
this
draft
is
almost
ready
for
working
with
glasgow.
B
B
I
think
our
current
plan
is
to
start
the
working
group.
Let's
go
as
soon
as
we
get
the
new
version,
anyone
in
favor
or
against
or
no
opinion.
I
mean
it.
It's
good
to
you
state
your
mind.
A
A
A
A
We
can't
hear
you
down,
at
least
on
my
side.
I
can't
hear
you.
D
D
E
Can
you
hear
me
now?
Yes
now
we
can
hear
you
okay,
so
the
idea
is
we
had
some
some
feedback
from
christian
francis
about
the
use
of
the
new
option.
We
define
for
keeping
the
ordering
warranty
that
we
need
for
a
lower
layer.
If
you
can,
please
go
to
the
next
slide
so
here
this
is
like
we
are
reviewing
the
the
requirements
for
a
new
blower
layer
and
we
are
stopping
in
the
ordinary
warranty
one
that
has
it
and
the
way
that
we
are
currently
keeping
this.
E
This
requirement
is
that
we
define
a
new
option
called
signal
motion
where
we
put
a
number-
and
this
number
reflects
the
the
message
that
is
currently
ongoing
and
allows
the
the
sender
and
the
receiver
to
understand,
which
is
the
the
current
message
and
the
one
that
is
going
to
expect
next.
Okay,
so
so
the
thing
is
that
there
was.
There
were
some
comments
regarding
the
the
use
of
this
option
because
of
several
things
like
we
are
introducing
a
new
option.
Can
we
do
it?
E
Can
we
achieve
this
without
creating
a
new
option
using
one
that
is
already
existing
or
does
co-op
provides
on
its
own
mechanisms
to
help
us
achieve
this
ordering
warranty?
So
if
you
can,
please
go
to
the
next
slide.
E
So
the
idea
is
from
the
general
schema
of
code
we
have
relating
relating
messages.
We
have
the
message
id
relating
requests
and
responses.
We
have
the
token
and
for
our
co-op
service,
we
proposed
the
segment
option,
so
the
idea
is:
can
we,
since
there
is
a
question
that
if
we
can
do
it,
do
this
in
another
way
we
were
wondering?
Can
we
achieve
this?
E
Only
with
a
token
if
there
are
no
ongoing
additional
co-op
exchanges,
can
we
even
go
further
and
use
an
empty
token,
maybe
to
save
bytes
and
a
if
we
are,
since
we
are
dealing
with
a
lockstep
protocol,
and
that
is
an
assurance
that
we
are
not
going
to
get
the
next
message
until
the
the
current
one
is
being
processed
correctly.
E
Maybe
we
can
even
leverage
the
message
id
if
we
have
the
the
capacity
of
influencing
the
co-op
engine
that
is
being
used
so
talking
with
with
question,
if
you
go
to
the
next
slide,
please
there
were
like
three
different
options
that
were
proposed
in
in
our
chat.
E
One
is
not
using
a
new
this
new
option
and
instead
using
the
ui
query
to
achieve
this
by
using
a
an
additional
value
after
the
the
value
that
that
signals,
which
is
the
bootstrapping
state
that
is
generated
when
the
when
the
authentication
starts
and
the
second
value
the
end
value
at
the
end
of
the
the
uri,
it
could
be
used
to
signal
a
a
specific
step
within
this
state.
E
E
There
is
an
issue
in
this
case
that
it
is
specified
as
that
these
options
can
be
used
with
a
2.01
response
code
in
the
in
the
rfc,
but
it
is
not
clear
if
this
can
be
used
with
a
2.0
for
change
response
option.
So
our
question
we
send
in
an
email
to
the
to
the
mailing
list
is:
can
we
do
this
with
with
the
location,
path
and
location
query?
E
And,
lastly,
a
question
proposed
the
use
of
a
function
that
I
think
is
close
to
be
a
another
c.
That
is
the
echo
option.
E
Deception
would
allow
transparently
to
keep
the
state
between
two
entities
to
synchronize
them
and
from
the
first
acknowledgement
this
echo
option
would
would
state
a
number.
We
would
have
a
number
that
will
reflect
the
the
current
state
of
the
of
the
exchange.
So
these
are
the
the
different
options
trying
to
find
an
alternative
to
generate
this
known
option
that
we
proposed
in
the
zero
zero
regression.
E
The
idea
is,
what
do
you
think
we
understand
that
the
yak
option
being
a
something
that
is
going
to
be
standardized
and
and
is
very
similar
to
what
we
fi?
Initially
probably
with
the
second
motion,
I
think
it's
a
clean
alternative
and
it
would
help
us
achieve
what
we
want,
but
maybe
you
see
that
is
interesting
to
go
in
another
way,
maybe
with
your
request
or
with
the
location
path,
if
we
can
do
that
instead
of
using
another
option.
E
So
we
are
at
the
point
that
we
understand
that
the
echo
option
is
an
interesting
alternative,
but
we
are
open
to
suggestions
and
from
from
the
working
group
that
I
think
the
last
slide
just
is
stating
what
we
think
about
the
the
possible
alternative
and
asking
just
asking
you:
what
do
you
think.
B
So
do
we
have
anyone
with
a
strong
opinion
against
that
or
anyone
with
a
strong
opinion
in
either
way.
F
Well,
I'm
a
few
hundred
miles
further
back
on
on
this
whole
thing,
so
I
have
no
idea
why
we
are
inventing
new
options,
inventing
new
ways
of
of
using
message,
ids
and
sequence
numbers.
So
my
first
question
would
be:
has
anyone
ever
looked
at
the
problem
of
running
eap
over
a
rest
protocol,
or
is
this
a
completely
new
thing.
E
F
F
So
to
me
this
looks
a
lot
like
other
situations
in,
in
which
rest
was
was
being
used
to
go
through
a
sequence
of
states
and
using
the
the
hyper
media
as
the
engine
of
application
state
approach.
F
E
F
So
one
one
important
aspect
for
me
is:
you
cannot
look
at
a
protocol
like
this
in
isolation.
So
there
are
several
executions
of
the
protocol
running
at
the
same
point
in
time,
and
you
need
to
understand
how
these
executions
actually
can
be
kept
separate
from
each
other,
and
it
seems
to
me
that
hasn't
really
been
looked
at
yet.
E
E
So
your
point
is:
we
should
consider
every
state
of
the
state
machine
to
be
able
to
understand
the
requirements
for
maintaining
the
the
the
signaling
in
rest
to
signal
the
the
current
step
in
which
we
are
in.
I
am
am
I
misunderstanding.
You.
F
Yeah,
so
so
thinking
about
the
state
in
sequence,
numbers
is,
is
a
little
bit
problematic
for
me
because,
as
I
said,
there
are
several
executions
of
the
the
potentially
several
executions
of
the
protocol
going
on
at
the
same
point
in
time.
So
how
do
we
keep
these
states
separate
and
we
probably
need
a
way
to
name
these
states.
E
Yes,
so
currently
we
are
under
under
the
assumption
that
we
are
with
constrained
devices
and
we
are
only
going
to
have
one
ongoing
authentication
process
at
a
time.
Maybe
that
is
a
wrong
assumption,
but
that's
with
what
we
start,
but
even
in
this
case
we
are
when
we
start
the
authentication
process.
E
We
are
returning
from
the
server
a
a
a
a
a
resource
identifier
as
a
signaling
to
the
to
the
client
to
to
which
state
does
it
have
to
send
the
the
next
authentication
messages
right.
F
I'm
I'm
looking
at
the
draft
right
now
and,
and
I
try
and
understand,
what's
going
on
there.
So
there
is
somebody
who
wants
to
authenticate
and
somebody
who's
serving
as
an
authentication,
server
right.
E
Yes,
maybe
logan
can
you
show
the
the
second
slide
of
the
other
presentation
there?
We
have.
A
B
Thank
you,
I'm
lost
in
my
windows.
E
Yeah
here
we
here
we
have
three
entities.
The
the
thing
is
that
the
authentication
server
is
not
showing
here.
The
authentication
server
is
a
a
triple
a
server.
The
controller
is
an
ip
authenticator
that
is
acting
as
a
forwarder
of
the
messages
between
the
iot
device
and
the
and
the
iph,
that
is
the
iot
device
and
the
ip
server.
E
But
in
this
case
we
are
only
showing
the
the
exchange
between
the
e-path
indicator
and
the
if
here,
but
we
have,
on
the
on
the
other
side,
a
a
an
ip
server
that
can
be
a
triple
server.
In
any
case,
the
triple
a
server
can
be
located
in
the
controller,
so
this
exchange
would
would
be
the
same.
E
So
the
idea
is
a
device
is
trying
to
enter
the
domain
of
a
controller.
The
first
message
signals
the
controller
through
the
the
bootstrapping
service
that
is
represented
by
b
in
this
case,
that
it
wants
to
start
the
an
authentication
from
that
point.
On
the
controller
it
takes
the
role
of
the
client
and
the
iot
device
of
the
co-op
server,
because.
F
E
Is
that
yeah,
because,
according
to
the
el
week,
one
document
of
the
recommendations
for
lightweight
implementations,
it
said
that
it
was
better
for
their
transmissions
to
be
on
a
more
capable
device,
and
this
one
would
be
the
controller.
So
if
the
iot
device
is
the
server,
it
won't
have
to
take
care
of
the
retransmissions.
F
E
So,
in
the
in
the
first
exchange
that
you
see
the
ip
request,
identity
and
response
identity,
the
iot
device
is
creating
a
resource,
in
this
case
b,
slash
x,
which
identifies
the
current
bootstrapping
or
authentication
process.
So
our
question
is:
how
can
we
achieve
ordering
warranty
with
this
exchange?
Can
we
use
just
a
token?
E
E
So
this
might
be
a
problem
if
we
want
to
make
this
process
available
to
generally
to
all
co-op
engines,
so
that
that's
where
the
the
question
of
how
do
we
achieve
this
signaling
of
the
current
exchange?
I
don't
know
if
I
explain
myself
yeah
so.
F
The
the
solution
is
kind
of
already
hinted
at
there,
but
but
it's
kind
of
a
little
bit
hidden.
So
when
you
do
a
post,
you
essentially
pose
to
a
resource
and
that
resource
has
a
name
and
that's
slash,
b
5
in
this
case
right
and
somehow
the
controller
needs
to
know
that
this
resource
exists.
So
I'm
assuming
that
the
first
post
actually
provided
the
name
of
that
resource.
F
E
F
Now,
yes,
good,
so
the
the
ack
would
essentially
tell
the
the
controller
what
resource
the
iot
device
now
actually
associates
with
that
ongoing
protocol
run.
So
a
201
created
is
exactly
right,
but
the
uri
path
here
is
a
bit
confusing.
That's
really
the
the
location
that
that's
increasing.
F
Okay,
you
are
talking
about
okay,
so
we
we
now
have
a
slash
b
eggs
and
the
the
controller
can
then
send
something
to
slash
b,
slash
x,
and
what
should
happen
now
is
that
the
the
device
creates
a
new
resource,
slash,
b
y
and
sends
back
another
created
and
says.
Okay,
I
have
created
a
resource
b
y
to
which
you
can
post
your
next
action,
and
the
device
probably
would
simply
be
deleting
slash
b,
but
it
doesn't
have
to
tell
the
controller
that
it
did
that.
F
E
F
A
F
F
F
The
the
slash
b
slash
x
and
the
slash
b,
slash
y
and
so
on,
or
the
b51
b52.
However,
the
sir
wants
to
call
them.
These
are
new
resources
and
these
resources
go
away
after
that
that
protocol
run
is
completed.
So
two
one
created
is
actually
exactly
the
right
response.
E
Okay,
thank
you,
okay,
okay,
so,
even
if,
if
inside
the
the
the
server
we
are
sharing
or
creating
a
bootstrapping
state,
that
is
the
the
state
machine
of
the
ip
of
the
state
machine,
and
that,
if
state
machine
is
the
same
towards
co-op,
we
can
be
just
creating
new
resources.
There
is
no
problem
there.
Okay,
perfect
right
great
great!
Thank
you
very
much.
G
Okay,
okay,
the
my
question
is
to
me:
I
understand
that
solves
somehow
the
problem
of
the
sequence
number
of
the
addition
of
the
sequence
number,
but
in
my
mind
it's
a
still
bit
confusing
that
you
have
a
new
resource
per
each
it
packet.
G
So
all
these
heat,
packets,
you
can
see
in
the
figures,
are
completely
related.
So
that's
why
we
use
the
same.
Let's
say
resource
somehow
saying
all
that
state
all
that
conversation
is
kept
by
that
state.
G
You
know
what
I
mean
is
you're,
changing
the
resource
that
that
resort
is
only
processing
a
couple
of
messages,
so
meaning
one
request
and
one
response,
but
somehow
those
messages
are
related
with
the
next
and
the
previous
ip
messages,
all
those
resources-
and
I
don't
know-
that's
that's
a
doubt
I
have
I
know
I
understand
it-
solve
the
problem
of
the
sequence
number,
so
it's
related
in
the
sense
okay,
so
the
next
resource
you're
going
to
use,
I
mean
the
iot
device
says
to
the
controller.
G
The
next
resource
you
are
going
to
use.
Is
this
one,
but
internally
the
the
the
service.
The
slash
b
service
is
relating
all
these
resources.
F
Well,
that
requires
stopping
to
think
in
terms
of
of
sequence,
numbers
and
and
starting
to
think
of
application
states,
but
the
the
point
is
when,
when
the
controller
does
a
specific
post,
then
from
the
the
point
of
view
of
the
device,
which
is
the
server
here
in
this
picture,
that
destroys
an
old
state
and
creates
a
new
state.
F
So
that's
exactly
what
what
is
being
modeled
by
by
doing
a
201
created.
So
after
you
have
done
a
post
to
to
step
four,
then
you
are
not
supposed
to
do
another
pose
to
step
four.
You
are
supposed
to
do
a
post
to
step
five,
so
it's
not
not
as
confusing
I
mean
if
you
think
about
how
how
you
actually
buy
things
on
amazon.
You
also
step
through
a
number
of
ui's
in
in
the
process
and
the
uis
encode,
where
you
are,
are
you
still
assembling
your
your
shopping?
F
G
In
my
mind,
in
my
mind,
what
would,
in
the
first
step,
what
we
had
in
mind
was
that
all
the
conversation
will
be
kept
in
one
resource
in
the
I
in
the
server
the
co-op
server
the
iot
device
and
then
taking
into
account
that
resource
you
will
receive
several
posts
to
that
resource.
G
G
You
know
what
I
mean
is
we
we
need
to.
We
need
to
relate
all
because
in
case
we
receive
like
an
old
message
for
that
resource.
We
need
to
either
retrospect
their
knowledge
or
just
discard
the
message,
because
we
are
receiving
like
an
old
one,
so
that
kind
of
thing
needs
to
be
done.
Based
on
that
resource,
I
mean,
if
I
need
the
resource
number
five,
it
means
if
I
receive
again
a
post
for
the
number
five.
G
I
should
retransmit
that
knowledge
for
that
resource,
or
if
I
will
receive
a
research
previous
resource,
then
I
should.
G
Forget
that,
because
this
is
a
duplicate
message,
so
all
everything
needs
to
be
implemented.
Somehow
I
guess
in
the
application,
the
part
of
the
of
this
slash
b
right
rafa,
I
mean
we
need
to
get
track
of
all
the
of
this
sequence.
A
Rafa
dan
and,
of
course,
then,
for
the
interest
of
time.
Okay,
I
would
invite
you
to
continue
the
discussion
on
the
mailing
list.
A
And
then
we'll
proceed
to
the
next
presentation
seek
them?
Are
you
ready.
D
A
Oh,
I
mean
your.
Your
draft
is
next
sorry
website
profile.
C
Please
do
okay,
so
since
the
itf
meeting,
actually
I've
collaborated
with
francesca
and
we've
agreed
to
put
the
changes
regarding
the
mqtt
part
into
the
draft
and
that's
been
worked
in
the
github
repository
the
next
step
of
implementing
the
change
based
on
the
architecture
change.
I
proposed
that's
in
progress
and
once
that's
finished,
we
will
submit
a
new
version.
However,
we
haven't
fully
gone
over
the
entire
draft
to
implement
that
architecture
change
which
affects
both
the
co-app
and
the
mqtt
sections.
C
There
was
a
question
regarding
how
mqtt
application,
which
manages
the
groups
in
terms
of
topics
which
can
also
have
wildcards,
can
be
implemented
and
how
the
group
security
for
them
could
be
supported,
and
for
that
I've
read
the
group
com
document
that
mirko
had
suggested
and
the
co-op
how
the
core
solves
this
problem
in
co-op,
and
there
are
the
idea
of
having
security
groups
versus
application
groups,
we
will
adapt
the
same
terminology
in
mqtt
description
of
the
pops
up
document
as
well,
and
there
are
kind
of
interesting
overlaps
there
and
but
the
general
ideas
can
be
used
to
describe
the
mqtt
part
as
well,
and
I've
also
confirmed
that
what
the
group
com
document
means
when
they
do
refer
to
a
group
was,
is
a
security
group,
not
an
application
group,
and
having
that
clarification,
we
have
now
a
clear
path:
how
to
support
mqtt
topics,
security
groups
and
how
to
discover
the
mappings
between
the
application
and
security
groups.
C
So
these
are
the
two
updates
in
summary,
short
short
story.
We
have
a
clear
path
up
to
implement
and
there
will
they
will
be
in
the
next
version.
A
Thank
you
very
much,
see
them
and
that
may
be
moku.
We
have
your
presentation
next,
all
right,
correct,
please
dania!
Can
you
share
a
slice
for
more
cookies.
H
Right.
Thank
you.
These
are
a
few
updates
since
the
itf
110
meetings.
I
basically
took
the
action
points
I
collected
at
the
meeting
and
we
are
building
for
the
next
version
next
slide.
Please.
H
Right,
the
updates
I
worked
on
are
already
captured
in
the
editor
scorpio
on
the
github
branch
11.
And
if
you
remember
it
was
mostly
about
few
things
that
were
discussed,
and
I
understood
the
grade
already
during
the
past
meeting
and
they
were
essential
about
aligning
this
document
with
some
related
details.
H
That
happened
already
in
the
group
score
document
in
core
in
short,
but
then
I'll
go
through
that
a
bit
more
making
this
group
manager
consistent
with
the
fact
that
now
group
identifiers
can
be
recycled
and
killing
some
redundancies
here
and
there
that
we
had
in
some
parameters.
We
were
repeating
two
times
the
capabilities
of
the
kausiki
types
basically,
and
the
goal
was
to
stay
that
once
only
so.
H
On
the
first
point,
as
I
said
now,
it
is
possible
in
group
score
already
to
have
reusage
of
group
identifiers
once
the
group
manager
just
exhausted
all
the
possible
values,
and
it
is
now
possible
safely
to
recycle
previously
assigned
values.
H
The
the
high
level
of
all
this
is
already
defined
in
the
group
score
document,
but
that
requires
some
more
detailed
mechanics
about
the
group
manager
in
this
particular
document.
Of
course.
H
As
long
as
that
member
is
in
the
group,
then
the
idea
is
that
at
some
point
the
group
manager
will
have
some
reasons
for
for
a
key
in
the
group,
and
we
know
that
when
that
happens,
it
changes.
Group
identifiers
say
it
wants
to
assign
a
new
group
identifier
gid
star
well,
rather
than
proceeding
right
away
right
away.
The
group
manager
will
also
check
in
case
any
current
group
member
has
as
its
birth
gid.
H
The
gid
start
is
going
to
be
assigned
in
the
group
and,
if
that's
the
case,
those
particular
group
members
that
are
there
since
forever
for
experiencing
a
whole
round
of
group
ids.
Well,
they
are
evicted
from
the
group
as
well.
H
So,
in
short,
there's
this
additional
mechanics
of
the
group
manager
for
storing
this
birth
gids
of
current
members
and
possibly
evicting
a
bit
more
members
before
actually
wrecking
the
group
to
enable
this
id
recycling.
H
That
was
one
point
and
it's
all
in
the
electroscopy
already
next
slide.
Please
yeah.
This
looks
more
complicated,
but
it's
actually
simpler
and
it
was
about
eliminating
the
redundancy
I
mentioned
before
so
at
discussed.
Also
in
the
previous
meeting.
This
affects
three
parameters
that
appear
in
two
different
spots
during
the
workflow.
H
The
first
part
is
the
response
from
the
aussie
info
endpoint
of
the
group
manager,
where
both
sign
info
and
three
defined
in
sk
group
com
already
and
acdh
info
entry
defined
in
this
document
instead
are
returned
and
in
the
old
content
column
you
you
can
see
that
it
used
to
be
that
way.
The
the
capability
of
the
key
type
for
cosi
were
present
in
both
parameters,
essentially
so
more
bias
on
the
wire
and
just
a
slightly
more
complicated
parsing.
H
H
H
What
I
did
was
actually
killing
altogether
cs
key
params,
because
we
had
already
cs
patterns
specifying
both
information
we
need-
and
that
simplifies
also
the
implementation
a
bit
because
the
joining
node
gets.
The
join
response
considers
cs
params
as
is,
and
it
is
ready
to
be
taken
and
put
into
the
security
context
generated
for
group
of
scores.
So
it's
also
very
aligned
with
the
format
of
the
security
context
structure.
One
has
I
already
implemented
this
changes.
These
changes
in
my
code
base
and
tested
that
so
it
works
fine.
H
So
this
is
all
about
addressing
the
action
points
from
the
meeting,
but
while
working
on
on
this
particular
point,
I
noticed
one
thing
that
ended
up
generating
a
possible
open
point
for
com.
Actually,
this,
as
is
before
or
after
the
change,
is
fine
anyway
for
the
algorithms
existing
today
that
have
only
one
cozy
capability,
the
key
type.
H
So
we
thought
of
this
before
in
the
group
of
score
document
in
core
and
and
started
to
think
for
the
future.
In
case
new
algorithms
can
be
added
with
more
and
or
different
capabilities
and
these
structures,
as
they
are,
that
wouldn't
fit
anymore
next
slide.
Please.
H
So
I
considered
exactly
what
we
did
in
the
in
the
group
of
score
document,
where
we
added
an
appendix
defining
a
more
general
template
for
the
structure
of
those
parameter.
That
is,
is
retrocompatible,
so
it's
not
going
to
break
the
past,
but
on
the
other
end,
is
also
a
future
proof
and
can
seamlessly
adapt
for
new
algorithms
to
come.
And,
of
course,
if
you
take
those
templates
and
you
consider
them
with
any
of
the
algorithms
today,
you
end
up
exactly
with
the
structures
we
have
already
in
the
document
bodies.
H
Following
exactly
the
same
principle.
I
added
equivalent
appendices
here
in
this
document
defining
this
generalized
format
for
those
parameters
following
the
same
principle,
so
you
use
them
today
with
the
algorithms
you
have
today
and
you
produce
the
structures
we
have
now
in
the
document
body
here
in
keygroup
common
score,
but
they
are
future
proof
for
possible
new
algorithms.
H
That's
also
indicators
copy
once
done
that
I
did
decide
to
check
and
it
was
all
fine
for
the
key
parameter
and
the
ecdh
info
entry
parameter.
We
have
a
large
degree
of
freedom
about
that
because
they
have
been
defined
in
this
document,
of
course,
but
it's
a
bit
different
when
it
comes
to
sign
info
entry,
because
I
thought
of
the
appendix
for
the
sake
of
this
document,
but
sign
info
entry
is
already
defined
in
this
keygroup
column
actually,
and
that
generated
an
open
point
which
is
on
the
next
slide.
H
H
H
So
the
way
things
are
now
are
a
bit
unstable.
I
think
I
need
to
be
fixed
exactly
because
signing
for
entry
is
defining
kigercom,
so
I
came
up
with
two
possible
ways
to
fix
this.
If
we
want
to
maintain
this
generalization
at
all,
it's
about
adding
something
in
square
common.
H
The
first
option
can
be
keeping
the
definition
of
sign
info
entry,
as
is
but
admitting
for
possible
profiles
to
to
define
essentially
deviations
as
long
as
they
are
complete
and
self-contained,
but
an
alternative
option
instead
would
be
to
move
from
kiger
como
score
to
keyboardcom
already
the
part
of
the
appendix
that
I
added
exactly
related
to
sign
info
entry,
and
this
is
possibly
more
cleaner
and
easier
to
understand
than
than
risking
to
create
gray
areas
with
option
one
instead.
A
H
B
B
So,
given
that
we
don't
have
so
many
people
attending
that
meeting,
I
I
am
well.
I
think
it's
good
to
you
mentioned
that
point
during
this
meeting,
but
I
have
the
impression
that
we
will
mostly
have
some
feedbacks
on
the
mailing
list
due
to
the
low
attendance
of
the
meeting.
So
do
you
plan
to
I
mean
I,
I
think
you
can
update
or
raise
that
discussion
on
the
mailing
list
to
see
how
people
get
concerned
about
that
and
to
pass
the
message
that
we
need
some
additional
review
of
the
document.
B
If
you're,
I,
I
would
go
for
the
concrete
one,
but
if
you
want
to
double
check
and
you're
unsure,
you
may
just
say
this
is
what
I'm
planning
to
do.
Okay,
if
anyone
has
anything
to
say,
say
it
now,
that's
but
yeah.
I
I
have
the
impression
it's
always
better
to
say
this
is
what
I
I
mean.
This
is
the
problem
we
we
had.
This
is
how
we
intend
to
solve
it
and
see
if
anyone
raised
the
any
concern.
C
Marco
is
the
concern
for
the
option.
Two
is
to
break
the
ac
group
home
and,
and
are
there
any
other
documents
or
implementations
that
rely
on
it
now
that
that
break
would
be
significantly
problematic.
H
Neither
option
one
nor
option
two
would
break
keygroupcom.
Is
that
if
we
care
about
this
future
proof
opening
something
has
to
be
said
already
in
kiger
com,
nothing
changes
for
the
present
and
for
current
implementations
anyway,
I
think
option
two
is
preferable
because
it
doesn't
open
for
gray
areas
like
option
1
and
what
it
requires
in
the
document
body
would
be
just
a
forward
pointer
to
the
appendix
and
that's
it.