►
From YouTube: IETF-ASDF-20230112-1500
Description
ASDF meeting session at IETF
2023/01/12 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
E
D
D
B
B
D
D
A
D
B
I
mean
I'm,
I
mean
it
is
a
tough
I
think
it's
a
it
must
be
one
of
the
sort
of
first
real.
You
know,
I
mean.
Obviously
there
were
there
were
ships
and
stuff
before
that,
but
they
don't.
They
never
run
on
sort
of
that
type
of
schedule,
and
you
obviously
need
to
fix
the
schedule,
because
otherwise
it
won't
be
safe,
because
you
can't
top
two
trains
on
the
same
track
at
the
same
time
and
everything,
but.
F
D
Yeah
there
was
one
there
was
one
show
that
was
done
on.
You
know:
Railways
Through
Time,
one
of
the
episodes
hour-long
episodes
was
Railways
in
war,
and
one
of
the
claim
one
of
the
claims
from
Holocaust
deniers
is
that
they
couldn't
possibly
have
moved
that
many
people
around,
and
this
show
make
our
users
as
well.
It
actually
only
took
one
percent
of
Germany's
railroad
infrastructure
to
move
that
many
people
and
that
they
had
400
trains
a
day
on
the
Eastern
Front
to
supply
the
troops
that
were
fighting
against
Russia
400
trains.
D
A
B
It's
a
logistic
thing,
you
need,
you
need
to
work
it
out,
but
and
I
think
I've
read
also
sometimes
around
the
you
know,
World
War
II
in
in
in
the
US
I
mean
the
railroads
got
their
together
and
started
shipping
stuff
with
I
mean
it.
It
gives
you
scale
to
have
said
you
cannot
get
the
scale
from
drugs
or
you.
A
B
D
B
B
A
B
B
B
B
There
used
to
be
a
limited
link,
I
think
that
might
get
lost
blue
sheets
covered
by
miteko,
and
then
we
have
a
quick
status
update
from
the
chairs
hi
Michael,
and
then
we
get
to
the
sort
of
the
meat
of
the
meeting
where
we
try
to
look
into
this.
Getting
the
SDF
RFC
or
the
draft
ready
for
moving
on
in
the
process.
B
You
know
this
stuff,
nothing
interesting
status,
update
the
only
I
mean
there
are
two
things
here.
When,
obviously
we
know
there's
history
and
everything
and
we
lost
on
Steam
in
2022,
I
would
like
to
get
that
back
and
finish
this.
Unfortunately,
the
draft
expired,
but
we
encourse
them
and
just
resubmitted
so
we're
in
our
own
version.
13.,
that's
good!
Thank
you
very
much
for
that.
We
need
to
really
get
this
to
the
Finish
Line
I
think
we've
spent
quite
some
time
sort
of
hiring
out
bugs
and
so
on.
B
B
We
should
obviously
have
more
virtual
interims,
but
the
big
question
is,
of
course,
should
we
have
a
actual
face-to-face
in
Yokohama
and
we
still
have
like
two
or
three
weeks
to
dismay.
Well,
actually,
I
don't
remember
the
deadline,
but
but
it
we
have
a
couple
of
weeks
to
decide
that
but
I
don't
know
if
we
should
have
an
ASDF
face
to
face
or
if
we
just
try
to
meet
in
the
hallway
or
or
what
makes
sense.
B
But
my
rough
planning
is
going
to
Yokohama
this
time.
So
it's
a
I,
don't
know
what
other
people
feel
I
don't
think
we
may
be.
We
maybe
don't
need
an
ASDF
to
actually
in
a
meeting
there
to
get
this
done,
but
it's
more
that
we
could
make
some
you
know,
show
it
off
perhaps
and
be
visible
Before
we
or
we
will
become
the
first
virtual
work
group
in
ipf
that
never
meets
Kirsten.
Please.
C
Yeah
I
think
these
are
good
points.
There
are
also
some
some
other
points
being
at.
A
physical
meeting
gives
an
opportunity
for
people
to
to
join.
Of
course,
conflicts
are
a
problem.
There
are
always
whether
that
makes
a
lot
of
sense
depends
on
what
phase
we
are
in
and
if
we
actually
are
getting
close
to
to
our
UTF
submission
drivers.
G
submission
then
actually
having
a
physical
meeting
is
useful.
C
F
Yeah
I
would
also
think
like
having
a
physical
meeting
would
be
great,
I
mean
for
first
fact
we
haven't
had
one,
but
but
then
also
perhaps
actually
getting
a
bit
of
a
bit
of
a
wider
group
together,
and
one
thing
that
would
maybe
would
be
for
having
it
on
the
agenda
is
exactly
to
avoid
those
conflicts.
So
we
would
have
a
place
that
where
we
wouldn't
be
ourselves,
conflicted,
that's
it.
Of
course
we
are
likely
to
be
a
small
group.
F
B
B
B
B
Yes,
there
will
be,
of
course,
conflicts
and
stuff,
so
maybe
I
think
it
would
be
coming
given
the
amount
of
time
when,
and
so
we
actually
spent
on
this
it
may.
What
maybe
make
sense
to
have
it
spread
to
a
larger
audience
and
having
it
visually
sort
of
in
the
agenda
for
IDF
would
probably
make
it
more
yeah.
You
know,
even
if
it's
a
small
meeting,
there's
some
more
people,
you
know
walking
into
the
room
and
so
on
so
I
I
think.
D
I
would
say
Okay,
so
we're
going
to
schedule
it
is
there.
Is
there
something
that
is
there
anything?
This
sounds
silly
in
ITF,
but
given
where
we
are
in
the
document,
is
there
some
kind
of
tangible
demo
that
that
might
be
helpful
for
people
who
wander
into
the
room
to
understand
what
we're
doing
or
to
motivate
it.
B
D
I'm,
just
thinking
about
providing
a
kind
of
no
I
am
talking
yeah,
okay,
I
thought
my
microphone's
muted
I'm.
Just
thinking
about
you
know.
If,
if
we're
trying
to
attract
more
interest,
then
something
that
explains
what
we're
doing
or
see
people
can
see
what
we're
doing,
maybe
maybe
motivate
them
to
actually
go.
Read
the
document
and
give
us
the
kind
of
reviews
that
we
need
to
advance
the
document.
B
Yeah
yeah
I
would
also
think
that
if,
if
we
make,
if
we
make
it
face
to
face,
if
it
would
not
be
like
you
know,
like
three
minutes
past,
we
start
with
the
first
issue
of
the
draft,
it's
more
than
you
spend
like
10
or
15
minutes,
or
maybe
even
more
working
through
the
the
kind
of
where
we
are
and
showing
some
demo.
And
you
know,
do
it
a
bit
of
Roadshow
kind
of
thing
and
then
get
to
the
more
kind
of
Concrete
technical
things.
B
F
Right,
yeah
and
no
no
worries
yeah.
Well,
we
do
have
the
one
page
website,
demos
that
you
know
allows
you
to
transfer
translate
between
five
different,
our
representations,
that's
certainly
something
easy
to
set
up
and
show
as
a
way
like
okay.
What
does
this
technology
actually
do?
So
that
might
be
useful
yeah.
C
B
C
B
D
D
That
could
be,
but
but
that
decision
is
not
final
until
maybe
the
end
of
next
week
or
something
basically
I,
don't
really
feel
like
I
have
funding
to
go
to
all
three
ietfs
this
year
and
that
one
will
be
the
most
expensive
one.
So
there
you
go,
but
I
don't
have
a
problem
with
with
what
you're
proposing
I
think
it's
a
really
good
idea.
D
The
other
side
is
that
anything
that
we
do.
Polish
I
really
think
that
probably
needs
to
go
into
something
needs
a
bit
of
a
a
a
a
a
a
road
show
to
some
other
other
iot
venues,
and
so
I
think
that's
even
if
they
are,
we
don't
expect
them
to
contribute
anything
I
think
it's
valuable
for
them
to
understand
that
this
work
exists
and
then
they'll
talk
to
it
about
to
they'll
talk
about
it
to
other
people
elsewhere.
B
Let's
say
that
we
have
an
intent
to
meet
to
have
something
in
in
Yokohama,
and
maybe
we
need
to
Hash
it
out
a
bit
more
the
details
of
what
we
could
show
and
so
on.
So
we
maybe
might
not
want
to
schedule
the
request
the
slot
this
week
right,
but
but
take
like
in
the
next
week
in
a
decision
to
go
and
I'll,
go
for
that
and
then
figure
out.
B
B
D
B
C
Well,
maybe
so
Jana
has
moved
on,
but
there
may
be
other
people
picking
this
up
so
I
don't
know.
I
would
be
interested
in
keeping
it
alive
and
right
now
it
still
works,
because
we
haven't
changed
SDF
a
lot,
so
the
mapping
is
still
correct
and
it's
it's
work
that
that
really
maybe
belongs
into
the
research
group.
I
don't
know,
but
that
should
be
kept
alive.
Okay,.
C
Yeah,
the
the
compact
is
just
just
a
tool
thing
so
when
I,
whenever
I
get
time
to
actually
work
on
that
tool,
I
have
way
too
many
tools
to
shoot
up.
That
I
should
be
working
on
right
now
and
I.
Think
the
the
concept
is
sound,
people
have
looked
at
it
and
and
found
it
useful
and
I
just
need
to
make
sure
I
have
all
the
components
together
to
turn
this
into
a
really
useful
tool,
and
then
I
will
update
the
route.
Okay.
C
Yeah
so
I
think,
mapping,
relations
and
and
SDF
type
link
are
the
three
documents
that
should
be
on
our
plate
as
a
working
group,
next
yeah,
two
Compact
and
young.
These
are
useful
individual
contributions
that
can
stay
individual
contributions
for
a
while,
but
I
think
the
lower
three
are
the
ones
that
that
we
should
make
sure
we
we
are
chartered
when
we
reach
outer
after
delivering
the
first
document,
and
we
should
make
sure
that
that
we
work
on
these.
B
C
Yeah,
thank
you.
So
we
had
about
half
a
year
since
Dash,
12.
and
I
wouldn't
immediately
subscribe
to
saying
we
ran
out
of
steam
where
I
think
it's
more
like
the
steam
went
somewhere
else
and
I
think
we
we
did
use
the
time
to
actually
make
sure
that
the
1dm
requirements
are
indeed
covered
requirements,
always
a
weird
thing,
because
in
engineering
there
aren't
requirements
that
there
is
design
and
the
requirements
work
with
the
move,
with
the
result
anyway.
C
So
I
think
we
have
completed
that
1dm
computers
check
phase
and
we
just
now
now
need
to
zip
things
up
and
draft.
There's
13
is
just
a
version
that
includes
the
one
PR
that
we
actually
had,
which
which
fixes
essentially
a
bug.
The
text
already
had
the
change,
but
the
the
cdda
didn't
so
that
that
is
now
fixed
and
yeah.
We
have
17
issues.
We
need
to
finish
them.
A
C
C
C
One
way
of
handling
this
is
cramming
as
much
information
as
possible
into
the
version
field,
which
makes
this
a
possible
item,
which
is
not
really
the
right
thing
to
do
things.
When
you
already
have
a
language
like
cddr
that
you
can
use
for
structuring
things.
So
maybe
we
should
simply
revisit
the
infobloc
issue.
One
final
time
make
sure
that
the
various
usages
in
in
one
dm
and
and
contributing
organizations
are
covered
and
write
up
what
we
need
to
standardize
about
that
usage.
C
F
Yeah
I
guess
what
part
of
this
work?
We
would
look
at
this
adding
the
information
about
the
creation
date.
That's
a
special
specific
field
in
case
where
you
want
to
have
the
perfect
field
content,
other
information
and
data
information,
I
guess
this
goes
the
same
same
issue
that
was
already
identified
with
the
web
of
things:
ecosystem.
C
So
next
group
SDF
type
I
promise
to
write
the
text
for
having
an
Ina
registry
for
the
SDF
type
values
I
didn't
get
to
this,
but
I
think
it's
pretty
clear
what
needs
to
be
done
there.
We
may
need
to
discuss
the
the
INR
policy
for
this,
but
yeah
I.
Think
that
that's
maybe
not
that
consequential,
because
if
people
want
to
to
squat
on
an
SDF
Drive,
the
bridge
would
anyway
so
yeah.
So
this
is
just
a
matter
of
writing
and
I.
Don't
think
we
have
open
questions
about
that.
C
So
the
next
group
is
names.
We
have
several
issues
that
discuss
names,
usually
around
evolvability
and
putting
things
into
namespaces.
So
we
have
number
83
that
just
the
the
title
just
says
cddl,
but
we
need
to
Define
it
and
whether
we
do
that
in
Syria
or
not,
it's
not
the
important
part.
So
how?
How
do
we
handle
qualities
that
have
a
namespace
name
in
them?
C
And
one
proposal
is
right
there
in
number
85,
which
would
provide
an
INR
registry
for
those
namespaces
so
that
that
sounds
very
weird
initially,
but
I
think
it
makes
a
lot
of
sense.
So
the
the
various
contributing
organizations
could
simply
register
the
namespaces
there
and
we
could
make
sure
that
they
don't
conflict
and
number
67
is
about
further
defining
the
syntax,
not
just
of
quality
names,
but
also
of
given
names,
so
the
names
that
are
internal
to
the
model.
C
D
D
D
C
So
finally,
there
have
been
some
other
technical
issues.
One
was
about
the
the
semantic
conflict
between
SDF
choice
and
enum,
and
there
was
a
discussion
in
the
GitHub
issue
today,
so
we
just
have
to
Define
what
that
means,
and
we
have
the
question
whether
we
can
express
SDF
features
in
SDF
files.
So
this
is,
strictly
speaking,
an
infoblock
issue,
but
it
is
something
that
is
closer
to
home
than
other
info
block
information,
so
that
that
is
something
that
that
is
probably
more
on
the
nice
to
have
side.
C
F
C
So
my
Hope
was
that
we
could
leave
the
resolution
process
alone
and,
as
I
wrote,
we
had
the
same
problem
in
cinema
and
in
the
end,
in
that
specific
example,
we
decided
not
to
have
two
attributes
and
because
it's
it's
really
complicated
to
do
that
that
merging.
But
we
could
come
up
with
a
different
solution
here.
I
just
think
it
should
be
compatible
with
the
fact
that
that
merging
might
lead
to
one
of
these
conflicts
and
the
the
person
referencing.
C
F
Yeah
I
guess
this
is
what
one
of
those
it
turned
out
to
be
slightly
more
complicated
than
I,
initially
thought
so
I'll
I'll
think
about
it.
But
thanks
for
the
clarifications
Carson
I
yeah
now
I
understand
you.
They
so
there's
two
different
merging
processes.
One
is
stf
merging
and
then
this
the
merging
of
enum
and
stf
choice
and
I.
F
Guess
it's
the
SDF
ref
merging,
which
you
want
to
keep
as
much
as
as
it
is
right
now,
right,
yes
and
then
the
whether
you
do
on
the
Second
Step,
something
that's
what
we
need
to
then
talk
about
yeah,
I,
I,
I,
agree
on
on
that
approach.
So,
but
basically
I
would
say
that
even
in
a
single
model,
without
any
SDF
reffing,
you
would
be
allowed
to
have
both
and
but
but
they
we
should
write.
I
mean
they
should
not
be
in
conflict.
F
C
C
E
Okay,
that
took
a
while
to
unmute,
I,
think
I,
I.
Think
I
put
this
recent
discussion
and
sort
of
clarified
it
for
me,
but
I
wanted
to
point
out
that
I
did
experiment
with
some
semantic
exception
processing
in
some
of
the
stuff.
I
worked
on
with
SDF
choice,
because
I
felt,
like
the
merge
for
SDF
Choice,
really
wasn't
very
useful,
so
I
thought
SDF
Choice
refining
of
SDF
Choice
should
be
sort
of
narrowing
the
field
of
choices
instead
of
expanding,
which
is
what
the
the
merge
would
do.
Rfc,
whatever
Json
merge
style.
E
Merge
would
do
merge,
merge,
hash
style,
I,
guess
they
call
it
so
I
think
there's
still
some
questions
there,
but
I
fully
agree
that
we
should
not
add
some
semantic
exceptions.
I
didn't
like
them,
I
liked
I
mean
the
result
worked,
but
I
didn't
really
like
that.
It
was
just
kind
of
too
ugly
I,
think
kind
of
what
I
concluded
so
I'm
still
looking
for
how
how
you
would
managed
to
refine
this,
we
have
choice
to
reduce
the
number
of
choices
instead
of
merge,
but
I,
don't
think
semantic
exceptions.
I
think
are
the
solutions.
F
So
so
Michael
do
I,
understand
your
case
of
expanding
or
reducing
the
scope.
I
guess
how
it
would
work
now
forgetting
enum
for
a
while
just
having
two
stf
choices.
If
you
SDF
ref
another
definition,
which
has
more
choices
than
you're,
actually
expanding
because
you're
adding
more
choices
on
the
enum
right.
F
E
But
yeah
I
think
that
you're
you've
you've
described
what
the
use
case
is
exactly
that
is
to
to
basically
have
a
a
thing
that
you
can
validate
against,
but
in
other
words
that
you've
chosen
one
of
the
choices,
that's
one
of
the
valid
choices
and
and
has
encodings
and
has
enums,
and
has
you
know,
internationalization,
and
all
of
that.
So
you've
picked
one
from
the
field.
But
you
really
want
to
pick
like
you
know.
E
E
F
F
C
You
really
want
to
write
a
program
to
do
the
processing
and
and
say
delete
all
other
things
that
that
have
oven
in
the
name
or
something
like
that,
and
that's
not
something
we
we
can
reasonably
do
so.
Maybe
we
will
have
an
extension
for
adding
programs
to
our
models
at
some
point,
but
not
today,
so
I
don't
think
we
can
really
solve
this
in
a
way
that
was
satisfy
or
will
be
really
great
for
all
areas
of
application,
but
we
can
make
make
it
work
in.
F
C
The
the
tudu
points
out
that
really
the
cddl
is
about
merged
documents.
It
doesn't
describe
the
documents
that
go
into
the
merge,
and
that
is
of
course,
your
typical
problem.
When
you
are
validating
or
modeling
data
structures
that
undergo
some
processing,
then
you
really
would
need
a
model
for
each
step
in
the
processing,
and
these
models
are
all
almost
the
same.
C
C
Thank
you
great.
So
time
check.
We
have
25
minutes
left
if
I'm
correct
okay,
so
there
are
three
more
groups.
One
is
a
group
of
issues
that
really
are
about
making
sure
that
we
correctly
interface
with
these
other
documents
that
we
talked
about
in
the
beginning.
So
number
84
is
about
an
interface
to
to
the
a
link,
oriented
drafts
and
number
76
is
about
interfacing
to
mapping
files,
and
this
is
this
is
an
issue
where
there
isn't
a
clear
definition
of
done,
but
yeah
we
want.
C
C
C
E
Yeah
waiting
for
the
unmute
again
quick
comment
that
there's
there's
still
kind
of
an
open
issue
on
how
mapping
and
bindings
work
and
whether
we,
whether
there
are
schema,
extensions
involved
and
and
sort
of
I
experimented
with
a
thing.
That's
actually
kind
of
being
talked
about
in
the
Json
schema.org
world.
Right
now,
which
is
using
multiple
schemas
to
validate
an
instance
and
how
you
overlay
them
and
extending.
C
E
C
E
Know
what
I
found
was
that
you
couldn't
with
with
the
way
that
things
are
repeated
yeah.
You
have
to
repeat
yourself,
but
in
this
particular
conversion
the
repeated
things
are
huge
blocks,
so
it
isn't
really
editable
in
a
way
that
you
know
that
you
could
do
confidently
or
even
machine
editable,
because
you'd
probably
have
to
change
several
blocks
for
some
of
the
edits
and
and
to
add
a
feature.
E
C
E
E
C
E
E
D
E
C
The
in
serial
1.0,
you
can
have
multiple
files,
but
these
are
just
all
thrown
in
a
big
bucket
and
and
then
interpret
it
together.
There
is
work
on
CDA
2.0
in
the
sibo
working
group
and
there
is
a
draft
out
there
that
explains
the
initial
set
of
of
capabilities.
We
want
to
achieve
there,
and
maybe
this
is
your
requirements,
for
this
would
be
very
useful
input
for
the
city,
layer,
2.2
2.0
process
in
in
the
sibo
working
group.
E
F
Excellent
and
I
do
remember
there
was
this
feature
version
in
cddl
that
I
guess
you
could
somehow
indicate
if
some
feature
is
supported
or
not
and
I,
but
I
guess
all
together.
I'm
wondering
like
if
we
should,
let's
say,
for
example,
do
the
SDF
relations
draft
and
nstf
Link
draft.
If
we
should
write
some
fragments
of
cdbl
that
could
somehow
automatically
by
tools
could
be,
you
know
imported,
do
the
master
CDL
and
you
could
do
by
this
and
somehow
nicely
automatically
that's
kind
of
where
I
would
love
to
go.
C
E
F
Yeah
and
I
think
it
was
of
course,
as
a
relation
with
the
info
block
features
feature
that
we
discussed
in
in
the
beginning.
It
would
be
nice
if
I
can
somehow
indicate
there's
some
way
to
automatically
map
that
when
I
say
in
the
in
the
info
book
feature
name
that
hey,
it
is
actually
this
piece
of
cddl
and
that
would
then
be
validated
based
on
the
set
of
features
indicated
in
the
info.
Block,
in
whatever
way,
is
a
good
way
to
automate
that,
and
it's
that
would
be
very
useful.
You.
C
All
right,
good
and
the
the
other
two
things
on
the
slide
are
really
things
that
we
can
do
during
doing
our
work
in
the
regular
glass
call,
so
add
some
automated
checks
and
test
cases
in
particular
negative
test
cases
yeah,
so
I,
don't
think
we.
We
want
to
finish
these
issues
before
starting
regular
bus
call,
because
we
will
actually
do
the
work,
checking
the
the
specification
based
on
what
what
we
do
in
completing
these
issues.
C
C
We
have
to
do
the
line
breaking
to
get
into
69
colors
we
have
to.
We
know
we
don't
have
to
we.
It
would
be
nice
to
have
examples
for
SDF,
where
we
don't
have
SDF
pointers,
to
input
output
parameters
anymore,
not
quite
sure,
yeah,
let's
find
out
what
that
was,
but
fortunately
we
have
somebody
who
has
assigned
themselves
to
this
item,
which
is
Michael.
C
C
Are
we
just
submitted
yeah?
So
this
is
the
the
set
of
issues.
As
I
said,
we
really
want
to
do
our
Readiness
check
and
those
test
cases
and
and
consistency
checks
belong
in
there,
but
we
also
want
to
check
our
Readiness
in
the
relationship
to
the
other
three
drafts
to
the
Future
drafts.
Mapping
namespaces.
Well,
that's
not
a
draft
that
comes
up
in
the
two
link
drafts
and
the
link
functionality
itself.
C
So
this
this
is
something
that
is
not
captured,
as
in
as
a
separate
issue,
but
needs
to
be
done
and
of
course
we
need
to
do
our
own
design
reviews,
as
we
always
do
in
a
working
class
called
so
this.
This
is
kind
of
the
next
step
when
the
the
18
issues
are
the
16
issues
that
we
want
to
cover
of
the
18
issues
are
done,
so
the
the
strategy
for
the
first
RFC
hasn't
really
changed.
We
would
still
want
to
minimize
further
additions
and
I
want
to
finish
what
we
have.
C
We
want
to
to
check
the
need
for
things
and
and
the
Readiness
of
things,
and
we
want
to
make
sure
the
extension
points
we
will
need
in
the
future
are
at
least
available,
even
if
we
haven't
fully
specified
them.
We
should
work
in
such
a
way
that
these
extension
points
can
be
added
without
every
implementation
out
there
breaking
catastrophically,
because
they
didn't
know
that
this
extension
point
was
going
to
come
in
I'm
done.
E
Much
these
slides
are
going
on
the
GitHub.
This
looks
like
a
great
reference
to
sort
of
keep
looking
back
at.
As
you
know,
we
we
try
to
do
things
offline
right,
so
I
noticed
there
hadn't
been
much
uploaded
to
the
slides
in
the
GitHub
for
a
while.
Maybe
that's,
but
it
would
be
nice
to
have
these
right
where,
where
do
I
find,
where
do
I
find
these
maybe
I'm
just
looking
in
the
wrong
place.
B
B
E
B
E
B
C
C
F
B
C
C
D
A
B
F
C
B
C
A
B
C
B
B
D
B
D
D
Yeah
input
conflict
in
groups
but
as
chairs
we're
listed
as
as
someone
who
must
be
there,
which
which
fundamentally
prevents
us
the
them
from
con
from
scheduling
two
groups
that
we
happen
to
be
chairs
for
into
the
same
slot.
But
then
there's
a
technology
but
I'm
saying
if
you
also
list
Michael,
carsten
and
Ari,
then
that
also
instantly
deals
with
any
other
chair
conflicts.
They
might
have.
That's
all.