►
From YouTube: ACE WG Interim Meeting, 2020-01-31
Description
ACE WG Interim Meeting, 2020-01-31
A
B
C
A
B
B
B
B
C
We've
also
clarified
the
text
clarified.
The
use
of
all
set
info
topic
try
to
explain
a
little
bit
about
more
on
giving
permissions
using
wildcards
for
the
scopes,
and
that
was
basically
the
majority
of
the
changes
in
the
past
week.
We've
in
the
past
weeks.
We
continue
to
receive
comments
from
Jim
and
Daniel
and
in
the
last
case,
majority
of
the
comments
are
focusing
on
how
the
client
authenticates
to
and
authorizes
to
the
broker
and
on
Jim's
recommendation.
If
you
remember,
we've
introduced
to
the
spec
a
four
ways
to
do
that.
C
To
do
this,
based
on
choices
on
TLS
and
MQTT,
and
one
of
Daniels
comments
was
that
in
the
case
where
the
TLS
was
in
anonymous
and
MQTT,
there's
no
authentication.
We
allowed
that
case
for
topics
that
didn't
require
any
permissions
to
to
publish
or
subscribe
to
or
the
offset
info
topic
as
the
first
step
towards
in
a
style
authentication.
C
He
was
wondering
whether
that
should
be
included
in
the
options
and
whether
the
wording
should
be
changed.
The
other
thing
that
I
would
like
to
have
feedback
on
is
that
the
use
of
multiple
tokens,
the
way
that
we
described
this
in
the
draft,
is
that,
if
a
token
is
being
submitted
through
the
TLS
handshake,
as
well
as
for
the
TLS
handshake,
as
well
as
in
the
conflicts
message
for
MQTT.
C
We
basically
only
consider
the
latest
token
and
any
permission
that
has
been
granted
in
the
previous
case
of
token.
Validation
is
overwritten.
We
always
consider
the
latest
token
and
we
kind
of
stick
to
that
for
the
cases
when
a
token
can
be
submitted
by
the
client
during
a
persistent
connection
after
the
connect
the
client
can
relocate
and
by
sending
a
token
again
and
we
kind
of
again
overwrite
the
previous
token.
So
this
is
another
thing
that
I
would
like
to
get
workgroup
opinion
on
web.
How
to
handle
multiple
tokens.
C
The
second
issue
that
I
would
like
to
raise
is
that
we've
kind
of
settled
on
certain
lengths
in
terms
of
the
way
the
exporter,
a
sign
challenge
is
used
in
the
TLS
that
it's
32
bytes.
Another
way
of
doing
the
proof
of
possession
that
we
described
that
can
be
used
in
version
5
of
mqtt
was
to
allow
a
challenge
response
flow,
where
the
broker
and
initiated
by
sending
a
nonce
and
the
client
adds
its
unknowns,
and
then
they
do
preferred
possession
over
those
two
notices.
C
We
kind
of
settled
on
8
bytes,
but
as
Jim
raised,
we
do
not
actually
have
to
do
eight
bytes.
We
already
consider
TLS
as
the
underlying
transport
security,
so
we
can
afford
to
use
larger
nonces,
and
that
is
something
that
I
would
like
to
also
I
get
work
group
opinion.
Should
we
stick
to
the
work
groups
decision
on
8
bytes,
or
should
we
extend
it?
I
don't
thinks
that
open
issues,
other
discussion
points
is
will
be
based
on
particularly
Jim's
and
Daniel's
comments.
C
So
far,
we're
also
also
welcoming
others
to
join
in
giving
us
comments
and
feedback
majority
of
the
stuff.
That's
remaining
at
the
moment
is
on
formatting
clarifications
on
certain
data
that
needs
to
be
passed
via
MQTT
messages,
and
the
examples
of
these
include:
how
do
we
pass
AS
creation
hints?
We
should
settle
on
a
format
on
that.
We
should
be
clear
on
how
the
authentication
data
is
omitted
when
we
are
permitting
as
discovery,
we
should
be
very
clear
on
the
auth
data
format,
etc.
C
C
C
B
C
Discussed
that
earlier
and
and
I
think
in
my
case,
particularly
for
the
TLS
mqtt,
we
can't
make
that
assumption
that
the
client
and
the
should
be
able
to
work
with
larger
sizes,
so
that
I
do
not
see
a
problem
for
this
particular
suspect,
because
we
already
make
the
assumption
of
a
slightly
powerful
client
that
can
handle
TLS
the
other
issue.
The
other
thing
that
I
would
like
to
clarify
is
that
if
we
are
fine
with
the
tailless
exporter
sizes,
we
mentioned
Jim
that
could
be
also
defined
as
variable
the
old
data.
C
B
B
B
C
I,
do
not
think
so.
I
think
I
think
the
length
that
we
settled,
but
with
the
32
bytes
and
having
a
fixed
size,
I'm
fine,
with
going
with
that
decision.
Actually
I
just
wanted
to
make
sure
that
there
is
no
other
opinion.
That
kind
of
says
no,
you
shouldn't
be
specifying
and
we
should
let
variable.
But
if
the
workgroup
is
fine
with
the
the
length,
then
I'm
also
fine.
A
C
That
could
be
something
that
we
can
discuss
now:
you're
right,
Daniel.
You
were
asking
in
this
response
challenge
one
I
kind
of
led.
The
RS
and
the
client
generate
random
nonsense,
knot-tying,
not
binding
it
to
the
TLS
exporter
and
I
gave
the
option
of
TLS
exporter
for
the
MQTT.
You
know
the
the
the
other
method,
which
could
be
supported
by
mk2
to
version
3
one.
C
B
A
C
Yes,
that's
because
that
is
because
for
mqg
version
3
one
I
cannot:
it
cannot
support
a
challenge
response
flow,
so
the
the
broker
and
the
client
needs
to
settle
on
is
kind
of
a
nonce
to
do
the
pop.
So
the
best
thing
was
to
do
to
rely
on
the
TLS
to
do
that
before
I
was
proposing
things
like
using
the
random
client
ID
something
from
the
payload,
but
there
was
pushback
on
that
that
you
know
that
might
not
be
random
enough
and
the
client
ID
may
be
repeated
over
different
sessions.
A
Mm-Hmm,
well
my
opinion,
but
I
am
I
mean
I,
don't
have
a
it's
just
my
thoughts,
so
I
mean
I,
don't
want
it
to
influence
in
one
way
or
the
other
is
that
what
I
am
personally
thinking
is
that
it's
better
to
not
rely
on
the
capabilities
of
the
I.
Think
it's
a
client
to
generate
some
nuns,
and
if
we
can
use
that
on
the
tls
exporter,
it's
I
would
say
it's
better
in
a
in
addition
that
it
provides
a
China
binding.
C
B
B
C
C
We
can
do
a
minimum
that
maybe
like
it's,
maybe
an
option
for
two
to
channel
binding
on
that
necessary.
But
again,
as
Jim
said,
when
the
when
there
is
real
authentic
ation,
this
has
to
be
done
anyway,
and
this
is
only
anchor
to
the
version
5
capability,
they
are--
authentication
and
in
the
real,
authentic
ation.
This
has
to
be
done
with
different
noses.
A
A
B
B
A
C
A
B
C
B
C
B
D
A
C
Label
foreign
ace
sign
challenge,
so
if
these
kind
of
I
was
thinking
and
I
probably
am
wrong
now
that
Jim
said
it
should
be
application,
specific
and
I'm
thinking
about
it.
I
was
just
thinking
that
if
a
exporter
tailless
exporter
was
used
for
that
particular
purpose
for
that
particular
purpose.
For
that
specific
purpose
for
a
sign
challenge,
maybe
it's
reusable
across
the
different
drafts
functionality
but
yeah?
Maybe
it
should
be
application.
Specific
yeah.
A
A
Once
we
have
version,
4
I
think
this
version
4
should
be
almost
ready
for
a
working
group
last
call,
so
what
I
I
would
like
to
is
I
have
at
least
before
we
start
that
working
group
last
call
a
number
of
reviews
and
then
maybe
have
it.
Do
we
want
to
have
a
pre
pre
review
by
the
security
Directorate
I.
A
A
A
A
D
D
This
is
actually
an
updated
slide
from
Singapore
main
changes.
We
clarify
that
gie
D
highlighted
in
yellow
on
top
left,
it's
not
strictly
speaking,
and
identifier
of
the
group
or
topic,
but
most
properly
his
name
actually.
So
it
has
nothing
to
do
with
an
actual
cryptographically.
All
security
related
identifiers
like
the
ID
context
of
Oscar,
it's
a
pure
name,
and
then
we
started
to
change
especially
methods
and
their
handlers
for
the
sub
resources
to
this
fruit.
One,
for
instance,
the
is
group
JD
pop
key
reasons
related
to
the
retrieval
of
public
key.
D
We
changed
the
method
post
to
fetch.
For
the
sake
of
retrieving,
the
public
is
only
of
some
specified
group
members
in
the
last
one.
Is
that
age
group
GID?
No,
that
used
to
be
just
as
group
GID
only
and
the
specific
group
member
requesting
for
actions
to
the
KDC
was
supposed
to
be
identified
by
the
particular
secure
session
or
channel
they
had
following
any
important
discussion
from
Jim.
We
decided
instead
to
go
for
one
for
the
sub
resource
pair
group
member
we're
not.
D
There
is
essentially
yet
another
name,
plain
name
for
the
group
members,
so
again,
nothing
to
do
with
anything.
Cryptographically
related
like
sender,
ID,
and
this
means
that
practically
every
group
member
upon
join
has
to
receive
such
name
and
that
exact
URI
path
of
its
concern
is
returned
in
the
location
path
in
the
join
response,
but
other
than
this.
D
When
it
comes
about
this
resource,
we
also
revised
the
method
and
handlers,
it
admit
and
we
introduced
delete
and
for
an
explicit
living
on
of
the
group
we
redefined
get,
which
is
now
about
getting
the
same
common
group
key
material.
You
can
get
with
the
get
method
on
ace
group,
GID,
plus
also
the
current
individual
key
material
for
that
node.
That,
for
instance,
in
group
of
score,
is
the
sender
ID
and
what
used
to
be
get
became.
D
Put
in
order
for
that
group
member
to
ask
for
a
new
individual
key
material,
so,
for
instance,
for
a
new
sender
ID
in
the
group.
There
are
cases
for
doing
that.
But,
of
course,
in
this
document
we
are
more
general
than
that
and
try
to
be
abstract,
and
this
was
the
main
update.
Actually,
if
you
switch
to
the
next
slide,
it
present.
Thank
you
presents
the
same
things
in
a
slightly
different
fashion
and
it's
more
complete.
E
D
Yeah
question
I
had
is
more
convenient
to
ask
here
actually
for
the
third
bullet.
Now
it's
about
retrieval
public
use,
all
of
them
would
get
or
a
selected
one
would
fetch.
We
had
a
separate
discussion
with
Jim
for
another
draft.
We
have
been
a
defining
group
manager
for
creating
and
configuring
the
group
for
foreign
administrator,
and
we
started
to
discuss
of
cases
where,
for
instance,
the
signature
algorithm
changes.
D
What
to
do
in
that
case,
other
than
brutal
solutions
like
restarting
the
group
from
scratch
or
forcing
everyone
to
leave
and
rejoin
software
solution
can
be
that
the
current
group
members
reapplied
a
new
public
key
that
is
consistent
with
the
new
signature
algorithm,
for
instance,
just
in
case
we
decide
to
go
with
that.
Would
it
be
useful
to
have
a
put
method
here
for
doing
so
so
for
uploading,
a
new
public
key.
E
D
B
That
I
would
rather
see
that,
as
part
of
a
put
on
the
GID
node
bigger
to
do
a
pop
and
you're
probably
going
to
want
to
roll
over
the
group
there,
the
key
loop
number
see
if
you're,
probably
gonna,
want
to
issue
new
new
keys.
At
the
same
time,
you
change
the
signature.
Algorithm
mm-hmm
makes
more
sense
to
put
make
that
part
of
it
be
able
to
be
part
of
the
put
loop,
ID
node
group
IDs,
slash
node.
D
D
We
clarify
what
we
specify
as
you
arrive,
so
the
URI
of
the
actual
certificate,
not
at
the
repository
and
then
as
I
mentioned
before,
we
ended
up
using
fetch
for
retrieving
public
keys
of
a
set
of
nodes.
The
was
in
fact
in
Singapore
discussion
between
having
that
as
a
fetch
horrible,
but
we
concluded
with
which
we
also
extended
a
lot
and
revised
the
list
of
requirements
define
here
that
are
expected
to
be
fulfilled
by
profiles,
instantiating,
destruct
and
well
related.
D
D
Next
slide,
please:
ok,
we
have
a
number
of
open
points
that
we
should
be
able
to
discuss
today.
I
think
and
next,
steps
for
us
are
in
fact
taking
care
of
those
open
points
and
continuing,
because
we
have
just
started
to
address
comments
we
got
from
from
Peter
on
the
list
as
well
as
comments
from
Jean
that
we
got
today.
In
fact,
thank
you
so
next
slide
please,
and
we
have
four
open
points
we
could
think
about.
First,
one
is
just
to
check
that
what
we
are
doing
is,
in
fact,
fine.
D
We
are
defining
and
registering
a
new
content.
Type
age
group
come
possible
to
really
distinguish
between
till
when
the
token
is
posted
and
that's
pure
age,
so
based
on
s
plus
C,
were
messages
against
what
happens
right
after
where
we
are
defining
new
parameters
whose
names
often
are
just
as
the
names
of
other
parameters
we
have.
D
So,
of
course,
we
don't
want
to
have
collisions
between
the
two
domain
and
in
fact
we
are
registering
also
our
new
synonymous
parameters
in
your
new
register.
We
are
introducing
so
just
double
check
is,
in
fact
correct
to
register
these
parameters
apparently,
and
you
have
them
in
using
messages
with
a
newly
defined
content
format.
D
D
Okay,
for
the
second
point,
that
was
something
that,
at
the
very
beginning
of
this,
when
we
were
still
writing
individual
documents,
we
consider
firstly
to
have
a
single
access
token,
indicating
in
the
scope,
multiple
topics
or
groups
to
join
at
once.
It
looked
too
complicated
to
do
at
the
time,
with
many
more
important
things
under
definition,
so
we
dropped
that
and
we
stick
to
a
single
topic
or
group
token.
E
A
D
D
B
B
But
that's
not
a
big
deal,
that's
our
in
array
right!
It's
a
moment,
I
think
that's
a
lot
more
difficult,
I!
Think
that's
a
lot
simpler
than
saying
we
want
to
be
able
to
to
you
know.
Well
we're
gonna
try
to
make
five
joins
at
the
same
time
and
okay.
Now
we
have
to
deal
with
some
of
them
succeed.
Some
of
them
fail.
How
do
we
return
the
correct
error
information?
What
do
we
do
with
that?
B
F
D
Okay
point
three
and
four
are
related,
starting
with
three.
There
can
be
cases
where
the
KBC
wants
to
rekey
the
group,
using,
let's
say
advanced
racking
schemes
based
on
some
multicast
messages
to
Ricky.
Well,
the
whole
group
at
once
in
the
ideal
case
or
subset
of
group
members
at
once,
and
although
would
of
course
require
the
group
members
to
know
the
URI
part
they
they
have
to
expect
getting
goes
because
messages,
as
well
as
the
multicast
address
in
the
first
place.
D
So
they
need
to
get
in
case
that
information
from
the
KBC
upon
joining
and
that
will
be
yet
another
parameter.
So
we
were
thinking
in
case
this
kind
of
advance.
Working
mechanisms
are
supporting
a
group
that
the
CDC
in
the
joining
response
can
include
this
information
so
that
the
group
members,
of
course
supporting
this
in
the
first
place,
are
ready
to
get
this
reeking
messages
if
they
are
sent
in
parallel
were
point
four
is
the
other
way
around,
and
this
is
probably
more
important
to
support
in
general.
B
D
B
B
D
B
I
mean
partly
me
part
of
my
worry,
is
how
much
how
much
of
that
information
gets
sucked
into
the
raheem
protocol
itself.
Should
it
be
part
of
the
raheem
protocol
inserted
part
of
the
general
solution,
so
little
bit
more
discussion
about
how
things
operate.
I
don't
necessarily
have
a
problem
with
folding
at
the
end
of
this
document,
so
you
don't
have
to
have
a
full
thing.
Just
you
know,
this
is
the
section
we
be
inserted
into
the
document.
Mm-Hmm
just
I
can
think
about
it
with
a
bit
more
information
around
it.
D
F
D
B
D
B
D
C
A
D
A
So
that's
a
it's
good!
So
again
one
you
you,
we
think
it's
quite
in
a
stable,
stable
state.
We
will
have
to
check
whether
we
want
to
we
have
a
issue.
We
want
to
have
the
security
directory
to
provide
feedbacks
on
or,
and
maybe
insist
on
more
reviews
on
that.
So
that's
the
way
we'd
like
to
move
that.
D
So
next
slide,
please,
okay,
of
course,
the
the
detail
description
here
as
a
profile
was
also
revised.
Changing
the
changes
just
made
in
is
clear
calm,
as
agreed
in
Singapore.
We
also
indicated
eight
bytes
in
size
for
the
tune.
Insists
announcer
Arsenal
is
also
used
here
for
proof
of
possession
of
the
clients
with
key
and
I
also
have
an
open
points
related
to
the
size,
but
that
comes
later
following
also
comments:
I
guess
from
Jim.
D
We
also
lab
rated
more
on
RS
nuns
because
of
course
the
normal
case
is
the
first
approach
with
a
group
manager,
and
this
is
returned
after
the
token
posting,
but
sometimes
that's
just
not
what
happens.
For
instance,
if
you
go
for
the
Detailers
profile
and
you
run
it
so
that
the
token
is
embedded
in
the
uncheck
message
is
itself
that
case
there's,
of
course,
no
our
stance
exclusively
returned
and
it
has
to
be
derived.
D
So
we
had
a
separate
section
describing
where
the
part
of
the
challenge
to
be
mapped
to
are,
as
nouns
comes
from.
Well,
there's
the
the
easy
case
in
case
it's
returned
explicitly
or
indicated
just
discussed
before
Els
exporter,
so
aligned
with
qdt
profile.
We
also
found
another
case
where
the
node
is
actually
rejoining
and
based
on
a
still
valid
token.
That
is
not
reposted,
of
course,
and
then
well
if
they
are
running
a
bit
TLS
session,
TLS
exporter
again,
if
they
are
using
all
score.
D
Instead,
we
are
considering
a
construction
that
we
are
also
using
in
another
document,
the
group
of
score
profile
race
in
a
different
meaning
than
this
one.
I
know
it
can
be
confusing,
but
that's
an
actual
transport
profile
of
ace.
Of
course,
we
need
feedback
on
this
Jim
started
to
give
us
something
in
mail
today
and
I
think
we
need
to
discuss
more
on
this
in
different
senses
to
be
more
aligned
with
the
MQTT
profile
when
it's
about
LS
exporter
and
about
this
construction
when,
instead
of
score,
is
used.
D
D
The
abstract
now
I
hope
reflects
better
the
fact
that
this
is
a
profile
of
a
skier
calm
and,
as
I
mentioned
before,
a
lot
of
content,
especially
from
the
first
two
sections,
was
taken
away
and
moved
to
a
skier
calm
because
it
just
add
general
applicability
and
fits
better
there,
and
we
also
dressed
review.
We
got
from
PETA
right
after
Singapore.
That
was
mostly
about
other
editorial
points
and
clarifications.
Nothing,
functional,
okay
and
the
next
slide
just
has
a
natural
forward
pointer
to
the
open
points.
D
I
have
on
this
and
of
course,
the
main
next
step
is
keeping
changes
in
Kong.
We
also
discussed
before
and
review.
We
got
today
from
Jim
and
I.
Have
three
open
points
and
I
probably
have
the
answer
already
from
the
discussion
at
the
first
presentation
so
till
today
we
have
this
LS
exporter
label
that
it
serves
the
same
purpose.
Actually
in
the
activity
profile,
and
here
so
generating
challenges
for
for
signatures,
so
to
start
with,
we
talked
to
defining
it
well
there
since
then
was
very
much
forward
in
that
sense
and
reusing
it.
D
In
fact,
right
now
we
are
reusing
the
label
from
there,
but
as
Jim
was
mentioning
before
and
I
also
agree
is
probably
better
shouldn't,
be
a
problem
for
the
allocation
per
se
to
to
define
a
new
label
for
the
very
same
purpose
here
in
this
document
at
least
it's
very
specific
to
this
profile
and
application
will
be
used
exactly
the
same
way.
Essentially
is.
B
C
A
B
D
D
I
was
wondering
a
whatever
we
do
can
be
aligned
with
what
the
nkvd
profile
says.
In
this
sense,
we
can
converge
on
the
same
time
of
and
kind
of
reasoning
and
other
than
that
either
look
also
to
the
Oscar
RFC,
where
appendix
beat
you
that
involves
exchanging
on
analysis
for
different
reason
than
that,
then
building
a
challenge
or
for
deriving
a
context
of
course
makes
this
kind
of
consideration
and
bottom
line
to
find
an
acceptable
trade-off
between
probability
of
collision
and
number
of
messages
required
to
have
repetitions.
D
D
B
I
have
a
whole
lot
less
problems
with
collisions
here,
because
this
is
basically
as
I
mean
as
far
as
I'm
concerned.
You
could
use
counters
here,
because
the
thing
to
do
is
to
make
sure
it
doesn't
look
like
something
you've
done
recently,
and
it
is
time-bound,
unlike
the
oscar
thing,
where
you're
deriving
a
key,
where
you
want
to
make
sure
you
don't
get
a
key
collision.
Yeah.
B
Yeah
they
could
potentially
be
smaller.
This
is
one
of
those
arguments
that
I've
had
with
accurate
times.
It's
like
well,
if
I'm
doing
DTLS
how
small
can
I
make
the
nonce
in
in
DTLS,
because
is
I
mean
it's
if
I'm
deriving
a
new
key
and
I'm
driving
a
nonce?
Well,
the
nonce
is
basically
just
a
am
I
on
the
right
session.
Mm-Hmm.
E
B
We've
had
all
sorts
of
discussions
about
you
know.
A
counter
is
bad
news
only
because
both
of
us
agree
that
making
the
nonce,
predictable
and
DTLS
is
probably
a
bad
idea,
because
you
might
be
able
to
get
some
information
from
predictability,
but
doing
something
like
encrypting
the
counter
and
using
that
for
your
nonce
is
probably
perfectly
fine.
We
were
having
these
discussions
as
part
of
the
lead
up,
so
it's
like
if
it's
time-bound
the
answers
are
slightly
different
than
it
is
not
time
bound
in
terms
of
lengths.
B
D
A
B
A
D
D
Thanks
and
last
point,
which
is
a
bit
tricky
while
going
through
the
revision
of
this
document
and
in
detail
on
the
restful
interface,
I
noticed
this.
We
can
send
a
get
through
group
of
score
GID,
node
name
and
that's
supposed
to
give
me
back
the
common
group
key
material
and
my
individual
key
material.
So
practically
my
sender
ID
in
this
case,
then
the
weight
is
defined
already
in
a
Spiricom.
D
It
is
abstract
enough
that
does
not
define
the
content
of
key.
We
do
here
so
a
possible
way
to
let's
say,
fix
this
and
keep
isn't
consistent
any
way.
You
would
be
that
in
the
response
from
group
post
core
group
name,
so
what
I
should
get
from?
Only
the
shared
group,
key
material
I
may
not
include
anymore.
The
client
ID
parameter
of
key
contain
with
my
sender,
ID,
and
so
the
the
purpose
and
the
semantics
of
the
operation
be
as
we
actually
want
it
to
be,
and
we
are
consistent
again.
D
D
B
D
A
D
D
Only
from
a
performance
point
of
view,
if
you
really
bother
about
the
size
of
a
send
ready
to
be
sent
and
more
in
general,
the
way
we
are
defining
that
metal
to
that
resource
is
getting
back.
The
group
key
material
share
with
everyone
in
principle,
and
instead
here
we
are
including
something
more
something
in
the
video,
so
I
think
we
are
diverging
from
the
intention
of
the
method.
D
You
are
supposed
to
get
only
what's
common,
and
that
is
contained
inside
key
problem.
Is
that
if
we
don't
say
anything
now,
key
is
including
also
the
sender
ID
of
that
node,
which
is
not
group
shared
information,
it's
individual
okay,
so
it's
more
than
you
we're
expecting
to
get
em
plus.
If
you
run
the
to
get
I
wrote
there,
you
get
back
exactly
the
same
thing.
F
A
B
D
A
big
point
in
genius
mail
this
morning.
That
was
also
related
to
the
case
where
the
join
in
northern
group
manager
talks
using
a
score,
and
you
may
want
to
derive
new
challenges
for
rejoining.
Under
the
same
token,
that
is
have
some
more
discussion
also
that
the
text
to
think
about
is
all
in
the
draft
or
Radian
in
the
mail
exchange
today
in
general,
points
for
the
Jim's
raised
in
in
his
review
are
open
points.
A
B
A
B
E
A
F
B
A
So
if
we
are
setting
an
interim
meeting,
we
need
to
have
two
weeks
notice
in
advanced,
so
the
only
question
I
would
like
to
know
is
that
I
guess
if
we
have
that
inter
meeting
in
three
weeks,
so
it's
not
going
to
be
related
on
the
update
of
the
draft
we
discussed
today.
That's
something
we
can
do
in
provision
also
and
cancel
if
if
all
problems
are
resolved,
so
it's
also
one
possibility.
If
you
think
that's
useful,
let
me
know
I.