►
From YouTube: IETF115-UUIDREV-20221108-1630
Description
UUIDREV meeting session at IETF115
2022/11/08 1630
https://datatracker.ietf.org/meeting/115/proceedings/
B
C
D
A
B
B
And
he
is
currently
displaying
the
the
note
well
slide,
which
of
course
is
a
reminder
to
everyone
that
everything
that
you
all
discussions
in
the
meeting
are
are
under
the
terms
of
the
note
well,
which
basically
has
a
lot
to
do
with
the
intellectual
property
rights
that
you
are
seeding
to
ietf
as
a
result
of
the
discussion,
and
so
you
should
read
this
in
detail.
If
you
haven't
already,
hopefully
you
have
already,
isn't
there
also
a
companion?
Do
you
have
the
other
slide.
B
B
B
B
B
E
B
E
A
And
I'm
going
to
give
you
a
slight
control
if
I
can
sure
control
there,
so
you
should
have
the
buttons
on
the
bottom
yep
got
it
got
it.
Thank
you
for
that.
Thanks
for
sharing
all
right
folks,
I
appreciate
everybody.
Having
me
today,
Kaiser
Davis,
Cisco
Systems
today
we're
going
to
talk
about
a
couple
different
items
and
we're
gonna
spend
the
bulk
of
this.
A
Since
we
had
an
intern
meeting
pretty
late,
pretty
recently
we're
going
to
spend
the
bulk
of
this
talking
about
what
we're
going
to
do
next,
but
we'll
get
through
this
very
quickly
in
the
first
set
of
slides
summary
today
is
just
discussing.
Why
we're
here,
what
we're
doing
we're
going
to
discuss
fixing
Errata
the
new
table
of
contents
in
the
document,
some
things
we
did
I
did
to
version
three
four
and
five
and
then
other
housekeeping,
and
you
know
what
are
we
going
to
do
for
draft
one?
A
What's
slated
for
release
at
the
end
of
the
month,
so
the
story
thus
far
is
myself
and
Brad.
Peabody
we're
working
on
draft
for
New
uid
formats,
this
added
specifically
version
678
and
uuid
Max,
and
some
best
practices
that
weren't
in
4122..
We
went
to
ietf
114,
we
did
a
dispatch
session
and
they
officially
said
hey.
We
should
create
this
working
group,
which
is
where
we're
at
right
now.
So
the
goal
of
draft
zero
was
to
merge
what
we
had
in
the
new
Peabody
document
with
RFC
4122
right.
A
In
addition
to
this,
we're
going
to
go
ahead
and
fix
the
Errata
we're
going
to
squash
those
as
we
go
right
as
bugs
so
the
new
draft,
zero
zero
that's
been
published
in
October,
was
effectively
the
merge
of
these
two
documents.
So
if
you're
not
up
to
speed
on
678,
you
know
take
take
a
little
bit
of
time
to
look
at
that.
If
you're
not
up
to
speed
with
some
of
the
Errata,
take
some
time
to
look
at
that,
because
that's
what
we're
going
to
be
talking
about
going
forward.
A
One
thing
that
we
found
in
creating
the
Peabody
document
was
that
the
4122
layout
and
table
of
contents
is
just
tough,
very
tough
to
work
with
to
get
the
concepts
that
we
need
across.
So
in
about
draft
three
of
our
document,
we
decided
to
overall
the
table
of
contents.
Make
it
a
little
bit
more
readable,
provide
some
better
groupings
for
these
need
to
know,
information,
things
that
are
related
and
things
that
are
best
practices.
So
you
don't
have
to
jump
around
15
different
places
in
the
document.
A
So
in
the
order
we
got
when
we
came
away
with,
was
introductions
and
ietf
language
you,
edit
uid
formats,
uid
layouts,
the
best
practices,
the
ietf
considerations
and
things
we
need
like
security
considerations,
Ayana
considerations,
the
references
and
then
appendixes
for
things
like
code
and
test
vectors
and
all
the
other
stuff.
We
want
to
shove
at
the
bottom,
as
references
feedback
from
around
the
internet
and
on
the
working
group
and
some
unicast,
chats
and
stuff
seem
to
be
that
this
was
a
good
table
of
contents.
It
pro
it
was
very
readable.
A
A
One
thing
to
note
here
is:
if
you're,
looking
at
4122
and
you're,
looking
at
our
document,
you're
going
to
see
a
distinct
missing
sections
which
are
those
algorithms
to
create,
maybe
a
time-based
uuid
or
a
random-based
uuid
again,
I
removed
these
around
draft
3
of
our
document
because
they
just
didn't
work
well
and
it
caused
all
kinds
of
weird
issues
extrapolating
that
so
that
stuff
has
been
just
reworked
into
these
specific
layout
section
right.
So
how
to
create
a
uuid
version.
A
We
I've
reused
all
of
the
text
from
those
they're
just
very
dated
in
the
way
that
they're
written,
I
guess
the
best
way
to
put
it.
I
can
easily
just
copy
and
put
and
paste
and
put
them
in
as
appendixes.
We
don't
want
to
lose
the
text,
but
I,
don't
think
anything
that
was
there
is
gone
and
it
was.
It
was
just
very
tough
writing,
like
version
seven
to
a
one
of
those
for
version,
seven
and
stuff.
We
just
had
a
lot
of
issues
with
it.
A
A
B
A
If
we
so
yeah,
so
the
algorithms
aren't
necessarily
an
algorithm
like
you
expect,
like
a
code
algorithm
or
math
or
any
of
those
types.
There
are
they're
just
text
like
here's,
a
set
of
steps
and
they're,
not
even
steps
they're,
just
unnumbered
bulleted
list
of
do
these
things
from
a
very
basic
programmatic,
View
kind
of
just
a
suit.
It's
pseudocode!
More
than
anything
we.
A
Just
around
clarifications
around
which
bit
where
which
you
know
which
level
of
Indian
is.
Should
we
use
they're
harder
to
fix
and
I
have
gone
through
the
document
and
made
an
attempt
to
make
it
conform
to
each
of
these
six
Indian
sort
of
bit
layout,
erratas
and
really
to
boil
it
down.
It
comes
down
to
very
consistent
language,
I'm
using
big
Indian,
because
that's
that's
what
every
one
of
these
uses
from
what
I
can
see
in
reviewing
the
other
specs,
defining
where
most
significant
bits
are
using
some
helper
verbiage
like
leftmost.
A
If
we're
talking
about
that,
defining
where
our
bit
and
byte
order
and
numbering
start
so
I
put
some
text
in
actually
borrowed
from
x667,
which
is
documents
kind
of
mirrored
with
we'll
talk
about
in
a
minute,
it
talks
about
how
we
start
our
numbering,
where
our
bits
and
bytes
are
where
things
like
the
variant
should
be
where
these
bytes
exist
kind
of
just
being
very
specific,
overly
specific
in
these
and
to
hit
on
these
points.
So
people
know
exactly
how
and
where
we're
talking
about
in
these
in
these
128
bits
and
I.
A
Think
I
did
a
pretty
good
job.
I
do
want
to
solicit
some
feedback
on
these
types
topics
right
here,
since
they
were
such
a
major
deal.
Just
look
at
these
keep
them
in
the
back
your
head
and
then,
when
you
look
through
the
document,
see
if
something
I
I
wrote
is
incorrectly
referencing
or
might
have
some
gray
area,
and
then
we
can
fix
it
right,
because
this
is
out
of
all
the
Errata.
This
is
the
biggest
thing
that
we
want
to
fix.
A
So
one
thing
we
did
with
version
six,
seven
and
eight
is
we
gave
them
all
their
own
block
layouts,
they
got
their
own
field
definitions
and-
and
just
in
that
section
you
can
go
straight
to
that
section
and
see
it
without
needing
to
go,
read
and
understand
uuid
version
one.
So
I
did
that
with
three
four
and
five
there's
a
lot
of
net
new
text
and
a
lot
of
text
pulled
from
those
algorithms
to
create
X
right,
so
it
decouples.
A
These
provides
better
clarification
and
allows
me
to
again
group
together
things
that
are
super
important
to
these,
as
well
as
provide
better
text,
vectors
and
extra
clarification
that
we
didn't
have,
because
it
was
a
here's
version
one
and
it's
the
bulk
of
the
document,
and
then
here's
how
you
do
these
other
three
and
they
reference
version
one.
So
you
got
to
kind
of
you
got
the
chicken
for
the
egg
scenario.
A
Maybe
you
don't
care
about
version
one
you
just
want
to
do
a
version
three
well
now
the
section
just
has
that,
and
it
has
everything
you
need
to
know
about
that
so
update
here.
You
know:
I
want
to
just
get
some
reviews
on
version
three
four
and
five
text.
They
should
mean
exactly
the
same
as
they
mentioned
in
the
previous
document.
If
I
maybe
move
something
or
gloss
something
slightly
incorrectly
I
apologize
I
can
fix
it,
but
this
is
all
net
new
for
three
four
and
five.
A
lot
in
that
new.
A
Next
up
is
General
housekeeping
I
went
through
the
document,
replaced
any
HTTP
link
with
https
links
to
the
relevant
site.
All
RFC
references
have
been
updated
to
their
latest
versions,
as
well
as
external
references.
If
something's
been
bumped,
I
made
sure
I
checked
it
and
bumped
it
as
well
as
security
considerations,
I
added
some
info
for
sha-1
and
md5.
Since
we
have
a
couple
rfcs
discussing
those
topics,
specifically
I
added
those
to
the
relevant
security
consideration,
links
and
reference
them
appropriately.
C
A
A
C
A
C
A
Yeah
I
understand
you
I
understand
your
point:
yep
the
the
two
hex
octet
and
the
four
hex
octet.
Those
are
from
the
original
document,
specifically
the
reason
that
I
redid,
the
ABN
F
was
because
it
all
referenced
back
to
uuid
version,
one.
So
again,
decoupling
version
one
from
other
stuff,
so
ABN
F
was
Rewritten,
but
I
may
have
just
missed
hexapta.
Thank
you
for
that.
A
All
right
next
up
is
some
action
items.
We're
going
to
talk
about
things
that
I
plan
to
do
for
draft
one
Cadence
for
releasing
would
be
monthly,
so
I
plan
to
work
on
these
and
push
this
out
by
the
end
of
the
month,
we'll
iterate
on
that
draft
two
by
the
end
of
December,
so
on
and
so
forth,
to
IET,
f115
so
or
116..
So
we
got
some
time
till
March.
A
A
That'd
be
awesome,
but
my
point
here
is:
should
we
potentially
toss
in
a
new
name
space
that
follows
what
I
see
is
the
logic
for
something
like
iot
devices
and
databases
which
are
nowadays
very
big
use
cases
so
that
other
libraries
will
Implement
them,
because
it
seems
to
be
again
that
if
we
don't
Define
it,
they
won't
implement
it
and
there
could
be
others.
These
are
just
the
two
off
the
top
of
my
head
working
with
uuids
in
this
space
for
the
past
three
years,.
A
E
I've
encountered
a
number
of
missing
namespaces
as
I've
been
working
in
suit
as
well,
and
the
solution
at
the
time
was
to
put
down
the
mechanism
to
generate
the
namespaces
I
used
in
the
suit
manifest
draft
I'd
be
happy
to
forward
that
on
to
you.
One
of
the
things
that
I
thought
was
particularly
relevant
is
that
there
was
no
private
Enterprise
number
prefix.
E
There
was
an
oid
prefix,
but
there
was
no
definition
about
how
you
dealt
with
oids
and
what
kind
of
encoding
you
used
for
the
oid
when
generating
a
uuid,
so
I
wrote
all
of
that
down
and
how
I
was
going
to
do
it.
I
thought,
maybe
that
would
be
something
to
document
as
well
and
I'd
be
happy
to
send
that
on
to
you.
A
Yes,
please
I'll,
look
forward
to
that.
I
got
a
topic
on
oids,
that's
coming
up
in
another
slide.
Thank
you
we'll
touch
on
that,
but
yeah
I
think
you're
you're
right.
We
just
need
to
define
a
couple
more
namespaces
and
then
just
a
better
way
to
how
we
handle
this.
Okay.
Thank
you.
Yep
and
just
commenting
on
Murray
out
loud
I
do
see
the
issue
with
the
hex
octet
I,
just
I'll
I'll
put
it
on
the
mailer.
Thank
you.
A
That
is,
do
you
Generate
random,
for
every
uuid
and
you
slap
it
in
there
or
do
you
generate
one
set
of
random
and
some
counters,
and
and
is
there
some
security
considerations
around
using
certain
types
of
pseudo-random
generators
versus
other
types
which
can
cause
issues
with
running
out
of
random,
exhausting
your
random
entropy
source?
And,
honestly,
it's
a
little
bit
out
of
my
league
on
that
topic
to
write
about
it.
Gentleman
said
he
was
going
to
send
me
some
notes.
I
never
saw
the
notes.
I
checked
all
the
issue.
A
E
A
E
A
A
A
Namespace
registration
template
I
need
to
update
the
namespace
registration
template
and
make
sure
that
it
follows
our
new
RFC
8141
that
shouldn't
take
too
long
to
do
it's
just.
Do
we
actually
need
to
put
a
namespace
registration
template
in
since
it's
already
allocated
I?
Guess,
that's
a
question
for
the
chairs
how
to
handle
this.
Do
I
just
slap
the
new
updated
template
in.
Do
we
need
to
submit
anything
after
updating
it.
D
D
Okay
understand,
if
you
look
at,
if,
if
you
look
at
what
happens,
the
document
like
4122's
probably
said
dear
Ayanna,
please
allocate
please
do
this
registration
for
us
and
then,
as
I
got
processed,
it
said
I
am
it
took
past
tense?
It
says
Ayana
allocated
blah
blah
blah,
so
the
the
text
in
4122.
Actually,
you
could
just
use
that
text
if
you
wanted.
If
we
really,
we
needed
to
be
clear
that
we
had
allocated
this,
then
you
can
just
use
that
text.
Iana
allocated
blah
blah
blah
as
per
RFC,
4122
and
you're
done.
There's.
A
D
A
D
A
Got
it
next
up
is
I've
got
a
couple
issue,
tracker
items
for
version,
seven
and
eight
number
one
is
at
some
point:
we
had
version
8
restricted
to
just
new
versions
of
time-based
euids,
and
then
it
was
relaxed
to
any.
You
know
vendor
specific
implementation,
uuids
can't
can't
do
or
experimental
and
I
forgot
to
remove
some
verbiage.
So
we
we
caught
brewfa
caught
some
some
info
there
and
we're
going
to
remove
that
and
then
this
one
is
further
clarifying
field
descriptions.
A
It
doesn't
change
anything
specifically,
but
just
adds
a
little
bit
further
clarification
about
the
usage
of
milliseconds
timestamp
and
a
forward
cup
a
couple
forward.
References
so
I
think
they
should
be
good
to
merge.
I
just
wanted
to
ask
the
group
and
make
sure
if
we're
okay
with
that
they're
they're,
really
just
very
simple
small
non-impacting
changes.
B
A
A
The
Maxi
uid
does
encroach
upon
the
reserved
variant
space,
which
is
at
the
moment
a
hex
value
of
an
e
or
an
f,
and
the
variant
ID
would
all
have
all
hex
values
of
f,
because
it's
all
ones
and
we
need
to
effectively
discuss
where
that
lies
and
how
to
effectively
put
that
in
there.
This
doesn't
affect
the
nil
uuid,
because
that
kind
of
goes
into
some
older
terminology
called
families,
which
is
what
was
used
before
there
were
variants
and
effectively.
A
Ben
is
looking
to
update
the
variant
table
with
a
section
that
adds
a
column
for
bytes,
so
that
within
the
hex
of
f
for
the
future
variant,
we
can
discuss
what
that
byte
can
or
cannot
be.
It's
very
very
clarified
like
to
the
to
very
to
a
very
nitty-gritty
kind
of
level
that
I'm
not
sure.
If
we
really
need
to
do
it
makes
sense
when
you,
when
you
discuss
it,
there's
a
lot
of
discussion
here.
I
can
take
it
to
the
mailer.
A
Next
up
is
this:
one
is
something
I
came
across
while
I
was
just
looking
through
all
the
references
and
updating
the
references
and
really
just
trying
to
make
sure
4122
stood
on
its
own
or
the
new
document
stood
on
its
own
and
I
noticed
that
apparently,
at
one
point
in
time,
RFC
4122,
itu,
x667
and
the
iso
9838
documents
were
exactly
the
same.
They
were
all
the
same
document
and
one
was
telecommunications
standard,
an
international
standard
and
then
an
RFC
proposed
standard
in
667.
A
They
updated
it
in
2008
and
then
they
updated
again
in
2012.
I
assume
ISO
was
in
lockstep
because
they
updated
their
document
in
2008
and
then
again
in
2014,
but
2014
and
2012
documents
look
to
be
exactly
the
same.
Our
document
was
never
updated
and
has
no
none
of
these
changes.
Specifically
one
of
these
things
in
there
is
discussing
oids
and
how
to
use
a
uuid
as
an
oid.
So
to
the
other
gentleman's
comments
about
oids,
they
have
that
text
in
their
document
which
we
could
take
now.
A
My
concern
is
first:
where
do
we
fit
into
this
picture
and
do
we
have
the
authority
to
add
the
new
uuids
and
the
things
that
we
are
doing
and
if
we
do,
how
do
we
get
involvement
with
itu
and
ISO
so
that
they
can
be
in
lockstep
with
us
and
final
question?
Should
I
pull
in
text
like
the
oid
information
and
whatever
else
I
can
diff
out
from
their
change
log
into
our
document
and
that's
the
open
floor
for
for
questions
and
chairs.
C
C
D
D
B
D
C
D
C
That
was
so.
My
next
question
was
going
to
be
our
entities
behind
paywalls,
because
when
I
come
to
the
isg
for
review-
and
we
can't
review
your
reference
documents,
how
are
we
supposed
to
say
that
this
is
good
or
not?
So
that's
something
to
start
thinking
about
earlier
right
is
usually
the
solution.
Is
we
go
to
the
organization
and
say:
look
we
need
this.
We
need
temporary
access
to
this,
so
that
reviewers
can
do
their
thing.
C
A
The
only
other,
the
only
thing
that
I
would
say
we
would
probably
have
to
Define
and
it's
a
it's.
A
quick
one-liner
is
the
oids
and
I
can
easily
add
that
to
draft
one
and
it
references
back
to
x667.
So
it's
so
we
can,
you
know,
put
our
own
spin
on
the
language
and
the
verbiage
and
write
it
up,
but
they
do
have
a
really
nice
defined
way
to
use
oids
as
an
integer
or
as
a
hex,
layout,
hex
and
dash.
E
So
the
oid
consideration
that
I
was
mentioning
earlier
was
the
reverse.
It
was.
How
do
you
convert
an
oid
into
a
uuid
and
there
are?
There
is
a
namespace
defined
for
that
in
4122,
but
it
does
not
explain
which
encoding
of
oid
you
should
use
and
I
have
seen
people
using
texting.
Coatings
of
you
of
oids
I
have
seen
people
using
binary
encodings
of
oids
and
I
guarantee
you
because
I
did
it
you're
going
to
find
someone
using
a
c-bore
encoding
of
an
oid.
A
A
Last
one
was
just
thinking
about
long
term
with
this.
Let's
say
we
have
all
this
we're
ready
to
go.
We
got
all
of
our
drafts
finished.
This
sat
for
as
a
proposed
standard
for
a
pretty
long
time.
Itu
has
theirs
of
telecommunity
to
standard
got
the
iso
International
standard.
Should
this
be
potentially
something
that
is,
is
an
internet
standard,
so
it
has
the
same
Authority
as
the
rest,
and
in
that
respect,
how
do
you
propose
once
we
get
to
that
point?
A
C
On
first
glance-
and
there
may
be
some
subtleties
here-
that
I
haven't
grasp
yet
you're,
adding
three
new
UI
uuid
types
that
have
never
been
standardized
before,
so
you
can't
go
to
internet
standard
right
now.
You
could
on
everything
up
to
six,
but
not
not
six,
seven
and
eight
themselves,
because
they're
new
or
they
appear
to
be
new
from
our
perspective.
So
the
process,
then,
would
be
you
re.
You
rev
this
like
you're
doing
at
proposed
standard
and
then
for
whatever
period
of
time,
we're
supposed
to
wait.
C
You
wait
let
it
deploy
and
be
out
in
the
world,
and
then
you
come
back
around
and
say
all
right.
We
need
to
elevate
this,
the
internet
standard
without
changing
or
like
with
whatever
changes,
are
allowed
for
that
piece
of
the
process,
but
I
think
you
could
get
resistance
right
now
to
be
wait
a
minute.
You
can't
introduce
three
types
and
say
it's
a
standard.
D
C
Step
I
think
it's
Errata
or
anything
like
if
you
have
one
through
eight
and
like
you
discovered
nobody
uses
two.
So
let's
just
take
two
out
or
Mark
two
as
deprecated
one
through
one
through
eight,
except
for
two
I'm
making
this
up
as
I
go
but
yeah.
Then
we
can
say
this
is
all
standard
except
two
is
deprecated,
and
then
that
would
work
too.
A
There's
nothing
nothing
removed
to
two
is
just
not
owned
by
us.
It's
it's
got
its
own
specification
through
a
whole,
completely
different
organizational
body
and
I,
just
added
a
second
reference
to
that,
so
that
people
can
go
do
that
if
they
want
that's,
it's
almost
never
implemented
anywhere
and
on
the
comments
of
who
has
Authority
every
library
that
I've
looked
at
in
source
code.
Reviews
has
used
4122
in
Snippets
in
in
references
to
4122.
Is
there
for
their
implementation.
A
C
A
C
So
there's
44
shoulds
in
this
document
and
every
time
I
see
one
of
those
I
think
all
right,
so
you're
giving
an
implementer
a
choice
to
do
one
or
the
other
like
do
the
thing
or
not
do
the
thing,
but
there's
no
particular
guidance
about
why
you
might
not
do
the
thing
that
it
says
you
should
do,
and
we
generally
like
these
days
like
to
see
some
sort
of
hint
about.
Why
might
I
decide
not
to
do
what
this
is?
Why
am
I?
D
C
That's
what
I
was
going
to
suggest
to
just
go
through
and
make
like?
How
do
you
really
feel
comfortable,
giving
someone
apps
if
they're
giving
them
Absolute
breadth
to
decide?
Then
it's
a
May
if
you're
giving
them
no
way
out,
then
it's
a
must.
Otherwise
you
should
have
a
clear
idea
in
your
head.
Why
I
might
decide
not
to
do
whatever
the
thing
says.
A
Yeah
in
my
my
comment
on
that,
specifically
is
the
entire
best
practices
section
does
detail
the
yeses
and
the
no's
the.
Why
would
you
do
this,
and
why
wouldn't
you
do
this
and
then
provides
the
should
guidance?
We
had
a
fair
amount
of
musts
in
like
draft
zero,
three
I
think
and
every
issue
tracker
it
seemed
like
everybody
was
opening
was.
This
must
should
be
assured
because
they
have
some
situation
where
they
want
to
do
something
slightly
different.
A
So
we
documented
that
in
the
best
practice
and
took
it
from
a
must
down
to
a
should,
so
we
actually
did
have
way
more
musts
back
in
the
day
that
got
moved
down
to
shoulds,
because
people
wanted
us
to
document
one-offs
and
caveats
and
things
that
we
put
in
best
practices.
So
that's
that's
my
comment
on
the
musk
for
should
so.
D
A
A
D
D
D
So
we
had
put
up
on
the
mailing
lists
back
and
in
October
a
second,
not
a
doodle
poll,
because
they
really
annoyed
me
as
a
paying
customer
I
paid
for
like
eight
years
and
anyway
so
try
this
thing
rally.
This
was
the
link
here,
I
just
posted,
that
link
into
the
chat
as
well
a
couple
minutes
ago,
and
we
have
basically
five
of
us
having
answered
this.
D
D
D
B
Was
going
to
talk
a
little
bit
about
working
group,
adoption
and
and
that
sort
of
thing
so
I
from
a
from
a
process,
standpoint
I
think
we
we
kind
of
jumped
to
step
on
the
on
the
process
in
in
moving
it
from
from
the
initial
author
drafts
to
a
working
group
graph,
because
you
know
there
that's
normally
accompanied
by
kind
of
a
a
working
group
consensus
and
that
sort
of
thing.
So
in
any
case
that
has
happened
and-
and
you
know
we
don't
need
to
revisit
that-
I.
Don't
think.
B
B
The
the
idea
is
that
if
there's
something
that's
controversial
that
that
we
need
to
come
to
agreement
on,
then
that
needs
to
be
a
consensus
call
from
the
from
the
working
group-
and
you
know
what
goes
in
is
the
working
group
consensus.
So
you
know,
as
long
as
things
are
moving
slowly,
let's
as
long
as
things
are
moving
smoothly.
Let's
keep
going
on
this,
but
if
we
get
to
a
point
where
there's
something
that
there's
some
disagreement
on,
let's
not
jump
to
to
doing
it.
D
Technical
ways
of
doing
that
is
to
make
it
a
pull
request
that
you
can
then
share
on
the
list,
and
then
people
can
see
exactly
what
the
text
is,
that
you're,
proposing
or
arguing
about,
and
we
can
actually
even
walk
through
those.
In
fact,
that's
what
I
would
propose
we
do
in
our
next
virtual
interim
is
that
we
literally
just
share
the
GitHub
page.
That's
on
the
screen
now,
and
you
know,
if
there's
wordsmithing
or
arguments
about
that,
then
we
just
will
do
that
right.
We
don't
need.
We
don't
need.