►
From YouTube: ACE WG Interim Meeting, 2021-01-14
Description
ACE WG Interim Meeting, 2021-01-14
A
Well,
we
will
probably
have
a
happy
new
year
for
a
few
interim
meetings
because
it's
a
new
year
in
every
part
of
the
world.
This
is
so.
This
is
our
first
meeting
now
our
january
meeting
for
the
ace
working
group,
I'm
showing
the
not
well.
So
please
take
the
time
to
read
this
slide
and
if
you
have
any
question,
please
come
back
to
me
or
raise
your
question
before
we
start
I'd
like
to
know.
A
B
A
I
can
help
out
with
the
minutes.
Okay,
thank
you,
garan,
okay,
good.
So
anyone
has
any
comment
before
we
start.
No,
so
let's
start
with
the
working
room
status.
So
we
had
a
chatter.
The
charter
is
being
reviewed
and
is
currently
presented
at
the
isg.
So
probably
this
time
as
I
am
speaking,
then
it
is
expected
that
there
is
a
an
external
review.
A
So
it's
a
regular
process,
it's
nothing
more,
but
at
the
end
the
chatter
is
being
to
to
be
published
or
approved
in
any
thought,
no,
no
sooner
than
beginning
of
february.
A
So
this
is
one
of
the
reasons
we
started.
Some
conditional
calls
for
adoption
so
that
we're
not
waiting
too
much,
and
this
is
why
you
may
have
seen
on
the
mailing
list
the
call
for
adoption
for
draft
with
cmpv2
over
co-app.
A
So,
where
we
are
with
that
working
group,
so
we
have
the
rfcq
in
which
we
we
still
have
the
draft
on
co-op
east.
I,
as
far
as
I
remember,
he's
waiting
for
a
dtls
number.
A
So
I
don't
know
how
it's
how
long
it's
gonna
take,
but
I
suppose
we're
seeing
the
end
of
the
tunnel,
but
did
I
notice
shen
on
on
the
I
mean
the
the
sun
turner?
Do
you
want
to
say
something
on
that
for
the
dtls.
C
Hopefully,
you
can
hear
me,
I
think,
we're
in
the
process
of
still
trying
to
get
some
final
changes
tweaked
in
there,
but
the
document
is
basically
ready
to
go,
so
we
just
have
to
give
it
to
the
ice
g
yeah,
okay,.
A
So
that's
it's!
It's
a
as
I
mentioned.
It's
the
we
see
the
end
coming
so
not
a
problem,
ada
review,
so
we
have
a
some
documents
that
are
waiting
for
another
document
that
is
in
the
working
group
queue
so
so
that
the
three
first
documents
so
as
soon
as
we
got
the
os
core
profiled
done,
all
those
are
going
being
sent
to
the
isg
and
we
have
a
new
document.
That's
been
sent
in
the
next
in
the
latest
months,
which
is
the
mqe
mqtt
tls
pro
5..
A
So
that's
the
one
I'm
considering
that
is
in
the
the
real
in
the
real
ben's
queue.
A
And
then
we
have
a
working
group
q,
where
we
do
have
a
few
documents
that
are
staying
so
the
the
os
profile
is
a
well.
We
had
a
latest
review,
and
so
this
document
has
I've
made
some
back
and
forth
between
the
working
group
and
the
revision.
A
So
I
think
we
are
reaching
the
last
step
now
and
as
soon
as
the
next
version
is
going
to
be
published,
my
expectation
is
that
it's
going
to
be
sent
to
the
ad
and
then
in
a
very
short
time
sent
to
the
isg.
Because
I
mean
it's
not
a
new
document
for
ben.
D
Just
that
I've
just
replied
to
your
to
your
email
just
before
this
meeting.
So
hopefully,
if
you
agree
with
my
my
answers
and
I'm
I
was
happy
to
see
that
it
was
mostly
clarifications
and
things
like
that,
so
I
don't
think
it
will
take
a
long
time
to
to
update
it's
on
high
on
the
priority
list.
So
as
soon
as
you
give
me,
the
the
okay,
I
might
actually
start
doing
the
changes,
and-
and
so
you
can
just
okay,
the
pull
request,
if
you
prefer.
A
Oh
yeah,
I
I
will
have
to
to
look
at
your
email.
I
saw
you
send
me
an
email,
but
I
haven't
had
time
to
look.
C
A
But
yeah,
I
would
do
that
probably
right
after
the
meeting.
So
if
you,
if
you
don't
see
any
problem,
I
I
don't
see
where
I
should
see
any
problem.
So
yeah.
D
So
there
is
not
a
lot
of
changes
and
hopefully,
if
you
agree
there
is
some
some
clarifications,
but
also
some
other
clarification.
D
A
D
A
Okay,
that's
great
news,
so
probably
my
expectation
is
that
way.
Before
the
next
mid
interim
meeting,
that's
going
to
be
out
of
the
queue
then.
The
second
document
we
have
is
the
aca
aif.
So
this
one
is
going
to
be
discussed
a
little
bit
more
in
detail
during
this
meeting
and
we
have
the
pub
sub
profile
that
also
have
been
updated
and
we
have
group
com
or
related
drafts.
A
So
I
also
updated
the
milestones,
so
my
expectation
is
that
we
get
focused
on
on
documents
and
that
we
do
move
them
forward
on
a
regular
basis.
A
So
I
have
plain
interim
meetings
one
per
month,
because
I
mean
I
think
we
were
quite
successful
with
those
these
meetings
are
not
expected
to
replace
the
mailing
list.
So
I
mean
please
don't
wait
for
the
meetings
to
discuss
some
of
the
things,
and
so
I
mean
most
of
the
discussions
should
be
handled
on
the
mailing
list
and
the
interim
meetings
should
be
really
there
to
fix
things
that
have
not
been
fixed
on
the
mailing
list.
A
Okay,
so
now,
let's
start
with
the
the
first
draft
or
presentation
we
would
like
to
hear
about,
which
is
the
aif,
I
don't
know
if
casting.
Maybe
you
want
to
oh
daniel.
B
Yeah
sorry
for
interrupting,
there
is
actually
a
very
final
pr
in
in
the
ace
framework
which
appeared
as
a
result
of
a
comment
from
one
of
the
implementers
of
of
the
oscore
profile.
B
I
just
want
to
point
out
that
on
the
github
there
is
pr
I
made.pr
it's
basically
just
the
formulation
to
address
one
possible
misunderstanding
of
the
term
overwrite,
which
is
used
in
in
in
the
framework
to
describe
the
process
when
you
update
the
access
rights.
B
So
there
is
a
pr-
and
I
think
that
would
be
great
if
we
could
consider
that
before
pushing
the
drafts
to
yeah
on
in
the
process.
A
So
you
are
talking
about
this
one:
yes,
okay,
okay,
so
that's
something
we
need
to
look
at
more
closely.
Is
that
something
ben
is
involved
in
it
or.
B
No,
it's
just
a
wording
it's
so
there
was
a
comment
from
marco
and
it
was
taken
to
the
authors,
and
I
was
I
made
this
small
pr,
which
is
basically
just
explaining
that
we
are
not
strictly
overwriting.
I
mean
this
is
framework
document.
Is
it's
not
addressing
exactly
how
this
process
is
going
when
you
update
the
access
rights,
so
the
overwrite
is
not
physically
an
override
of
of
the
old.
I
mean
it's
not
like,
like
it's
implemented
as
as
deleting
the
old
and
replacing
it
with
the
new.
B
It's
actually
a
little
bit
more.
I
mean
there
are
some
information
that
you
might
lose
in
that
process.
So
that's
not
the
intent,
but
the
term
override
is
is
replaced
with
removing
superceding
was
a
considered
alternative
right.
So
proceeded
what's
the
word,
so
it's
just
a
wording
thing.
E
Okay-
and
I
remember
the
same
kind
of
rephrasing
for
consistency-
would
happen,
then
in
some
sentences
of
the
oscar
profile,
but
just
to
catch
exactly
with
that.
Okay,
so.
A
Is
is
that
something
that
maybe
needs
to
be
raised
on
the
mailing
list
so
that
everyone
agrees
on
that
sure
I
can
send
an
email
yeah?
I
think
that's
the
best
way
to
to
handle
that
and
of
course,
I'm
gonna
have
a
look
at
this
and
will
tell
ben
for
that
also.
Okay,
thanks
thanks
for
bringing
this
okay,
so
yeah,
so
for
iaf.
So
currently
the
document
is
at
least
mentioned
by
two
documents,
which
is
the
mqtt
and
the
group
com.
A
So
from
a
discussion
I
had
with
carsten,
I
mean
we
sort
of
went
through
remaining
points,
so
I
mean
filling
the
templates
finalizing
security
and
introduction
sections
and
then
some
comments
that
have
been
provided
earlier:
positioning
afterward,
non-constrained
mechanisms,
so
my
thoughts
are
that
maybe
the
introduction
would
be
the
place
to
to
to
mention
that.
A
I
think
it's
originally
from
a
comment
from
ban
from
jim.
He
also
mentioned
that
a
resource
that
has
been
created
may
be
granted
some
specific
access
right.
This
should
not
impact
the
it
does
not
expect
that
it
impacts
the
for
format
being
described,
but
it
might
something
that
we
mentioned.
A
So
basically,
what
we
would
like
to
hear
is
from
the
people
that
are
referencing
this
document
if
they
have
any
any
concerns,
and
if
there
are
anything
they're
willing
to
see
in
in
the
next
version-
and
I
will
leave
probably
the
floor
to
to
to
custom-
to
see
if
he
wants
to
add.
F
Anything
yeah,
so
the
the
draft
formally
isn't
complete.
F
We
still
have
to
fill
in
the
the
media
type
registration
template
and
we
have
to
write
a
security
consideration
section
so
that
that's
the
the
minimum
amount
of
work
that
needs
to
be
done,
and
then
we
have
a
number
of
of
comments
that
are
not
like
do
this.
Do
that,
but
are
just
raising
interesting,
partly
philosophical
questions,
so
we
we
are
a
bit
at
leisure
to
decide
whether
we
actually
want
to
do
something
or
don't
want
thing.
F
And
of
course
there
are
the
comments
of
from
the
people
who
actually
are
using
this
and
right
now,
I'm,
as
you
said,
I'm
very
interested
in
hearing.
If
there's
anything
else,
that
needs
to
be
done
at
this
point
in
time.
A
A
It's
a
very
short
document,
so
I
mean
don't
be
afraid,
but
it
would
be
good
that
I
mean
once
it's
being
published.
We
have
to
review
in
the
few
coming
days
after
the
publication.
A
So
I
can
ask
signum
for
for
as
a
co-author
of
the
amputee
draft,
I'm
wondering
if
any
of
the
group
a
draft
could
volunteer
for
reviewing
the
next
version
of
that
draft.
E
Marco
here
I
can
have
a
look
at
it
and
by
the
way,
it's
already
used,
also
in
sk
group,
common
score,
where
a
separate
af
data
model
is
defined.
E
In
fact-
and
I
I
can
anticipate
the
same-
will
happen
with
yet
another
data
model
for
the
gm
admin
document
when
we
started
to
think
of
how
to
use
aaf
in
a
new
way.
For
that.
So
I'm
not
sure
we
are
going
to
use
the
data
model
already
defined
in
the
document,
meaning
that
the
basic
rest
model
and
the
dynamic
rest
model.
But
I
can
still
have
a
look
at
it,
and
maybe
I
can
come
up
with
with
comments
if
I
notice
anything
when
using
it.
In
those
other
drafts.
A
Okay,
so
so
that's
very
good.
Thank
you,
marco.
I
will.
I
will
ask
sign
also
to
check
that,
and
so
I
will
contact
her
and
ask
her
for
that.
So
yeah.
D
A
We
we
should
expect
a
new
version
in
the
next
coming
weeks,
so
that's
probably
beginning
of
february.
That's
my
guess
is
that
am
I
correct
correct
with
that
custom?
Is
that
striking
to
do
it
this
month?
Okay,
perfect,
and
so
my
expectation
is
that
as
soon
as
we
got
to
this
review,
we
started
working
group
last
goal
on
that.
A
And
the
regular
yes,
are
they
that's
really
my
laker,
my
lack
of
expertise,
but
I'm
wondering
if
there
are
any
other
working
group
that
should
be
involved.
You
think
in
the
review
or
that
we
see.
F
When
we
have
done
our
review,
you
probably
want
to
include
http
with
okay
or
maybe
the
the
new.
What's
it
called
the
the
do
interesting
things
with
http
that
mark
nottingham
is
interested
in
working
group.
We
get
what
it's
called.
A
Yes,
okay,
good
yeah,
so
I
think
that's
nice
to
to
to
have
those
pepsi
profile.
So
I'm
wondering
if
francesca
do
you
have
any
anything
to
mention
any?
You
were
expecting.
D
I
I
can
give
a
short
status
update
is
that
after
new
year?
Well,
as
you
might
have
seen
of
started
contact
with
sigdom,
who,
unfortunately,
is
not
on
the
call
today,
but
she
has
started
to
think
about
the
mqtt
part
of
the
pub
sub
profile
and
she
had
some
comments
already.
So
we
need
to
sit
down
and
think
about
about
it.
In
particular.
The
first
comment
she
had
was
about
that.
D
She
doesn't
think
that
the
two
authorization
servers
which
are
now
defined,
as1
and
as2-
should
be
defined,
so
it
should
be
separated,
so
she
she
thinks
that
they
should
be
one
entity,
so
that
would
be
a
one,
bigger
change
and
yeah,
and
there
is
a
lot
of
more
comments
that
come
from
the
think
about
mqtt.
D
So
this
is
not
so
we
just
I
just
resubmitted
it
just
for
keeping
it
alive.
But
for
me
this
wasn't
in
my
priority
list.
So
far,
so
now
we
can
start
picking
up
the
the
pace
again,
but
probably
not
before,
for
me
at
least
not
before
the
oscar
profile
is
done.
D
So
I
I
don't
really
know
what
to
tell
you
about
the
next
update,
but.
A
D
Not
definitely
not
for
little
weeks
or
something
like
that,.
A
Yeah,
I
would
say
the
the
profile
should
be
done
by
in
the
next
two
weeks,
but
I
think
especially
because
there
is
a
I
mean
a
collaborations
between
you
and
cygn
in
that
document.
I
think
it
would
be
good
to
to
be
quite
reactive
so
that
the
working
group
can
also
yeah.
D
It
would
have
been
good
to
have
this
document
move
forward
with
the
mqtt
document
as
well,
but
that
one
is
more
advanced,
so
we
kind
of
like
I'm
already
late
on
this,
so
I
don't
know
if
we
can
pick
up
and
if
we
can't,
then
I
am
not
really
sure
we
will.
I
will
check
we
seek
them
and-
and
we
will
try
to
have
a
better
update
for
next.
For
me,
I
see
yeah.
A
A
Okay,
so
that's
good
and
I
mean
a
working
group,
please
I
mean
to
provide.
A
D
Yeah,
I
don't
think
it's
time
for
feedback,
yet
we
will
for
next.
A
Okay,
right
yeah
feedbacks
on
the
document,
but
I
saw
an
email
where
some
points
have
been
raised.
So
if
anyone
has
any
any
any
comment
on
that,
that's
that
was
my
yes.
G
D
The
points
that
seek
them
brought
up
and
we
will
also
discuss-
and
anybody
is
obviously
welcome-
to
write
feedback
about
those.
A
A
Yeah,
thank
you.
So
I
guess
for
the
next
meeting
we
will
have
a
thorough
discussion
on
this
draft.
That's
my.
A
How
how
I
see
the
thing
to
confirm
the
yeah?
Okay,
okay,
so
good?
Well,
it's
nice
that
this
work
is
moving
on.
So
thank
you!
A
group
comes
so
I
think
marco
got
two
presentations.
Marco
and
francesca.
E
Yeah,
thank
you
daniel.
We
resumed
to
work
on
this.
This
is
just
the
collection
of
open
points
we
have
compiled
and
one
is
actually
from
the
november
itf
meeting
plus
more.
We
talked
about
in
the
meanwhile.
So
next
slide.
Please
yeah.
The
conclusion
about
this
open
point
in
november
was
to
think
more
about
it.
So
we
are
still
at
the
same
point
in
fact,
but
just
to
to
refresh
our
memory.
E
E
So
far,
we
have
assumed
that
the
kdc
is
running
just
one
application
or
in
this
particular
context
one
application
profile
base,
but
it
may
just
as
well
run
multiple
applications
not
at
all
related
to
each
other
at
the
same
time-
and
you
can
think
of
this
even
as
a
much
more
general
point
in
a
is
applied
to
any
resource
server.
So
not
necessarily
a
kdc
point
is
a
client
posts,
a
token
where
scope
is
encoded
as
a
by
string.
E
So
at
that
particular
point,
what
should
the
kdc
or
more
in
general,
the
resource
server
do
meaning?
How
is
it
supposed
to
know
exactly
how
to
parse
a
scope
according
to
to
which
format
so
for
the
context
of
this
work?
E
Well,
we
know
that,
for
instance,
in
some
profile
we
have
that
as
a
civil
array
indicating
group
on
one
side
and
rolls
on
the
other
side,
but
you
may
have
other
formats
for
other
application,
but
right
when
the
token
is
posted,
you
don't
know,
and
you
need
a
hint,
so
maybe
not
to
orthodox
hint
that
I'm
actually
using
in
my
group
manager.
E
Implementation
is,
is
the
audience
claim
of
the
token
that
I
actually
associate
to
a
service
like
a
group
manager
for
group
score,
for
instance,
and
well
they'll
work,
but
probably
we
can
do
better
to
be
also
more
general
than
this
next
slide.
Please.
E
So
we
thought
of
and
proposed
in
november,
two
possible
approaches
that
again,
all
in
all
are
about
giving
a
hint
on
how
the
scope
should
be
should
be
parsed
and
one
is
prefixing
the
scope
with
one
byte,
whose
value
can
be,
in
fact
the
hint,
and
this
has,
of
course,
to
be
agreed
between
the
the
resource,
server
and
the
authorization
server,
for
instance
upon
resource
server
registration
time
and
and
of
course,
if
there
are
multiple
resource
servers
around
running
that
same
set
of
applications,
for
instance.
E
Well,
they
all
need
to
sync
on
on
a
common
value
associated
to
a
format
during
that
registration
phase.
There's
another
way
that
well
it's
fundamentally
about
prefixing
a
hint,
but
it
uses
the
actual
keyboard
tags.
E
So,
since
the
one
by
silver
tags
are
pretty
delicate
to
consider
for
registration,
they
will
probably
mean
already
a
bit
more
overhead,
though
compared
to
the
overall
size
of
the
token,
it's
probably
acceptable,
and
probably
an
overall
two-byte
zebra
tag
would
be
sufficient.
E
The
problem
then
becomes
also
how
well
this
scales
overall
in
the
ecosystem
and
well,
what
makes
an
application
entitled
to
to
claim
for
a
new
tag.
Value
to
register
these
are
just
open
questions.
E
We
didn't
come
to
an
actual
decision,
other
other
than
a
tentative
proposal
to
have
an
appendix,
describing
both
approaches
and
how
they
could
be
used.
Otherwise,
what
exactly
to
do
and
what,
how
much
defined
in
this
document
or
somewhere
else
is
still
an
open
point.
In
fact,
and
there
I
added
some
comments
we
raised
in
november
from
from
ben
and
karsten,
but
we
can
discuss
this
more
today.
I
think.
D
No,
we
would
have
to
pick
one
yeah,
okay
or
or
I
mean
we
could
also.
As
marco
said,
he
has
kind
of
fixed
it
right
now
in
his
implementation,
with
a
with
a
a
tweak
that
is.
D
Yeah
the
audience,
but
it
would
be
better
to
have
a
cleaner
solution,
at
least
in
my
opinion,
and
while
you
were
talking
michael,
I
thought
about
what
about.
If
we
register
one
keyboard
tag,
not
one
for
each
possible
form
of
scope,
just
one
syllable
tag
and
then
in
our
skill
com
document,
we
register
a
new
ayana
registry.
D
That
would
contain
so,
basically,
the
prefix
or
whatever.
That
is
going
to
be
called
that
that
tells
what
the
format
of
scope
it
is,
and
so
you
would
use
both
the
zebra
tag
and
then
another
registry
to
indicate
the
actual
format.
The
keyboard
tag
is
only
telling
you
you
see.
It's
like
this
is
the
scope
perfect
by
the
value
that
you
find
in
this
registry,
so
that
we
don't
need
to
read
like
register
several
different
tags,
one
for
each
format
in
cbor.
So
maybe
then
we
could
even
use
a
one.
E
So
the
tag:
what
do
you
think
of
that
the
tag
indicates
there's
and
a
format
integer
following
and
then
there's
scope.
D
So
the
tag
would
indicate
that
the
the
the
following
item
is
a
prefixed
scope.
So,
even
though
daniel
said,
oh,
I
repeat
one
or
both.
Actually,
this
solution
would
be
both
both
options.
E
It's
good
and
they
would
work,
I'm
just
thinking
that
probably
makes
scope
a
cyborg
sequence
right.
The
format
now.
D
This
the
scope
itself
is
whatever
scope
is
defined.
To
be
it's
the
the
format
you
know,
and
then
you
have
a
prefix
and
then
sure
you
can
have
either
a
sequence,
a
simple
sequence
with
the
prefix
and
then
the
other
scope
or
you
could
have.
I
haven't
thought
about
this
is
details.
I
haven't
thought
about
that,
but
yeah,
let's
assume
it
more
sequence,
so
you
save
one
byte
to
avoid
dna.
E
We
still
have
to
go
for
a
by
string
as
a
final
thing
anyway,
possibly
tied
sure.
So
probably
I
don't
know
if
the
bi
string
should
drop
the
sequence
then
rather
than
array.
D
A
D
Saying
is
that
you,
we
can
add
the
nyana
registry
for
the
prefix,
and
the
seaboard
tag
will
just
indicate
that
what
follows
is
prefix
plus
scope.
It
doesn't
need
to
indicate
the
exact
encoding
of
scope,
and
in
that
case
we
yeah
it
it's.
There
is
still
one
more,
but
it's
still
longer
than
just
the
prefix
and
also
if
we
do
it
this
way,
we
don't
mandate
that
this
is
used.
You
could
still
do
the
prefix
by
itself,
if
they,
if
the
rs
and
aes
agree
beforehand,.
A
Yeah
before
because
one
of
the
questions
I
would
have
is
it's
it's,
I
mean
it's
not
something
where
you're
sending
every
packet.
So
it's
just
when
we're
setting
the
the
system.
D
A
I
would
be
inclined
to,
rather
than
looking
for
optimization,
to
have
something
that
is
architecturally
clean.
D
Yeah,
I
agree
with
that.
On
the
other
hand,
we
don't
want
to
register
a
ton
of
cyborg.
I
mean
I
don't
know
how
many
format
of
scopes
we
were
looking
at,
but
I
that
was
one
another
thing
that
we
don't
want
to
register.
One
zebra
tag
for
each
for
a
format
of
scope
and
combining
these
two
would
solve
that
problem.
E
Yeah,
okay
and
actually
we
can
have
up
to
56
or
so
possible
formats
encodable
in
one
byte
of
prefix.
E
If
we
play
around
with
positive
and
negative
values,
I
I
was
more
struggling
with
the
actual
encoding.
I
think
that
the
the
practical
buy
string
that
scope
has
to
be
will
have
to
rope
a
sequence
composed
of
the
prefix.
D
I'm
not
it
sure
how
you
yeah,
because
so
so
we
would
have
a
tagged,
byte
string
and
that
tagged
by
string
or
tagged
debor
sequence
yeah.
I
think
we
need
to
think
a
little
bit
more,
how
that
is
actually
encoded.
E
E
We
still
have
to
tag
exactly
by
string.
I'm
saying
the
value
of
the
by
string
wouldn't
be
any
more
an
array,
but
it
has
to
be
a
sequence
integer
for
the
format
and
then
the
array.
E
A
So
I
I
have
the
impression
that
I'm
not
sure
everyone
is
following
the
discussion,
so
maybe
what
I
would
suggest
is
that
you
you
take.
The
design
you
think
is
the
best
one,
and
the
important
thing
is
that
we
sort
of
agree
that
fighting
and
having
something
very
complex
for
one
bite,
maybe
not
really
worth
it,
and
I
think
we
can
take
that
from
that.
So
just
propose
something,
you
think
is
the
best
solution
and-
and
I
mean
having
something
clean
and
that
is
implementable-
would
be
prioritized
over.
E
E
No
well,
it's
fine
just
to
give
it
more
visibility
because
it
in
principle
it
affects
any
application
using
ace.
I
think
okay
perfect,
so
just
not
to
risk
that
it
goes
on
the
radar.
A
Yeah,
I
would
it
be
a
a
huge
thing.
I
don't
have
any
opinion
on
that.
I'm
usually
trying
to
reduce
the
number
of
documents,
but
I'm
happy
I'm
happy
anyway.
A
But
I
I
yeah,
I
understand
your
point.
Maybe
any
anyone
has
an
opinion
on
that.
D
I
mean
it
would
be
good
if
the
framework
that
I
mean,
even
if
the
framework
doesn't
define
this,
but
if
it
had
a
reference
to
something
like
that,
it
would
be
good
because
it
would
make
the
implementer
aware
that
this
is
possible
and
there
is
a
solution
existing
and
then
where,
where
this
is
defined,
either
in
the
document
or
in
a
separate,
very
short,
two-page
document.
D
It's
kind
of
the
same,
but
I
don't
know
it.
It's
a
shame
that
ludwig
is
not
here
either
because
he
would
have
had
a
very
strong
opinion
about.
I
don't
know
if,
if
maybe
do
you
have
an
opinion
about
adding
intense
referencing?
Something
like
this
saying
that
this
is
a.
A
I
think
I
I
I
my
view
would
be
that
we
don't
have
so
many
documents,
so
if
it's
some
some
something
we've
realized
while
designing
in
the
group
I
mean
I
mean
I
mean
documents
that
are
coming
after
will
reference
the
group
come
and
then
it's
going
to
be
in
the
mainstream.
A
D
D
Reason
why
we
brought
this
up
is
that
this
is
a
more
general
thing
that
has
basically
it
it's
applicable
also
for
applications
that
are
not
based
like
there
are
not
groups,
so
it
would
be
true
for
the
oscar
profile
or
whatever
other
application
of
of
the
framework.
D
That's
just
why
we're
saying
general
that
if
you
know
if,
if
someone
else
is
implementing
something
else
and
they're
not
aware
that
this
system,
they
will
not
know
to
use
it,
maybe
if
we
move
it
out
of
the
ascii
group
common
and
we
make
a
separate
document,
then
it's
it's
easier
to
find.
I
don't
know
it's
just,
but
we
can
start
with
a
proposal
and
then
we
can
take
back
the
discussion
on
if
we
should
have
it
separate
or
in
this
document
or
something
else.
A
Yeah,
I
I
I
would
be
more
in
favor
of
focusing
on
the
on
that
document
and
since
we
don't
have
a
thousands
applications
or
related
to
the
framework,
I
think
it
makes
sense
to
to
have
this
being
specified
in
one
application
or
I'm
not
to
worry
about
that,
but
maybe
maybe
I'm
wrong.
So
if
anyone
got
a
strong
feeling
on
that,
it
would
be
good
to
to
raise
that
maybe
on
the
mailing
list
or
ludwig
can
state
it's
mine.
A
But
if
we're
not
hearing
from
anyone,
I
would
suggest
we
focus
on
the
key.
The
group
cup.
D
A
E
Good,
okay:
that
was
it
for
this
point,
but
it
was
the
toughest
one.
I
have
to
say:
okay,.
E
Thank
you,
yeah.
We
just
noted,
while
going
through
the
many
requirements,
that
the
documentary
finds
that,
of
course,
a
particular
profile
as
an
instance
of
this
document
should
also
specify
for
a
certain
role
that
the
group
member
can
have
practically
what
what
kind
of
operations
that
role
enables
the
group
member
to
do
and
in
the
original
text
on
top,
we
are
referring
as
associated
to
operations,
exactly
co-op
methods,
and
that's,
maybe
too
specific,
for
instance,
if
practically
co-op
is
not
used
to
communicate
in
the
group.
E
Think
of
mqtt
already
I
mean
that
even
rest
metals
may
be
still
too
specific.
E
So
still,
a
few
hours
ago,
we
had
a
more
complicated
refreshing
alternative,
but
francesca
noticed
is
probably
good
enough
to
just
replace
that
is
with
eg,
so
essentially
mentioning
hop
methods,
just
as
a
possible
example
of
operations
intended
to
be
associated
to
roles.
A
If
everyone
is
happy
with
that,
I'm
fine,
I,
I
think
also
that
if
you,
if
you
have
one
reference,
which
is
the
co-op
meta
methods,
anything
that
I
mean
is
somehow
associated
to
that
I
mean
it's.
We
have
a
transitive
relation
between
those,
so
I
think
it's
fine.
E
Oh
yeah,
if
you
remember,
there
are
sub
resources
at
the
kdc
one
for
each
group
member,
and
I
think
christian
in
one
of
his
review,
noticed
and
made
us
remove
the
possible
observation
of
that
nod
sub
resource
from
the
associated
node,
because
there
was
apparent
no
reason
to
to
do
that.
E
Actually,
there
might
be
a
reason
that
can
be
an
advantage
for
the
group
member
for
observing
this
dedicated
resource.
E
E
E
A
F
Yeah
I
just
said
it
makes
a
lot
of
sense
having
all
these
callback
uris
being
exchanged
that
that's
the
http
http
way
of
doing
things,
because
they
don't
have
anything
else.
We
do
have
observation
and,
as
you
mentioned
it,
it
just
falls
together
neatly.
So,
let's
just
use
what
we
have.
E
Okay,
next
slide,
because
here
it
comes
the
catch
that
requires
a
bit
of
addressing
at
the
kdc
there's
there's
another
common
resource
to
the
whole
group,
so
to
the
whole
members
where
they
join
and
that
once
members
they
can
be
interested
in
observing
as
well
to
get
updated
key
material
in
case
it
changes.
E
The
the
two
notifications
would
be
very
similar
in
content
in
case
the
the
key
material
changes
in
the
group
and
that's
just
redundant
so
using
the
possible
observation
of
the
node
dedicated
resource,
like
I
said
in
the
previous
slide,
a
trick
to
avoid
that
can
be
that
the
group
member
observes
its
node
sub
resource,
using
also
the
no
response
stating
it's
not
interested
in
successful
responses.
E
So
what
we
really
want
to
get
as
a
possible
notification
is
only
the
one
following
the
deletion
of
the
node
resource
because
of
the
the
eviction
from
the
group.
E
So
then
we'll
have
what
we
want
avoiding
any
redundant
overhead.
As
an
almost
duplicate
information
received,.
F
D
Another
thing
would
be
to
just
say
that
that
this
is
like
the
consideration
that
this
happens,
if,
if
nodes,
observe
both
resources
and
then
allow
applications
to
decide
if
they
want
to
observe
both
these
users
at
the
same
time,
because
they
could
only
just
observe
one
and
then
yeah
not
observe
both.
E
E
E
E
F
D
D
E
D
B
B
F
E
Great
thanks
so
next
one
great
still
thinking
of
that
same
node
sub
resource.
The
group
member
can
send
the
put
request
to
request
new
individual
key
material
practically
in
the
group
score
case.
A
new
sender
id
and
the
payload
should
be
empty.
So
right
now
we
are
not
saying
what
the
case
you
should
do
if
it
receives
a
request
with
no
empty
payload.
E
F
Ignoring
means
that
you
never
can
extend
it,
so
if
you
do
do
an
extension
of
the
protocol
later,
where
there
is
a
non-empty
payload,
the
the
kdc
would
just
ignore
it,
and
you
would
never
know
whether
the
kdc
actually
has
has
acted
on
it
or
not,
so
my
preference
would
be
to
have
a
bad
request.
There.
E
All
right
thanks
and
the
second
point,
perhaps
a
bit
less
controversial,
is
it
might
happen
that,
right
when
the
request
comes,
the
kdc
for
several
reason,
is
not
able
to
to
produce
and
provide
a
new
sender,
id
or
or
whatever
new
individual
identifier
to
the
node.
That
seems
pretty
obvious.
Instead
to
return
a
503
error.
F
Yeah
that
depends
a
lot
on
how
you
expect
implementations
client
implementations
to
act
on
this
I
mean
service
on
available
can
be
anything.
So
if
you
get
that
code,
you
don't
really
know
whether
this
is
just
out
of
of
key
material
or
something
else.
Bad
has
happened.
E
Okay,
this
is
really
specific
to
the
put
request,
which
is
exactly
about
requesting
a
new
individual
key
information.
If
that
helps
otherwise.
E
F
So
essentially,
we
could
simply
define
the
problem
payload
so
like
we
have
problem
payloads
for
for
other
kinds
of
problems,
and
that
could
include
the
information
when,
when
it
might
be
opportune
to
try.
F
E
E
Right
yeah,
it's
good
just
to
say
we
are
running
out
of
time.
I
think
so
I
I
suppose
you
want
me
to
stop
here.
A
I
mean
actually,
I
was
thinking,
is
that
okay,
for
I
mean
it
depends
on
the
people.
We
can
continue
a
little
bit
to
find
to
finish
this.
This
presentation
we
are.
A
Way
we
are
almost
done
by
the
way:
yeah,
okay,
so
and
and
then
so,
it's
not
too
bad
that
we
focus
on
this
document
as
opposed
to
the
admin
one
for
for
this
time.
So
I
I
think,
that's
fine.
If
we
can
get
the
the
updates
and
move,
I
mean
get
get
the
focus
on
one
document:
it's
not
too
bad.
Also
so
yeah
after
we
finish
with
this
document,
we
might
adjourn
the
meeting.
E
Okay
next
then
yeah
right
that
does
another
resource.
This
is
common
for
the
group.
Instead
pub
key,
you
can
send
requests
to
get
public
keys
of
other
group
members
and
other
than
the
the
get
method
we
we
also
described
how
the
the
fetch
method
can
works
here,
where
you
can
indicate
a
subset
of
public
keys.
You
are
interested
in
by
ids
of
group
members
or
roles
of
those
group
members,
so
on
top
you
have
the
current
format
for
for
the
fetch
payload
describing
the
filter.
E
In
fact,
we
we
we
thought
it
would
be
useful
to
enable
also
the
the
reverse
direction
of
the
filter.
With
respect
to
the
ids
of
the
group
members
indicated,
and
that
would
be
indicating
sorry
having
one
more
boolean
parameter
in
the
payload
of
fetch
and
there's
an
example
with
more
discussion
in
the
next
slide.
E
E
So
you
are
essentially
asserting
what
you
want
considering
the
filter.
But
if
the
flag
is
false,
we
can
revert
this
rule
so
that
you
want
the
public
keys,
except
for
the
group
members
with
the
specified
ids
in
the
filter,
and
that
can
be
useful.
E
For
instance,
for
a
group
member
that
has
been
in
the
group
for
a
while,
more
members
have
joined,
and
the
group
member
might
have
missed
a
few
public
keys
of
new
group
members,
but
it
has
a
bunch
of
keys
already
and
they
would
like
to
send
a
fetch
request
with
a
negative
id
filter
so
specifying
the
ids
of
the
public
is.
It
has
already
asking
us
for
for
all
possible
other
public
keys
that
have
been
added
in
the
meanwhile,
and
it
doesn't
have
yet.
E
Because
the
only
way
to
get
public
keys
of
nodes-
you
don't
know
they
have
joined
already-
is
just
about
asking
for
well
the
full
set
with
with
a
get
or
or
with
an
empty
id
filter,
then,
and
then,
of
course,
you'd
get
all
keys
currently
present.
E
E
Great
and
we
let
it
thanks,
please
right.
This
is
just
to
to
have
more
feedback
in
case.
We
are
misunderstanding
anything
here
and-
and
this
is
probably
all
texts
that
remain
from
previous
version-
that
don't
sound
right
anymore.
E
E
The
kdc
was
in
fact
supposed
that
this
request
was
consistent
with
the
roles
of
that
group
member,
but
actually
the
roles
don't
really
play
any
role
in
the
the
ability
legitimacy
of
a
group
member
to
leave
the
group
that
that's
something
that
should
be
always
possible,
in
fact.
So,
unless
we
we
forgot
something
or
we
are
not
seeing
something
we
we
meant
some
time
ago,
it
should
be
just
about
deleting
this.
This
text
about
the
delete
operation.
E
I
mean,
I
suppose
we
don't
want
that
anyone
should
be
able
to
leave
the
group
and
it's
just
a
favor,
to
the
kdc
in
terms
of
material
to
keep
around
the
manage
after
all,
okay,
so
we
will
just
remove
the
text
and-
and
that
comes
back
in
another
paragraph
later
on,
but
okay,
thank
you.
E
Yeah,
it
would
make
sense
if
you
really
want
to
forbidden
not
to
leave
based
on
its
roles,
but
I
mean
that
not
at
the
end
of
the
day
can
still
just
forget
about
the
group
altogether
and
practically
leave
anyway.
So
I
don't
see
what
can
really
add
or
help
so.
E
Okay,
then
we
can
just
bring
this
text
up.
So
do
you
intend
to
remove
the
text
or
to
you
know
I
was
to
remove
it
unless
we
were
really
not
seeing
any
possible
reason
to
keep
it.
Okay,
yeah.
E
Right
this
should
be
the
last
big
one
and
following
the
joining
request,
the
job
response
include,
if
requested,
a
public
keys
of
the
group
members,
and
they
can
also
be
specified
as
a
response
to
the
pub
key
sub
resource,
and
now
we
are
all
considering
cozy
keys,
especially
as
exact
encoding
for
public
keys,
and
we
are
saying
that
in
that
case
the
kid
parameter
of
the
cosy
key
must
be
present
and
include
a
valid
identifier
for
that
group
member.
E
That
is
responsibility
of
the
specific
profile
to
define,
in
particular,
in
the
in
the
group
score
case.
That
kd
field
takes
us
value.
The
the
sender
id
that
the
node
has
in
the
group,
but
thinking
more
generally,
of
course.
Well,
you
may
have
one
day
alternative
encoding,
then
then
call
the
keys.
We
are
actually
already
admitting
this
and
ways
to
signal
it.
E
Okay,
but
then
you
need
to
be
ready
to
to
have
an
encoding
of
public
keys
where
there's
no
equivalent
internal
field
to
indicate
something
like
kid
and
but
you
still
need
that
information
to
be
to
be
provided.
So
it
has
to
be
in
the
actual
messages
exchange
between
the
the
kvc
and
the
joining
nodes
or
the
group
members.
E
So
we
thought
of
possibly
introducing
one
more
optional
parameter,
essentially
in
the
join
response
and
in
the
response
to
the
from
the
pub
key
resource
and
parameter
in
case
the
the
public
keys
are
requested,
and
the
used
encoding
is
such
that
the
key
doesn't
include
any
embedded
indication
of
identifier,
and
this
new
peer
identifiers
parameter
would
be
essentially
analogous
to
the
p
roles
parameter.
We,
we
have
already
explicitly
indicated
indicating
the
roles
of
the
members
in
the
group.
E
Okay,
if
I'm
not
wrong,
the
last
one
was
really
about
minor
editorial
things
in
case
anyone
had
a
comment:
yeah
it's
about
renaming
one
parameter
that
is
really
about
the
uri,
so
it
should
be
named
control,
uri,
not
control
path,
and
it
was
trying
to
avoid
my
blame,
absolutely
use
and
abuse
of
expressions
like
those
that
we
can
definitely
remove.
E
A
But
it's
editorial.
Okay,
so
looks
good
yeah.
So,
as
I
mentioned,
I
think
it's
it's
it's
good
to
to
get
focused
on
that
one,
and
I
my
impression
is
that
we
can
move
this
one
and
then
consider
either
the
os
corp
profile.
No,
not
the
os
core
gm
admin
in
the
second,
in
the
second
term,
the
first
one
being
the
group
contract
and
then
the
the
admin,
because
that's
going
to
be
the
same
person
working
on
those
well
the
same
set.
So
at
some
time.
A
I
think
at
that
point
where
we
are-
and
I
mean
I'm
I'm
happy
to
be
wrong,
but
my
understanding
is
that
it's
possible
that
we
get
focused
on
one
and
then
the
other
rather
than
having
those
two
parallel
drafts.
E
A
small
final
comment:
sk
group
com
score
is
pretty
stable
and
it
will
mostly
be
about
updating
it
to
reflect
the
updates
we
do
in
this
document.
Instead.
Okay,
consistency,
yeah,
okay,
is
that
the
same
with
the
gm
admin?
No,
that
that's.
A
So
good,
okay,
that's
relatively
new
document
and
requires
actual
work
on
new
features:
okay,
yeah
yeah,
but
so
what
I
I
suggest
is
that
for
the
time
being,
we
really
focus
on
this
key
group
com
draft.
So
the
two
of
those
the
os
core
and
this
one
and
then
we
focus
on
the
admin.
One
sounds
good.
A
Okay,
so
thank
you,
everyone,
I
think
we
we
may
stop
this
meeting
and
thank
you
for
attending.
I
think
thank
you
for
participating.
We
made
good
progress,
I
think,
and
again
happy
new
year
and
see
you
next
time
on
the
mailing
list.