►
From YouTube: IETF-ACE-20230220-1400
Description
ACE meeting session at IETF
2023/02/20 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
B
Yes,
you.
C
A
Okay,
I
have
the
impression
that
I
mean
the
application
plays
me
in
mute
after
a
few
seconds.
So
as
soon
as
you
don't
hear
me,
just
ping
me,
okay,
the
only
slide
set
I
see
is
those
one
from
the
pub
sub
and
sign
them
told
me
that.
A
A
B
D
B
A
So
I
just
approve
your
slides,
Marco,
okay,
so
no
I
probably
have
to
to
do
something
with
the
material.
Maybe
update.
A
Logan
was
expected
to
to
start
the
meeting,
but
he's
he
has
a
hurricane,
so
I
told
him
yeah.
It's
fine,
I'm,
Gonna,
Take
It.
A
A
A
Yeah
I
mean
no,
no,
no
I
mean
I
can
see
them
on
the
even
on
a
on
the
miteko.
So.
B
B
B
E
B
Okay,
yeah
I'll
be
quick.
It's
just
the
status
update
on
the
ongoing
work
on
both
drafts.
In
parallel
revoke
token
notification
and
Oscar
GM
admin.
B
Notification
yeah.
We
went
through
the
the
list
of
things
to
do
two
interview
meetings
ago,
I've
been
working
on
the
electroscopy
on
the
working
group.
Github
I
managed
to
do
almost
everything,
especially
we
thought
about
adding
examples
when
the
cursor
extension
is
also
used.
B
I
did
that
and
I
took
the
opportunity
to
collect
all
examples
we
had
already
together
with
the
new
ones
and
have
all
of
them
in
an
appendix,
because
it
started
to
be
quite
a
lot
of
material
anyway,
I
also
added
the
are
there
any
other
new
appendix
I
mentioned
that
I
had
in
mind
about
collecting
and
explaining
together
the
the
different
parameters
and
constants
that
we
are
introducing,
so
they
don't
just
appear
in
line
in
the
text
and
when
I
was
doing
that,
I
noticed
that
one
of
those
especially
had
an
inconsistent
name
compared
to
the
other
ones,
so
I
just
prefer
to
to
get
things
aligned,
while
working
on
the
document
as
a
whole.
B
I
also
noticed
I
think
about
the
of
course,
optional
possibility
to
use
a
particular
query,
parameter
defined
in
a
core
document.
Pmax,
it
appeared
in
only
two
sentences
and
I
I,
believe
exaggerating
with
normative
language.
That,
of
course
resulted
in
a
normative
reference,
and
this
parameter
is
not
at
all.
B
A
vital
building
block
for
this
approach
is
just
a
possible
way
to
influence
the
authorization
server
in
sending
observed
notifications
like
the
file
in
a
core
document,
so
I
prefer
to
rephrase
the
text
to
relax
it
and
to
be
not
normative
anymore,
which
also
makes
it
sufficient
to
have
the
core
document
as
an
informational
as
or
an
informative
reference
and
as
a
side
effect.
Now,
the
ace
document
does
not
have
any
normative
reference
anymore
that
are
not,
which
should
be
good.
B
Overall
yeah
I've
also
gone
through
a
number
of
clarification
and
minor
fixes
in
the
document,
but
not
in
critical.
What
I
have
left
mostly
and
I'm
still
working
on?
That
is
a
number
of
security
considerations,
for
which
I
had
no
note
row
notes
and
that
I
have
to
compile
in
in
proper
text
for
the
security
consideration
section,
yeah
I
don't
have
any
particular
big
issues
remaining
in
mind.
So.
B
The
plan
is
the
same
as
mentioned
last
time,
having
a
revised
version
covering
all
of
this
before
the
cutoff
and
if
no
other
issues
or
open
points
arise.
That
version
should
be
ready
to
consider
for
a
working
group.
Last
call-
and
this
is
revoke
token
notification-
any
question
or
comment
on
this
one.
B
I
hear
none
so
I
move
to
the
next
one
yeah
I'm
working
in
parallel
on
this
one.
That
requires
a
bit
more
work,
but
still
you
can
see
the
progress
also
on
the
GitHub
repo,
when,
unfortunately,
the
editor
scope
is
not
deployed
correctly.
We
still
have
that
problem.
B
I've
completed
a
number
of
things,
especially
adding
a
new
section,
discussing
a
number
of
considerations
about
possible
multiple
concurrent
administrators
responsible,
even
if
to
different
extent,
for
the
same
Oscar
group
under
the
group
manager
and
I
managed
to
fix
a
number
of
things.
I
I
noticed
for
the
case
when,
when
callal
is
used
and
then
I
have
a
list
of
ongoing
steps
that
I'll
try
to
take
care
as
much
as
I
can
also
before
the
cutoff.
B
Some
of
those
are
also
security
considerations,
because,
right
now
we
have
only
one
very
little.
Paragraph
I
think
that
there's
a
few
things
to
say
both
on
the
actual
operations
that
can
be
performed
at
the
group
manager,
as
well
as
on
on
the
Practical
actors
involved,
and
especially
the
group
manager
and
the
administrators
foreign.
B
This
is
also
ongoing,
as
mentioned
in
the
last
interview
when
I
presented.
This
I
really
want
at
least
to
start
translating
the
correct
sample
and
simple
diagnostic
notation,
using
also
but
c
bar
and
I
started
doing
that
already,
while
working
on
the
document,
I
also
noted
that
it'd
be
good
to
Define
one
more
error
condition
on
the
group
manager.
B
In
case
it
is
requested
to
create
a
new
group
configuration
or
update
an
existing
one
in
a
way
that
it
would
result
into
something
that
the
group
manager
itself
doesn't
support,
so
that
that
requires
I,
believe
a
new
related
error
code,
I'm
not
talking
about
a
co-op
responser
or
code
I'm
talking
about
an
oscore
GM
admin
error
code
to
be
transported
in
the
payload,
of
course,
but
we
have
a
number
of
other
error
codes
already.
B
So
it
is
just
about
following
the
same
pattern
about
the
error
or
the
code
point
and
recommendations
for
how
an
administrator
should
follow
up.
If
this
error
code
is
received,
and
then
a
number
of
qualifications
that
I
also
noted
would
be
better
to
to
include
about
possible
reasons
to
deviate
from
recommended
default
parameter
values.
If
one
is
not
specified
by
the
administrator
and
on
some
operations
affecting
multiple
resources
at
once,
in
principle,
that
would
require
to
be
performed.
B
So
I
expect
to
cover
all
that
before
the
cutoff.
If
I
don't
complete
something,
it
will
probably
be
about
the
choral
examples,
then
we
also
talked
about
a
future
document
split
yeah
I.
Don't
think
it
will
happen
this
time
around
for
this
cutoff,
but
I
understand
that
it
will
happen
possibly
after
itf116,
also
based
on
on
the
discussion
and
the
well,
the
checking
of
the
mailing
list,
thanks
Daniel,
so
I
understand
this
will
happen.
B
It's
about
having
the
current
document
as
dock
one
to
proceed
after
having
removed
the
coral
related
content
and
having
that
a
doctor,
as
a
new
working
group
document
focused
on
on
the
use
of
this
approach
on
Coral
instead
by
the
way
since
that
was
started.
Also
the
previous
interim.
The
plan
for
doctor
is
not
at
all
about
obsoleting
or
making
a
beast
anyway
of
dock.
One
I,
don't
think
even
about
updating
it.
It's
just
a
document
rescribing
how
to
use
this
method
with
coral.
B
There
was
an
early
thought,
at
least
about
a
document
name
anyway
and
I.
Think
I
mentioned
this
name,
and
it's
like
here
at
the
previous
meeting,
and
can
we
go
for
something
as
simple
as
this?
What.
A
Do
you
think,
oh
yeah,
yeah
sure
I
mean
that's
I
mean
I.
Just
wanted
to
I
mean
the
only
reason
for
that
discussion
and
it's
not
it's
just
to
to
make
it
clear
to
everyone.
So
so
no
one
get
upset
when
you,
when
you
arrive
with
your
new
document
and.
F
B
A
Listen
to
that
actually
yeah
yeah,
but
I
I
also
think
that
it's
it's
it.
It
will
avoid
any
confusion.
If
now
everyone
I
understand,
we
will
have
that
document.
So
when
you
do
the
split
with
whatever
is
in
the
coverall
dock,
you
just
submit
it.
So
we
we
can
have
this
adopted,
and
but
if
you
wait
a
one
year
or
six
months,
people
won't
remind
so.
A
B
B
Doc,
two
and
yeah:
if
it
works
for
you,
it
can
be
a
working
group
document
right
away
or
I.
Don't
know
if
you
want
to
go
through
a
formal
for
adoption.
A
B
I
plan
to
do
that
after
ATF
116.
as
I
note
in
this
Slide,
the
split
is
not
super
straightforward
editorially,
because
now
the
coral
content,
of
course,
is
intentionally
Blended
in
a
nice
way.
So
I'll
have
to
spend
some
time
in
taking
out
all
the
parts
and
make
a
new
self-standing
document.
But
I'll
do
that.
After
a.
B
And
this
is
all
I
have,
so
we
are
on
the
plan.
A
C
Only
I
had
if
they
can
just
at
some
point
during
the
meeting
I
wanted
to
give
a
quick
update
about
the
key
Google
yeah.
A
Sure
you
can
I
mean
sure
yeah
I
mean
so.
Do
we
have
any
questions
regarding
Marco's
presentation,
I,
don't
see
any
any
comment
known
I,
don't
see
anything
that
is
blocking.
So,
it's
mostly
to
say
we
are
aligned
with
what
we
mentioned
and
I
don't
see
any
blocking
Point,
nor
even
questions
Marco
is
expecting
from
from
us.
So
so
I
think
we're
pretty
on
track,
which
is
good
yeah,
so
I
see
sigm
and
Ricker.
So
Ricker
you
want
to
make
a
shorter
update
about
the
shepherd.
A
C
Yes,
the
quick
update,
so
the
actual
Shepherd
write-up
I
have
that
finished
now.
So
it's
about
some
final
formatting
to
not
turn
two
long
lines
and
I'll
submit
it
should
be
during
the
day
and
for
the
actual
Shepherd's
review.
That
I
also
almost
done
with
again
some
formatting
and
making
it
a
bit
cleaner
to
point
to
the
right
sections
and
such
but
I
should
be
able
to
submit
that
by
tomorrow
or
latest
Wednesday.
A
A
B
A
A
So,
thank
you.
Ricard
I
I
was
saying
that
as
soon
as
it
get
published,
if
you
don't
see
a
request
for
publication
in
the
24th
hour,
just
ping
me
back
again
and
then
it's
going
to
be
in
Paul's
hand
and
and
and
and
I
hope
those
two
or
three
documents
are
going
to
be
in
the
rftq
very
soon.
A
Yeah
sometime
I
am
for.
A
Day
I
mean
my
audio
is
being
mute,
but
I
didn't
hear
the
question
but
I.
C
G
Yes,
okay,
let
me
give
you
a
quick
update.
I've
been
working
on
the
document,
but
I
haven't
bumped
up
the
version
number
but
hoping
to
put
a
new
version
by
the
cutoff
date.
I
asked
Marco
to
join
the
authors
and
he
kindly
accepted
because
I've
been
picking
his
brain
a
lot
about
key
group
com
as
well
as
making
use
of
a
number
of
solutions
from
Key
crypto.com
Oscar.
G
So
it
made
sense
some
of
the
updates
that
the
document
includes
some
of
the
discussions
that
we
had
with
Marco
in
a
design
meeting,
which
looked
into
clarifying
terminology,
making
sure
that
it
is
clear
to
all
the
readers
that
this
document
is
about
a
security
group
and
not
an
application
group,
and
the
distinction
between
the
two
is
clear
that
the
application
group
corresponds
to
that
pops
up
group
around
a
single
topic
and
a
topic
can
have
subtopics.
G
So
I
also
made
an
effort
to
go
back
to
Pub
sub
document
and
see
that
our
definitions
of
the
terms
are
very
well
aligned
to
Coyote
Pub
sub
as
well.
We
discussed
a
few
things
about
how
the
mapping
is
from
the
security
group
to
application
group
at
the
moment.
The
way
it's
written,
it's
kind
of,
considers
the
one-to-one
relationship
between
a
security
group
versus
an
application
group.
G
So
a
topic
name
is
representative
of
the
application
group,
as
well
as
the
security
group,
which
makes
things
a
lot
simpler
when
you
are
asking
for
different
permissions
in
within
a
scope,
and
then
we
also
considered
the
possibility
of
one
application
group
being
used
by
multiple
security
groups.
G
G
We
and
Michael's
earliest
suggestion
registered
a
core
PS
GM
to
represent
a
resource
for
group
membership,
and
then
I
would
have
to
follow
the
choir
pops
up
a
little
bit
about
how
the
resource
Discovery
regarding
the
group
membership
resources
will
happen
and
then
again,
following
Marco's
suggestion,
I
did
support
for
extended
format
of
scope,
registered
the
content,
format
and
clarified
the
KDC
and
how
it
acquires
credentials
for
publisher
clients.
G
G
Sorry
for
breaking
garan
majority
of
the
things
that
I
say
is
on
the
slide.
Hopefully
it
will
be
covering
a
good
summary,
so
this
is
planned
for
cut
off
and
one
of
the
things
that
needs
to
be
clarified.
G
Better
is
the
client
workflow
especially
about
when
the
client
approaches
the
resource
server
and
if
it's
not
aware
of
an
authorization
server,
the
optional
as
Discovery
and
then
getting
the
token
and
maybe
doing
additional
resource
Discovery,
including
a
KDC
Discovery,
then
approaching
KDC
and
getting
the
right
keys
for
doing
confidential
communication
so
that
workflow
needs
to
be
better
described.
G
The
scope
format
needs
to
be
cleaned
up
and
needs
to
be
expanded
so
that
we
can
flag
when
the
to
the
as
when
the
request
is
for
a
KDC
or
a
broker
scope
and
then
other
Pub
sub
operations.
At
the
moment,
we've
only
support
publish
subscribe
operations
in
the
scope
format.
G
Maybe
other
operations
need
to
be
considered
added
in
so
that
will
be
much
more
clear
once
I
kind
of
review
the
pop
sub
document
and
make
sure
I
understand
what
kind
of
permissions
may
be
needed
in
addition
into
the
scope
format,
and
then
maybe
we
want
to
do
this
for
a
future
proof,
a
reserved
kind
of
place
for
admin
related
actions
operations.
G
The
most
important
part
is
the
handling
the
join
response
and
how
the
closer
key
returned
and
how
the
non's
construction
can
be
done.
We
consider
two
options.
One
option
was
base
IV
and
sender,
ID
provided
by
KDC
partial
IV
as
saying
for
all
senders
and
it's
set
by
KDC
again
and
then
option
two
was
again
base:
ID
provided
by
KDC
and
the
partial
IV
space
divided
among
senders.
G
This
option
was
the
option:
actually
the
late
dim
discussed
with
Francesca,
and
that
was
in
the
GitHub
issues
the
option
mentioned,
but
we
feel
the
option
one
might
be
a
cleaner
solution
to
create.
You
know
those
unique
nonsense
for
each
submission,
and
this
might
be
something
that
we
discuss
in
the
working
group.
Other
things
to
do
group
reaching
this
is
not
planned
for
this
version,
because
there's
a
lot
to
do
to
clean
up
to
clean
up
in
this
document,
but
for
the
next
versions,
group
Key,
Management,
Group
key
re-keying.
G
At
the
moment,
it's
written
as
it
is
a
default
point
to
point
routine,
but
maybe
we
need
to
think
about
a
solution
that
incorporates
the
pubs
up
nature
of
the
communication
and
other
things
that
needs
to
come
up
in
terms
of
Co-op
core
pops
up
which
might
be
flagged
as
necessary.
To
add
into
this
document.
I
gave
an
example
of
Brokenness
Pub
sub
mentioned
in
the
co-op
subdocument,
for
instance,
and
how
do
we
support
that?
G
And
the
the
important
thing
for
the
cutoff
is
the
finalizing
the
group
requirements
list
and
not
the
only
optional,
possibly
but
the
actual
main
requirements,
group
requirements
finalized
and
the
documents
plan
for
116
116
is
that
we
have
a
clean
document.
That
is
the
most
basic
pops
up.
Groupcom
communication
described
in
this
document.
Basically,
and
that's
the
overview
I
have
for
this
document.
It
does
have
a
few
versions
in
its
in
its
future
and
it's
not
ready.
Yet.
A
Okay,
Marco:
do
you
want
to
do
you
have
a
question
because
I
I
see
you
in
the
in
the
list.
B
Yeah
I
have
a
few
comments,
starting
from
the
previous
slide,
then,
of
course
that
can
continue
in
one
more
design
team
meeting,
but
I
have
a
few
quick
comments
right
here
on
the
second
bullet
point,
a
core
psgm
I
think
it's
even
simpler
than
than
what
than
what
is
in
this
slide.
B
If
we
follow
the
same
speed
of
kiru
kamoskor,
it's
really
the
resource
type
of
a
resource
at
the
KDC
and
so
for
the
group
membership
in
terms
of
membership
to
a
security
group,
and
it's
not
involved
in
in
other
kinds
of
Discovery,
like
of
topic
Discovery
and
that's
covered
in
the
core
document
through
different
resource
styles,
for
resources
at
the
broker.
G
B
B
Right
on
on
the
topic
of
the
scope
format
with
AF
yeah,
an
inner
bullet
point
said
other
core
Pub
sub
operations,
Discovery
create,
read
and
remove
so
on
the
Discovery
part,
that's
also
defined
in
the
in
the
core
document,
of
course,
and
that
shouldn't
really
require
any
particular
access
control
of
permission.
B
It's
just
about
using
a
web
linking
directly
from
from
the
broker
or
through
resource
directory
and
find
out
the
the
data
resources
where
to
publish
And
subscribe
and
for
a
topic
on
create,
read,
remove
so
I
suppose
this
refers
to
yeah,
creating
the
topic
and
its
configuration
and
possibly
updating
it.
That's
the
administrative
part
of
permission
and
the
core
document
is
covering
both
parts,
so
the
administrative
part
and
the
using
part,
this
Ace
profile,
is
covering
only
the
the
user
part.
G
G
I'm
happy
to
clarify
that
way.
The
only
thing
that
is
a
little
bit
bothering
me
the
difference
between
create
and
publish
when
a
topic
doesn't
exist,
because
if
I
read
correctly
the
co-op
pops
up,
it
might
be
the
case
that
the
publisher
might
come
to
a
non-existent
topic
and
then
the
broker
may
decide
to
create
the
topic
and
accept
the
publication.
G
B
G
This
particular
broker,
basically.
B
As
far
as
I
understand
the
direction
in
core
the
topic,
configuration
has
to
be
created
first,
before
a
publication
can
happen.
G
Seemed
to
accept,
publish
with
no
topic
as
well,
so
I'll
clarify
that,
but
okay
I'm
happy
actually
this
is
this
is
great
simplification.
We
can
remove
the
app
operations
that
are
admin
related
completely
from
the
description
and
maybe
clarify
that
this
only
covers
just
publish
subscribe.
Assuming
it's
only
considering
users,
we
did
plan
another
the
scope
for
admins
as
well.
B
Yeah,
the
future
proof
reservation
is
good,
but
I
think
it's
better
off
if
this
document
focuses
on
authorization
for
for
the
users
and
then
possibly
a
future
document
like
Pub
sub
admin
focuses
on
the
permissions
for
administrators
of
topics
like
for
for
a
group
of
school
case,
we
had
one
document
for
the
users
to
get
the.
G
B
Yeah
and
without
spending
too
many
words,
the
discovery
of
topics
at
the
broker
for
users
and
of
configuration
for
possible
admins
again
at
the
broker,
is
really
entirely
taken
care
of
in
the
core
document.
So
I
don't
think
we
should
Define
really
anything
new.
In
that
sense
here
we
can
really
be
streamlined
on
the
authorization
for
users.
Okay,.
B
But
then
you
also
mentioned
somewhere
in
this
line.
The
discovery
of
the
KDC.
G
Oh,
this
is
the
thing
that
we
discussed
yeah
if
you
haven't
met.
If
you
don't
remember,
we
discussed
this
in
the
design
meeting.
G
B
Go
ahead
no
and
I
I
think
we
should.
We
should
take
a
slightly
different
way
than
what
I
suggested
myself
a
design
team
meeting
that
was
about
including
this
information
as
metadata
and
a
topic
configuration,
but
anything
about
configuration
should
be
precluded
from
from
users.
It's
only
for
admins,
so
a
better
way
for
a
publisher
of
subscriber
to
find
out
the
KDC
Associated
to
a
topic
can
be
well.
B
It
can
happen
when
discovering
the
topic,
the
resource
that
the
broker
were
to
publish
basically
and
using
web
linking
again
and
again
from
the
broker
or
the
resource
directory.
A
link
to
the
topic
resource
can
go
side
by
side
with
a
link
to
the
KDC
and
those
two
can
be
related
by
the
Rel
Target
attribute,
and
we
are
doing
something
similar
also
in
a
document
about
the
group
of
scorecays.
B
So
if
you
provide
well
enough
detailed
link
format,
responses,
for
example,
when
discovering
topics
you
may
at
the
same
time,
also
give
an
indication
of
the
KDC
to
go
to
so
this
should
be
defined
in
in
this
document.
I
think,
but
building
on
the
topic,
Discovery
defining
the
core
document
anyway,.
G
Yes,
okay
and
the
the
KDC
Discovery,
the
the
workflow
needs
to
be
described.
That's
why
I've
mentioned
that
the
discovery
I
mentioned
in
the
pub
sub
operations.
It
was
encompassing
Beyond,
KDC
Discovery.
This
is
something
again.
We
discussed
in
the
design
meeting
whether
when
a
person
gets
a
to.
You
know
when,
when
a
client
gets
a
token
or
the
person
get
a
client
gets
a
token
and
approaches
the
broker.
Can
we
assume,
like
by
default,
do
other
operations?
That
was
that's.
Why
this
slide
has
that
information,
but
yeah?
B
B
And
and
then
one
last
thing
on
the
brokerless
pub
sub
thing
that
you
also
mentioned.
If
you
look
at
the
editor's
copy
of
the
core
document,
it
seems
that
that
part
is
gone
all
together:
okay,
I'll
post
the
link
in
the
chat
for
convenience.
So
this
is
the
branch
where
Jaime
is
working
and
well.
You
can
also
check
the
actual
editor's
copy,
but
yeah
that
legal
section
that
was
opening
for
a
brokerless
alternative
is
gone.
So,
oh.
G
That's
excellent
yeah
that
was
a
question
mark
yeah
yeah.
That
was
a
question
mark
because
I
was
looking
at
the
latest
version
of
the
published
version
of
the
collab
core
Pub
sub
and
I
had
a
question
mark
there,
whether
you
know
it's
going
to
stay
or
go
basically,
yeah;
okay,
that's
fine!
If
it's
not
in
the
edit,
the
in
the
editors
copy
of
the
latest
version
and
that's
what's
going
to
be
submitted
next
ITF
and
then
there
is
one
less
thing
to
worry
about.
B
A
A
I
have
one
question
regarding
the
two
options
for
the
key:
how
you
so
is
it
I
mean
the
the
the
the
problem
I
see
with
option.
Two
is
that
if
the
the
IV
is
I
mean
because
the
IV
is
provided
by
the
KDC
I
mean
the
IV
knows
how
many
centers
there
are.
So
it's
fine
to
do
it
once,
but
over
time
those
number
might
change,
and
it.
D
G
We've
we
we
agree,
I
think
Marco
also
agrees
so
because
he
was
suggesting
option
one
else
with
more
offices.
I
brought
both
options
because
I
thought
it's
worth
discussing
as
this
was
the
first
solution,
I
found
in
the
GitHub
issues
as
the
initial
plan,
and
then
there
was
a
communication
disconnect
and
I.
Don't
know
how
that
plan
changed
or
was
improved
on,
but
we
were
questioning
that
and
in
Marco's
review
that
came
up
as
well
and
we
were
thinking
option.
G
B
B
Space
and
trade-offs,
I
think
option.
One
is
better
trade-offs
than
option
two
in
different
ways:
they
both
work
of
course
option.
One
then
requires
to
build
the
actual
Cipher
nouns
in
the
non-trivial
way,
and
I
expect
would
consider
a
construction
similar
to
to
the
one
of
our
score.
A
As
long
as
they
are
discussed,
it's
fine
but
I
just
wanted
to
make
sure
yeah.
F
A
Okay,
so
just
before
we
move
on
I
I
just
want
to
to
present
you,
the
not
well
I
think
you
I
mean.
Did
you
see
the
nut?
Well,.
C
G
And
joining
me
in
this,
but
the
next
version
is
going
to
be
more
focused
on
cleaning
up
and
fulfilling
the
requirements
of
key
groupcom.
Basically,.
A
Okay
yeah,
so
that's
good,
I
I
think
it's
a
it's
a
good
step,
and
since
this
draft
is
becoming
more
active,
it's
it.
It's
really.
Fine
I
agree
that
we
need
to
to
Target
an
inter
intermediary
version
for
for
the
cutoff
and
then
and
then
update
that
document
regularly,
so
that
it
can
be
sent
to
the
publication.
I
mean
we
can
have
a
publication
request
in
the
in
the
next
few
months.
A
I
don't
see
anything
that
that
is
blocking
us
from
advancing
I
mean
there
is
no
issue
being
raised
or
concerned
specific
concerns
that
we
think
needs
more
discussion.
So
this
is
a.
This
is
a
good
point.
A
Yes,
it's
a
little
bit
late,
but
still
it
has
been
mentioned
so
so
we
know
that
those
discussions
have
are
happening
in
the
this.
These
rules
I
just
wanted
to
to
show
them
because
we
have
to-
and
now
I
mean
I'm
wondering
if
there
are
any
other
topics
that
we
want
to
discuss.
C
D
F
D
Was
curious
about
the
the
two
meetings
scheduled
for
for
March
here,
one
in
the
week
before
the
ITF
and
one
at
the
ITF
meeting,
have
you
decided
or
have
you
discussed,
having
both
or
or
one
of
them
and
if
so,
which.
A
Yeah
yeah
regularly
I,
don't
know
why
he's
a
so
I
think
the
discussion
is
whether
we
have
an
interim
meeting
yes
or
no
I
mean
what
do
you
people
think?
Is
it
useful?
Is
it
not
useful.
B
A
Yeah
yeah
sure
so
who
who
would
participate
to
that
meeting
if
that
meetings
happen,
who
thinks
it's
a
bad
idea.
E
So
I
was
going
to
comment
that
we
are
working
on
the
update
of
enrollment
over
secure
transport
over
Oscar,
which
is
an
old
document
that
has
been
hanging
around
for
a
while
and
hasn't
been
updated
in
a
year.
So
right
now
we
are
working
on
updating
this
and
I
will
be
requesting
to
to
present
this
during
the
ITF
meeting.
I,
unfortunately,
won't
be
available
during
the
week
before
when
the
interim
is
I
believe
scheduled.
So
for
me,
having
the
meeting
at
ITF
would
be
would
be
great.
A
A
So
I
mean
is
there
anyone
saying
that
we
need
to
have
the
meeting
because
I
mean
just
you
can
say
it
in
the
chat
because
I've
received
only
half
of
what
you're
saying
for
some
reason,
so
so
I
I
think
is
Constant
saying
we
should
have
the
interim
meeting.
A
E
F
It
takes
10
seconds
to
switch
on
the
microphone,
so
no
I
think
it's
generally
a
bad
idea
to
have
an
interim
in
the
week
before
the
IHF
I
mean,
if
you
don't
have
a
meeting
at
the
ITF,
then
that's
okay,
but
if,
if
you
do
I'm
not
quite
sure
how
we
would
just
to
root
the
work
between
the
two
meetings
to
make
this
this
useful
and
we're
not
going
to
have
any
progress
between
two
meetings
right.
F
A
So
yeah
I
think
we
we
have
a
consensus
that
we
don't
have
a
an
interim
meeting.
A
A
C
A
Okay,
thank
you.
Everyone
I
think
we
can
adjourn
the
meeting
and
see
you
next
time.