►
From YouTube: EIPIP Meeting 71
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/198
A
Good
morning,
everyone
welcome
to
EAP
meeting
71
I
have
shared
agenda
in
chat,
and
we
have
added
a
few
topics
for
discussion.
The
first
few
sub
items
are
issues
taken
from
the
EIP
GitHub
repository.
Maybe
we
can
start
from
there,
so
the
first
one
is
to
propose
policy.
Last
call.
Changes
shall
be
separated
from
the
pr
to
move
to
final
I
guess
this
was
added
by
Victor,
but
I
don't
see
Victor
on
the
call
right
now.
Oh.
B
A
All
right,
so
part
of
this
was
also
suggested
by
you
in
the
last
meeting
with
the
EAP
editing
office
hour,
I
guess
the
person
has
to
make
a
new
PR
to
make
it
to
final
I
mean
like
a
separate
PR
from
the
last
call.
Changes
is.
B
B
A
The
next
one
is
a
hide,
stagnant
and
withdrawn
eips
from
the
eipa
list.
Issue
number
is
6027.
A
D
D
Feel
you
can
just
wind
up
with
VIPs
that
have
gone
to
stagnant
they're
still
out
there
in
Google
they're
still
historically
interesting,
Google
says
here
it
is
you
go
to
that
page
and
where
is
it
or
else
Google
just
stops
indexing
it
and
it
disappears
from
history.
A
B
I,
don't
think
it's
too
high
the
actual
Erp
itself,
just
just
the
list,
but
yeah
I
can
see
how
that
would
make
it
harder
to
to
index
it.
I'd
be
okay
with
displaying
them
separately.
I
think
we
might
already
do
that
yeah.
We
do
so
yeah,
I
I.
Don't
think
we
need
to
make
this
change.
D
This
is
a
reason:
I
always
prefer
the
ietf
policy,
if
everything's
the
draft,
and
then
it
has
a
status,
but
we
already
lost
that
no
no
point
going
back.
C
C
A
All
right
looks
like
looks
like
generally
not
in
favor
of
this
proposal
or
to
like
hide
stagnant
and
withdrawal
eips
from
the
EAP
list.
So
maybe
we
can
leave
a
comment
over
there.
A
The
next
sub
item
is
changes
to
final
EIP,
so
I
have
found
a
bunch
of
eids
which
are
already
into
final
statuses,
and
authors
have
requested
certain
changes,
sometimes
the
original
author
and
sometimes
any
contributor
from
the
community,
so
I
have
listed
all
of
them.
The
first
one
here
for
references,
number,
6104,
I'm,
sharing
here
Link
in
the
chat.
Generally
speaking,
we
are
aware
that
EIP
editors
are
not
very
much
in
favor
of
having
a
final
proposal
getting
updated,
but
these
are
available
in
the
form
of
pull
requests.
B
A
A
So
eap20
is
like
a
very
old
EIP,
which
has
been
widely
accepted,
so
main
concern
here
is
to
have
it
have
these
changes
added
to
erp20
all
together
or
maybe
have
a
new
proposal
instead.
B
A
I
think
Matt,
you
had
a
strong
opinion
on
that.
Maybe
if
you
would
like
to
add
why
you
think
it
is
not
a
good
idea
to
have
new
recommendation
fit
in
for
these
proposal.
A
The
pull
request
number
is
6038
for
updating.
Eip
20
run
away
to
fit
most
current
eip1
recommendations.
Oh.
E
D
A
So
it
is
about
the
usage
of
license
changes
with
the
The
Proposal,
which
has
been
recently
merged.
A
So
do
we
want
to
have
further
edits
in
the
pull
request,
or
do
we
want
to
have
like
not
include
these
changes
in
eip-21
together.
B
I
think
it's
fairly
nuanced
I
can
make
some
comments
on
the
actual
PR,
like
I,
think
moving
like
simple
summary
to
description.
I
think
that's
a
perfectly
fine
thing
to
do,
but
changing
it
from
like
solidity,
0.4.17
to
0.8.17
I
think
is
way
out
of
line
for
what
we
should
be
doing.
E
A
All
right,
it
seems
most
of
the
editors
are
in
agreement
that
we
should
not
go
for
the
bigger
changes
to
eaps,
which
are
already
into
final
statuses.
So
for
this
weekend,
like
maybe
you
know,
drop
this
pull
request.
We
can
close
this
but
comment.
A
Very
well,
the
next.
D
Slow
down
this,
this
does
bring
up
an
interesting
issue,
because
the
solidity
code
is
out
of
date.
People
use
this
use.
People
use
this
to
build
on
and
we're
giving
them
a
version
of
solidity
that
won't
compile
anymore,
possibly
but
I,
don't
know
in
general
how
we,
how
we
want
to
handle
that
or
just
leave
it
to
the
user.
E
D
D
So
yeah
it's
it's
generally
unfortunate
that
we
use
that.
We
use
solidity
for
this
sort
of
specification,
but
I
I
just
don't
know
if
we
should
have
a
way
to
update
these
things
once
they
get
grotesquely
out
of
date.
D
I
guess
it
could
take
a
new
PR,
but
that
seems
silly
when
nothing
changed,
nothing
changed,
I!
Guess
it's
a
matter
of
just
if
the
solidity
gets
to
where
it
just
won't
compile
without
you
know,
really
obvious
changes.
You
know
and
I
don't
I,
don't
know
solidity
well
enough
to
judge
if
this
is
still
if
this
is
still
going
to
compile.
Okay.
A
Okay,
is
it
safe
to
summarize
that
the
current
PR
in
the
current
form
may
not
be
able
to
merge,
like
editors,
do
not
have
consensus
on
them
on
that,
however,
if
we
are
changing
the
solidity
version,
it
may
require
a
new
pull
request
to
change,
or
maybe
a
new
pull
request
can
be
sent
out
for
further
consideration.
D
Yeah,
it's
just
a
dangerous
thing,
making
sure
that
the
new
salinity
really
does
specify
the
same
thing
as
the
old
solidity
when
things
are
not
backwards
compatible,
and
there
is
no
formal
specification
for
solidity.
So.
A
A
So,
with
this
meeting
we
can
I
mean
I'm
trying
to
summarize
it
and
I
will
add
the
summary
to
this
agenda
only
for
whatever
we
have
discussed.
Obviously,
that
will
be
also
noted
in
the
notes,
but
for
this
particular
pull
request,
we
do
not
get
General
consensus
here,
however,
we
are
considering
updating
solidity
for
older
proposals
not
specific
to
eap20,
but
in
general.
D
I'm
not
saying
we
should
I'm
just
saying
there
is
an
issue
here
to
keep
in
mind
that
I.
Don't
it
there's
no
way
we
can
go
back
through
all
of
the
APS
and
update
their
solidity,
but
it
is
an
issue
and
especially
if
the
authors
of
an
EIP
feel
a
need,
but
it
it
doesn't
seem
right
to
alter
a
final
EIP
I'm,
just
pointing
out
there's
an
issue
and
it
may
take
a
new
IP
to
do
it.
We
may,
in
the
future,
want
to
to
separate
that
out.
D
D
Or
of
having
this
one
directed,
it's
it's
our
Panda
here
anyway,
is
he
on
the
call
you.
A
A
A
B
B
C
A
B
B
Problem,
the
only
change
is,
is
the
link
down
at
the
bottom.
D
D
It
they
can
find
it,
and
this
is
why
we
want
to
severely
limit
outside
lengths.
D
D
It
would
be
much
better.
It
doesn't
look
like
there's
much
of
anything
except
a
link
to
get
to
this
anyway,
but
I.
Don't.
D
I
mean
it
just
looks
like
yeah,
it's
just
a
it's
a
link
to
some
code
master,
that's
no
good!
The
master
keeps
changing
it.
It
should
be
linked
to
a
particular
commit
here.
We
still
hasn't
fixed
that
anyway.
Oh
no,
he
finally
has
a
blob
to
a
particular
commit
yeah
I
see
what
he's
trying
to
do
he's
trying
to
fix
an
old
mistake.
B
D
Okay,
I'm
sorry
I
didn't
review
this
sooner.
But
let
me
let
me
go
look
at
that.
D
We
have
a
concept
of
a
rata,
but
we
we
have
no
process
for
it
yeah,
so
it
it's
long
past
time,
perhaps
to
just
get
our
act
together
on
a
rata
and
then
we
can
and
we
can
handle
these
things.
A
D
D
So
I'm
just
I'm,
seeing
here
I
mean
it's
old,
so
things
aren't
broken
out
everybody's
got.
You
know
some
standards,
he's
referencing
I,
think
some
of
that's
actually
normative
some
issues,
various
discussions
and
the
others
clearly
not
normative,
but
a
lot
of
it
prior
art
that
he's
trying
to
trying
to
incorporate
either
directly.
D
B
C
D
B
A
This
for
this
PR,
if
you
can
maybe
leave
feedback
that
to
distinguish
between
normative
and
non-normative
links,
that
would
be
nice
if
Williams
or
the
author
responds
to
that
very
well.
Otherwise,
we
can
let
it
be
there
for
some
more
time
for
yeah.
A
All
right
with
that,
maybe
we
can
move
on
to
the
item.
Number.
Two.
Oh
sorry,
a
before
item
number
two:
there
is
one
last
or
final
EIP
related
discussion
needed,
which
is
for
pull
request,
number
5877.
A
This
is
again
a
very
old
proposal,
authored
by
vitalik
for
simple
replay
attack
protection.
B
So
is
this:
this
is
a
list
of
the
existing
chains
at
the
time
right.
B
It
probably
shouldn't
have
had
a
list
in
it
in
the
first
place
and
eips
are
not
the
best
place
to
maintain
lists
so
I'm
I'm,
just
gonna
close
this.
Unless
somebody
objects.
A
A
Moving
on
to
item
number
two.
This
is
part
of
continued
from
earlier
meeting
discussions
because
we
have
discussed
this
in
the
past.
However,
there
is
a
new
proposal
on
the
table.
It's
a
straw,
man
proposal
proposed
by
Victor
I.
Suppose
Victor
is
here.
If
you
would
like
to
maybe
summarize
your
proposal
and
yeah
people
can
share
their
thoughts
and
opinion.
F
Yeah,
so
the
idea
is
that
I
heard
from
various
authors
and
editors
that
there's
no
clear
nuclear
criterias
for
advancing
status.
Some
would
like
a
very
easy
way
to
go.
Go
through
to
get
to
final,
something
going
to
go
into
I
know
is
too
fast.
Something
going
to
find
out,
didn't
have
some
of
the
IP
didn't,
have
enough
consensus
or
demonstrated
interest
to
go
to
final.
F
So
this
is
an
attempt
to
to
formalize
what
it
means
as
a
criteria
for
each
status
and
the
Highlight
is
that
for
what
we
already
know,
core
of
obviously
required
client
implementations
and
imply
I
mean
I,
understand
the
implant
in
implied
level
of
what
it
means
to
client.
F
Implementation
is
multiple
client
implementation
and
getting
adopted
in
the
hard
Fork,
but
when
it
comes
to
erc's
network
and
interfaces,
there's
no
higher
requirements
and-
and
in
the
discussions
on
raised
concerns
that
if
some
VIPs
go
into
final
too
fast,
we
also
saw
things
like
EIP
7.17
12.,
and
that
was
like
going
into
final
status
prematurely.
It
has
a
lot
of
interest,
it's
being
widely
adopted,
but
it's
editorially
a
disaster.
F
We
all
I've
seen
that
I
also
recently
discovered
things
like
tweet
four
seven
five,
which
has
had
a
lot
of
editorial
issues,
even
after
the
it
passes,
does
the
final
so
just
want
to
kind
of
propose
something
that
people
can
agree
on.
F
F
F
The
other
thing
that
people
propose
I
heard
is
that
lower
bound,
which
I
think
poja
here
is
in
favor
like
some
of
recently
another
authors
in
the
same
thread
proposed
a
upper
Bell
which
is
deadline
to
move
to
the
next
step,
so
I
just
want
to
put
it
on
the
table
for
the
bring
it
up
to
the
attention
to
this
group
and
see
what
you
generally
are.
F
B
I
I
don't
want
to
add
any
more
requirements
that
make
it
more
difficult
to
get
an
EIP,
finalized
and
I.
Think
we
make
it
very
clear
that
final
is
not
an
indicator
of
adoption
or
or
or
or
use
or
quality
of
the
eips.
Like
technical
merits,
it's
just
a
statement
about
like
if
it's
going
to
change
or
not
and
I
think
adding
like
multiple
requirements
for
like
implementations
or
or
having
certain
levels
of
adoption
before
we
move
to
final
I.
B
Think
that's
that's
going
to
be
too
taxing
on
the
EIP
process
and
I.
Think,
like
what
benefit
is
it
going
to
bring
us
it's
going
to
bring
us
that
most
standards,
like
even
more
standards,
don't
make
it
through
the
process
and
just
sit
in
draft
or
in
review
for
longer
periods
of
time?
I,
don't
think
it's
going
to
help
anything
and
on
the
like
minimum
length
of
time,
but
between
changing
statuses,
I
think,
that's
I,
don't
know
it
just
seems
like
adding
delays
for
no
reason.
B
Maybe
we
need
to
do
a
better
job
as
editors
of
making
sure
that
sufficient
discussion
has
has
taken
place,
but
I
don't
think
a
Time
bound
is
going
to
change
anything
like
Eep
712
was
sitting
in
stagnant
for
years
and
it
still
ended
up
a
mess
like
I,
I
I.
Don't
think
a
time
limit
is
going
to
improve
anything
if
more
people
aren't
looking
at
it.
F
I
heard
the
same
says:
didn't
want
to
text
authors
more
or
completing
either
a
barrier
to
advance
the
final
so
that
we
don't
have
a
lot
of
VIP
laying
at
I'd
like
draft
Tour
review
status
yeah.
What
do
dragon
and
Matt
think.
E
I,
mostly
Echo
what
Sam
said:
I'd
really
think
that
we
spent
a
lot
of
time
trying
to
separate
the
concept
of
like
Readiness
for
from
eips
and
just
have
it.
You
know
moving
something
to
a
place,
that's
fixed
and
then
letting
like
the
Readiness
be
defined
outside
the
process.
So
I
think
this
is
a
regression
in
that
sense,.
F
Yeah,
how
about
Greg.
F
Yeah,
my
intention
is
not
just
to
react.
My
intention
is
not
thought
to
kind
of
propose
something
to
add
object
obstacles,
but
every
once
in
a
while
I
heard,
for
example,
editors
or
other
authors
comes
in
and
says.
Why
is
this
even
the
CIP
even
worthy?
That's
one
thing,
and
then
that
creates
a
lot
of
debate.
If
we
can
say
the
worthiness
is,
is
not
going
to
be
control
unilaterally
by
either
the
author
or
by
the
by
by
the
editors.
F
That
would
be
a
good
thing,
because
I
on
one
side,
I
worry
that
if
we
disallowed
authors
to.
F
To
to
propose
VIPs
and
then
they'll
be
like,
unless
you
guys
are
all
super
open
which
I
can
also
turn
into,
but
then
we
would
be
anticipating,
like
10
000
left
other
Humanity
10
000
of
VIPs
are
coming
in
and
I
doubted
to.
If
that
is
what
this
repository
wants,
and
the
other
thing
is
that
either
we
let
editors
single-handedly
or
as
a
group
decide
whether
an
EIP
is
at
worth
it.
F
It's
also
kind
of
placing
a
lot
of
Burden,
as
well
as
a
lot
of
single
subjective
bias
to
pip
editors.
Some
may
argue
that
how
about
we
look
at
the
thread
and
see
who
is
on
the
discussion
and
that's
still
very
subjective
and
therefore
the
worthiness
we
were
looking
trying
to
look
for
something
that
is
more
objective
in
determining
worldiness
Readiness
is
the
same.
F
We've
seen
interfaces
that
we're
not
even
compatible
in
Readiness,
and
then
it's
still
made
into
final,
and
so
that's
why
we
want
to
like
propose
some
of
the
implementation
requirements
to
at
least
make
sure
that
it
works.
F
Some
I
think
implied
like
one
of
the
eips
that
I
was
I,
interact
with
being
asked
by
an
editor
like.
Is
it
useful
or
is
it
Worthy
and
that
made
if
that
is
a
technical,
peer
and
feedback?
That's
fine,
but
as
an
editor
asking
that
might
imply
that
there's
a
gap
editorially
to
enter
an
EIP.
B
Yeah
so
I
think
you
know
asking
if
an
EIP
is
worthy
or
not
is
fine,
but
if
the
author
says
yes,
then
I
don't
think
any
of
us
will
stop
it
from
going
through
the
only
time.
I
think
we
would
stop.
It
is
for
eips
that
are
not
expected
to
have
multiple
implementations
that
have
to
like
interrupt
that.
That
is
I,
think
the
only
bar
for
worthiness
that
we
enforce.
F
B
Rotations,
it's
not
whether
there
will
be
or
won't
be
it's
whether
this
stand
like
whether
the
The
Proposal
standardizes,
something
that
would
have
multiple
implementations
like,
even
if
there's
only
ever
one
implementation
of
it
and
it's
by
the
EIP
author.
That's
fine!
If
you
standardize
it,
it's
it's
whether
or
not
like,
there's
the
expectation
that
somebody
else
could
come
along
and
make
another
compatible
implementation.
F
Well,
for
me,
it's
I'm
okay,
to
reduce
that
down
to
one
implementation,
I'm
more
in
favor,
of
having
multiple
one
but
I'm
I'm.
Okay,
I
think
it's
okay
to
require
at
least
one
but
We've
also
seen
eips
go
in
without
like
showing
or
without
having
implementations
and
finalized,
and
that's
what
I
felt
the
last
the
gap.
F
I
think
one
one
thing
could
happen
is
that
EIP
did
not
work
like
that.
That
specification
did
not
work
and
waste.
Editors
were
future
authors,
time
to
look
into
like
waste,
not
author,
but
why
implementator
implementers
time
to
look
into
right?
A
final
EIP
that
doesn't
work.
B
F
Yeah,
that's
that's
why
I'm
trying
to
like
I,
I,
I
I,
do
hear
the
sentiment
in
this
in
this
room
today
that
you,
you
don't
want
to
add
hurdles
to
altars
I
I'm
fully
in
in
that
I
I
love
to
have
authors,
be
more
easier
to
make
it
easier
for
them
to
propose
and
then
work
through
and
I.
Consider
myself,
mostly
an
author,
but
I
just
want
to
like
put
it
here
and
then
see,
maybe
six
months
from
now.
This
will
come
back
up
and
then
we
can
still.
F
We
can
continue
to
use
that
as
a
basis
to
discuss
what
kind
of
criteria
we
want
to
require
for
our
advancing
at
status
any
anytime.
Anyone
is
a
complain
about
why
something
goes
into
final,
too
fast
or
too
slow.
Maybe
we
can
use
that
thread
as
a
discussion.
How
can
we
better
improve
our
process
to
set
an
expectation
and
and
and
and
standards
for
something
to
be
expected
for
the
status
advancing
to
be
expected?
F
A
I
am
not
sure
of
any
EIP
so
far,
which
has
been
into
final
status,
and
it
was
like
not
working.
So
the
idea
of
standardizing
is
to
have
a
standardized
process
in
place
like
the
codes
in
place,
for
which
any
implementer
any
adapt
developer.
May
pick
up
that
standard
and
try
to
add
it
to
the
project
if
they
won't
want
to
integrate
that
concept
into
that
project
and
adding
too
much
boundaries
for
people
to
even
submit
a
proposal
to
become
a
standard
is
something
I
think
is
not
very
fair
to
them.
A
However,
I
am
open
to
the
idea
like
when
we
have
this
kind
of
examples.
We
can
probably
come
up
with
some
other
policies,
just
like
Sam
mentioned
that
if
we
can
have
finally
ipv
withdrawn.
So
if
we
found
like
if
we
come
across
a
proposal
which
is
actually
not
functional,
which
I
think
is
not
going
to
happen
because
multiple
eyes
are
there
on
any
proposal
the
moment
it
enter
into
a
pull
request
or
goes
to
a
fellowship
of
ethereum
magician.
A
So
that's
rare
of
rarest
case
that
a
proposal
could
get
into
the
final
status
and
for
that
we
should
not
increase
our
boundaries.
However,
I
am
into
favor
of
like
kind
of
defining,
not
defining
or
maybe
setting
hard
line
over
there,
but
a
general
idea
of
getting
more
discussion
into
discussion
thread
if
I
have
not
mistaken.
A
This
proposal
idea
may
have
been
fired
by
a
pull
request
that
I
found
for
a
meta
Eep,
which
is
currently
into
last
call,
and
it
would
be
finishing
its
last
call
under
30
days,
which
I
really
think
is
not
a
good
idea
for
proposals
under
Mata
category,
because
that
is
process.
Related
proposal
should
be
discussed
in
eipip
meeting,
so
we
can
think
of
something
around
like
how
we
can
increase
the
length
of
discussion,
but
not
hard
coding
that
length
of
discussion
onto
the
EIP
one
is
my
card.
Yeah.
B
We
have
started
the
the
peer
review
process
where
we
nominate
people
from
the
list,
so
I
think
that'll
help
a
little
bit.
A
F
A
It
just
comes
to
my
mind
that
the
period
of
14
days
definitely
gave
us
one
eipip
meeting
in
between
last
call
to
final
status,
I
mean
obviously
I
can
bring
it
up
in
the
meeting,
but
yeah
any
other
thoughts
on
there.
D
Yeah
I
I
agree
that
some
arbitrary
period
of
time
doesn't
necessarily
help.
D
There's
a
bigger
issue,
there's
a
bigger
issue
with
these
as
to
whether
we
really
should
have
an
implementation
before
it
goes
final
with
core
eips
by
the
time
it
goes
final,
it's
on
the
main
net
and
a
many
RC
is
a
lot
more
useful.
If,
if
there
isn't
an
implementation
and
people
know
it
works
yeah
for
ANSI
standards
work,
we
wouldn't
we
would
not.
We
would
not
accept
Library
proposals,
which
were
our
non-core
proposals
that
we
would
not
accept
them
without
it.
Well,
I
shouldn't
say
not.
D
F
Yeah
that
yeah
I
that's
what
I
felt
too
and
by
the
way
this
is
not
just
to
to
to
to
kind
of
add
hurdle
for
something
to
be
proposed.
This
is
just
adding
some
bar
for
something
to
finalize
and
just
to
make
one
to
make
the
distinct
Extinction
clear.
A
So
my
general
understanding
of
timeline
here
is
from
a
proposal
when
it
is
added
to
a
GitHub
repository
till
the
time
it
reaches
last
call.
Generally,
they
take
up
three
to
four
weeks
in
normal
cases
like
sometimes
there
are
a
lot
of
proposals.
It
takes
time
to
review
all
these
proposals
and
all-
and
on
top
of
that,
if
we
add
60
days
for
final
call,
I
mean
like
last
call
that
would
defining
the
length
of
any
meta
or
informational.
A
Eip
cannot
be
less
than
three
months
and
sometimes
if
the
initial
period
is
over
a
month
say,
for
example,
it
is
two
or
three
months
already
then
adding
additional
two
months
will
be,
like
maybe
author
may
lose
interest
in
pursuing
the
proposal,
and
that
will
stagnant,
and
even
if
it
is
a
good
proposal,
author
may
lose
interest.
A
So,
generally
speaking,
not
in
favor
of
setting
a
hard
set
boundary
over
there
of
60
days.
However,
yeah
I
think
the
process
that
was
discussed
in
the
last
meeting
of
peer
reviewer
and
adding
more
reviewer
would
be
good
idea
for
having
implementation
core
eips
follow
a
little
different
process.
So
we
can
just
exclude
that,
because
that
is
to
be
implemented
by
the
client
team
for
ERC
I.
Think
we
discussed
in
the
last
meeting
as
well
that
having
maybe
a
prototype
of
that
would
be
also
a
good
idea
or
yeah
having
a
strong
discussion
on.
A
F
I
agree
to
most
of
the
points
in
the
matter
of
waiting
for
60
days.
You
mentioned
that
the
author
may
lose
their
interest
in
pursuing
I.
Think
if
you're
proposing
a
matter
which
is
a
fact
not
not
to
say
those
old
matter,
that's
only
recording
the
hard
work,
but
then
in
in
the
in
the
late
latest
status.
We
use
mostly
use
beta
for
a
procedure
right
if
someone
propose
a
meta,
EIP
and
lose
interest
in
the
future
after
just
50
days.
F
F
Even
if
the
author
loses
interest,
the
matter
in
AIP
can
still
advance
to
final
right
if
they
get
into
the
last
call
sufficiently,
because
the
group
will
also
continue
to
take
on
and
just
finalize
it
just
like,
we
see
for
other
standard
eips
I
wouldn't
feel
too
uncomfortable
for
we
to
require
a
longer
waiting
period
of
time
for
people
to
give
feedback
for
MATA
for
information,
I
really
don't
care,
because
it's
non-bonding
I
even
think
oh
information
or
should
only
be
live
and
and
okay
to
have
subject
to
Future
change.
But
yeah.
A
Well,
we
are
very
close
to
time,
so
if
anyone
would
like
to
and
give
final
piece
of
thought
and
feedback
here,
we
do
not
have
any
pull
requests,
so
we
do
not
have
to
make
any
decision.
However,
we
do
have
a
discussion
thread
of
at
Fellowship
of
ethereum,
magician
and
Link
can
be
found
in
agenda,
so
people
can
definitely
add
their
thoughts
there,
but
yeah.
If
anyone
would
like
to
give
any
panel
piece
of
feedback.
C
A
So
I
think
we
can
continue
collecting
more
feedbacks
and
we'll
try
to
revisit
this
discussion
in
future
meeting
for
today's
meeting,
I
also
wanted
to
bring
another
issue
for
discussion.
I
know
we
don't
have
time
to
finish
up
the
discussion,
but
at
least
we
can
collect
initial
feedback
on
that.
So,
okay,
that
is
related
to
EIP
bot
I'm
skipping.
One
item:
I'm,
going
to
item
number
three
directly
request
section
that
we
discussed
briefly
in
the
EIP
editing
office
hour
so
for
for
required
section.
A
At
present,
the
eapw
bot
allows
final
stagnant
and
withdrawn
EIP.
My
proposal
here
is
that
withdrawn
EIP
may
be
removed
from
there,
because
a
withdrawn
EIP
may
not
have
a
necessarily
followed
throughout
the
steps
of
a
standardization
and
may
not
be
ready
to
be
to
be
an
EIP
which,
which
can
be
considered
for
dependency.
A
B
F
C
A
Think
the
last
one
yeah
I
think
yeah
anyway,
we
are
out
of
time.
So
I
have
added
the
issue
number,
it
is
6131.
Maybe
we
can
wait
for
more
thoughts
there.
If
nobody
objects,
then
hopefully
we
can
make.
This
change.
Is
that.
F
D
My
concern
here
is
that
one
author
can
pull
in
another
EIP
as
a
requirement
at
a
stage
like
if
they're,
both
in
draft
say,
which
is
not
a
problem
and
then
the
one
that
they're
referring
to
requiring
falls
into
stagnant
or
gets
withdrawn.
And
then
what
does
the
original
author
have
to
do?.
A
One
correction
I
would
like
to
mention
here
like
by
mistake:
I
said
the
current
eipw
allows
for
final
withdrawn
and
stagnant.
Actually,
it
is
final.
Living
and
withdrawn
stagnant
is
not
considered
in
the
first
place,
so
the
only
status
which
is
under
question
is
withdrawn.
Should
it
allow
withdrawn
in
the
required
section
or
should
not.
D
Well,
probably
not,
but
maybe
this
is
an
old
worry,
but
it
is
a
pain
if,
if
you
referred
to
another
draft
and
the
draft
slips
off
to
stagnant,
should
you
have
to
go
take
over
what
went
stagnant
and
make
it
a
draft
again
in
order
for
your
proposal
to
proceed,
foreign.
F
I
I
I'm
in
favor
of
letting
draft
and
review
status
as
we
as
flexible
as
possible
and
reference
anything
like,
even
if
it's
a
stagnant
work
or
or
I'm,
okay
to
ban
or
not
ban
which
one
but
I
think.
If
we
give
a
draft
and
review
bigger
flexibility,
that's
okay,
I
think
for
last
call
to
getting
into
last
call.
F
They
want
to
make
sure
that
the
required
the
required
EIP,
the
depending
the
depend,
EIP
being
depend
on,
should
also
be
in
at
least
last
call,
because
something
go
into
last
call
is
soon
to
finalize
and
should
be
treated
more
seriously
and
if,
at
that
point
something
still
either
stagnant
or
withdrawn,
the
author
should
feel
enough
either
remove
them
or
remove
the
requires
if
it's
not
a
high
dependency
or
be
motivated
enough
to
pull
and
take
over
and
then
drive
that
into
into
last
call.
A
I
think
that
would
be
too
much
of
hassle
for
editors
if
they
start
allowing
draft
and
review,
because,
as
Greg
was
mentioning,
that
there
are
chances
that
they
may
end
up
on
withdrawn
or
stagnant,
so
to
be
on
the
safer
side.
I
think
it's
a
good
idea
for
bot
to
allow
only
final
and
living
and
yeah
even
withdrawn
can
be
taken
out,
except
for
the
withdrawn
proposal.
F
Well,
I
think
what
I
said
is
you
for
Bots
to
not
even
complain
for
Drafting
and
reviews
like
for
if,
if
this
EIP
is
in
draft
status
or
yeah
S4
reviews,
so.
B
So
review
I
think
we
have
to
have
the
Restriction
because,
like
if
it's
in
the
requires
header,
it's
required
reading
like
it's
necessary
to
understand
the
current
EIP.
So
if
the
current
EIP
is
be
is
ready
for
review,
that
means
all
of
its
dependencies
also
need
to
be
ready
for
review
like
you
can't
review
an
EIP,
the
one
you're
looking
at
right
now,
if
it's
dependencies
are
still
allowed
to
change
freely
like
it,
they
have
to
move
in
in
somewhat
of
a
lock
step
here
like
for
draft.
D
And
yeah,
that
just
means,
if
you
want
to
move
out
of
draft
into
review,
yeah
you'll,
have
to
somehow
resurrect
what
what
slipped
out
of
what
slipped
out
of
draft.
But
okay,
I,
think
I.
Think
I
understand.
B
Cool
so
I
have
to
drop
off
sorry
guys,
but
thanks
for
coming
out
I'll
talk
to
you
soon,
yeah.
A
I
I
think
thank
you.
Everyone
I'm
not
sure
when
the
next
meeting
will
be
because
it
is
falling
on
vacation
time,
so
maybe
I
can
take
a
poll
or
ask
people
on
the
grip
and
see
if
we
would
like
to
keep
the
next
meeting
on
28th
or
in
January.
Well.
Thank
you.
Everyone
for
joining
have
a
good
one.