►
Description
Evolvability, Deployability, & Maintainability (EDM) Program Meeting, 2021-10-13
A
All
right
welcome
to
our
edm
conversation,
so
I
will
share
my
browser,
so,
first
of
all,
yay
ib
user
lose.
It
is
in
the
sent
to
rfc
editor
state.
So
we
are
done
with
this
modulo
off
48
stuff
in
rfc
editor
comments,
but
this
is
out
the
door.
So
we've
we've
done
something
in
the
group,
which
is
great,
I'm
really
happy
with
how
we
were
able
to
resurrect
that,
and
I
was
able
to
close
one
of
our
earliest
github
issues
of
should
we
do
something
with
user,
lucid,
so
whoo.
A
The
things
that
we
wanted
to
talk
about
today
are
essentially
you
know.
What
do
we
think
it
makes
sense
to
do
next,
because
this
was
just
kind
of
a
small
first
step
to
look
at
what
are
the
extensibility
mechanisms
mechanisms
we
have,
but
there
are
different
ways
in
which
work
can
spill
over
from
that,
both
in
the
kind
of
theoretical
extensibility
angle,
as
well
as
the
practical.
A
A
A
B
B
So
so
yeah
the
the
idea
about
making
code
easier
to
find
certainly
code,
is
important
to
a
lot
of
ietf
efforts.
I'm
most
familiar
with
the
things
around
the
hackathon
we've
been
doing
to
try
to
put
more
emphasis
on
running
code,
but
you
know
it
shows
up
in
a
lot
of
places
and
which
is
great,
but
finding
code
is
that's.
You
know.
B
Related
to
drafts
can
often
be
quite
challenging,
and
so
this
has
been
a
topic
of
discussion
not
only
in
the
edm
list,
but
I
think
it
was
on
the
working
group
chairs
list
and
maybe
a
couple
others,
and
I
just
tried
to
capture
some
of
those
thoughts
in
a
draft
to
make
it
easier
for
us
to
discuss
and
hopefully
make
some
progress
on
making
things
better
so
so
yeah.
The
general
idea
is
that
there
is
this
code.
B
It
exists,
we're
doing
things
to
try
to
make
sure
that
there's
more
of
it,
but
but
really
even
just
of
that
code,
that's
already
out
there
to
make
it
easier
for
those
who
know
about
it
to
identify
it
as
such
and
then
for
those
who
are
interested
in
working
in
a
certain
area
to
help
them
like
realize
that
this
code
exists
and
be
able
to
find
it.
That's
really
the
goal
here.
B
So
this
code,
at
least
from
my
perspective,
it
can
exist
in
a
lot
of
efforts.
I
think
some
people,
when
they
think
of
code
and
internet
drafts
and
standards,
they're
thinking
of
perhaps
like
reference
implementations
or
certainly
more
direct
things
like
here's,
a
client
or
a
server
that
actually
implements
the
protocol.
We're
standardizing
and
that's
fantastic.
I
mean
it's
wonderful
when
you
have
those
types
of
things,
but
I
think
there's
a
lot
of
other
things
too.
B
That's
really
very
targeted
toward
hey,
there's
this
aspect
of
this
protocol,
or
you
know
this
idea
we
have,
and
we
just
want
to
be
able
to
prove
or
disprove
that
it
actually
works
so
and-
and
you
know,
a
lot
of
this
code
may
not
be
of
any
value
anymore.
So
knowing
what
code's
there
and
the
state
it's
in
is,
it
is
often
difficult.
B
B
We
have
had
cases
of
people
working
on
that
and
hackathons,
and-
and
that
can
be
good
too
so,
but
you
know
it's
certainly
no
matter
what
it
needs
to
be
publicly
available.
Otherwise,
it's
not
very
useful,
and
I
think
this
is
pretty
the
last
well,
it's
pretty
obvious
too
right.
It
needs
to
be
at
least
somewhat
related
to
work,
that's
going
on
in
the
ietf,
and-
and
this
could
be
any
of
those
cases
that
we
talked
about
earlier,
being
very
direct
or
more
of
an
indirect
relation.
B
I
guess
that
that
the
idea
was
was
more
baked
right,
because
people
have
actually
implemented
it,
but
it
doesn't
necessarily
have
a
life
that
section
doesn't
necessarily
have
a
life
beyond
the
draft
going
to
rfc
the
github
working
group
or
get
working
group
that
actually
created
to
come
up
with
some
best
practices
around
how
working
groups
can
can
use
github
and
get
to
to
work
on
drafts.
So
you
know
we
have
that
and
then,
of
course
we
have
the
hackathon
that
I've
mentioned,
which
just
you
know,
results
in
more
emphasis
and
generation.
B
I
would
say
of
code,
so
so
we
do
have
some
things.
So
the
proposal
here
is
to
put
a
little
bit
more
structure
around
using
those
things
and
yet
have
it
be
very
lightweight
and
just
come
up
with
a
process
that
maybe
at
least
moves
the
needle
forward
a
little
bit
in
terms
of
making
code
easier
to
find.
B
So
the
first
thing
would
be
to
set
up
a
repo
that
follows
the
recommendations
that
came
out
of
the
get
working
group
right
and
there's
a
couple
rfcs
there
about
about
how
to
do
it
about
how
to
set
up
a
repo
for
an
internet
draft
that
you're
working
on.
So
when
you're
working
on
a
draft
I'd
say
you
should
you
should
do
that
and
then
in
the
readme.
B
You
can
include
some
information
about
code
that
you
know,
and
this
could
just
be
a
pointer
to
another
git
repo
or
you
know
it
could
be
located
wherever.
But
some
information
that
you
know
the
readme
would
be
the
thing
that
people
would
look
at
to
say.
Okay,
here's
this
internet
draft,
that's
being
worked
on
within
the
ietf,
and
here
are
some
links
to
some
code.
B
Then
the
data
tracker
has
a
mechanism
that
exists
where
you
can
associate
a
github
org
or
get
github
repo
with
an
internet
draft
and,
and
that
would
be
a
good
thing
to
use.
This
is
where
you
can
put
the
link
to
your
your
repo,
so
people
can
find
the
readme
very
easily
the
implementation
status
that
we
mentioned
before.
B
B
Case
that
you
actually
get
an
rfc
and
it's
published,
we
want
this
information
to
live
on
and
and
also
for
us
to
be
able
to
change
it.
If
we
need
to
so
then
one
suggestion
which
I
thought
was
really
good
was
we
could
make
use
of
the
inline
errata
functionality
that
we
have
and
and
through
that
you
can
actually
add
references
to
to
code
which
may
just
be
a
link
to
the
same
readme,
but
maybe
later
on.
B
B
D
B
Okay,
well,
we
can
see
if
there's
a
better
way
that
to
capture
it.
That's
that's
great!
Okay!
So
here's
the
data
tracker-
and
I
pulled
this
up
to
show
how
you
can
add
this
additional
information
additional
resources.
I
guess
it's
called
associate
this
with
your
draft,
so
you
know-
and
this
is
my
my
draft
on
running
a
hackathon
in
the
data
tracker.
So
now,
if
I
click
on
this
link,
hopefully
I'm
still
sharing
the
right
thing.
B
D
D
Sure
that
there
are
cases
where
there
are
two
competing
implementations
of
the
same
rfc
wind
by
the
authors
and
one
by
somebody
else
that
believes
it's
better
or
whatever,
because
until
now
the
repo
and
the
data
tracker
requires
the
multi-group
chair
or
the
authors
to
modify
it.
So
how
can
a
competing
buyer,
whatever
company
thinks,
could
put
their
code
there.
B
Well,
you
know,
I
think
one
way
to
go
about
that
would
be
you
know.
Like
let's
say
I
was
running
into
that
problem,
that
I
had
a
competing
implementation,
that
the
draft
author
wasn't
necessarily
super
fond
of.
I
think
I
would
probably
send
a
pull
request
to
add
a
link
to
my
my
implementation
with
a
little
bit
of
information
about
what
it
is
and
I'll
link
to
it
to
the
readme
and
then
yeah.
B
Maybe
I
can't
update
the
draft
because
I
don't
have
right
pillages,
but
at
least
there's
kind
of
that
trail
where
you
can
see
me
submitting
it
and
then
you
know
the
the
working
group
should
be
monitoring
that.
So,
if
you
have
an
author
who
is
screening
implementations
that
that
they
don't
like
well,
that's
kind
of
like
rejecting
contributions
to
the
draft
that
you
don't
like
you
need
to.
D
D
B
E
E
They
like
they
get
a
github
repository
in
the
working
group
organization,
and
so
one
thing
here
is
you
know,
especially
because
of
eric's
comment
about.
You
know
people
disagreeing
in
the
working
group.
You
could
imagine
having
a
like
implementations
of
this
draft
working,
a
github
repository
in
the
working
group
organization
that
only
the
chairs
have
added
access
to
anyone
else
can
create
prs,
and
so
the
authors
of
the
draft
don't
have
any
more
access
well
or
even
there,
but
like
the
idea
is
that
that
repository
would
carry
like
working
group
consensus.
E
Just
like
the
you
know,
the
working
documents
do
to
some
extent
and
then
the
draft,
just
even
in
the
draft
itself,
has
an
implementation
section
that
says
for
details
that
are
up
to
date
about
the
implementation
visit,
this
github
repository,
and
so
once
the
rc
is
published.
It
is
immutable.
You
don't
need
any
errata,
because
that
link
stays
true
they,
but
the
problem
is
then,
because
then
the
you
know,
ownership
and
the
access
control
of
that
list
goes
to
the
working
group
chairs.
E
And
so,
if
someone
shows
up
later
and
says
hey,
I
wrote
up
an
implementation.
It's
the
chair's
responsibility
to
say
yep.
This
looks
like
a
reasonable
implementation.
I'll
add
it
to
the
list.
We
don't
need
to
say
which
one's
best
we
just
say
that
it's
there
and
but
but
then
what
does
happen
if
the
working
group
gets
closed
not
available.
E
Like
we
have
inr
registries,
where
the
working
group
that
created
them
has
been
closed,
so
you
could
imagine
having
the
list
of
implementations
maintained
by
ayanna,
though
yes,
the
look
on
tommy's
face
is
very
correct,
like
the
like,
I
just
said
something
to
get
a
new
quick
version
added
to
the
list.
It's
been
weeks,
I
don't
know.
What's
going
on
like
ayanna,
is
not
the
simplest
process,
but
yeah
we
would
need
a
change
asset
controller.
A
You
know
I
was
expecting
you
to
kind
of
go
a
different
direction
with
the
suggestion
there
when
you
said
ayanna
of
like
how
you
know
in
iana
registers,
you
have
designated
experts
which
live
beyond
a
working
group
chair,
and
so
you
could
essentially
say
you
know.
Oftentimes
experts
are
chairs
or
authors
and
you
you
could
just
have
you
know
a
designated
github
maintainer
for
the
area
that
just
takes
over
the
working
group.
Github
and
you
know
if
the
isg
gets
mad
at
them,
then
you
know
they
choose
a
different
person
to
maintain
it.
A
E
I
I
like
that,
because
that
allows
to
evolve
this
during
and
past
the
lifetime
of
the
working
group,
and
it
also
gives
an
appeals
process.
That's
simple,
because
you
would
say
if
for
some
reason
either
you
know
that
person
just
stops
responding
to
their
email
or
they're
being
difficult,
and
they
don't
want
to
add
your
implementation
because
they
don't
like
you,
you
can
it
says
you
know
you
appeal
to
the
security
ads,
for
example,
if
it's
a
security
related
topic,
and
we
know
that
we
will
have
security
ids
for
all
of
time,
yep.
A
We
you
know,
we
do
see,
as
you
point
out,
I
think
already
charles
in
your
document
like
there
are
examples
of
people
doing
this
like
quick.
Has
it
on
the
wiki
page
for
the
base
draft
repository
and
within
http.
We
have
different
information,
often
stuffed
in
other
repositories
within
the
working
group,
one
there's
we
have
at.
We
have
a
specific
wiki
repo
that
has
a
wiki
attached
to
it
and
I
imagine
other
people
have
different
ones.
A
So
part
of
this
is
just
having
like
what
we
did
with
the
git
working
group
to
begin
with,
like
what
is
a
uniform
way
of
doing
it.
What's
a
template
that
you
can
take
of
like
here's,
an
easy
place
to
put
it
like,
you
know,
I
know
with
some
newer
working
groups
like
within
add
the
chairs,
just
kind
of
said
all
right.
Let's
just
take
the
template
of
what
you
know.
A
A
A
So
probably
we
just
say
you
know
there
should
be
either
a
like
what
we
see
like
working
group,
materials
or
a
wiki
repo
or
a
implementations
repo,
and
that's
just
like
a
common
place
to
put
it,
which
then
individual
read.
I
guess
individual
readmes
would
just
take
you
to
that.
I'm
saying
like
hey.
If
you
want
to
find
out
more
about
the
implementations,
this
working
group
is
doing
go
to
the
wiki
that
could
work.
B
Yeah
then
I
think
you
would,
it
seems
to
me
you
kind
of
have
to
have
one
kind
of
process
for
individual
drafts
before
they're
adopted
by
a
working
group
and
then
once
they're
in
a
working
group.
They
should
follow
the
working
group
practice
which
the
more
like,
if
we
can
have
a
a
uniform
working
group
practice
that
really
makes
things
very
easy
and
and
maybe
by
starting
with
the
template
so
that
you
know
most
working
groups
do
the
same
thing.
B
I'm
sure
you're
still
going
to
have
some
outliers,
though
that
do
things
a
little
differently,
oh
sure,
and
then
the
other
challenging
thing
is
the
one
eric
mentioned
once
the
working
group
closes.
But
I
think
we
could
leverage
some
of
the
yeah
things
we've
done
in
the
past
for
having
experts
or
you
know
a
place
to
go
to.
When
you
have
a
question
about
an
rfc
for
which
there's
no
longer
a
working
group,
we
could
probably
look
very
similar
mechanism.
A
Okay,
so
I'm
gonna
besides
taking
notes
kind
of
translate
these
into
some
of
our
own
edm
github
issues.
Just
so,
we
can
keep
track
of
the
ideas
of
you
know
things
we
can
work
on.
So
I
think
one
that
seems
to
be
coming
out
of
this
is,
you
know,
define
a
standard
place
to
track
implementations
in
like
working
group,
githubs
and
so,
for
example,
that
can
be
a
wiki
in
a
specific
repo
github.
So
that
seems
to
be
one
thing
that
we
could
do.
That's
really
related
to.
A
You
know,
mainly
the
active
work
of
you
know
as
I'm
doing
this.
How
am
I
saying
hey
I'm
working
on
this
too?
How
do
we
maybe
do
interop
after
that
or
whatever,
and
then
there's
this
separate,
one,
which
I
think
kind
of
falls
into
our
larger
maintainability
theme
of
like
what
happens
when
you
close
your
working
group
and
what
happens
to
your
github.
B
B
D
A
D
A
D
Yeah
yeah,
oh,
I
got
a
working
group
but
which
is
a
nightmare.
It's
dnsd,
the
chairs
are
completely
dumped
david
right.
Just
in
case
you
did
not
notice
yeah
yeah,
yeah
yeah
again
right,
they
don't
make.
My
problem
is
a
big
big,
big
thing,
but
we
need
to
think
about
it
and
and
by
the
way
I
was
when
I
was
reading
this
the
abstract
chart.
E
B
D
Yeah
yeah
and
the
other
point:
if
it
appears
on
data
tracker,
maybe
I'm
getting
paranoid
right,
but
I've
been
burned.
Does
it
mean
that
the
iatf
llc
endorse
the
code?
Because
if
somebody
replaces
a
you
get
a
nice
implementation
of
whatever,
let's
say,
quick
and
then
replace
quick
by
equipped
with
a
back
door
and
people
trust
the
atf
first.
D
B
Yeah
I
get
that,
although
the
the
the
information
you
have
on
the
data
tracker,
would
it
it's
it's
sort
of
indirect
right,
because
you,
your
pointer
and
the
data
tracker,
would
be
pointing
you
to
not
v1
implementation.
That's
pointing
you
to
a
place,
it's
funny
to
the
place
where
you
find
out
about
all
the
implementations.
Maybe.
B
B
Are
good
for
the
itf
to
do
in
general
or,
for
you
know,
maintainers
of
code,
to
do
in
general
to
let
people
know
the
status
of
your
code,
so
we
kind
of
have
a
level
of
expectation
of
hey.
What
am
I
getting
with
this
or
is
this?
Is
this
maintained?
What
if
I
want
to
contribute
all
those
things
right,
they're,
just
good
practices
for
for
collaborating
on
code.
A
Yep
once
I'm
adding
those
notes
to
our
issue
about
a
standard
place
to
track
things
yeah,
so
I
think
that's
those
are
both
kind
of
very
interesting
directions.
We
can
go
in
the
other
bit.
I
wanted
to
jump
back
to
charles
of
what
you
were
saying
was
talking
about
like
oh,
we
have
the
inline
errata,
which
that's
a
interesting
kind
of
hack
around
this.
A
D
C
B
B
B
It's
maybe
like
i2
nsf
right
there's
been
work
on
the
drafts
that
are
from
that
working
group
to
illustrate
how
to
to
use
some
of
the
protocols
that
are
there
in
the
context
of
say,
openstack
or-
and
I
think
if
you
go
you'd
find
some
interesting
things,
but
I
wouldn't
say
that
it's
it's
a
reference
implementation
of
of
the
draft.
It's
just
a
draft.
That's
adding
some
support
for
that
protocol,
at
least
for
certain
use
cases
which
is
useful
right.
But
it's
not
it's
not
a
reference
implementation.
A
I
I
guess,
though,
that
type
of
thing
you
know
if
I
had
people
in
my
working
group
doing
that
like
it,
would
be
nice
to
capture
that
somewhere
in
this
wiki
about
implementations.
They're,
like
some
of
these,
would
say:
hey
you
know,
people
did
this
work
and
if
you
want
to
go
kind
of
go
back
through
the
history
like
what
we
can
see
with
quick
of
like
here
are
all
the
implementation
status,
checkpoints
and
these
people
did
this
much
of
this
one,
and
this
much
of
that
one.
A
You
know
besides
just
saying
hey,
who
can
I
interrupt
with
you
and
say
which
parts
of
this
spec
like?
Did
anyone
implement
migration?
Do
you
know
like?
Did
anyone
try
these
parts
out?
It's
it's
a
useful
thing,
so
I
guess
if
we,
if
we
have
this
commonplace
like
in
a
github
or
something
the
implementation
status,
section
of
your
draft
could
just
point
to
that.
It's
like
look
over
here.
If
you
want
to
see
that,
and
then
you
don't
need
to
worry
about,
is,
is
this
particular
one
appropriate
to
list
so.
C
I
think
it's
important
to
keep
in
mind
that
there
are
different
requirements:
people
looking
for
code,
if
you
are
actually
a
protocol,
developer
and
you're
in
the
discussion
right.
You
just
want
to
like
interrupt.
You
want
to
check
some
parts
of
specification
and
so
on,
but
if
later
on
somebody
reads
an
rfc,
they
actually
may
be
looking
for
an
implementation
that
they
can
just
take
in
use,
or
they
might
just
want
to
look
at
code,
so
they
can
implement
their
own
code.
A
What
I
was
wondering
is,
you
know,
I,
I
think
it's
probably
wrong
to
abuse
the
actual
inline
errado,
but
you
know
at
the
risk
of
going
down
the
living
documents
track.
You
know,
can
you
could
we
imagine
something
similar
in
which
someone
with
the
right
authority
be
that
the
working
group
that
produced
the
rfc
or
the
isg
can
say
all
right?
A
You
can
have
an
in
you
know
some
inline
marker
or
link
out
to
you
know
more
info
about
implementations,
or
you
know
something
like
that
and
not
it
doesn't
have
to
be
a
full
living
document
type
thing,
but
it's
just
a
way
to
say:
hey,
here's
an
rfc
by
the
way.
If
you
want
to
learn
more
about
how
this
is
actually
deployed
click
here,
then
you
can
go
to
their
github
wiki
and
that
can
get
updated
and
change.
Just
like
an
errata.
Could
it
just
gets
displayed.
When
you
view
the
rfc.
D
C
Also
metadata
for
all
the
rfcs
and
and
we
we
display
those
metadata
or
we
use
this
metadata
in
the
data
tracker,
but
we
also
display
them
in
other
parts.
So,
like
we
link
to
the
error,
turns
on
that's
part
of
the
metadata
and
those
are
changeable.
But
of
course
the
metadata
don't
show
up
in
the
text
version
or
in
the
pdf
or
whatever.
D
A
C
C
A
A
D
A
C
D
No,
no
I
mean
one
difference
right
is
that
there
is
a
history
for
iron
models,
elder
revision
of
one
model,
specifically
so
the
first
model
distribution
narrative,
but
the
revisions
are
kept
by
the
ion
ayano.
Now
the
code
itself
is
within
inf
servers
right.
So
it's
not
a
pointer
to
something
else,
but
it's
a
big
difference
all
I
say
it
may
be
a
way
to
something
to
explore.
B
A
A
To
do
justification
like
what
is
the
right
template
to
go
off
of
you
know
what
should
be
even
recommended
to
working
group,
and
I
think,
looking
at
stuff,
that
quick
has
done
that
http
has
done,
or
let's
try
to
find
some
of
these
examples
of
existing
implementation
status
collections
and
what
works
well
about
them
and
figure
out
you
know:
can
we
come
up
with
kind
of
a
recommendation
for
how
that
would
work?
At
that
point,
we
can
just
you
know,
kind
of
build.
The
template
get
people
to
start
using
it.
A
A
A
A
C
A
C
C
No,
I
think
we
want
some
consensus
about
it,
but
I
think
it
would
be
good
to
actually
talk
to
robert
about
this,
because
we've
been
talking
about
changing
metadata
for
this
update,
update
tag
right
and
he
had
some
concerns
about
tooling
and
changing
these
kind
of
stuff.
So
I'm
not
sure
how
complicated
it
is
and
how
this
integrated
whatever
and
what
that
actually
means.
So
it
would
probably
be
good
to
talk
to
robert.
E
D
A
A
B
It
more
exciting
and
that's
an
area
where
we've
made
a
lot
of
good
progress
with
a
lot
of
working
groups.
Now
we'll
have
a
bit
of
time
for
hackathon
projects
to
be
shared
in
the
working
group,
which
is
super
valuable.
It's
nice
that
we
we
share
them
at
the
end
of
the
hackathon,
but
oftentimes
it's
you
know
it's
not
not
really
your
target
audience,
and
so
you
can't
go
very
deep
on
anything
both
because
you
don't
much
time,
but
also
it's
just
not
relevant
to
everyone
so
but
yeah.
B
When
you
show
it
in
your
working
group,
then
it's
like
hey
those
are
the
drafts.
People
are
reviewing
and
it
it's
very
helpful.
So
I
think
there
is
that
sort
of
tie
between
what
the
working
group
is
doing
and
the
hackathon.
I
think
perhaps
formalizing
that
a
little
bit
with
here's,
where
how
your
hackathon
projects
fit
into
the
working
groups.
You
know
wiki
pages
the
data
tracker
or
your
github.
That
means.
B
So
I
don't
know
what
a
good
format
for
discussion
in
the
ied
open
meeting
would
be.
Is
it
best
to
have
a
draft
like
to
have
an
updated
version
say
of
this
draft
where
at
least
some
of
this
stuff
gets
gets
captured
or
it
just
seems
like
you
know,
an
internet
draft
is
the
best
way
to
have
someone
look
at
something
yeah.
A
Draft
is
a
fantastic
way
to
get
people
in
the
ietf
to
read
something
yeah.
I
think
that
makes
sense
yeah.
So
if
we
want
to
kind
of
you
know,
take
this
discussion
figure
out.
How
do
we
roll
that
into
the
draft?
I
think
you
know,
parts
of
what
we
want
to
do
are
not
going
to
all
be
bound
to
a
draft,
but
we
can
still
have
a
draft
that
describes
what
we
think
should
be
done.
C
B
C
I
don't
think
it's
necessary
to
have
a
draft
to
ib
open.
If
you
have
slides
there
will
be
discussions
as
well,
so
you
can
always
have
production,
of
course,
but
if
you,
if
you
if
draft,
makes
no
sense,
if
you're
actually
planning
to
publish
something-
and
I
think
this
is
also
maybe
the
what
people
might
assume,
if
you
write
a
draft,
then
people
might
assume
you
actually
want
to
publish
it
so
be
careful
there
as
well,
maybe
a
little
bit.
B
B
A
A
B
A
Yeah
and
the
other
thing
I
think
we
can
do,
which
is
we're
doing
it's
like
you
know,
there's
a
working
group
chairs
list
and
stuff.
We
could
come
up
with
like
a
little
survey
that
we
send
out
about.
You
know,
do
you
track
implementations?
Do
you
want
to
do
you
know
and
kind
of
figure
out?
You
know
what
are
people
currently
using
for
this?
Are
they
not
using
something?
A
E
That
that
sounds
good.
I
would
love
to
get
a
feedback
from
like
the
wider
community
at
its
see
what
people
think
and
from
there
we
can
kind
of
see
kind
of
based
on
a
feel
of
the
room,
because
in
general
the
people
who
care
the
most
about
process
tend
to
attend
iab
open.
So
that's
the.
I
think.
That's
the
right
place,
yeah.