►
From YouTube: IETF-UUIDREV-20230216-1900
Description
UUIDREV meeting session at IETF
2023/02/16 1900
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
B
B
B
B
B
A
B
B
C
B
B
B
C
C
C
Specifically,
we
have
a
variant
in
the
ietf
that
we
do
everything
in,
but
Neil
and
Max
kind
of
don't
exist
in
those,
and
it's
just
calling
that
out
in
a
better
way,
there's
a
lot
of
solutions
thrown
around,
but
they
were
really
deep
solutions
that
ultimately,
we
just
added
a
couple
lines
to
the
table.
So
if
we
look
at
the
commit
we're
just
adding
some
lines
to
the
table
so
that
earlier
in
the
document,
people
can
see
that
those
exist,
so
they
exist
in
a
varied
space.
A
C
Yeah,
exactly
that's
what
it
does
if
you
click
the,
if
you
click
the
commit
hash
to
the
right,
I
think
Michael
like
for
number
16,
not
that
that
goes
to
the
to
the
actual
comment,
go
to
go
to
the
commits
tab
and
then
on
the
right
side.
It
says
like
C7
onto
that
very
first
one
c16.
It
says
like
C7
202
go
go
because
I
still
goes
to
that.
Go
back.
One.
C
Oh
I'm,
very
right,
there's
like
a
blue
c70d2,
yeah
click
that
guy
and
this
this
shows
the
actual
change.
Specifically
in
here
it's
just.
The
text
is
green,
we're
saying
hey:
this
exists,
here's
forward
reference
and
then
hey
this
exists
here.
Here's
the
forward
reference
as
an
FYI.
We
know
that
they're
not
in
the
space
that
we
use,
but
if
you
want
more
info,
go
check
out
that
section.
C
The
next
one
you
can
just
click
49,
we'll
just
go.
We
can
look
at
them
in
the
in
the
don't
click
it
that
way,
click
the
click
commit,
but
this
one's
going
to
Jim's
comments
on
some
clarification,
around
non-descript,
node,
IDs
and
ultimately
steering
towards
the
correct
one
that
we
want.
So
in
this
I
moved
some
things
around
I
changed
the
verbiage
and
effectively
tried
to
leave.
No
ambiguity
that
the
centralized
registry
was
not
what
we
want
to
do
so
I,
basically
flipped
the
order.
C
It's
second
and
then
I
called
out
some
some
text
that
says
hey.
We
want
you
to
use
nondescript
node,
IDs,
we're
just
being
complete,
but
showing
you
the
other
way.
People
do
it.
It's
not
what
we
want
you
to
do.
So
the
new
text
effectively
is
what
I
just
said:
we're
showing
the
two
methods
that
exist
out
there
in
the
world.
Don't
do
that
one?
Furthermore,
you
don't
need
to
do
either.
This
is
just
helping
you,
that's
that's
what
that
changes
and
I
hope.
It
addresses
Jim's
comments
on
the
original
draft.
C
C
56
was
I.
This
was
caught
I.
We
talked
about
in
the
last
interim,
where
we
remove
the
a
b
and
F
and
when
I
was
fixing
some
of
the
commit
merges,
I've
I
messed
up,
I
I,
let
this
slip
through
and
this
effectively
is
removing
it
from
the
I.E,
the
Ina
section
and
actually
giving
it
back
to
and
using
reusing
the
one
that
we
have
up
in
layout,
which
is
the
better
one.
So
I
kind
of
just
pointed
back
to
those
and
said:
hey
the
a
b
and
f
that
we
would
use
is
up
there.
C
So
we
don't
have
two
abnifs,
and
this
is
something
I
thought
I
did
right,
but
then,
when
I
was
looking
at
the
document,
I
realized
I,
somehow
undid.
My
changes
so
should
have
already
been
cool,
but
that's
there.
What's
next
up
57,
that's
formatting.
We
can
skip
it.
I,
just
added
I,
just
fixed
the
markdown.
C
So
this
is
security
considerations.
This
is
the
there's
one
gentleman
who
has
never
messaged
me
about
anything
but
specifically
had
a
lot
of
strong
feelings
about
random.
So
what
I
did
was
I
I
found
another
really
good
use
of
random
and
a
document
that
exists
out
there.
That
is
very
well
updated.
Has
a
lot
of
scenarios
on
using
random
and
I
effectively
cited
this
and
gave
it
and
added
it
to
the
effectively
the
unguessibility
in
some
other
sections,
and
just
said
hey?
D
A
C
Was
just
a
very
it
doesn't
hurt
scenario:
yeah.
There
was
a
scenario
that
I
again
I
I
was
looking
for
some
feedback
from
them
on
that
it
was
just
there's
concerns
about
running
out
of
random
and
initializing
random,
properly
and
using
cryptographic
randoms,
and
just
all
these
things
about
like
we
should
provide
proper
guidance
about
how
to
use
random
and
applications,
and
it's
not
the
goal
of
the
RFC
right.
C
We
can
cite
out
other
places
that
provide
guidance
on
how
to
effectively
program
Randomness
in
your
application
or
or
pseudo
or
cryptographic
random,
but
I
don't
want
to
spend
sections
and
talking
about
you
know
the
topic:
that's
better
left
for
other
documents,
so
I,
just
citing
it
better.
Okay,
that's
the
goal.
C
A
Okay,
well
I
mean
and
then
a
normative
reference,
of
course,
is
one
that
had
that
we
have
a
dependency
on
in
terms
of
the
requirements
in
this
document,
and
so
it's
it's
much
more
problematic.
To
cite
something
that
is,
you
know,
like
a
say,
a
random
academic
paper
or
something
like
that.
I
think.
That's
of
the
sort
that
this
is.
C
C
C
C
C
B
C
C
Think
the
agreement
from
the
discussion
was
still
put
it
in
the
uuid
version,
8
space,
but
let's
provide
the
further
discussion,
was
let's
just
provide
some
extra
guidance
around
that
and
that
there's
going
to
be
another,
commit
that
fixes
that,
on
that
base
feedback
guidance,
this
was
first
attempt
we're
going
to
put
it
in
a
new
uidb8.
And
then,
if
you
go
back
to
the
commit
list,
we'll
see
the
second
one
which
is
scroll
down
just
a
little
bit,
which
is
going
to
be
that
right
right
there
again
Yep.
This
is
the
second
half
of.
E
C
Which
is
effectively
inside
of
the
the
best
practices
section
where
we
have
name
based
UI
generation,
I'm,
calling
out
that
we
need
to
use
that
namespace
in
conjunction
with
the
hat
or
sorry.
The
hash
space,
in
conjunction
with
the
namespace,
in
conjunction
with
the
name
and
those
three
values,
can
give
us
a
nice
version.
Eight
that
shouldn't
conflict
with
some
others
and
then
I
provided
basically
hash
spaces
for
all
of
the
Shot
2
Shot,
3
and
Shake
algorithms,
and
then
I
also
provided
a
singular
test.
C
B
B
B
A
B
A
C
No,
the
there's
no
bit
field
for
the
the
type
of
hash.
It's
just.
The
hash
is
used
as
one
of
the
inputs
of
the
the
hash
space,
namespace
and
name.
All
three
together
are
the
inputs
that
get
the
output
of
that
type
of
of
hash.
So,
if
you're
using
256,
you
use
the
256
hash
space
with
the
namespace,
with
the
name,
if
you're
using
512,
you
use
the
512.
B
Hashtag,
so
so,
if,
if
I
start
with
example.com
right,
here's
the
name
www.example.com
and
I-
want
to
make
a
namespace
hash
from
that.
I
want
to
use
a
hash
to
make
a
V8,
namespace
uuid,
then,
basically,
what
I'm
doing
is
I'm
mixing
this
plus
this
plus
this,
which
basically
results
in
it
being
unique
and
if
I
changed,
hashes
I
also
get
a
different
value,
but
it's
deterministic.
C
A
A
That's
all
they
know
yeah,
but
you
know
we're
we're
talking
about.
You
know
far
in
the
future
when,
when
Shaw
512
is
is
being
deprecated
and
they
want
to
go
to
Shaw
1024.
Let's
say
it:
isn't
it
isn't
possible
to
look
at
one
of
these
hashes
and
and
and
know
know
which
one
is
used
in
order
to
know
how
to
generate
something
that
perhaps
matches
with
it
you
have
to
you
have
to
do
it
by
trial
and
error.
D
C
The
comments
of
about
not
taking
a
bit
is,
at
the
end
of
the
day
we
have
122
bits
and
Brad
and
I
had
we're
going
to
allocate
one
bit
or
two
bits.
I
forget
to
make
this
121,
so
we
could
have
some
interesting
versions
right
and
variant
stuff
and
the
amount
of
backlash
we
got
from
everybody
for
just
changing
a
single
bit
into
going
from
122
down
to
121
and
the
levels
of
of
entropy,
and
all
these
other
conversations
on
how
that
shook
out
was
we
backed
down
from
changing
kany
of
that?
C
So,
if
anything
also,
we
talked
about
truncating.
If
anything,
this
topic
makes
a
lot
of
sense
for
something
like
uuid
long
as
an
example,
Jim
and
and
Michael,
where
we
have
longer
uids
where
128
is
the
base
and
it
can
go
up
to
a
larger
number,
you
can
introduce
the
entire
Shaw
512
hash
and
then,
like
you,
said,
a
subversion
hash
base.
But
at
the
moment
we
can't
we
got
128
bits,
122
that
are
usable
and
taking
any
more
Away,
really
angers.
A
lot
of
folks.
C
C
It's
just
not
embedded
in
the
the
the
the
end
uuid
being
output
by
the
algorithm
kind
of
kind
of
reminds
me
of
like
http's
method
for
like
md5,
authentication
or
Shaw,
where
you
put
all
the
ingredients
that
you
used
and
then
they
have
a
shared
secret
and
they
kind
of
send
the
ingredients
they
compute
and
they
know
ultimately
what
happened
there,
but
they
never
actually
sent
that
final
result
across
the
wire
similar
kind
of
diffie-hellman.
You
send
some
ingredients,
an
application
could
send
that
shot
256.
C
B
C
B
B
To
to
clarify
and
write
up
more
clearly
in
the
change
in
the
post,
let's
post
this
version
and
then
let's,
let's
bring
this
up
as
an
as
an
issue
into
the
working
group.
I
mean
there
were
only
five
people
here
today
and
you
know
wonder
whether
or
not
it's
an
issue
I
mean
obviously
the
the
we
knew.
We
have
this
property
for
md5
and
Shaw,
one
that
you
can
know
what
it
is
by
just
looking
at
it
and
I'm
trying
to
deprecate
it.
Those
things
we're
we're
not
yeah.
D
I
think
it
would
be
really
beneficial.
Sorry
I
was
just
going
to
say,
I
think
it
would
be
beneficial
if
there
were.
If
someone
has
a
use
case
of
like
what
more
specifically,
what
real
world
problem
we're
trying
to
solve
with
this
right,
just
because
yeah
anyway,
I
just
think
that
would
be
it.
That's.
C
That
guy
is
this.
One
was
the
expansion
of
the
multiplexed
fields.
You
know
the
high
low
inversion.
This
is
all
effectively
changing
all
of
our
our
stuff,
so
that
you
know
where
we
see
online
654
time.
High
inversion,
it
actually
has
version,
is
the
four
bits
time
high
is
the
four
bits
this
rippled,
obviously,
throughout
the
entire
document.
If
we
change
the
field,
I
had
to
change
the
definitions,
we
had
to
change
the
test
vectors.
C
We
had
to
change
kind
of
everything
that
reference
time
high
inversion
and
same
with
for
these
specifically
clock
sequence,
high
res
and
clock
sequence
low,
because
that
was
a
multiplex
of
the
variant
two-bit
variant
and
the
clock
sequence
so
ultimately
split
those
apart
I
think
it
looks
better.
This
was
feedback
from
a
lot
of
folks
that
they
wanted
this
change.
We
were
keeping
it
for
backwards,
compatibilities,
it's
a
lot
of
stuff,
but
it
makes
sense
to
just
rip
that
Band-Aid
off
and
fix
it.
So
that's
what
this
fixes-
and
this
is
ultimately
what
we
changed.
C
C
C
C
C
Oh
yeah,
so
this
was
text
that
was
copied
from
4122
by
themselves
raw.
You
know
no
modifications,
no
changes
and
what
I
went
through
here
and
I
just
changed
the
text
so
that
it
reads
better
throughout
the
document
it's
a
little
bit
more
formal
and
effectively
it
conveys
the
same
thing,
but
it
kind
of
isn't
as
hard
to
read
I
guess,
because
when
I
was
reading
through
this
section,
I
I
had
to
read
it
like
five
ten
times
to
understand
what
we're
trying
to
convey.
It
was
just
copied
from
the
old
doc.
C
So
just
cleaning
up
the
text,
so
it
gels
better
with
the
rest
of
the
document
and
that's
the
next
three
commits
are
actually
just
that
they're,
just
looking
at
what
the
old
RFC
had
and
if
there's
a
better
way
to
rephrase
it.
So
we
could
look
at
those
pretty
quickly.
47
was
I
believe
the
same
thing
for
trying
to
think
which
one
this
is
yeah.
This
is
the
uuid
generator
States.
One
of
the
comments
from
Jim
I
believe
is,
you
know
the
old
document
said:
oh,
they
could
just
say
they're
unavailable.
What
does
that
mean?
C
What
is
unavailable?
What's
the
return
there,
so
I
put
text
around
a
what
the
generator
States
mean,
because
this
is
a
mesh
of
like
three
sections
in
the
RFC
old
RFC
and
then
provided
effectively
some
guidance
more
around
the
unavailable
section
and
ultimately,
just
not
gave
this
one.
Another
Fresh
coat
of
paint
to
kind
of
just
really
bring
that
section
home
because
again,
it's
just
copy
and
paste
and
it
didn't
really
read
well
top
to
bottom.
When
you
just
kind
of
jump
to
that
section
and
kind
of
just
go.
C
And
then
44
is
the
final
final
item,
and
this
one
specifically
is
talking
about.
This
is
I,
think
another
comment
from
I
think
the
gym,
and
specifically
it
was
why
we
chose
the
time
stamps
and
why
Unix
why
the
the
rollover
is
not
really
a
problem
and
ultimately
with
calling
out
the
final
validity
date
of
these
time
space
time
stamps
just
so
they're
more
apparent
in
that
you
know
the
rollover
event
is
not
a
2038
problem.
This
isn't
a
problem
in
the
2000s,
it's
approximately
5623
and
10
080
889.
C
Yes,
sir
and
I
know:
I
I
was
thinking
the
same
thing,
I'm
involved
with
a
lot
of
those
conversations
here,
so
it
makes
sense
to
call
out
last
very
last,
commit
I
actually
forgot
about
because
it
was
so
late
is
back
on
the
shot,
256
kind
of
stuff,
so
the
shake
algorithms
can
produce
variable
rate
outputs.
This
is
the
very
very
last
one
down
there
on
February
10th,
and
this
is
just
adding
a
line
to
that.
That
effectively
says
if
you've
got
one
of
those
Shake
algorithms
for
Shaw
Three
that
are
used.
C
You
have
to
Output
128
bits
for
your
hash,
or
else
you're
not
going
to
be
able
to
fill
out
the
uid.
So
you
know
just
calling
out
that
if
you're
going
to
do
those
You
Gotta,
it
must
be
120
bits
or
larger
and
truncate.
Some
data
I
didn't
realize.
Shake
was
I,
didn't
realize
it
was
variable
rate
variable
output
right,
but
it's
good
call
out.
B
C
Yeah,
let
me
yeah,
let
me
put
an
item
to
test
some.
Some
shake
algorithms
I
can
I
can
throw
some
inputs
in
and
just
run
it
over.
You
know
hello,
world
or
something
and
just
see
what
happens
when
I
do
different
different
rates
and
if
it
is
different
based
on
the
output,
yeah
I'll
strike
the
or
larger
yeah.
A
C
Yeah
in
my
head,
I
was
going
more
with
how
it
does
it
with
sha-1
and
Shop
256,
where
we
just
dropped
the
bits
off
at
the
end.
But
that's
a
good
point
on
the.
Maybe
it
does
a
different
output
based
on
what
we
request
so
I'll
test.
It
and
I'll
give
us
a
good
answer,
something
crispy,
but
that's
the
that's,
the
general
gist
of
what's
in
draft
two,
a
lot
of
cleanups
The,
Shaw,
256
and
Beyond
stuff,
and
just
in
general,
mostly
formatting.
B
C
C
B
C
All
of
those
are
going
to
get
closed,
except
for
the
the
final
one,
which
is
the
should,
must
check
where
somebody
goes
through
and
just
checks
and
make
sure
that
every
should
has
an
alternative,
and
every
must
has
has
a
thing.
You
know,
basically,
that
the
thing
we
talked
about
which
I
slated
for
draft
one,
but
now
it's
in
draft
two,
where
we
just
kind
of
sit
down
and
just
say,
did
we
cover
all
of
the
bases
on
those
should
musks
and.
B
C
A
C
C
B
Know
so
so,
but
just
to
be
clear,
so
it
stays
closed
and
then
you
know
it
opens
again
the
Saturday
of
the
meeting,
but
anyway
we're
not
planning
to
meet
in
person
there
as
I
recall
right,
Jim
right,
so
you
know
yeah.
So
my
mind
is:
what
do
we
have
left
to
do
to
get
to
working
group
last
call
we
need
to
post
draft
O2.
E
B
C
C
C
So
basically,
code
appendixes
and
nothing's
changed.
So
if
we
look
at
draft
01,
there's
a
bunch
of
appendixes
in
the
final
document,
which
are
example
C
code
on
creating
uuid
versions,
one
through
eight
right,
I
changed
the
multiplexed
fields
on
version
one
and
and
almost
everything
in
version,
one
through
five
relied
back
on
those
Multiplex
Fields.
So
there's
a
lot
of
work
to
change
all
of
that
code.
That
opens
this
up,
obviously
to
erratas
and
bugs,
because
not
every
code
has
bugs
in
some
way
there's
some
interesting
copyrights.
C
We
Brad
and
I
created
six,
seven
and
eight
because
we
wanted
to
to
mimic
what
RFC
4122
had
so
at
the
time.
We
really
didn't
want
six,
seven
and
eight,
but
we
we
did
it
because
we
wanted
to
show
and
be
compliant
and
kind
of
have
the
same
structure
that
the
old
document
has
so
people
expected
it.
They
got
it.
C
My
question
for
the
group
is:
do
we
need
any
of
this
in
appendix
a
example
code?
Because
if
so,
it's
going
to
be
a
lot
of
work
to
go
through
and
modify
one
through
five
and
then
five
as
well
as
six
and
then
finally,
it
just
opens
us
up
to
potential
erratas
and
all
kinds
of
other
things.
That
could
be
a
problem.
B
B
C
Almost
like
this
is
something
we
put
in
a
like.
You
know
you
take
this,
you
put
it
in
a
uuid
GitHub
and
call
it
a
day
and
say
Here's
the
C
code,
implementation
kind
of
like
the
entire
I
would
go
back
to
srtp,
because
I'm
really
intimate
with
that
document.
It's
like
there's
a
live,
srtp,
there's
implementations
and
then
there's
the
RFC.
The
code
isn't
in
the
RFC.
It
rarely
is,
there's
the
structures,
maybe
C
structures
and
stuff,
but
you
don't
I,
don't
see
rfcs
with
just
literal,
C
and
H.
B
C
C
No,
not
this,
not
this,
no
I'm,
not
this!
In
the
in
the
in
the
code,
the
generation
names
days
of
A1.
Sorry,
it's
like
a
subsection
there's
a
there's,
a
name
I
fixed
it,
but
there
was
a
whole
section
in
here
and
that
this
thing
generated
it
wrong,
basically
based
on
the
inputs
and
some
other
stuff,
so
I
had.
A
A
C
A
C
C
I
think
the
test
vectors
are
better
anyway,
it's
just
speaking
out
loud
like
like
that's
what
other
rfcs
do
they
provide
your
inputs?
We
have
test
vectors,
I,
think
that's
a
way
more.
That's
way
better
than
the
example
code,
I
mean
there's
so
many
languages.
Nowadays
you
can't
cover
them,
so
I
think
we're
much
better
place.
E
Hi
I'm,
finding
that
yes
I
agree
with
the
sample
code,
do
not
and
don't
do
an
informative
reference
to
the
sample
code
in
4122.
It
remains
published
and
shows.
When
you
go
to
the
RFC,
you
know
repository
for
this
new
RFC.
It
will
show
that
it's
a
complete,
4122
and
I,
but
that's
a
question.
I
had
does
this
RFC
update
for
4122
or
does
it
obsolete
it
obsolete,
okay,
but
it
you
know,
you'd
still
be
able
to
see
that
4122
was
the
credit
sensor.
E
C
B
Maybe
earlier,
like
the
start
of
it,
I
think
we
need
a
three
or
four
week
or
working
group
last
call
I
think
we
need
to
spread
the
word.
You
know
widely,
because
I
think
they're
used
all
over
the
place.
Maybe
we
have
to
communicate
with
some
of
these
ISO
and
itu
people
that
had
a
document
that
looked
sort
of
similar.
B
E
I
would
urge
a
four-week
last
call
yep
and
a
certain
amount
of
spelunking,
for
which
other
standards
bodies,
obviously
I,
would
say,
itu,
ISO
and
I
triple,
possibly
and
and
then
even
after
you
know
telling
that
standards
body.
What
you
mean
to
tell
is
somebody
who's
the
go
through
nitf
liaison.
If
so,
that
it
gets
to
the
room
like
in
igu.
It
would
be
study
group,
17,
security.