►
From YouTube: EIPIP Meeting 88
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/257
A
Welcome
to
eipip
meeting
88,
we
have
shared
agenda
in
chat,
which
is
issue
number
257
on
eipip
GitHub
repository.
Thank
you,
everyone
for
joining.
We
will
go
ahead
and
start
with
our
agenda
item
and
the
first
one
here
is
to
discuss
open
issues
and
priyas.
We
will
also
discuss
issues
from
the
past
that
are
ongoing.
Discussion
will
have
a
look
at
the
monthly
Insight,
a
brief
of
EAP
editing
office
hour
and
anything
else.
Anyone
would
like
to
share
or
discuss
today.
A
So
starting
with
the
very
first
item
under
which
we
have
the
first
one
listed
here,
is
placing
a
warning
on
erc20
I
know
this
was
recommended
by
Sam
Wilson
Sam.
If
you
would
like
to
provide
an
overview
on
what
this
is
all
about,
sure.
B
I
wouldn't
say:
I'm
recommending
this,
but
I'm
the
one
who
put
it
on
the
agenda.
B
B
C
Yeah
I
noticed
he
was
also
like
trying
to
get
in
touch
with
the
foundation
through
us,
and
things
like
that
and
yeah
I
think
you,
you
sort
of.
Let
him
know
that
he
was
talking
to
the
wrong
people,
but
he
should
be
talking
to
core
devs
and
contacting
the
foundation
directly
with
some
of
these
issues.
C
D
Right,
I
I,
so
my
view
on
this
is
that
the
rc20
is
definitely
as
that
caveat
and
that
is
by
Design.
D
Finding
the
right
place
to
show
the
the
warning
is
something
that
I
felt
slightly
leaning
towards
in
favor
of,
but
I
also
think
in
a
larger
scope.
In
a
larger
context,
we
should
start
to
think
about
how
do
we
allow
proceeds
allow
supersedes
or
how
do
we
allow
newer
best
practice?
D
For
example,
like
the
internet
standards
like
rfcs,
they
will
say
this
RFC
is
superseded
by
the
other
one,
and
also
they
will
have
a
number
for
Best
Practices,
so
they
will
actually
refer
to
best
practices
in
those
cases
and
for
standards.
That's
important
like
the
erc20.
Maybe
it's
a
play,
a
good
place
and
good
example
for
us
to
discuss
EIP
editors
and
ERC
editors
group
as
a
whole.
How
do
we
harness
and
QA
this
practice
of
continuing
to
improve
we've?
Seen
this?
D
We
also
seen
the
caveats
in
the
how
the
approval
was
made
right.
Initially,
erc20
was
designed
to
set
up
specific
approval
approval
limit.
However,
most
of
the
exchanges,
these
decks
require
a
very,
very
high
or
almost
unlimited
approval
when
they
actually
use
that,
like
uni
slot
permit
2.
those
are
prac
what
we
see
in
practice
and
then
I
think
of
a
good
starting
point
for
us
to
discuss.
How
do
we
talk
about
Improvement
of
standards
and
how
do
we
direct
people
to
use
newer
and
better
Backward
Compatible
versions?
So
that's
my
view.
D
A
E
Yeah
thanks
for
that,
I
I
tend
to
agree
that
some
form
of
update
or
a
Rada
should
coexist
with
the
immutability
of
a
final
one.
E
An
author
should
be
able
to
say,
like
please
see
this
later
informational
EIP,
that
some
of
us
also
wrote
that
wrote
this
EIP
sort
of
like
best
practices,
like
you
mentioned,
like
linking
to
a
later
document
that
nuances
that
are
caveat
that
or
give
the
implementation
guidance
or
something
because,
like
super
session
sort
of,
implies
a
technical
thing
being
replaced
by
an
a
newer
technical
thing,
with
Legacy
support
for
whether
to
proceeding,
but
like
just
a
newer
document
that
just
describes
problems
not
foreseen
at
the
time.
It
went.
Final
is
a
different
speed.
E
F
Yeah
I
think
we
I
mean
there's
like
two
issues
here:
should
these
be
allowed
in
in
general
and
in
this
one
a
particular
should
it
be
allowed
I
think
there
needs
to
be
some
sort
of
standards.
I
think
I
I'm
personally
opposed
to
putting
a
warning
on
erc20
for
this,
because
it
amounts
to
user
error
and
I.
F
Think
that
should
be
considered
part
of
the
warning
one
that
I
could
get
behind
was,
let's
say,
hypothetically,
there's
a
break
for
the
Blake
too,
for
the
Blake
2
hash
function
that
you
know
something
is
cryptographically
broken,
that's
worthy
of
a
warning
on
an
ERC
or
an
EIP,
but
something
that
is,
you
know,
practice
and
use.
B
So
what
are
the
big
problems
with
these
kind
of
warnings
and
additional
notices
and
I?
Think
that's
one
of
the
reasons
we
don't
have
them
so
far.
Is
that
who
has
the
authority
to
make
these
claims
so
like?
Let's
say
that
I
don't
know,
Blake
two
is
broken.
B
How
do
we
verify
that
it's
broken,
and
how
do
we
verify
that?
Adding
that
information
is
you
know
correct
and
maybe
for
for
Less,
black
and
white
things
like
this
erc20
there
are,
you
know,
fungible
token
standards
that
don't
let
you
send
tokens
to
contracts
that
don't
support
it,
so
they
fix
that
whole
class
of
user
errors.
B
But
you
know
I,
say
I'm
with
you
on
this
one
day,
I
know
where
I
I
don't
think
we
should
put
a
warning
on
it
because
you
know
you
it's
like
mailing
money
to
an
address
that
doesn't
exist
and
you
don't
put
that
warning
on
the
postal
service
right,
like
so
yeah,
basically
I
just
don't
want
EIP
editors
to
have
the
power
to
determine
whether
or
not
something
is
worthy
of
a
warning
so
I'm.
You
know
we
should
just
not
have
them
at
all.
D
I
think
you
bring
up
a
good
point
and
a
center
of
it
is
who
has
the
authority
and
I
I?
Think
I'm
with
you
on
that
in
that
ERC
editors
on
probably
not
the
best
one
to
have
that
Authority,
whether
to
with
that
consideration
somewhere
to
allow
readers
to
be
more
cautious
or
have
an
added
educated
approach
to.
D
It
is
I
think
a
separate
story
about
where
the
authority
who
the
authority,
who
has
the
authority,
maybe
also
as
the
Authority
or
maybe
we
can
have
a
social
consensus
to
allow
that
to
happen.
And
even
if
it's
a
warning,
I'm
not
saying
like
on
top
of
it,
there
should
be
a
warning
I'm
more
in
my
mental
model,
I'm
more
thinking
of
maybe
it
should
happens
in
the
consideration.
I,
don't
know
if
it's
a
security
consideration,
but
this
is
something
pretty
new
to
a
lot
of
people.
D
D
Yet
so
my
view
on
that
is,
if
people
will
be
writing
ERC
from
day
one,
and
if
there
is
a
consideration
section,
maybe
in
the
consideration
section
they
just
mentioned
that
not
all
addresses
by
ethereum
Design,
as
the
ad
has
the
ability
to
to
send
back
or
to
resend
another
erc20,
that's
different
from
the
address
that
doesn't
exist,
the
USPS
will
rebond
address
or
if
it's
an
empty
house,
some
people
can
go
in
there
and
and
claim
it
and
buy
the
design
of
ethereum
at
the
moment.
D
Right
now,
an
address
is
by
generated
by
a
lot
of
the
actions
and
then,
if
it
doesn't
exist,
then
it
doesn't
exist
right.
The
contract
is
a
hashes
or
EOS.
Is
it's
it's
the
public
key?
So
that's
the
difference
between
the
empty
address
metaphor
versus
these.
The
the
skin
scenario
I'm
done
I'm
done
talking.
E
E
E
E
A
generally
useful
thing,
the
Blake
2
example,
is
good
because
if
you,
for
instance,
if
you
wrote
an
EIP
that
was
like
a
pre-compiled
for
a
specific
signing
function
or
you
know,
cryptography
is
sort
of
always
supersedable
or
unforeseen
complications.
Other
event
practices
come
up
later
after
something
goes
final,
the
author
should
be
able
to
say,
please
see
this
later
ehip,
and
so
it
isn't
really
appropriate
for
that
author
to
say,
like
two
is.
E
We
can't
use
it
anymore.
They
could
only
say
look
at
this
other
document
and
in
that
other
document
it
could
argue
that
maybe
it's
bad
According
to
some
criteria,
but
it's
like
just
pointing
to
a
later
document.
Not
you
know
anything
more
substantive
that
was
sort
of
like
my
idea
of
the
Errata
thing
and
in
that
sense
also
coming
back
to
the
specific
case.
E
E
A
politest
thing
to
do
if
there
was
an
errata
option
available
to
authors
of
final
EIP
H.
We
can
tell
the
person
hey,
you,
don't
keep
bothering
us,
don't
keep
bothering
ethereum
Foundation.
The
only
person
who
could
point
to
updated
guidance
would
be
the
authors
of
erc20
Like,
For,
Better
or
For
Worse.
Maybe
this
mean
to
them,
but
I
don't
know
just
just
on.
E
B
I
think
they
could
fall
under
Errata
or
clarifications.
A
E
I
just
assumed
I
assumed
that
adding
any
even
non-normative
text
to
it
to
a
final
EIP
was
breaking
the
immutability.
I
didn't
even
know
that
was
an
option.
I
was
assuming
you
could
only
Point
towards
a
later
EMP.
You
have
to
ask
the
authors
to
make
another
yeah.
C
Okay,
there's
the
button.
A
final
is
final
and
Errata
are
for
the
case,
where
the
EIP
actually
fails
to
describe
the
actual
intended
normative
Behavior,
so
that
this
is
this
is
what
erc20
does
normatively
for
all
I
know.
There's
applications
out
there
that
actually
use
this
behavior
for
a
purpose.
C
So
there's
just
there's
no
there's
no
point
to
to
going
in
and
changing
these
things.
There
are
other
token
standards
you
can
use.
If
you
don't
like
this
behavior
and
this
person
is
quite
free
to
to
write
an
informative
EIP,
describing
this
problem
and
making
These
Warnings
and
he's
free
in
a
bigger
sense
to
create
his
own
group
to
start
some
process
of
going
through
going
through
things
and
starting
up
the
starting
a
process
for
finding
these
problems
and
creating
EIP
to
to
to
report
them.
Maybe
a
living
iip.
C
We
just
don't
have
a
process
for
this,
and
it's
not
clear
that
it's
it's
at
the
editor's
problem
to
start
keeping
track
of
ways
that
you
can
get
in
trouble
using
various
using
various
standards,
there's
any
number
of
ways
to
get
in
trouble
with
ethereum
and
lose
lots
of
money.
A
I
would
agree
to
that
like
there
could
be
proposals
which
are
superseding
but
supersede
is
no
more
status
for
ethereum
improvement
proposal,
so
perhaps
we
can,
as
Greg
suggested,
maybe
suggest
the
user
to
come
up
with
another
proposal
which
may
fix
an
informational
proposal.
If
that
helps
so
they
can
share
more
information
about
that
and
also
Sam
suggested
to
have
a
PR
against
erc20
I.
Don't
know
what
is
the
conclusion
here
like
what
is
the
recommended
action?
Great.
A
A
I
think
with
that,
the
conclusion
for
this
item
is
editors
may
not
be
responsible
of
keeping
track
of
adding
warnings
to
proposals
which
are
already
into
the
final
status
and
the
user
can
come
up
with
information
on
EIP
and
share
the
information
at
various
levels.
A
E
A
B
Yeah
so
Panda's
been
having
an
effort
to
cite
yeah
like
to
have
EIP
show
up
in
Google
Scholar,
and
one
of
the
things
you
need
to
do
to
have
that
happen
is
have
a
like
a
real
bibliography.
B
B
D
Can
we
have
that
and
maybe
touch
the
movie
requires
later
down?
The
road
I
know
that
in
some
places
we
strictly
previously
strictly
enforces
what
goes
into
the
requires,
must
there's
normative
links
and
if
we
have
nothing
I'm,
not
I
was
not
a
big
fan
of
that
requirement,
but
if
we
have
mandated
that
in
the
past,
maybe
that
needs
to
be
considered
taken
into
consideration
when
we
remove
this
all
together.
B
D
C
Yeah
I
agree
with
Victor
there.
We've
I've
proposed
a
reference
section
and
not
all
of
the
links
in
a
reference
section
have
to
be
up
to
date
in
the
way
that
the
require
section
does
need
to
does
need
to
track
track,
what's
normative
at
a
given
time,
so
I
think
they
serve
independent
purposes
and
I,
wouldn't
I,
wouldn't
want
to
try
to
generate,
require
system
automatically.
A
I
would
appreciate
if
either
Victor
or
Greg
May
add
a
comment
to
this
pull
request.
That
might
be
helpful
because
panda
is
not
on
the
call,
although
the
recording
will
be
made
available,
but
that
would
help
future
discussion
on
this
PR.
A
I'm
Greg
I
am
wondering,
if
your
hand
is
raised
for
this
one
or
from
the
earlier
okay
cool
moving
on
to
the
next
one
is
adding
adding
numbering
guideline
I
think
this
PR
is
also
created
by
Panda
peep
last
month
with
respect
to
how
we
are
changing,
EIP,
numbering
I.
Suppose
the
pr
number
here
is
7388
any
comments
on
that.
A
A
A
A
A
Okay
yeah,
the
idea
is,
the
bot
will
move
it
to
stagnant
and
the
moment
the
bot
will
make
it
to
the
stagnant.
It
will
obviously
create
a
PR,
and
that
will
automatically
generate
a
message
to
the
author
that
this
proposal
I
mean
this
EIP
is
being
moved
to
stagnant.
If
he
or
she
wants
to
not
stagnant
that
proposal,
they
can
come
up
with
a
PR
to
move
it
to
the
final
yeah.
D
I
felt
this
is
another
example
of
problem
with
EIP
ownership.
D
The
problem
happens
when
authors
contribute
to
the
point
when
they
stop
getting
actively
engaged,
do
they
still
own
the
VIP,
or
does
the
community
or
in
in
any
group,
owns
this
community?
This
come
up
in
our
previous
conversation
of
the
remove,
whether
to
add
a
warning
to
yes20.
D
The
author
was
no
longer
very
active
in
this
particular
ercs
and
then
also
in
in
that,
in
this
case
of
when
at
EIP
of
last
call
losses,
authors
to
move
it
to
final,
so
maybe
in
the
future
we
can
discuss
about
how
do
we
handle
or
how
do
we
help
in
this
case,
in
those
cases,
in
an
ownership
perspective.
A
D
A
B
This
would
allow
linking
to
cves,
which
I
think
might
be
kind
of
nice,
and
we
have
an
author
asking
for
it.
I
just
wanted
to
know
if
anybody
had
objections
to
that
before
I
wrote
up
the
EIP
for
it
or
the
the
pr
rather.
A
Just
to
clarify
so
for
this
particular
item,
people
think
that
it
would
be
a
good
idea
to
come
up
with
an
EIP
and
Sam
would
be
taking
care
of
that
yep
perfect.
A
The
last
one
under
this
section
is
update,
EIP
5069
replace
handbook
with
Charter.
So
in
the
in
the
last
meeting
of
eipip,
we
discussed
that
the
proposal
the
charter
shared
by
Sam,
should
be
in
two
parts.
Some
updates
goes
to
eip1
and
some
update
schools
to
EIP
5069
I
see
a
big
overhaul
here.
The
proposal
is
being
moved
from
informational
to
meta
and
a
lot
of
things
are
being
changed.
The
pull
request
number
is
7468
I.
Think
Sam
is
looking
for
some
last
feedback.
D
My
I'm
generally
in
favor
of
that
direction,
proceduralize
them.
What
do
you
think
if
we
change
the
content
and
teach
them
informational,
at
least
for
a
amount
of
time
like
a
few
months
for
the
general
public
editors,
authors
and
everyone
to
get
familiar
with
them
before
moving
them
to
the
meta,
the
reason
being
that
moving
to
Mata
is
enforceable
and
for
important
document
like
this
is
since
we
need
more
like
if
we
are
imposing
a
review
last
call
final
for
a
technical
document.
D
I
think
we
should
also
have
a
way
for
people
to
know
that
something
is
coming
up
it's
important
and
if
we
want
to
adopt
them,
there
is
a
time
for
you
to
voice
your
your
feedback
in
in
general
public
property
in
general
public
this.
This
is
because
the
editing
itself
is
still
in
drugs,
and
it
has
not
been
published
to
be
viewed
by
a
lot
of
people.
It's
currently
only
editors
are
involved.
D
I
think
we
should
I
think
at
least
a
better
way
is
to
publish
it
as
an
informational
and
then
have
a
PR
standing
there
to
say
hey
in
a
few
a
long
number
of
weeks
that
were
moving
into
Mata
enforcing
it.
And
you
better
response
by
by
this
and
then
also
I,
think
it's
worthy
of
bumping
up
the
fem
threads.
B
D
Well,
that
yeah
that
will
work
currently,
no
one
is
engaging
in
in
the
EIP
editor
handbook
thread
and
if
we're
turning
it
into
Charter,
which
is
I,
think
I'm
in
favor
of
that
it
makes
enforceable.
And
then
then
people
should
really
care.
B
D
B
Yeah,
exactly
I,
just
I
I,
don't
understand
what
like
like.
Why
do
we
need
input
from
people
who
are
not
editors
on
this.
F
So
when
you're
working
with
a
system,
it's
nice
to
know
how
you
expect
it
to
work,
although
this
would
be
law
and
how
these
readings
actually
work
as
case
law,
and
they
are
quite
different.
So
that
is
a
point
of
frustration.
Is
that
it's
a
random
number
generator
when
someone
who
is
not
an
editor
interacts
with
the
system,
I'm
kind
of
disappointed
now
to
hear
the
topic
groups
you're
out
of
this:
are
they
out
in
general?
Are
they
just
out
of
the
specific
ERC.
B
F
I
mean
from
an
outside
perspective
when
The
Outsiders
don't
have
any
input
and
they
watch
what
should
have
been
an
agreed-upon
thing
that
was
agreed
in
principle
three
weeks
ago
get
spinned
over
and
over.
They
lose
a
lot
of
faith.
So
that's
that's
a
perspective.
As
an
outsider.
D
I
I
think
what
I
hear
Daniel
says
is
that
it
will,
if
we
let
Outsider,
give
us
the
back
on
this
and
give
them
some
time
it
will
allow
us
to
accumulate
more
faithful
credit
from
them.
D
If
we
don't,
then
we
lose
the
chance
to
to
get
their
credit
and
to
improve
our
credibility
by
soliciting
outside
feedback
is.
Is
that
a
good
understanding
of
your
perspective.
F
Well,
even
if
you
get
the
outside
feedback,
will
it
speed
up
the
process
of
actually
coming
to
a
decision
and
consensus,
because
anything
that
slows
down
that
process
is
going
to
cost
credibility.
A
C
Sorry,
which
do
you
want,
did
things
go
really
fast
or
that
the
community
has
time
to.
Let
us
know
that
that
this
is
a
charter
for
a
group
that
they
actually
want
to
serve
them
in
the
ways
that
we
want
to
serve
them.
C
C
B
All
right
so
I'm
hearing
that
you
guys
want
me
to
have
a
last
call
type
period
for
this,
where
we
can
get
feedback
from
the
community
and
I'm.
Also
hearing
that
Dano
is
upset
that
it's
taking
a
very
long
time
and
that
we
aren't
making
any
decisions.
Is
that
a
reasonable
summary
of
everybody's
stances.
F
A
Just
to
I
traded
here,
a
proposal
which
are
moved
as
living.
There
are
very
limited
proposals
which
are
in
living
status.
That
already
provides
this
flexibility
to
make
changes
in
future.
That's
the
reason
why
we
do
not
have
this
last
call
thing
added
for
proposals
which
are
in
living
statuses.
However,
I
find
it
as
a
good
idea
to
have
it
publicized
reliving.
A
The
fem
discussion
thread
is
good
suggestion
we
can
perhaps
make
use
of
that,
but,
as
per
my
understanding,
we
do
not
necessarily
wait
for
another
14
days
for
this
to
be
settled
down.
So
if
people
are
okay,
we
can
perhaps
keep
this
PR
open
for
another
seven
days
or
so,
and
maybe
we
can
have
discussion
thread
ignited
again
on
fam
about
this
change
coming
up.
A
Would
that
be
a
fair
resolution
that
we
are
coming
to
a
decision?
We
are
going
towards
getting
this
certainty
and
we
are
not
waiting
for
a
very
long
time.
C
F
A
Yeah
I
understand
that,
but
I
I
don't
think
we'll
be
moving
in
that
direction.
We
are
not
going
back.
The
decision
is
still
there.
We
are
just
trying
to
make
sure
the
decision
is
added
and
being
reflected
in
the
document,
so
people
can
follow
and
refer
it
in
future.
A
So
I
see
a
couple
of
hands
up
by
the
editors
here.
Just
as
a
summary,
we
can
have
this
pull
request
open
for
next
seven
days
and
after
that,
if
Sam
will
change
from
you
know,
draft
draft
to
a
real
PR
that
would
be
merged
by
bot.
So
anyone
having
any
thoughts
try
to
come
up
before
that.
D
So
so
I
think
I
would
personally
suggest
that
we
publish
it
at
as
opposed
to
merged
as
a
SL
post
of
keeping
it
as
a
draft
PR
because
not
be
not
many
people
will
be
able
to
see
that
and
also
publishing
it
allows
search
engine
to
pick
it
up
allows
much
more
notification
to
kick
off,
so
what
I
would
suggest.
D
Alternatively,
we
introduce
all
the
change,
publish
it,
except
for
the
type
being
informational
rather
than
meta,
and
in
a
few
weeks
we
made
another
pull
request
to
Move
It
from
informational
to
matter
just
start
enforcing
it.
B
Well,
as
long
as
I
keep
in
draft,
it
won't
merge
it.
That's
why
I
keep
it
in
draft.
A
Yeah
but
I
think
Victor
is
suggesting
that
we
should
make
it
like
as
a
normal
PR,
so
people
can
see
it
and
it
should
be
publicized.
A
D
And
maybe
we
should
drop
a
line
in
the
document
says
this
is
going
into
matter.
If
no
objection
like
in
a
time
that
we
agree
in
a
timeline
that
we
agree
upon.
C
Yeah,
okay,
so
yeah.
A
C
A
E
B
Final
time,
my
understanding
of
the
plan
is
change,
the
pr
from
a
meta
to
informational,
so
that
there
will
no
longer
be
a
status
update.
Then
merge
the
pr
and
then,
in
two
weeks
from
today
on
the
next
eipip
call
we
can
ratify
the
like
make
this.
Our
government's
process
do
I
understand
that
correctly.
D
Yeah,
except
for
two
weeks,
maybe
too
short
for
people
to
give
this
kind
of
feedback,
but
I'm,
okay,
if
it's
too
weak
I'm,
just
yeah.
A
The
league
is
generally
the
last
call
period,
even
if
we
are
not
following
it
formally
the
last
call
period
informally
it
is
being
founded
here.
So.
A
B
So
these
are
seven
five:
zero,
six
and
seven
five
zero,
five
yeah
okay.
So
these
two
are
somebody
put
raw
HTML
in
their
proposal.
They
just
look
like
it's
just
not
necessary
HTML
tag,
so
I
just
want
to
remove
it
for
formatting
purposes.
A
So
the
other
PR
7505
is
also
same
or
similar
right.
A
D
B
B
A
I'm
sorry
about
that,
the
next
one
here
is
a
PR
number,
six,
eight
six
zero.
It
is
about
a
proposal
which
is
already
in
final
number,
is
4804
I!
Think
there
were
some
suggestions.
Review
Suggestions
by
Sam
and
author
has
responded
to
that.
I
do
not
see
any
change
in
the
code
here,
but
yeah
I,
wonder
if
people
are
generally
okay
to
get
this
PR
mush
because
it's
been
a
while
it
is
setting
over
there.
B
Oh
so
I
I'm
still
I
think
in
the
camp
of
not
updating
this
but
yeah
I
guess
we
can
read
this
and
comment
on
it.
A
Moving
on
to
the
attempt
number
two:
okay,
we
have
eight
minutes
left
and
let's
try
to
move
as
fast
as
possible,
discussion
continued
or
updates
from
the
past
meeting.
It
is
about
EAB,
ER
security
repositories,
split
I,
think
we
discussed
part
of
it
in
fact
more
of
it
in
the
earlier
discussion.
Yes
Dano,
if
you
have
to
add
anything
on
this
topic,.
F
F
Okay,
I'll
move
it
in
last
call
for
two
weeks
from
today,
perfect.
A
C
Yeah
Sam
and
I
discussed
this
and
there's
just
an
editing,
merge
issue,
as
eip1
has
changed
enough,
that
the
merge
can't
happen
and
there's
what
we
want
to
happen
is
to
be
sure
that
the
core
devs
can
keep
track
of
their
own
statuses.
We
don't
want
to
force
them
into
the
that
there
must
be
a
review
period.
There
must
be
a
last
call
period,
they
had
their
own
workflow
and
they
need
to
put
that
in
the
document
and
I
think
Sam
may
remember
better.
F
The
split
is
separate
from
all
other
governance
issues,
whether
we
use
headers
or
not,
and
those
moved
into
the
discussion
of
what's
going
on
with
the
new
topic
groups
and
with
the
EIP
editor
Preamble
I
was
hoping
we
could
talk
about
topic
groups
this
week,
because
I
was
hoping
that
the
new
Charter
would
have
been
resolved
by
now
and
I
think
that
we
can't
really
talk
about
those
details
until
after
the
charter
is,
is
complete
and
set
those
standards
and
because
the
agreement
that
I,
remember
from
all
Cortez
from
two
weeks
ago
was
the
split
is
completely
separate
from
governance
issues.
B
C
C
So
what's
what
we
broke
out
of
that
was
the
working
groups,
because
the
question
the
question
Sam
and
I
ran
into
was
simply:
do
we
give
the
core
devs
the
status
field
itself,
or
do
we
give
the
core
devs
their
own
Preamble
to
to
keep
track
of
their
own
governance?.
F
I'm
in
favor
of
reducing
the
scope
of
Court
governance,
so
letting
the
topic
groups
decide
their
own
status.
Thing
is
in
line
with
that
General
principle
that
the
the
central
groups
are
doing
less
and
less
is
giving
more
and
more
power
to
the
topic
groups,
so
I
would
prefer
that
poor
devs
get
to
do
what
we
want
with
the
status
groups.
You
could
say
like
well,
you
need
to
categorize
these
in
some
mutable
and
immutable
States.
F
F
C
Not
really
I,
don't
think
the
it's
up
to
the
working
groups
of
mutable
and
immutable
is
even
a
concept
for
them
from
the
from
the
editor's
point
of
view,
the
statuses
that
really
matter
are
draft
final
and
final
doesn't
really
matter
to
us
until
after
an
upgrade
really
if
the
editors
want
to
make
it
go
final
before
an
upgrade
fine,
but
we're
not
concerned,
we
okay.
F
So
if
it's
providing
a
list
of
states
that
map
to
immutable
and
immutable,
if
the
topic
groups
map
their
statuses
to
draft
a
draft
status
in
the
final
status,
then
we
don't
need
the
the
editor
status,
because
we
can
map
it
into
the
topic
group's
workflow.
C
Brought
everything
in
between
draft
and
Final
is
up
to
the
core
devs
and
the
question
is
simply:
do
we
let
the
core
devs
use
the
existing
status
field,
or
do
we
give
the
core
devs
their
own
Preamble
in
the
header
of
the
document?
There's
an
extra
Preamble
that
a
working
group
can
use
to
put
any
Fields
whatsoever
that
they
need.
F
F
You
can
add
other
headers
for
topic
group,
but
to
have
like
a
header.
That
means
two
different
things
between
core
governance
and
topic
of
governance.
I
think
is
sort
of
friction.
That'll
result
in
problems.
B
Yeah
I
think
so
the
way
I
had
originally
written
this
up
is
the
first
Seven
Fields
I
think
were
were
fixed,
and
that
was
like.
The
data
was
created,
the
authors
who
can
edit
the
document
what
topic
group
it
belongs
to
there's
a
few
of
these
fixed
ones,
but
then
anything
after
those.
Those
first
and
number
of
them
would
be
totally
up
to
the
topic
group.
C
C
It
just
creates
a
separation
of
responsibilities,
so
we're
not
having
to
coordinate
it
all
on
that.
F
So
what
if
the
topic
groups
had
a
naming
requirement
to
say
that
if
they
had,
if
that
the
last
word
in
their
status
needs
to
be
one
of
draft
or
finals,
so
they
could
distinguish
at
the
glance.
So
we
have
proposed
draft
on
CFI
draft
EFI
draft
test
net
draft
main
net
final.
So
that
way
from
one
field
you
can
get
both
informations
or
you
could
require
that
they
have.
F
Every
topic
group
have
a
final
State
and
their
final
state
is
final
and
it
might
be
final
Dash
rejected
final
Dash
implemented
final
Dash
mainnet,
and
everything
else
is
draft
I.
Think
with
with
two
Fields
you're
going
to
get
too
many
conflicting
States,
because
the
topic
group
statuses
really
should
map
into
this
is
either
a
draft
date
or
a
final
state.
And
it's
going
to
reduce
it's
gonna
result
in
people
messing
it
up.
F
We
could,
even
in
in
the
there
is
no
course
data
that
the
editor
that
the
authors
put
on
is
something
that
the
regulars
put
on
when
they
render
it
onto
the
main
page.
So
we
could
put
the
mapping
inside
of
the
logic
that
there's
a
sort
of
VIP
logic
that
Panda's
writing.
C
C
Some
some
of
them
are
just
my
desire
to
somehow
dissociate
dissociate
this
as
much
as
possible,
so
that
the
core
devs
and
the
editors
do
not
need
to
coordinate
on
this
stuff
and
also
that
the
ietf
pretty
much
gets
by
with
everything,
either
being
a
draft
or
an
internet
standard.
That's
that's
it
from
the
from
the
publication.
F
But
we
very
significantly
from
the
ietf.
That's
why
I
want
to
call
these
topic
groups
instead
of
working
groups,
because
we
don't
do
anything
close
to
what
an
ietf
working
group
does
we
don't
assign
an
editor?
We
don't
assign
a
chair.
We
don't
make
the
chair
responsible
for
writing
it.
It's
not
a
large
group,
so
it's
quite
different
already
from
ietf,
which
is
why
I
prefer
things
like
calling
in
a
topic
group
to
make
it
clear
that
we're
not
confused
with
other
processes.
C
Well,
Google
topic
group
and
Google
working
group
under
topic
group
you'll
get
nothing
that
makes
any
sense
under
working
group.
You'll
get
all
kinds
of
different
working
groups
and
all
kinds
of
organizations.
Working
groups
are
people
who
get
together
and
organize
themselves
to
get
some
work
done.
Topics
are
just
anything
you
can
talk
about.
C
The
core
devs
are
organized
to
work
on
a
task.
How
they
organize
themselves
is
not
the
editor's
concern.
The
editor's
concern
is
just
is
this
a
document?
That's
still
subject
to
change,
or
is
it
a
document
that
is
no
longer
subject
to
change?
I
I.
Think
that's
the
only
thing
we
care
about
this
is
not
a.
This
is
not
a
hard.
C
C
For
the
good
discussion
on
this
I
appreciate
it
Sam
are
you,
are
you
pretty
sure
you
understood
what
Dano
said,
I
I'm
too
tired
at
this
point.
B
Sounds
like
a
fun
evening,
but
yeah.
My
understanding
is
that
data
wants
to
have
a
file
somewhere.
That
says,
you
know,
on
the
left
hand,
side
the
name
of
the
status
and,
on
the
right
hand,
side
of
Boolean
indicating
whether
it's
a
draft
or
a
final
and
then
each
each
working
group
defines
that
file.
A
A
Sam
has
dropped
off,
I,
don't
know
if
there
is
any
future
call
with
respect
to
that
proposal,
if
there
would
be
I'm
hoping
that
the
announcement
would
be
in
the
Discord
Channel.
Thank
you.
Everyone
for
joining
us
today
have
a
good
day.