►
From YouTube: EIPIP Meeting 82
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/235
A
A
I
think
the
first
one
with
respect
to
patent
has
already
been
merged
before
this
meeting,
so
we're
gonna
mark
them
as
checked.
The
next
big
item
for
discussion
was
proposed
by
Matt.
I,
don't
see
him
here.
The
item
was
issue
with
auto
review.
Bot
I,
don't
know
if
anyone
else
here
has
any
update
or
anything
to
share
on
that
particular
topic.
A
If
not,
maybe
we
can
get
back
to
this
topic
when
Matt
joins
the
call,
if
today,
if
not,
then
we'll
bring
it
in
the
next
meeting.
A
Moving
on
to
the
next
item
listed
here,
which
is
issues
with
cl,
link
validation
and
this
issue
is
created
by
Tim
Bako,
and
we
briefly
discussed
this
also
in
the
EIP
iting
office
hour
yesterday.
B
So
the
issues
that
basically,
when
PR
people
draft
PR's
they
mentioned
to
request
and
since
we
allow
links
in
consensus,
specs
and
execution
specs,
so
the
expectation
is
that
PR
studies
Repose
should
be
allowed,
at
least
in
the
draft,
and
because
in
the
draft
there
is
a
straight
up
discussion
going
on
and
so
VMS
basically
cover
quite
the
number
of
files
number
of
files
as
well.
As
you
know,
there
was
yesterday.
B
We
also
discussed
that
if
there
was
a
possibility
of
putting
the
commit
link
of
the
PR,
but
even
that
there
is
an
issue
that
commitment
generally,
if
you
got
from
GitHub,
it
belongs
to
the
serves
repository
so
which
this
even
will
not
be
concerned.
Suspects
or
execution.
Specs
and
again,
you
know
commit,
can
be
pruned
out
or
run
the
bad
smells
in
the
main
level.
Even
then,
the
commits
a
new
commit
would
be
created,
a
special
effects
crash
and
special
message.
B
So
basically
the
idea
is
to
allow
request
for
drafts
here
and
then
basically
you
know
if
on
the
review,
then
there
has
to
be
a
static
blog
that
points
to
these
repose.
C
C
A
A
So
it
looks
like
there
is
a
one
Comet
related
like
a.
We
can
have
a
specific
comment
added
to
the
EIP
documentation.
Does
anyone
disagree
with
that?
Like?
Can
we
have
it
or
do
we
want
to
go
ahead
with
to
do
things.
A
A
D
Oh
my
concern
with
allowing
links
in
draft
and
then
forcing
people
to
remove
them
if
they
go
to
review
it's
kind
of
two
things,
so
things
stick
and
draft
for
a
lot
longer
than
they're
supposed
to
so
that's
a
common
problem
and
the
other
one
is
that
it
might
hold
proposals
from
going
to
review
when
they
would
otherwise
be
ready
to
do
so
if
the
pull
request
hasn't
been
merged
yet,
but
I
think
there's
a
relatively
minor
concerns.
D
I
I
do
worry
that
adding
these
like
relaxations
for
draft
proposals
will
be
will
lead
to
more
of
the
similar
things.
But
you
know
we
can
cross
that.
F
I'm
generally,
in
favor,
of
allowing
this
allow
pull
request
in
the
draft
status.
B
So
basically
allow
referring
to
your
circumstances,
specs
and
execution
specs
in
in
the
draft
erps.
So
once
they
have
to
move
to
review,
then
we
require
them
to
have
primary
links
rather
than
PR
links.
C
B
So
things
PR
by
dipline,
which
basically
refers
to
a
PR
and
Tim,
also
has
created
an
issue
where
he
basically
runs
that
one
can
refer
to
pairs
for
draft
erps.
C
B
I
think
so
I
mean
they
do
that
to
that
particular
proposal
that
matching
two
content
suspects
is
like
doing
it,
taking
it
to
final
status
and
I
mean
basically
putting
draft
accepting
drafting.
It
means
that
you
know
it.
It
is
to
be
discussed
and
among
the
peers
and
all
that
right,
so
basically
merging
to
consensus.
Specs
and
accepting
in
draft
in
my
opinion,
are
two
different
things.
C
B
That's
the
point
that
okay
for
drugs,
at
least
we
can
allow
it
and
obviously
post
craft
for
the
review
status.
It
has
to
be
a
proper
blah
blink
prospects
or
a
directory
from
there.
So
so
the
point
is
to
relax
for
draft
so
that
it
can
easily
help
in
discussion
and
all
that.
C
C
G
C
D
D
F
So
I
I
think
I
I,
don't
know
why
you
are
objecting
to
that
I.
Think
if
you
maybe
you
help
me
understand
it
better.
If
the
goal
is
to
disallow
link
because
the
link
can
be
disappearing
then
linking
to
a
commit,
it
can
also
disappear
if
it's
not
fully
merged
right,
if
not
it's
not
merged
in
the
master.
Basically
I.
D
There's
definitely
like,
like
I,
said
in
the
comments,
I
think
there's
a
whole
other
class
of
problems.
We
need
to
think
about
there
like,
at
least,
if
you
have
the
commit
hash,
you
can
verify
that
what
you
have
is
what's
linked
to
in
the
commit
or
in
the
EIP
but
yeah
the
availability
is,
is
definitely
a
concern.
There.
F
Yeah,
but
you
can't
guarantee
that
anyway
and
then
we're
talking
about
draft
right.
D
F
I
think
so,
if
we
understand
it
correctly,
salmon
matches
disagreeing
and
then
their
gender
and
Gavin
and
I
are
agreeing.
We
should
we
put
that
in
on
hold
with
and
revisit
under
certain
circumstances.
Or
do
we
call
that
a
a
consensus
already.
G
G
He's
then
he's
not
linking
to
something
which
is
in
fact,
what
he
needs
to
link
to.
The
alternative
is
tell
them
you
can't.
You
can't
put
the
draft
in
until
the
consensus
spec
corresponds
to
what
the
draft
is
depending
on.
F
D
Yeah,
but
so
if
you
link
to
a
pull
request-
and
somebody
reads
the
EIP
at
that
pull
request
like
like
they
read
that
EIP
today
and
then
the
pull
request,
completely
changes
purpose
and
does
something
else.
Then
what
you
reviewed
when
you
read
the
EIP,
isn't
what
is
getting
like
implemented?
They
don't
match
up.
B
I
think
we
we
can
allow
for
campaign
lengths
so
that
you
know
that
this
does
not
really
change
so
so
we
so
it
seems
like
that
consensus
spec
will
have
the
commit,
as
Sam
already
mentioned,
in
the
comment.
So
now
what
what
we
are
a
person
can
do
is
he
can
basically
generate
a
complete
link
that
will
you
know
this,
would
a
source
comment
and
the
target
commit,
and
that
will
not
that
will.
That
is
that.
That
is
a
static
one,
so
that
should
both
it
should
just
give
the
diff.
E
G
We
have
an
execution
layer
proposal
or
if
we
have
a
consensus
layer
proposal
that
depends
on
the
other
layer.
The
proposals
you
know
pretty
much
have
to
go
in
together,
but
you
know
to
say
that
we
can't
actually
link
from
one
to
the
other
until
there's
a
full
PR
ready
to
go,
makes
it
difficult.
You
know
pretty
much.
They
can't
both
go
to.
They
can't
both
go
to
final
until
it's
together,
and
so
both
of
them
are
actually
in
a
sort
of
limbo.
G
So
I
just
don't
see
a
choice
in
draft
stage
and
I
think
think
it's
more
useful
to
be
able
to
point
to
that
commit,
and
yes,
during
the
draft
stage,
if
that
commit,
is
no
longer
relevant.
If
the
consensus
group
says
no,
there's
no
consensus
on
this.
E
D
A
As
an
alternative
here,
I'm
just
wondering
like
if
we
allow
this
thing
like,
even
if
the
pr
is
not
merged,
be
there
in
the
draft
form,
but
we
can
design
the
bot
if
we
can
update
the
bot
in
a
way
that,
when
the
proposal
is
moved
from
draft
to
review,
make
sure
that
pull
request
has
merged.
A
So
we
do
not
end
up
and,
like
you
know,
reviewing
the
proposal
all
over
again
when
we,
when
it
reaches
to
last
call
or
final
and
generally
speaking
when
it
is
a
core
proposal
that
is
there
for
last
call
when
it
gets
into
test
net
phase
right.
So
if
we
can
update
our
bot
at
the
time
of
a
status
change
of
review,
what
do
people
think
about
that?.
A
So
maybe
we
can
think
of
like
do
we
have
like
enough
support
for
that
or
do
we
have
someone
strongly
opposing
to
that.
F
I
think
that
that's
generally
okay,
for
you
have
having
a
bot
if
I
understand
you
correctly
you're
suggesting
that
if
there's
a
bar
that
can
help
safeguard
that,
that
would
be
good
I'm
in
favor.
Of
that
too.
I
just
think
that
there
shouldn't
be
a
blocking
me
requirement
before
this
get
implemented
in
the
process.
A
See
a
comment
and
no
more
Bots
but
I
would
like
to
understand.
Is
it
possible
with
eipw.
D
B
D
Yeah,
it
has
like
the
semester,
two
or
three
dots
and
I,
don't
ever
remember
which
and
then
the
command.
C
D
Yeah
that
would
work
yeah,
I'm,
okay,
allowing
links
like
that
I'm,
okay,
allowing
links
to
just
the
tip
of
the
pull
request.
Those
are
both
fine
as
long
as
it
has
a
commit
hash
in
the
URL
I'm
perfectly
fine
with
it.
F
That
sounds
like
consensus.
A
Right
so
as
a
summary,
we
can
state
that
links.
Tuple
requests
are
allowed
under
12
circumstances
when
it
is
tip
of
the
commit
and
when
it
includes
a
diff
and
commit
hash
together,
but
again
just
for
authors
to
be
aware
of
that,
there
could
be
a
bot
check
when
status
is
changed
from
draft
to
review.
D
Yeah
I
think
we
still
wouldn't
allow
links
to
a
pull
request,
but
that's
a
technicality.
It
would
just
be
you'd
link
to
the
commits
in
the
pull
request,
but
yeah.
D
Yes,
it
is
that,
like
it
is
a
problem,
but
it's
a
separate
problem,
whether
we
we
solve
but
by
having
a
backup
of
the
the
those
repositories
with
those
commits
specifically
or
something
else,
but
like
at
least
right
now,
it
is
possible
to
write
a
verifiable
backup
of
the
each
repository
if
we
want.
G
It
seems
we
can't
really
solve
these
problems
until
we
solve
the
issue
of
how
to
reconcile
the
consensus,
specs
and
the
execution
specs
it.
If
we
pull
the
consensus
specs
into
the
EIP
process,
it
gets
a
lot
easier.
G
A
Hopefully,
we'll
get
there
too
very
soon
right
now,
we
do
not
have
exact
process
for
consensus,
packs
moving
with
the
EIP
process,
but
yeah.
E
A
If
anyone
could
maybe
write
the
response
or
the
summary
for
this
particular
action
item
in
the
issue,
so
that
issue
can
be
closed
or
if
all
quarter
would
like
to
discuss
it
in
codep
meetings
they
get
to
know.
What
is
the
consensus
here
with
respect
to
this
particular
issue,.
G
A
G
D
I
I
think
the
consensus
outside
of
the
EIP
editors
is
to
not
pull
the
processes
together
any
more
than
they
already
are.
G
Well,
this
is
one
of
the
problems
that
one
of
the
problems
created
by
trying
to
by
trying
to
treat
you
as
completely
separate
I
I-
don't
like
that,
but
so
it
goes.
A
Maybe
that's
an
issue
for
another
time.
When
we
get
like
a
strong
support
in
that
and
we
have
a
proposal,
we
can
bring
it
in
the
eipib
meeting.
A
So
I'm,
taking
that
gajinder
Singh,
will
be
responding
to
that
issue
that
so
that
the
issue
can
be
closed
and
will
also
write
a
comment
to
the
respective
pull
request
with
the
eips
all
right.
So
that's
all
about
it.
Moving
on
to
the
earlier
item
that
we
missed
when
lightline
was
not
here
so
just
want
to
briefly
check
on
that
is
the
issue
with
auto
review
bot.
Where
are
we
with
that,
and
do
we
have
a
solution,
or
do
we
get
to
know
why
that
was
not
working.
A
This
is
about
the
auto
review
bot,
not
the
number
one.
So
did
you.
D
A
Okay,
oh,
they
are
the
same
one:
okay,
perfect
okay.
So
the
error
that
we
received
I
mean
that
was
mentioned
in
the
Discord
chat,
was
because
of
this
review.
Bot.
E
D
A
C
A
Moving
on
to
the
next
item
here
that
is,
ERC
is
a
status
advancement
criteria,
I
suppose
this
was
proposed
by
Victor,
but
before
that
I
just
read
a
comment,
as
I
mentioned,
that
he
may
have
to
take
off
in
in
few
minutes.
Anything
specific
Sami
would
like
to
discuss.
No
I
I
see
a
proposal
which
is
there
in
final
status,
like
the
proposal
is
already
in
final,
and
there
isn't
some
update
for
that
proposal
to
be.
You
know
some
some
specific
changes
for
that
proposal
and
the
peer
number
is
7077.
A
Okay,
okay,
then,
let's
go
sequentially
coming
back
to
the
proposal,
ERC
status,
advancement
criteria,
Victor!
If
you
would
like
to
briefly
explain
what
is
the
concern
here
and
what
are
we
looking
from
EIP
editors
group.
F
Yeah,
thank
you
so
I
have
this
presentation
and
and
hopefully
that,
if,
if
you're
not
at
your
screen,
that's
fine
too
I'll,
just
verbally,
also
explain
so
generally
we're
talking
about
a
proposal
for
formalize
how
ERC
Advance
status,
because
currently
it's
pretty
subjective
to
my
opinion
and
then
it
also
reduces
the
chance
that
we
are
capable
of
of
scale
scale
up
our
reviewer
tech
review
or
editor
review
queue.
F
So
the
general
goal
is
to
kind
of
find
what
we
have
in
consensus,
how
status
advance
and
then
we
can
so
that
we
can
make
it
better
so
and
less
arbitrary
and
just
want
to
mention
that
the
the
prior
art
that
we
have
is
that
core
EIP
require
adoption
to
finalize
and
also
VIP
and
pep,
both
that
we
that
EIP
has
been
inspired
by
requires
adoptions
to
finalize.
F
It
seems
a
common
practice
to
require
adoptions
to
finalize
and
also
it
helped
us
generally
kind
of
testy
implied
requirements
whenever
we
make
it
allow
the
ERC
to
advance,
which
is
soundness
and
usefulness.
I
I
I
generally
personally
apply
that
whenever
I
am
an
author,
I
don't
apply
those
requirements
when
I'm
an
editor
for
guarding
the
status
but
like
as
a
community
member
as
an
author
I
would
assume.
F
Soundness
is
a
lot
of
time
what
people
look
for,
and
so
also
to
mention
that
it's
interesting
that
I
am
doing
doing
some
research.
Not
only
PP,
is
doing
requiring
reference
implementation
to
be
completed
and
to
be
finaled
and
our
core
EIP,
of
course,
I.
The
rfcs
are
also
doing
it.
So
if,
if,
if
there
is
any
argument,
I,
that's
hey
erc's,
requests
for
comments
and
then
they're
different
from
the
other
eips
that
needs
the
heart
for
the
Korea,
a
hard
work
or
anything.
F
So
it's
interesting
that
RFC,
which
is
what
ERC
is
inspired
by,
also
has
similar
requirements
where
proposed
standard
in
their
case
and
seems
to
be
strapped
in
our
status
that
require
no
reference
implementation,
but
basically
required
design
choices,
resolved
and
then
also
desire
that
desirable
instruction
argument
for
the
for
the
proposal
and
the
draft
in
their
case,
which
is
I,
see
in
our
case.
F
There's
reviews
require
at
least
two
independent
and
interoperable
implementations,
and
we
need
the
when
it
needs
to
be,
and
it
needs
a
significant
implementation
and
successful
operational
experience
to
become
a
internet
standard,
and
so
the
goal
the
The
Proposal
here
is
that
we
require
at
least
no
requirement
for
a
draft
but
require
one
implementation
to
move
to
review
and
I.
Don't
know
two
or
three
independent
information
to
last
call
and
it
it's.
It's
I
understand
that
like
how.
F
How
does
it
call
Implement
independent
is
difficult
but
like
at
least
have
two
or
three
implementations
for
it
to
be
standardized
would
be
something
interesting
to
me.
My
question
now
for
the
editor
and
everyone
who's
on.
The
call
is
that
how
much
should
we
require
how
much
implementation
should
we
require,
if
at
all,
and
should
we
use
status
or
should
we
create
something
different
like
I
know
that
internet
IFC
use
maturity,
so
we
can
either
use
the
status
or
we
can
use
a
different
thing.
So
these
are
the
two
questions.
F
I
think,
to
begin
with,
we
can
I'll
be
happy
to
review
that
and
I'm
sure
that
it
can
be
a
very
clear
week
like
it
can
be
a
very
clear
ask
if
we
want
to
ask
the
technical
peer
reviews.
As
long
as
we
have
a
clear
ask,
so
I
wouldn't
worry
too
much
about
that.
F
I
I
do
understand
and
I
agree
with
you
that
the
the
mandates
to
to
review
the
to
to
validate
that
a
reference
implementation
exists
is
a
is
over
a
more
overhead
work
for
either
the
editor
or
technical,
peer,
reviewers,
I
I,
believe
that
could
be
solved
if
we
have
a
clear
boundary
of
what
what
two
review.
F
Yeah
I
also
any
other
comments
or
questions.
D
G
Basically
looks
pretty
good
to
me,
you
know
a
few
details,
but
I
just
don't
see
any
huge
problem
with
it.
G
G
If
we're
pretty
much
I
think
that
means
it
runs
on
the
main
net.
There
should
be
test
cases
at
some
level
in
the
EIP.
So
if
it
runs
on
the
main
net
and
passes
the
test
cases,
it's
an
implementation.
F
I'm
taking
notes,
thank
you
Greg.
E
F
And
just
also
mentioned
that
I
think
past
taste
case
is
a
great
idea.
I
love
that
so
I
incorporate
it
in
The
Proposal.
One
thing
that
I
really
like
what
Sam
was
doing
for
wallet
is
that
the
proposed
a
test
suit
for
the
compliant
wallet
and
that
basically
reduces,
or
at
least
increase
the
scalability
for
verifying
compliance.
F
I
also
yeah
I
also
see
that
Matt
is
responding.
That
three
seems
too
high.
D
So
you
were
saying
earlier
that
if
a
reference
implementation
exists
and
passes
the
test
cases,
so
does
that
mean
we
need
to
run
the
test?
Cases
against
the
three
reference
implementations
is
that
what
asses
editors
are
going
to
be
doing.
F
So
we
can
shift
the
burden
to
the
burden,
proof
to
the
author
to
say,
hey
and
then
I
to
my
understanding,
they're
more
than
happy
to
do
that
which
is
hey.
These
are
the
you.
F
You
probably
want
to
also
verified
the
implementation,
and
by
doing
so
you
can
either
manually
verify
them
or
you
can
create
test
cases,
so
your
compliant
can
run
it
against
them
and
I
think
the
compliance
where
the
adopters
probably
want
to
have
some
formal
test
cases
as
well,
so
that
it
reduces
their
overhead
of
like
manually
checking
whether
they
comply
or
not,
that
just
a
little
bit
of
overhead
but
I,
think
technically.
That
makes
everything
scalable
and
make
everyone
happier
so.
D
I
I
don't
want
this
to
sound
harsh,
but
it
really
just
sounds
like
you're
saying
we
want
authors
to
ask
chat
GPT
to
rewrite
their
reference
implementation
three
times
and
then
that
that's
it
because,
like
there's
no
I
mean
obviously
this
will
work
for,
like
you
know,
good
faith
authors,
but
someone
who
just
wants
to
get
their
proposal
in
will
just
make
three
different
reference:
implementations,
upload
them
on
three
different
GitHub
accounts
and
then
that's
it.
Their
proposal
will
continue
right.
F
D
F
I
think
here's
what
I
think.
First
of
all,
you
can't
even
like
the
alternative
is,
don't
we
don't
require
it,
which
then
we
relinquish
our
ability
to
even
verify
ex
any
reference
implementation
exists.
So
having
requirement
for
reference,
implementation
or
adoption
is
no
worse
in
than
current
scenario.
So
that's
the
first
thing,
and
the
second
thing
is
that
we
do
understand
that,
like
in
a
if
we
treat
it
as
a
security
problem,
sure
it's
hard.
F
You
can't
like
completely
rule
out
the
chance
of
sebo
attack
in
this
case,
but
a
lot
of
authors
are
reputable
and
then
a
lot
of
people
who
deploy
smart
contract
have
track
records
on
chain
which
is
not
too
hard
to
spot
a
problem
and
like
completely
hiding
the
the
track
from
it
is
almost
is
also
very
hard.
So
I
wouldn't
kind
of
think
of
that
as
too
much
of
a
of
blockage
for
adopting
this
as
a
procedure
requirement,
I'm.
F
So
the
general
motivation
is
to
find
a
social
consensus
of
what
it
takes
to
advance
ERC
status,
because,
alternatively,
currently
I
feel
it's
a
little
bit
too
arbitrary
and
I.
Don't
want
to
tell
the
Erp
authors
that
hey
so
long
as
you
don't
have
links
in
your
erc's
and
you
you
comply
with
all
formats,
and
so
long
as
one
of
the
editors
in
are
happy.
We're
allowing
you
to
advance
to
final.
F
What
I
really
want
is
to
make
this
process
less
arbitrary,
where,
given
the
the
scenario
of
any
editors
or
any
good
face,
Common
Sense
editors
would
be
able
to
make
similar
judgments
so
that,
now
that
we
have
seven,
we
can
advance
to
like
more
people
in
the
future.
Like
with
similar
and
approach
like
we
call
earlier
what
we
call
them
technical
reviewers.
F
What
do
we
create
separate
roles
for
that?
That's
fine
but
like
having
a
subjective,
more
or
less
subjective
criteria
for
advancing
them
is
the
goal
and
can
help
scale
up
all
the
EIP
reviews,
but.
C
F
By
if
I
started
to
like
allow
the
very
basic
rule
rule
of
current
leaders,
basically
no
requirements
for
ERC
to
advance
right.
F
F
So
that's
that's!
That's
what
I
I
want
to
propose
to
make
ercb
like
you
spent
so
much
time
discussing
how
to
disallow
links.
F
I
think
if
they're
more
important
things
to
make
ERC
really
works
and
they're
really
useful,
and
then
we
do
seem
every
once
a
while.
The
question
comes
up:
hey
is
this
ERC
useful
at
all,
or
should
we
reject
them
or
not?
F
But
given
the
standard,
if
we
are
approaching
approaches
so
long
as
authors
show
up
and
Advance
their
ER
status,
then
that
question
should
not
come
up.
I
presume
there's
some
implied
social
consensus
that
we
require
soundness.
We
require
usefulness,
but
I
don't
know
if
that
is
your
consensus,
like
can
I
throw
meaningless
thing
on
ERC
draft.
D
So
the
only
two
things,
the
only
two
things
that
I
review
for
are:
does
it
meet
a
minimum
bar
of
like
you?
Different
parties
need
to
communicate
with
each
other,
so
that's
kind
of
like
the
the
absolute
minimum
bar
for
making
a
standard
is.
Are
there
going
to
be
multiple
implementers
or
multiple
consumers
of.
E
D
D
F
I
think
that's
pretty
subjective,
if
you
anytime,
like
I,
can
anyone
can
show
up
like
just
like
use?
I'll
play
The
Devil's
Advocate,
just
like
you
said
anyone
can
just
do
chat,
gbt
three
times
or
and
Implement
them.
They
can
very
well
just
argue
on
their
ERC
says:
hey.
We
are
three
of
us
and
then
we
need
to
communicate
with
each
other,
and
then
here
is
the
ERC,
so
that
renders
that
that's
the
same.
That
applies
the
same
to
yourself.
F
F
I
think
that's
yeah,
I
think
I.
Think
that's
I
I
hear
you
I
hear
that
you,
you
think
that
so
long
as
they
want
to
communicate
themselves,
they
can
and
I'm
just
going
to
feel
that
it's
very
it's
not
demonstrating
soundness
and
usefulness
as
as
far
as
I'm.
D
Concerned
yeah,
so
I
think
the
real
problem
you're
trying
to
solve-
and
you
know
forgive
me
for
speaking
for
you
here,
but
is
you
want
to
improve
the
reputation
of
erc's
like
the
process
itself
right?
You
want
erc's
to
meet
a
higher
bar
than
they
currently
meet
so
that
people
trust
ercs
more,
whereas
I
I
would
like
to
keep
erc's
like
we
just
publish
whatever
people
send
us
for
the
most
part,
and
other
people
have
to
decide
the
quality
and
I
think
that's
the
root
of
our
disagreement.
Is
that
roughly
correct.
D
D
Requirements
formatting
of
the
documents-
those
are
all
things
for
like
they
are
for
the
process
itself
like
we
want
to
guarantee
availability,
but
we
don't
guarantee
soundness.
So
we
we
choose
what
we
we
guarantee.
I
think.
F
So
yeah
I
I
think
if
you
lay
out
that
you
think
that
ERC
can
be
meaningless
or
the
meaningfulness
is
where
reader
generator,
who
don't
necessarily
adopt
them,
who
don't
necessarily
use
them
to
to
judge
where
I
generally
believe
that
in
erc's
needs
to
be
adopted
to
be
meaningful.
G
I
would
be
happy
enough
to
see
a
requirement
for
one
implementation
and
test
cases
to
get
from
after
it's,
not
the
editor's
job.
To
actually
doing
the
implementation
could
be
wrong.
It
might
not
actually
pass
the
test
cases.
It's
the
review
process
that
that's
that's
part
of.
G
B
G
Sorry,
team
teams,
teams
don't
really
want
to
implement
something.
That's
not
already.
You
know
a
standard
or
close
to
it.
It
yeah
it's
just
a
lot
of
work
for
no
purpose,
so
you
could
have
a
group
of
10
people
who
say
yes,
we
really
want
to
do
this
and
here's
our
implementation
and
telling
them
go
find
two
other
groups
to
implement
it.
F
Yeah
I
I
see
I,
hear
that
you
you,
you
are
happy
to
see
one
implementation
and
you
don't
well.
You
think
it's
too
high
to
ask
for
multiple
implementations.
F
Is
it
okay
that
we
say
that
having
one
implementation
from
draft
to
review
is
consensus?
And
then
we
don't
have
a
consensus
about
what
it
take
to
move
to
review
to
last
call.
D
I'm,
more
okay
with
requiring
one
but
I'm
I'm
I,
guess
I'm
not
strongly
objecting
to
requiring
one
but
I'm,
not
in
favor
of
it.
F
Okay,
okay,
yeah
sounds
good
and
I
saw
that
Matt
says
three
for
last
call
is
too
high.
Not
you
have
any
concerns
for
for
requiring
one
from
preview
to
from
draft
to
review.
C
E
C
E
C
Merging
this
to
review
and
if
the
person
says
that's
not
an
eip1
or
I,
don't
want
to
do
that
for
some
reason,
then
just
let
them
go
through.
F
E
E
A
I
think
if,
if
we
want
to
go
ahead
with
that,
it
would
be
better
to
be
reflected
in
eip1,
but
we
can
also
maybe
learn
more
about
it
by
if
you
can
create
a
pull
request
there
and
see
if
there
is
any
strong
objection
to
that,
because
this
discussion
is
here
in
the
closed
room
when
we
have
a
pull
request
open,
probably
people
will
come
and
add
more
feedbacks.
G
G
The
quality
of
Steve's
and
it
will
help
with
just
the
sheer
number
of
them-
we've
been
trying
to
deal
with
and
certainly
be
a
better
solution
than
splitting
the
repos
and
other
such.
A
All
right,
so
we
are
at
time.
Thank
you,
Victor,
for
sharing
this
I
hope.
The
recording
of
This
will
be
helpful
for
people
to
follow
the
discussion
as
well
as
why
we
are
reaching
to
that
kind
of
consensus,
and
when
we
have
the
pull
request,
we
can
probably
take
it
from
there.
A
We
have
just
one
minute
left.
I
would
like
to
have
attention
of
editors
for
the
pr
number
7077
what
people
think
about
getting
it
merged.
A
D
I
think
I'm
fine
with
it.
It's
just
formatting
changes
and
moving
a
bracket
to
a
new
line.
Yeah
I
don't
have
a
problem
with
it.
A
A
Oh,
it
would
okay,
perfect
cool,
so
I
will
add
that
in
the
summary
as
well.
Thank
you.
Everyone
for
joining
and
I
have
added
the
month
summary
for
EIP,
editing,
sorry
eibs
inside
we
don't
have
time
to
go
through
it,
but
people
can
check
the
link
added
here
in
the
agenda.
Thank
you.
Everyone
for
joining
us
here
today,
I
hope
to
see
you
in
two
weeks
have
a
good
one.
Everyone.