►
From YouTube: IETF108-ACE-20200729-1100
Description
ACE meeting session at IETF108
2020/07/29 1100
https://datatracker.ietf.org/meeting/108/proceedings/
B
C
A
A
This
is
the
not
well.
I
guess
you
should
be
familiar
with
that
by
now.
If
you're,
not
please
the
time
to
read.
A
A
So
I
I
I
suppose
we
we're
gonna
start
anyone.
Anyone
has
any
any
comment
regarding
the
agenda.
A
So,
okay,
so
agenda
bashing.
Anyone
has
anything
to
say
about
the
agenda.
A
A
Okay,
so
now
status
update
jim.
Do
you
want
to.
B
D
Yeah,
so
the
oscar
propel
has
ended.
Last
call
atf
last
call,
and
we
got
two
reviews
from
jen,
art
and
upstair,
and
I
just
recently
I
this
morning
went
through
them
and
added
issues
to
the
github
and
all
the
review
comments
are
quite
minor
editorial
clarifications
and
we
also
got
some
ayanna
ayanna
comments
which
showed
me
there.
D
There
is
some
fixes
to
do
in
the
ayanna
section,
and
also
that
we
author
have
to
send
mails
to
various
review
mailing
lists
for
adding
parameters
such
as
the
cwt,
etc,
yeah
yeah,
but
so
to
participants.
D
B
Okay,
the
dtls
authorization
profile
is
roughly
in
the
same
situation.
It's
gotten
some
comments
and
it
needs
some
author
updates
and
a
new
version
produced
and
then
I
believe,
ben
will
be
able
to
move
all
four
of
those
drafts
to
into
iesg
process.
A
E
F
I
I
honestly
haven't
looked
at
the
issue.
I
think
olaf
was
on
top
of
that,
but
I
haven't
talked
to
olaf
in
a
while
either
so
I'll
ping
him
after
the
beating.
A
When
you
go
to
the
mic,
please
mention
your
name.
It's
gonna
be
be
easier
for
the
mini
taker,
which
is
jim,
and
if
anyone
wants
to,
I
mean
to
help
me.
Please
help
him.
G
G
Okay,
great
so
I'm
going
to
give
an
update
on
the
mqtt
tls
profile
next
slide.
That
says
at
version
six
now
update
since
the
last
interim,
so
the
major
update,
as
discussed
in
the
interim,
was
replacing
the
scope
format
with
the
aif
model.
G
This
version
6
also
includes
responses
to
jim's
review
comments.
The
latest
review
comments
that
was
published
on
the
list
and
the
latest
review
basically
made
sure
that
we
have
all
the
right
definitions
in
place,
especially
the
definition
for
a
session.
Now
that
we
support
session
continuation
and
we
also
added
some
clarifications
in
terms
of
the
expected
behavior
for
clients
and
servers
and
did
a
few
corrections,
not
anything
too
major
in
the
rest
of
the
changes
next
slide.
G
I
just
wanted
to
remind
how
the
scope
format
has
changed.
It's
now
adopts
the
aif
model
and
I
used
the
model
suggested
by
jim
on
the
list.
The
only
change
I
introduced
is
to
shorten
the
permission
strings
to
pub
and
sub
thinking
that
their
meanings
are
clear
in
the
spec.
I
also
changed
the
example
so
that
it
captures
the
various
different
topic
filters
that
mqtt
accepts,
especially
in
terms
of
wild
cards.
Next
slide.
G
There
are
still
two
open
issues.
The
first
one
is
regarding
the
session
continuation.
If
you
remember
with
in
one
of
the
inter
interim
meetings,
we
discussed
that
for
quality
of
service
purposes,
the
broker
may
support
session
continuation.
G
Sorry
to
zero
and
supplying
a
session
expiry
interval
which
might
be
indefinite
if
the
brokers
support
session
continuation,
they
have
to
keep
state
for
the
client
in
mqtt.
This
state
includes
the
client
identifier
how
long
the
session
states
should
be
kept
for
and
additional
publish,
subscribe
messages
and
acknowledgement
messages
for
for
communication.
That
requires
a
higher
quality
of
service
when
we're
connecting
to
the
broker.
The
client
still
must
provide
a
token,
and
this
token
still
must
be
validated
using
the
proof
of
possession
that
we
describe
in
the
spec.
G
At
the
moment,
I've
written
this
down
as
a
may
thinking
that
this
is
a
shortcut
for
the
client
for
the
broker,
if
it
realizes
the
client
is
using
the
same
token
as
before
it
can
skip,
for
instance,
introspecting.
The
token,
however,
with
may,
the
broker
cannot
really
validate
if
the
reconnecting
client
is
the
same
client
as
before.
This
is
an
issue
in
the
original
mqtt
as
well.
So
two
clients
maybe
use
the
same
client
id
and
they
might
both
want
session
continuation
and
there
will
be
a
clash.
G
This
is
not
necessarily
a
huge
security
problem,
because
the
clients
are
still
permission
by
the
token
what
they
receive
or
send.
So
they
cannot
do
beyond
what
their
token
allows
them
to
do,
but
it
will
affect
quality
of
service
because
some
of
a
client
a
client,
a
and
client
b,
if
they
have
clashes
some
of
client
ace
messages
can
come
to
client
b.
G
If,
if
the
client
b
takes
over
client
a's
client
id,
if
we
change
this
from
mate
to
must
in
its
current
state,
the
spec
cannot
support
this,
because
it
would
assume
that
the
clients
that
are
continuing
this
session
always
use
the
same
token
through
these
continuations.
G
But
for
some
reason
the
client
might
have
gotten
a
new
token.
So
we
need
to
make
a
change
if
we
turn
this
to
a
must.
So
my
question
to
the
work
group
should
this
be
changed
to
a
must
and
if
it's
a
must.
G
The
suggestion
I
have
is
that,
since
we
support
this
for
both
mqtt
version,
31
and
mv5,
an
oath
flow
based
solution
is
not
appropriate,
so
we
would
need
to
change
the
connect
message
to
support
two
tokens
and
we
would
need
to
rewrite
the
language,
so
the
broker
for
continuing
clients
expect
to
see
and
and
which
have
a
some
session
state
already
at
the
broker-
would
expect
to
see
two
tokens
in
the
connect
message,
and
then
we
have
to
think
about
some
error
messages
when
this
doesn't
happen.
G
So
if
a
client
doesn't
provide
a
two
tokens
and
it
has
some
session
state
at
the
broker,
this
has
to
be
rejected
with
appropriate
message.
This
can
be
a
protocol
error,
for
instance,
following
the
mqtt
error
messages
and
for
clients
clashing
with
client
ids.
G
The
cl
if
a
client
has
already
took
if
this
server
has
client
state
matching
the
client
id,
but
the
tokens
do
not
match
it
can
send
and
client
identifier,
not
valid
error,
for
instance.
So
we
need
to
think
about
error
messages
when
these
do
not
do
not
hold.
G
The
other
open
issue
is
regarding
reauthentication.
This
is
not
necessarily
an
open
issue.
I
just
wanted
to
confirm
with
the
working
group
that
the
language
I
put
there
is
appropriate
as
again
in
interim
meetings,
we
discussed
how
the
reauthentication
happens
during
a
connection,
and
we
accepted
this
to
be
allowed
for
clients
that
use
the
challenge
response
flow.
They
can
push
another
token
during
their
session
and
the
broker
accepts
these
requests
if
a
token
has
already
been
accepted
and
validated
via
challenge
response.
G
One
issue
with
this
flow
jim
raised
that
clients
may
send
connect
messages
without
any
token,
and
they
can
try
to
go
into
re-authentication
by
sending
an
oath
message
immediately
after
so
we
kind
of
change
the
language
so
that
we
don't
allow
this
to
happen.
So
we
don't
allow
broker
to
process
any
data
by
the
client
after
the
connect
packet,
but
before
the
conak
packet,
so
it
has
to
decide
the
fate
of
the
connect
first
before
accepting
any
packets.
A
A
It's
a
question
from
from
ben,
which
says:
I'm
gonna
read
it
unless
ben.
Do
you
want
to
talk
directly.
E
I
can
try
and
talk
directly,
okay,
partly
I
just
I'm
not
very
familiar
with
how
the
details
of
mqtt
work,
but
I
was
sort
of
wondering
if
the
session
continuation
could
be
treated
sort
of
as
a
an
optimization,
but
you
still
have
the
option
to
fall
back
to
a
non-continuation
flow,
and
if
that
was
the
case,
then
the
requirement
to
use
the
same
token
would
not
necessarily
be
as
as
difficult
because
if
your
token
changed,
you
could
just
do
a
fresh
session.
G
I
think
that's
perfectly
possible
as
well,
and
it
would
not
change
require
any
change
to
the
spec.
It
would
basically
ask
like
so
if
the
client
connects
with
a
new
token
and
it
doesn't
so
what
happens?
Let's,
let's
think
about
what
happens
in
that
state
if
the,
if
basically
allow
the
server
to
associate
a
state
and
it
doesn't
match
the
current
token
that
the
client
provides
the
server
would
reject
that.
Basically,.
G
I
think
we
still
would
need
to
do
some
changes
to
the
spec,
because
if
we,
if
we
do
this,
we
assume
the
client
to
act
properly
like
they
would
stop
a
session
continuation
if
they
got
a
new
token
and
they
would
start
a
clean
session.
But
I
don't
think
clients
are
expected
to
behave
properly.
They
might
try
to
come
with
a
session
continuation
and
then
they
would
have
to
provide
a
token
and
then
we
will
fall
into
a
case
where
the
broker
needs
to
respond
to
that
request.
G
So
it's
either
keeps
session
state
a
token,
a
session
state
and
then
makes
a
check
or
it
doesn't
if
it
doesn't
keeps
it
a
session
state
and
if
the
token
is
valid
it
would
continue,
and
we
are
back
to
the
case
where
client
id
clashes
can
happen.
G
A
But
I
would
say
it's
a
if,
if
clients
do
not
behave
properly,
that's
their
problem,
I
would
guess
no.
G
Yeah,
it
is
going
back
to
the
case
where
client
we
we
don't
validate,
that
the
client,
the
reconnecting
client
is
the
same
client,
which
is
the
current
case
of
the
of
the
spec.
G
So
if
that's
acceptable,
we
don't
need
to
make
any
changes
to
the
spec
and
we
live
with
whatever
negative
effect
on
the
client
it
has,
and,
as
I
said,
I
don't
think
it's
a
security
issue.
It's
a
more
quality
of
service
issue
for
the
clients
that
have
clashing
client,
ids.
A
So
as
anyone
any
any
comments
regarding
what
has
been
said
and
any
concern
that
it's
up
to
the
client
to
behave
properly,
unless
he
is
going
to
be
affected.
G
Actually,
in
this
case,
the
clients,
if
we
don't
make
any
changes
to
the
to
to
the
spec
at
the
moment,
client
can
push
a
new
token,
because
the
all
the
server
cares
is
whether
the
token
provided
in
the
connect
is
valid
or
not.
So
if
it's
valid,
it
would
be
basically
using
the
new
token
and
whatever
session
state
associated
with
it.
We
just
don't
guarantee
that
it
is
actually
the
client
session
state.
G
However,
since
the
session
state
is
filter
by
the
what
the
token
permits
or
not
it
might
not
get
it's,
it
may
basically
get
some
acknowledgement,
messages
or
publish
messages
from
another
client
session.
A
But
well
I
I
don't
have
all
the
bits
in
mind,
but
the
latest
statement
seems
to
be
a
problem.
No.
G
Well,
the
it's
so
again,
the
case
is
only
a
quality
of
service
problem
in
my
head,
because
it
is
not
a
a
private
message
that
the
broker
is
sending
to
the
client.
This
is
a
message
that
is
associated
with
a
topic
and
if
the
new
client
is
allowed
to
see
messages
from
that
topic,
he
can
definitely.
D
G
Those
messages,
however,
if
client
a
comes
later
and
then
some
of
these
messages
will
not
in
is
not
going
to
be
delivered
to
client
a
anymore
because,
according
to
the
server
it
has
already
delivered,
it.
G
Jim,
I
did
check
this.
I
checked
the
language
in
the
mqtt
to
see
what
happens
when
client
becomes
so
client.
A
connected.
Continuing
and
client
b
comes
with
the
same
client
id
mqtt
says
the
server
basically
accepts
the
new
client,
but
then
I
recently
checked
the
language
again
and
it
says
it
has
to
validate
the
new
client
and
one
of
the
validation
options
might
be
that
it
has
to
comply
with
some
of
the
further
restrictions
and
authentication
and
authorization
checks.
G
So
we
can
say
that
since
the
client
id
came
oh
yeah,
so
one
of
them
is
accepted
and
with
a
valid
token
we
might
say
it
doesn't
accept
a
new
client
but
you're
right.
It
still
doesn't
know
who's
right
who's
wrong.
So
there
might
be
cases
where
people
are
thrown
out
of
their
sessions.
Definitely.
G
G
G
Yeah
they're
all
they
can
happen
in
vanilla
mqtt.
They
can
happen
in
the
mqtt.
Basically
we're
not
adding
additional
problems
to
mqtt.
It's
just
that
if
we
basically
allow
the
client
the
server
to
keep
token
as
the
client
state,
we
might
get
rid
of
these
errors
because
we
won't
allow
client
id
clashes.
We
will
accept
only
the
client
that
has
the
former
token
we
expect
be
allowed
as
the
session
to
continue
the
session.
Any
coming
client
will
not
have
a
matching
token
anyway,
so
they
wouldn't
be
accepted.
G
If
the
client
cannot
prove
that
it
has
the
former
token
it
won't
be
accepted,
etc.
So
we
might
resolve
actually
issues
with
the
client
id
clashes.
If
we
add
this
additional
state.
A
G
Okay,
that's
acceptable
for
me
as
well.
I
just
wanted
to
make
sure
that
we
basically
have
an
agreement
on
this,
because
I
kind
of
went
for
the
best
effort
language
with
may
before
and
being
fully
aware
that
we
are
not
really
validating
clients
across
sessions
and
I'm
happy
with
the
solution.
A
But
I
also
have
the
impression
that
we
should
really
prevent
that
one
session
is
being
taken
over
by
another
client,
even
though
they
have
the
right
to
subscribe.
G
D
G
You
know
again,
this
is
not
something
that
we
are
introducing
as
a
byproduct
of
our
authentication
mechanisms.
It
can
happen
in
mqtt
already.
I
think
it
has
to
be
resolved
in
another
layer
like
in
a
operations,
layer
or
etc,
for
if
this,
if
a
client
is
experiencing
way
too
much,
it
has
to
be
resolved
outside
the
protocol.
I
think
that's
how
mqtt
resolves
it.
A
G
A
Yeah,
okay,
so,
which
means
that
clients
need
to
have
a
reconnection
a
way
to
reconnect,
I
mean
it's
not
once
they've
done
their
session,
they
they
must.
G
G
This
might
be
even
problematic
because
then
they
will
take
over
the
session
of
that
client
and
that
will
come
back
and
it
will
go
on
forever.
So
that's
why
I
suggested
that
it
probably
is
resolved
not
outside
the
protocol
in
mqtt,
some
other
if
clients
continuously
disconnect
because
client
ids
are
clashing,
I'm
sure
there
is
something
that's
done
outside
the
protocol
in
mqtt
deployments.
G
G
Because
it
keeps
a
single
client
id
per
session,
it
cannot
have
the
same
clients
with
two.
It
cannot
have
two
clients
with
the
same
client
id
connected.
A
A
Okay,
but
what
okay?
So
it
doesn't,
it
doesn't
knows
whether
the
client,
the
client,
it's
a
reconnect
or
if
it's
still
online.
G
E
Okay,
yeah,
I
think
it's
sounding
you're
only
going
to
get
into
trouble
with
like
people
forcibly
taking
over
each
other's
sessions
or
whatnot.
E
E
G
Yes,
so
I
will
leave
it
as
may.
Is
that
the
decision?
The
name
was
basically
for
a
for
me
if,
for
instance,
for
reference
tokens,
the
server
has
already
introspected
the
token
already
and
then
decline
connects
with
the
same
token
again,
and
he
says
okay,
I
have
actually
a
valid
introspection
results
in
my
state.
I
will
not
do
an
additional
check
with
the
ais
and
I
use
the
introspection
result,
because
I
know
what
this
token
will
will
come
back
with.
G
Of
course,
this
is
within
the
timeouts
of
you
know
how
the
tokens
should
be
introspected
and
etc.
We've
already
introduced
measures
around
around
that,
but
this
was
just
a
kind
of
allowing
the
server
to
do
a
shortcut.
That's
why
I
said.
May.
A
G
G
Language
as
well
add
that
to
the
spec
explaining
that
this
might
happen,
but
this
is
a
property
of
the
mqtt
rather
than
the
ace
profile.
A
G
Id
I'm
just
I
don't
know
from
the
top
of
my
head.
The
random
generation
is
suggested,
but
it
might
be
still
problematic
for
the
client
identifier,
because
if
you
keep
session
state
and
you
keep
connecting
with
random
identifiers,
you
might
bloat
the
server
with
with
information
that
is
never
going
to
be
accessed
again.
So
it
is
23
utf,
8,
encoded,
bytes
in
length,
the
client
id
okay.
A
Okay,
so
I'm
wondering
if
anyone
has
something
to
do
or
if
we're
all
converging
to
may.
A
And
if
not
yeah,
it
seems
I
mean
we
m,
we
might
document
a
little
bit
that
problem
and
just
mentioned
it's
not
related.
It's
related
to
mqtt,
not
ace,
okay
and
move.
G
A
That's
my
my
reading
francesca
was
in
the
in
the
queue.
I
don't
know
if
she
has
something
to
say.
A
A
A
H
G
We
can
move
on
next
slide.
This
was
just
saying
what
I
have
so
the
questions
I
have
about
the
spec,
these
the
questions
about
basically
registering
additional
registrations
that
we
might
need
to
do.
G
This
spec
basically
allows
the
as
to
include
a
thumb
print
of
the
rssx
509
certificate
for
the
client
to
do
a
server
authentication
during
the
tls
handshake,
and
this
is
in
rscnf
and
the
thumbprints
for
the
jot
is
registered,
and
for
this
spec
we
were
basically
using
json
web
tokens
and
the
optionally
we
were
allowing
the
seaboard
web
tokens
and
the
question
is:
should
this
spec
register
thumbprints
for
this
confirmation
claim
as
well
or
will
there
be
any
other
spec
that
does
it?
G
What's
the
expectation
from
the
working
group
about
this
question?
The
second
is
the
registration
that
needs
to
be
done
in
the
aids
profile
registry
for
the
mqtt
tls
profile,
it
kind
of
asks
for
receivable
value
and
I'm
not
too
sure
what
goes
in
there.
So
those
are
the
two
questions
I
have
regarding.
D
G
G
C
B
I
think
we're
gonna
end
up
wanting
wanting
them
someplace
else
reasonably
soon.
So
those
show
up
at
some
point.
G
All
right,
then,
I
can
go
to
the
next
slide,
so
in
the
next
steps.
As
since
I
have
confirmation
regarding
the
open
issues,
we
can
resolve
that
in
the
text
and
there's
so
based
on
the
latest
jim's
review
as
well.
I
do
not
think
there
are
many
technical
issues
or
any
technical
issues
left
in
the
spec
to
discuss.
G
There
are
two
there's
more
work
to
be
done
in
the
implementation
there.
There
were
two
implementations
I
were.
I
was
involved
with.
One
is
with
the
attenborough
university
that
basically
took
the
hive
and
queue
which
is
an
enterprise,
mqtt
provider
and
their
community
edition,
stuff
and
kind
of
implemented.
All
the
flows
for
the
mqtt
version,
five
as
well,
but
it
doesn't
reflect
the
latest
changes
to
the
spec
at
the
moment,
especially
with
the
aif
change
as
well.
G
The
second
one
was
just
a
proof
of
concept:
prototype
which
kind
of
remained
at
version.
311
and
more
work
needs
to
be
done
to
bring
it
to
version
5
support.
So
these
are
the
two
implementations:
I'd
be
I'll,
be
focusing
next,
but
for
the
next
next
steps
for
the
for
the
next
steps
for
this
spec.
I
basically
am
looking
at
the
workgroup
chairs
to
give
me
guidance
on
what
should
be
done.
A
Okay,
thank
you
so
guidance
on
on
regarding
the
implementation
is
that.
A
Okay,
so
well
I
mean
maybe
jim
has
another
view,
but
my
my
guess
is
now
that
we
with
the
next
iteration
we
will
be
ready
for
working
group.
Last
call.
A
But
that's
my
my
feeling,
and
so
we
will
need
to
to
have
a
final
reviews
from
the
working
group
and
and
then
we
will
send
the
document
to
to
ben.
G
I
think
pretty
soon,
because
the
issues
that
we
discussed,
we
basically
leave
the
language
as
it
is,
and
then
I'll
just
have
to
add
the
explanation
regarding
the
regarding
the
explanation
of
what
what
happens
in
a
client
id
clash.
That's
the
that's,
what's
kind
of
remaining
thing
to
do,
and
that
should
be
easy
within
a
one
or
two
weeks.
I
should
have
another
version.
A
A
C
Yes,
I
missed
the
point
about
the
cwt
confirmation
claims.
Are
there
additional
ones
that
you
need
beyond
those
already
registered
by
rfc.
C
B
There
may
be
some
dtls
systems
that
are
going
to
want
to
use
certificates
too.
So
I
think
that
may
show
up
as
part
of.
C
C
A
Okay,
so
well,
do
you
have
any
more
questions,
signum.
A
D
D
Just
for
an
update
on
what
happened
since
last
interim,
which
was
22nd
of
june,
so
we
submitted
a
version
8,
which
was
based
on
a
review
from
jim.
It
was
mostly
editorial
changes
and
clarification,
or
maybe
I
can
also
share
my
video.
So
you
can
also
see
me
while
I
talk
so
the
details
of
these
changes
that
were
90.
Some
something
comments
can
be
found
at
the
pull
request
linked
here
and
then
there
was
24
issues
that
were
created
as
a
result
of
jim's
follow-up
review.
D
So
we
are
starting
to
plan
a
version.
Nine
and
of
those
most
of
them
are
again
clarifications,
but
four
we'd
like
to
discuss
today
next
slide,
please
so
the
first
point-
and
one
of
the
major
ones
from
today
is
that
we
have.
We
have
discussed
with
jim,
to
remove
the
default
to
your
eyes
from
the
ac
group
home
and
have
the
because
right
now
there
is
a
default
uri
and
then
the
application
profiles
can
define
their
own
uri
if
they
need
to
and
for
example,
ascii
or
com
or
score.
D
D
So
we
had
the
proposal
to
remove
that
and
have
all
the
application
profiles
used
the
same
one
that
would
be
defined
in
this
document.
Ace
key
group
com
and
to
do
so,
then
the
kdc
would
have
to
say
for
each
group
itself
the
information
about
what
application
profile
it's
using.
For
example,
group
1
uses
encodings
from
this
application
profile.
Group
2
uses
this
other
and
it's
necessary
that
the
kdc
knows
this
information,
obviously
for
encoding
and
additional
requirements.
D
So
this
there
is
actually
three
options
and
not
not
two.
So
the
first
one
is
to
register
the
ace
group
as
a
well-known
uri
in
this
document.
The
second
one
is
to
register
a
resource
type,
only
one
for
this
root
uri
and
describe
the
resource
directory
used
to
find
this
uri.
And
it's
the
same
way
that
we
have
discussed
for
the
auth
info
in
the
framework
and
as
a
consequence,
if
we
pick
this
option,
then
we
need
to
decide
a
couple
more
things.
D
The
first
one
would
be
do
we
need
to
define
new
target
attributes
for
each
application
profile
to
do
filtering.
So
as
an
example,
let's
say
that
you
want
to
access
all
groups
that
have
cert
that
are
under
a
certain
profile.
Let's
say
you
want
to
access
all
oscar
groups
and
you
don't
care
about
the
pub
sub
groups.
You
could
you
could
request
this
uris
and-
and
you
could
have
a
target
attribute
saying
only
want
to
do.
D
I
only
want
these
so
do
we
need
to
do
something
like
that
and
also
as
a
note,
we
already
have
registered
an
interface,
so
I'm
not
really
knowledgeable
about
interfaces
and
resource
types,
but
we
already
have
registered
the
interface.
We
have
iona
registration.
So
can
we
use
that
instead
of
registering
another
resource
type
and
how
is
that
different?
D
D
I
I
But
I
think
it's
really
more
likely
that
that
somebody
who's
trying
to
discover
something
already
knows
that
this
is
going
to
be
an
oscar
group
or
a
pubs
up
service.
So
I
also
think
that
see
jim's
comment
here.
I
also
think
that
that
registering
different
resource
types
may
work
better
and
yeah
resource
types
are
cheap,
so
I
think
we
we
can
give
out
several
of
them.
I
If
you
really
want
to
be
able
to
find
out
something
is
just
generally
a
group
com
thing
you
can
still
define
an
interface
type,
which
you
can
then
add
to
the
resource
type
and
say:
oh
by
the
way
this.
This
is
one
one
example
of
a
generic
group.
Config.
D
J
Can
you
hear
me
yes,
hi
yeah,
I
also
support
number
three
and
we
are
actually
already
doing
that.
Just
registering
a
resource
type
in
another
document.
I
record
document
with
the
suggestion
from
gin
to
move
the
registration
in
keygroup
com
all
scoring
state,
but
yeah
that
helps
a
lot
for
filtering
during
a
discovery
phase.
B
Not
only
put
it
on
the
slash
group
or
slash,
slash
group
com
thing,
you
can
also
put
it
on
slash
group
com,
slash
group,
one,
so
that
group
one
actually,
you
can
advertise
that
group,
one
actually
is,
is
oscor.
While
slash
group
two
could
be
something
else
and
the
slash
group
root
could
say
I
support
both
of
them.
D
Uh-Huh,
okay,
I'm
just
so
you're
talking
about
registering
the
resource
type
do
do
we
need
to.
D
D
Okay,
so
so
I'm
just
wondering
if
we
need
to
I
see
what
you're
saying
and
I'm
not
sure
that
requires
any
any
addition
to
the
document,
except
for
registering
a
resource
type
for
each
application
profile.
D
Yeah,
okay
yeah,
because
then
what
you're
saying
that
is
that
you
could?
You
could
use
this
resource
type
when
doing
a
resource
discovery,
also
for
not
only
the
root
but
the
other
child
of
the
root.
A
Just
for
me
to
as
a
clarification,
what
are
the
different
application
profiles?
We
have
it's
two
or
three,
no.
D
D
That
includes
both
co-op
pub
sub
and.
A
Okay,
so,
okay,
so
that's
so
mqtt
is
in
pepsab.
D
Well,
this
application
profile.
Yes,.
D
So
as
a
comment
as
a
result
of
comment
from
jim,
we
will
clarify
the
difference
between
group
name
and
group
name
and
group
identifier,
and
so
the
difference
is
that
the
group
name
is
the
invariant
once
established
identifier
of
the
group,
which
is
used
in
the
scope
to
identify
the
group
between
as
client
and
kdc,
and
it
can
be
encoded
as
anything
which
and
we
propose
to
changes
to
text
string
for
simplicity,
while
the
old
capital
group
name
is
the
value
that
is
used
in
the
uri
and
it
maps
in
some
sense
to
the
group
name.
D
But
it's
not
the
same
value
and
it's
we're
going
to
keep
it
that
way
and
then
finally,
there
is
a
group
identifier
which
is
the
identifier
of
the
group
key
material
and
not
of
the
group
itself,
and
the
difference
is
that
this
identifier
changes
with
three
keys
and
we
will
add
this
group
identifier
right
now.
We
were
not
talking
about
this
group
identifier,
but
we
will
ask,
we
will
add
it
as
a
result
of
review
comments.
So
next
slide.
D
So
it's
important
to
understand
this
difference,
because
this
is
another
update
that
we
propose
to
do
is
to
add
a
put
and
handler
at
the
root
of
the
interface
of
the
kdc.
So.
A
Just
francesca
yeah.
A
Regarding
the
previous
issue,
I
can
see
ben
in
the
in
the
in
a
driver,
room,
explain
expressing
some
concern.
Okay,
that
some
directorates
and
isg
reviewer
might
ask
for
a
larger
difference.
D
The
reason
for
calling
group
identifier
would
be
that
that's
what
the
oscore
document
calls
it
and
that's
because
the
oscorp
group
communication
document
calls
it
that
way.
So
we
are
inheriting
it
from
those
documents
yeah
we
we
can.
Let's
discuss
this
offline,
I
think
it's
or
ben.
Do
you
want
to
say
something.
E
D
No
problem,
okay,
so
for
the
for
this
up
for
this
proposal
update.
Is
that
we're
adding
this
put
handler
where
the
client
would
send
the
list
of
group
identifier
and
get
back
the
corresponding
group
names
and
the
uris
at
the
kdc?
For
those
identifier-
and
this
is
useful
when
there
is
a
re-key,
the
node
gets
group
identifier,
so
the
identifier
of
the
group
key
material
which
it
does
not
recognize
and
wants
to
know
what
group
to
to
contact
like
what
group
to
ask
for
key
material
at
the
kdc.
D
For
example,
it
needs
to
know
the
uri
s
group,
slash,
group,
1
or
g1,
where
g1
is
the
where
this
is
the
uri
for
group,
one
and,
and
so
a
way
to
do
this
is
to
the
client
will
do
a
put
at
the
root
of
the
interface
at
the
kdc,
including
the
group
identifier.
D
Let's
say
in
this
case,
it's
asking
for
two
group
identifiers
and
the
the
response
would
be
a
205,
including
group
identifies.
So
it's
a
map,
including
group
identifier,
an
array
of
group
identifiers
gname,
which
is
group
names
in
this
case
group,
one
group
group
two
and
then
gui.
So
an
array
of
your
eyes-
and
this
is
missing
a
closing
parenthesis,
but
just
imagine
that
it's
there
and
both
these
requests
and
response
would
have
content
format.
D
D
D
D
And
also
we
could
talk
about
put
versus
post
and
we'd
welcome
feedback
on
that
as
well
and
jim
is
saying
this
should
be
fetch,
which
is
also
good
point.
I
D
D
So
I'm
happy
with
this,
and
if
there
is
no
other
comments
on
the
encoding,
I
think
we
can
move
to
the
next
one.
A
Just
clarification,
why
should
it
be
a
fetch.
A
D
D
So
you
would
send
a
put
request
to
this
resource
to
get
back
input
to
derive
key
material
to
protect
outgoing
messages
to
the
group,
and
this
is
different
than
group
key
material.
This
is
something
that
allows
you
to
write
to
derive,
for
example,
a
specific
key
that
is
individual
to
you
to
the
node
requesting
it
so
making
the
parallel
with
those
core.
This
would
be,
for
example,
getting
the
sender
id
in
the
oscar
groups.
D
So
we
are,
we
cannot
talk
about
so
this
is.
It
is
hard
to
give
the
hint
of
what
this
individual
key
material
is
without
talking
about
oscor.
D
Some
application
profiles
may
not
even
implement
individual
key
material,
so
the
proposal
that
came
from
one
of
jim's
comments
was
to
to
make
it
so
that
profiles
may
additionally
use
this
handler
to
rekey
the
whole
group.
So
basically,
what
we
want
to
say
is
that
this
is
used
to
get
to
renew
your
individual
key
material
and
optionally,
additionally
re-key
the
whole
group.
D
Okay,
great
and
also
reading
the
chat
and
ben
seems
to
agree,
and
yes,
we
definitely
need
to
add
some
considerations
about
that
and
I
think
yes
next
slide.
That's
my
last
slide.
The
plan
is
to
submit
version,
zero,
nine
and
then
possibly
working
group
plus
call.
D
So
yeah,
I
I
guess
we'll
we'll
move
forward.
We
do
these
updates
that
we
discussed
today
and
the
rest
of
the
follow-up
comments
from
jim
and
then
we
can
move
forward.
Thank
you.
A
J
J
Right.
Thank
you.
This
is
an
update
on
this
working
group
document.
It's
an
application
profile
base
from
kegelcom
next
slide.
Please.
J
Use
your
recap:
this
is
about
an
ace
client
that
wants
to
access
an
oscar
group
through
the
group
manager,
so
it
gets
an
access
token
first
posts
it
at
the
group
manager
then
sends
a
joining
request
and
it
gets
in
the
joining
response.
The
key
material
to
communicate
with
group
of
score
in
the
group
next
slide.
Please
right
in
this
update.
We
have
mostly
closed
the
number
of
open
points
already
discussed
at
the
latest
interim
in
june.
J
The
biggest
one
was
actually
when
the
etc
combination
should
be
checked,
to
possibly
stop
a
nod
from
continuing
and
as
we
agree
that
happens
only
when
processing
the
actual
joining
request.
So
if
that
contains
a
scope
expressing
a
combination
that
doesn't
make
sense
that
the
joining
is
interrupted
and
as
suggested
by
gene,
we
have
moved
to
this
document
as
more
appropriate.
J
So
we
are
essentially
defining
an
af
specific
data
model,
af
oscar
group
com,
to
express
scopes
for
this
application
profile
and
at
a
high
level,
we
still
have
scope
as
an
array
of
scope
entries
and
each
of
which
has
to
express
the
group
name
and
the
roles
intended
to
get
in
the
group.
But
now
we
are
trying
to
follow
an
af
paradigm
instead.
J
Next
slide,
please
to
give
a
bit
more
details
about
that.
In
fact,
according
to
the
new
data
model,
we
have
as
first
element
path
in
the
scope
entry
still
the
group
name
as
text
string
as
it
used
to
be
before.
J
But
now
the
the
role
or
combination
of
role
is
expressed
as
a
single
integer,
which
is
actually
a
bitmap,
indicating
the
exact
roles
that
that
node
is
supposed
to
to
get
in
the
group,
and
that,
of
course
meant
a
lot
of
new
ayana
registrations,
mostly
to
cover
the
the
actual
aif
part,
but
also
for,
for
the
sake
of
future
extensibility,
to
create
a
new
registry
about
the
identifiers
for
the
roles
in
the
group.
J
Yes,
you
can.
Okay
with
that
single
integer,
you
can
express
multiple
roles
combined.
H
J
J
Okay,
yes,
we
had
some
mismatch
in
the
formats
of
two
information
representation,
one
in
the
parameter
one
in
a
payload,
so
we
already
had
a
method
actually
based
on
fetch
to
request
public
keys
of
other
group
members.
For
a
note,
that
is
already
also
a
group
member
and
the
format
of
that
payload
was
different
from
the
format
of
an
analogous
parameter.
J
Get
pub
keys
instead
used
in
the
joining
request
to
get
at
joining
time
the
public
keys
of
the
current
group
members
and
that
used
to
work
in
an
all-or-nothing
way.
J
So,
if
the
parameter
is
present,
it
had
to
be
an
empty
array
to
just
get
all
public
keys
of
current
group
members,
and
we
made
a
change
to
align
the
format
of
that
parameter
to
the
fetch
payload
of
that
other
method
and
request,
not
necessarily
all
the
public
keys
of
the
current
members
in
the
group,
but
only
the
public
keys
of
members
that
have
particular
roles
or
combination
of
roles.
J
So
we
indicate
that
as
a
filter
rule
in
in
the
first
inner
array
and
following
again
the
same
encoding
based
on
aif,
that
we
considered
for
scope
actually,
while
for
this
particular
case
for
this
parameter
in
the
join
request,
the
second
array
is
always
empty,
because
the
joining
node
has
no
idea
of
the
not
names
at
that
point
in
time
we
we
chose
to
get
anyway,
a
second
array
always
empty,
just
to
to
keep
the
very
same
format
of
the
fetch
payload
instead
and
there's
a
final
thing.
J
We
have
also
defined
here
the
default
values
for
group
policies
that
now
the
group
manager
has
to
return
in
the
joining
response.
So
in
case
when
creating
the
group,
those
values
for
those
policies
were
not
specified.
The
group
manager
has
to
consider
those
as
default
values
next
slide.
Please-
and
this
actually
concludes
my
updates.
We
we
have
one
open
point,
which
is
mostly
clarification.
We
we
noticed
also
talking
to
other
people
in
the
joining
response
to
indicate
the
sender
id
assigned
to
the
new
member.
J
We
are
using
the
client
id
parameter
from
the
score
security
context,
object
because
it
was
convenient,
no
need
to
register
a
new
one
and
all
in
all,
this
is
an
ace
client
verify
that
the
name
client
id
has
nothing
to
do
with
any
possible
co-op
role
that
the
new
member
takes
in
the
group,
so
just
avoid
confusion,
and
then
jim
suggested
also
to
move
the
registration
of
a
resource
type
associated
to
this
kind
of
of
joining
resource.
J
From
from
the
document
where
it
is
currently
registered
to
this
one
as
more
appropriate-
and
this
was
pending
a
decision
about
using
resource
types
in
his
key
guru
combat
is,
since
we
got
the
decision
now
so
moving.
This
registration
here
can
be
done.
We
were
just
wondering
in
if,
since
we
would
move
the
registration
to
to
this
document,
a
different
better
name
than
the
current
one
will
be
more.
J
Yes,
then,
we
plan,
of
course,
to
have
interrupt
tests,
and
I
can
think
of
our
implementation.
James
and
peter
van
der
stalk
also
has
one,
but
after
that,
we
believe
this
can
also
move
on
to
working
roblox
gold.
A
Okay,
great,
so
we
probably
need
a
little
bit
more
reviews,
but
it's
it's
great
plans.
A
So
basically
there
is
a
call
for
reviewing
those
drafts
as
soon
as
they're
being.
A
Published
now
jim,
I'm
wondering,
should
we
go.
A
To
the
cmp
ver
is
yeah,
should
we
go
to
the
cmp
presentation?
First,.
A
A
K
K
The
previous
trap
was
to
make
changes
to
the
existing
cmp
v2
profile,
to
make
it
more
suitable
for
iot
devices
and
since
iot
devices
use
mostly
coap
for
their
transport
because
of
the
power
constraints
this
so
this.
This
was
basically
one
of
the
intended
chapters
in
the
draft,
but
then
this
it
was
decided
that
we
will
probably
remove
remove
this
thing
out
of
the
lightweight
cmp
profile
draft
and
create
it
as
a
new
document
in
this
group,
because
that's
the
more
suitable
place
for
this.
K
So
so
in
general,
we
have
support
for
http
transport
for
cmp
v2
protocol,
and
this
coep
is
very
similar
to
http
and
I'm
trying
to
follow
whatever
is
returning
rx66712,
which
defines
http
transport
for
cmp
protocol.
K
So
these
are
the
some
key
key
points.
What
we
are
in
like
highlights
of
the
draft,
so
the
first
thing
is
basically
the
cmp
v2
profile
is
transport
agnostic.
So,
basically
the
way
the
protocol
is
written,
you
can
even
use
email
to
do
basically
do
the
transactions
to
get
a
certificate
from
the
from
the
ca
or
re,
and
then
the
second
thing
is
to
support
block-wise
transfer
mode,
to
avoid
fragmentation
and-
and
third
main
point
is
so
basically
because
so
because
most
of
the
existing
systems
they
support
http
for
cmpv2.
K
It
will
be
a
good
idea
to
use
a
cop
to
http
proxy
at
the
boundary
of
the
constraint
device
network
so
that
the
existing
systems-
they
don't
need
to
change
much
and
lastly,
coaps
can
be
used
for
instead
of
ceo.
If
we
need
to
have
additional
secrecy,
where
you
don't
even
want
the
people
to
see,
if
if
there
is
a
coap
content
going
through
or
there
is
a
cmp
v2
transaction
happening
and
it
can
use
dtls
basically
so
so
these
are
the
some
key
points
of
the
draft
next
slide.
K
K
To
add
this
to
basically
adopt
this
document
in
this
working
group,
so
so
that
is
the
main
point
of
discussion
today.
So
if
we
want
to
like
support
the
recharger
to
add
this
so
that
we
can
adopt
this
dot
draft,
so
anybody
has
any
questions.
A
So
yeah
jim.
B
An
enrollment
protocol
which
in
some
respects
is
part
of
ace
it's,
and
this
is
basically
the
same
thing
as
what
the
s
document
did.
B
B
E
A
Thing
anyone
strongly
opposing
for
such
a.
A
Document
so
I'm
hearing
none,
so
the
question
I
would
have
is
that:
can
we
adapt
that
document
without
retiring?
The
working
group.
E
I
think
we
would
need
to
recharter
to
to
pick
it
up.
It
was
just
better
in
the
past
few,
okay.
A
Yeah
yeah,
that's
fine,
so
we
will
probably
have
first
recharger
and
then
do
the
call
for
adoption.
That's
my
understanding.
A
Yeah,
I
don't
think
we
should
be
long
to
recharter
jim.
B
I
don't
know
we
have
to
finish
looking
at
things
note
that
that
doesn't
preclude
people
from
doing
reviews
on
the
documents
we
can
review
documents
that
are
not
part
of
our
charter.
A
A
F
Oh
yeah,
okay,
duran
selander
from
erickson,
I'm
just
curious.
I
have
I'm
sorry.
I
haven't
read
the
draft
just
trying
to
understand.
I
mean
I
I
read
in
the
table
of
contents.
There
is
something
about
multicast,
co-op
and
proxy
support.
F
Could
you
just
elaborate
a
little
bit
wait
on
on
that?
What's
how
that's
important
so.
K
K
Yeah,
basically,
I
see
like
to
have
a
good
adoption
of
this
thing.
It's
better
to
have
proxy
because
coap
or
internet
itself
is
born
to
some
prone
to
some
basically
attacks
and
all
those
things
because
of
being
on
udp.
So
it
provides
some
additional
security
to
the
servers.
F
So
so,
basically,
what
what
this
draft
is
about
is
the
transport,
how
you
transport,
yes,
with
co-op
or
or
or
with
co-op
and
http,
or
with
security
as
well
yeah.
Okay,
thanks.
A
I
So
I'm
not
sure
whether
we
really
have
to
repeat
yesterday's
talk
from
the
core
working
group.
Can
we
quickly
find
out
how
many
of
the
people
were
in
the
co-working
group?
Just
everyone
who
was
in
the
car
working
group
request
speaker
permission
and
then
we
will
see
who
was
there?
So
four
people
were
there:
five
six.
I
Okay,
maybe
we
have
to
go
through
this
quickly,
then
so.
The
the
authorization
information
format
is
a
proposal
that
has
been
around
for
quite
a
while.
I
So
this
is
the
the
really
just
the
the
access
control
information
next
slide
and
we
we
recently
decided
that
we
make
this
a
little
bit
more
generic.
The
original
proposal
only
supported
mapping
paths,
uri
paths
to
permissions,
and
we
now
have
a
generic
form,
which
is
essentially
just
an
array
of
pairs,
and
then
you
can
can
instantiate
this
by
saying
or
my
my
object.
I
Selector
is
a
path,
and
my
my
permission
is
a
set
of
bits
that
that
stand
for
corp
method,
so
that
that's
the
basic
thing
but,
as
we
already
have
seen,
other
documents
like
mqtt
and
group
com
define
their
own
version
of
this
next.
I
Yes,
so
the
the,
if
you
want
to
have
a
variant
of
aaf
for
something,
then
you
need
to
put
in
both
the
the
the
type
for
the
object,
identify,
object,
selector
and
the
type
for
the
permissions,
and
in
this
case
the
type
for
the
permissions
are
derived
from
the
co-op
methods.
These
already
have
numbers,
so
it's
obvious
how
to
to
use
those
numbers.
I
Yeah,
so
the
the
most
recent
addition
to
af
and
in
draft
show
9
is
based
on
the
observation
that,
while
iot
devices
usually
have
mostly
static
resources,
so
the
the
model
of
mapping
paths,
uri
path,
the
paths
to
static
resources
to
permission
bits
works
very
well.
While
that
is
the
case,
there
are
some
dynamic
resources
in
iot
devices,
typically
called
action
resources
because
they
are
created
when
a
client
performs
an
action
on
a
device
such
as
moving
an
actuator
arm,
and
so
on
that
that
might
take
some
time.
I
So
these
are
bits
that
you
can
set
on
a
resource
on
a
base
resource
that
would,
you
would
use
to
start
an
action
and
the
dynamic
means
the
resources
that
are
created
based
on
actions
based
on
requests
on
this
base
resource,
so
the
action
resources,
those
are
governed
by
these
permissions
and
these
permissions
are
typically
different.
I
So
if
you
have
a
base
resource
that
allows
you
to
to
make
coffee
and
then
you
get
an
action
resource
that
is
controlling
one
particular
coffee
making
process,
you
might
have
a
delete
request
on
that,
so
it
stops
making
that
coffee.
But
of
course
you
wouldn't
give
the
client
the
the
permission
to
delete
the
coffee
maker.
I
So
these
are
different
and
therefore
they
get
different
bits.
And
when
we
discussed
this
yesterday,
we
found
out
that
we
maybe
need
another
copy
for
resources
that
are
related
to
a
base,
resource
and
but
but
haven't
created,
haven't
been
created
by
this
particular
instance.
So
we
will
have
to
find
out
how
to
do
that
next
slide.
A
I
have
to
check,
but
I
haven't
seen
any
major
opposition
to
that
draft.
B
A
Then,
if
you're
speaking,
we
don't
hear
you,
but
we
see
you.
E
Permission
so
I
had
a
question
from
the
previous
slide,
which
is
sort
of
with
a
concept
of
tracking
the
resources
created
from
a
base
resource
and
having
the
the
permissions
for
those.
So
who
has
to
track
which
resources
are
created
from
a
given
base
resource?
I
Only
the
resource
server
can
do
that,
because
the
resource
server
is
usually
not
really
asking
anyone
else
about
that.
If
a
client
has
a
permission
to
use
the
base
resource
to
create
an
action,
then
it
just
goes
ahead.
This
visa
server
just
goes
ahead
and
does
that
so
it
would
mark
the
the
temporarily
created
action
resource
with
the
identity
of
the
client
that
created
it
and
copy
over
the
permissions
minus
32,
so
that
the
client
can
access
this
action
resource.
I
E
Thanks
and
just
to
give
a
brief
note
for
everyone,
you
had
on
the
last
slide
my
question
about
what
else
is
similar
to
this,
and
that
was
just
with
me
looking
at
our
charter
text,
which
reminds
us
to
use
things
that
exist
already
when
possible
and
to
also
bear
in
mind,
if
there's
potential,
broader
scope
for
things
that
we
do
so
just
to
clarify.
That's
where
I
was
coming
from
with
that
question.
I
Yeah
I
I
when
I
started
this,
I
I
looked
for
other
ways
of
doing
this
and
I
was
surprised
not
to
find
anything
and
the
reason
really
is
that
the
idea
of
having
a
server
that
has
a
pretty
fixed
set
of
static
resources,
and
somebody
else
tells
that
server
who
is
allowed
to
access
those
resources.
That's
pretty
specific
to
iot.
So
it's
kind
of
new,
or
at
least
it
was
new
in
2014..
E
A
You
we
can
move
to
the
next
presentation.
Do
we
have
any
preference
between
admin
or
I
would
prefer
gm
admin
personally,
but
okay,
because
I
think
that's
going
to
be
the
last
one.
J
J
Okay,
thank
you,
marco
here.
This
is
an
update
on
another
document,
defining
a
different
interface
on
the
oscar
group
manager.
J
Next
slide,
please
so
just
to
recap:
this
interface
is
intended
for
an
administrator
is
client
for
creating
deleting
and
configuring
all
score
groups
at
the
group
manager
before
the
joining
process
can
start
for
candidate
members,
and
it
has
an
overall
design
pattern
similar
to
the
one
of
the
co-op
apps
of
broker,
though
in
the
way
it
becomes
a
bit
simpler
and
right
now
we
are
supporting
both
link
format
and
sybor
and
corel
and
in
principle
the
idea
is
to
have
the
group
manager
two
new
types
of
resources.
The
first
one
is
a
single
instance.
J
G
J
A
J
Oh
thanks
for
nothing.
We
can
make
things
uniform,
best
intent.
Of
course,
thank
you,
yeah,
just
an
overview
of
the
interface
all
on
the
single
instance
group
collection.
The
idea
is
that
a
request
can
be
sent
to
create
a
new
score
group
and
that
practically
means
creating
two
resources.
J
A
J
Do
shall
we
take
it.
B
J
J
We
moved
away,
as
I
mentioned
before,
some
default
values
to
the
other
draft.
We
try
to
simplify
the
text
of
a
section
describing
side
effects
that
would
happen
on
the
current
group
members.
If
the
administrator
decides
to
update
the
group
configuration
on
the
run,
apparently
it
was
a
bit
hard
to
read
now
it's
hopefully
it's
awfully
better,
please
jim
check.
Let
us
know
next
slide.
Please
right.
J
We
have
also
added
an
actual
payload
in
the
response
to
a
group
creation
now
specifying
more
information
in
return
to
the
administrator
that
can
be
used,
especially
to
advertise
the
existence
of
the
group
or
to
register
it
to
a
resource
directory,
and
we
also
better
clarify
the
intention
and
scope
of
this
work
in
the
introduction,
also
based
on
feedback
from
from
carsten
and
christian
on
the
list
and
giving
more
guidance
on
how
practically
the
registration
of
the
group
can
follow,
for
instance,
on
a
resource
directory
either
from
the
group
manager
itself
or
from
the
administrator
on
behalf
of
the
group
manager.
J
Next
slide,
please
right.
We
have
a
number
of
a
pen
point.
One
came
from
review
from
jim
that,
if
we
understood
correctly,
he
was
suggesting
to
consider
two
different
names
for
the
oscar
group
created
one
intended
for
the
administrator
for
admin
operations
and
one
instead
intended
to
be
advertised
and
made
public
for
candidate
members
to
join
so
yeah.
I
agree:
it's
fine,
there's,
no
big
penalty
on
doing
that.
I
I
just
wanted
to
hear
more
on
advantages.
You
you
are
seeing
in
doing.
J
B
Know
how
much
an
advantage
or
disadvantage
is
that
is
just
the
model
that
the
pub
sub
people
over
in
core
were
using.
J
J
Okay,
thanks
that
we
have
a
kind
of
new
open
point
that
also
peter
raised
recently
right
now,
when
creating
a
group,
the
administrator
suggests
the
name
that
the
group
should
take.
J
Of
course,
if
it's
taken
already,
an
error
is
returned,
but
we
are
leaving
the
final
decision
on
the
group
name
to
the
group
manager
and
we
have
been
thinking
to
simplify
this
and
to
just
have
the
administrator
proposing
the
name,
and
if
that
name
is
available,
that
name
is
taken
when
creating
the
group
they'll
simplify
things
a
bit,
and
it
goes
along
the
line
of
thinking
of
the
administrator
that
well,
it
knows
what
it's
doing.
It
has
reasons
to
to
try
to
go
for
that
name.
H
Just
one
of
the
reasons
that,
if,
if
you,
if
this
is
about
the
path
of
the
group,
if
it's
not,
then
please
stop
me
right
now,
the
server
might
have
more
just
have
more
constraints
than
the
administrator
is
considering.
If
it
is
not
about
the
path,
sorry
for
the
interruption.
J
Okay,
thank
you
we'll
discuss
more
on
this
next
slide.
Please,
okay
and
christian
also
suggested
that
it's
worth
looking
into
a
kind
of
use
case
where
other
than
the
administrator
as
a
main
one
creating
the
group.
There
may
be
other
site
administrators
that
can
jump
in
later
on
and
be
allowed
to
do
at
least
something
on
those
groups
like
if
they
created
them,
and
this
somehow
is
also
aligned
with
with
a
side
issue.
J
We
started
to
discuss
during
the
latest
hackathon,
especially
with
jim,
and
we
are
starting
to
think
to
to
define
a
proper
scope
format
that
can
be
used
here
to
express
what
an
administrator
can
do
and
we'll
do
that.
Keeping
also
this
use
case
in
mind.
J
And
finally,
I
would
also
like
to
consider
when
creating
the
group
that
the
administrator
can
specify
also
the
names
of
the
application
groups
using
data
score
group,
and
they
will
be
aligned
also
with
an
assumption.
We
are
doing
in
another
document
where
we
are
assuming
that
the
group
manager
knows
of
these
application
groups
and
their
names
when
it
registers
links
to
the
security
group
in
the
resource
directory,
and
this
is
also
aligned
with
suggestions
that
jim
gave
in
a
coral
informs
discussion
in
core
taking
this
document,
as
as
a
building
example.
J
This
is
the
conclusion
we
have
a
number
of
steps
ahead
related
to
the
open
points,
the
format
of
scope,
more
operations
for
the
for
the
interface
and
considering
again
related
to
the
choral
forms,
discussion,
even
more
information
and
hints
that
we
can
give
to
the
administrator
in
response
to
a
group
creation.
J
A
Yeah,
we
will
go
back
to
to
the
last
question
on
the
mailing
list.
I
I
think
we
should
close
the
meeting
now.
So
thank
you,
everyone
for
attending
just
to
let
you
know
that
we
have
interim
meetings
in
september
and
october,
trying
to
find
the
chair
slides,
so
these
have
been
registered
now.
So
please
we.
We
hope
that
the
working
group
last
call
for
all
the
documents
that
are
ready
for
working
group.
A
Last
call
are
gonna,
be
submitted
before
those
meetings,
so
please
update
your
draft
and
so
that
we
can
start
those
calls.
Thank
you
for
this
this
time
everyone
signed
the
blue
sheet.
So
that's
perfect,
thank
you
and
well.
What
can
I
say?
Jim
ben.
Do
you
want
to
say
something.
E
I
just
had
one
unrelated
point:
I
wanted
to
call
to
everyone's
attention
the
ietf
gather.town
setup,
which
is
sort
of
a
virtual
environment
where
you
can
wander
around
in
a
environment,
kind
of
like
the
conference
hallway
and
run
into
people
and
chat,
and
at
least
for
me,
it's
sort
of
a
nice
representation
of
the
typical
itf
in
person.
Experience
where
you
can
find
your
old
friends
and
catch
up
with
how
they're
doing
and
whatnot.
E
E
A
A
So
yeah,
please
everyone
go
to
that
site
and
yeah.
So
thank
you
for
the
for
attending
this
session
and
maybe
see
you
at
the
at
the
the
break
is
that
in
town
or
gathering
or
I
don't
know
it's
a
bit
of
mist
of
everything?