►
From YouTube: IETF-CBOR-20230614-1400
Description
CBOR meeting session at IETF
2023/06/14 1400
https://datatracker.ietf.org/meeting//proceedings/
B
So
one
more
thing
that
we
maybe
can
briefly
discuss
now
that
Christopher
is
here,
is
what
the
intention
is
with
respect
to
the
the
the
actual
data
format.
Specification
I
forgot,
what
what's
its
name,
Guardian,
something,
whether
that's
something
that
that
the
sibo
working
group
should
work
on
some
other
activity
in
the
IHF
should
pick
up.
C
Question
there
are
two
other
things
that
I
would
love
to
maybe
talk
about,
one
of
which
is
the
registration
of
tax.
We
chose
some
yeah,
we
you
know.
C
That's
actually
a
different
way.
There
may
be
some
confusion
about
what
we're
registering
so
the
that
has
nothing
to
do
with
DC
board.
So
maybe
we
can.
We
can
talk
about
that.
So
the
other
thing
is:
do
we
know
how
many
people
are
actually
I
mean?
Are
we
good
we're?
Are
we
only
going
to
be
meeting
virtually
at
at
San,
Francisco
or
so
far?
I,
don't
I
think
Carson's
not
going
to
be
there.
C
I,
don't
know
who's
going
to
be
there
in
person
for
the
Seaboard
meeting,
I
mean
it's
next
door
to
me.
So
it's
easy
for
me,
so
that
was
another
one
of
my
questions
like:
what's
the
agenda
for
and
how
many
people
and
etc
for
the
Facebook,
the.
A
The
agenda
is
something
that
is
the
main
agenda
point
for
today
and
I.
Think
Carson
has
prepared
slides
primarily
on
that
cool,
so
I
I've
taken
that
as
a
question
for
for
India
already,
okay.
A
Okay,
I'll
see
that
is
free
past
the
hour
and
I
think
we
are,
and
we
are
at
least
five
people
are
together.
Let's
get
this
started,
hello,
everyone.
This
is
an
igf
interim
of
the
Civil
working
group.
A
A
So
we
have
yeah
as
we've.
Basically,
basically,
we've
already
done
the
agenda
bashing.
We
we
want
to
talk
about
what
we
do
at
the
ITF
in
San
Francisco
I
want
to
follow
up
on
the
working
group.
Adoption
calls
on
edn
literacy
and
CDL
2.0
roadmap.
That
would
be
very
short,
and
then
we
can
continue
with
the
topic
of
core
topics
of
guardian
and
registration
of
taxes.
A
If
there
is
nothing
more
to
add
here,
Carson,
please
take
it
away
on
the
topic
of
what
you
suggest.
We
talk
about
in
the
itf17
agenda.
B
Why
do
I
see
two
versions
of
that
slide?
Take.
A
I
do
not
know,
frankly,
I
relied
on
everything
to
be
managed
by
medical
automatically.
A
B
I
think
it
does
look
all
right,
so
I
I
was
probably
could
use
this
meeting
to
do
a
little
bit
of
planning,
so
not
so
much
focus
on
any
particular
document,
but
just
see
where
we
are
with
the
various
documents
and
so
timing
wise.
We
have
three
and
a
half
weeks
until
the
internet
draft
deadline,
and
then
we
have
two
more
weeks
before
the
ITF
week.
B
So
this
is
kind
of
the
the
planning
Outlook
that
I
I
want
to
cover
today
and
I
would
just
like
to
go
through
a
number
of
documents
that
that
I
have
on
my
radar.
That
doesn't
mean
that
we
are
complete.
B
So,
let's
see
other
documents
come
up,
so
one
document
that
that
we
have
had
in
in
a
waiting
mode
for
a
while.
No
is
the
the
time
tag
document.
So
this
is
a
document
that
defines
civil
structures
to
represent
time
stamps
the
durations
and
and
periods,
and
this
has
been
stable
for
quite
a
while.
It
has
received
the
the
tag
allocations.
B
The
Target
locations
actually
came
before
RFC
89499
changed
the
registration
guidelines,
or
these
were
still
pretty
much
first
come
first
served
and
we
are
just
waiting
for
a
good
time
for
this
document
to
be
published
as
an
RFC
and
one
important
other
activity
about
information
about
timestamps
in
the
iitf
is
the
C8
activity
which
had
some
some
administrative
extra
Loops,
but
now
has
gone
through
an
ITF
last
call,
which
is
scheduled
to
close
tomorrow,
and
there
are
already
some
interesting
comments,
but
there
are
probably
no
impacts
on
the
the
way.
B
B
B
Okay,
so
please
feel
free
to
interrupt
me
at
any
time.
I'm
just
going
to
go
to
the
next
item,
which
is
sibo
picked
that
actually
passed
the
working
plus
call
last
year.
Already
it
actually
is,
is
a
document
with
two
Parts.
One
is
the
part
that
defines
the
the
tags
that
are
used
for
referencing
information
out
of
the
the
tables
that
silver
pack
defines
other
people
call
this
dictionary,
so
that
appears
to
be
pretty
stable.
B
We
had
one
one
major
change
by
by
using
the
the
only
two
table
subtables
for
one
for
sharing
and
one
as
a
generic
argument
table.
We
used
to
have
more
of
those,
so
we
merged
those,
and
but
we
really
want
to
have
before
we
go
ahead-
is
a
little
bit
of
implementation
and
user
experience
with
tables
set
up
so
right.
Now
the
the
draft
defines
a
tag
113
that
is
used
for
a
table
setup
that
is
setting
up
shared
and
argumentables
separately
and
I.
B
Think
we
actually
want
to
merge
this,
at
least
for
the
default
setup.
The
ideas
that
other
documents
that
make
use
of
package
may
go
ahead
and
Define
their
own
table
setup
mechanisms,
possibly
using
tags,
possibly
using
information
that
comes
out
of
media
types
and
so
on.
So
the
the
context
that
is
used
for
interpretation
of
the
sibo
data
can
also
provide
table.
Information
about
the
reference
tags
should
be
something
that
is
common
to
all
applications
of
sibo
pack.
B
B
So
maybe
we
want
to
have
one
more
interim
where
we
look
at
this,
maybe
in
two
weeks
I,
don't
know
that
that
would
be
my
suggestion,
but
my
suggestion
would
also
be
that
we
have
something
that
that
we
can.
Finally.
B
So
yeah
I
see
that
that
Martin
is
not
here.
B
B
So
the
next
item
is
the
three
documents
that
bring
us
forward
on
the
way
to
CDA
2.0.
B
There's
the
the
grammar
update,
which
is
essentially
a
fixed
document
for
for
8610
as
it
is,
we
Define
a
few
more
control
operators,
which
is
something
that
that
is
just
exercising
an
extension
point
that
8610
has
so
so
none
of
these
really
in
CDA
2.0.
But
there
are
things
we
we
want
to
have
in
place
and
the
the
part
that
is
going
to
be
the
the
one
of
the
major
components
of
CDA
to
zero
is
the
modules
document.
B
B
So
the
the
data
tracker
is
kind
of
writing
you
out
here.
Okay,
so
I
was
going
to
ask.
Do
we
want
to
do
this,
but
we
will
do
this
in
the
next
item,
but
that
would
be
something
where
we
probably
would
think
about
next
steps
at
117,
my
personal
guesses,
that
we
will
push
forward
the
grammar
update
and
the
control
operators
relatively
quickly,
because
the
the
grammar
updates
are
kind
of
yeah.
B
That's
some
things
we
need
to
do,
and
we
also
can
do
the
control
document,
because
that's
really
something
that
we
probably
will
be
doing
somewhat
regularly.
So
the
the
last
one
was
published
in
December,
20.
21,
so
maybe
having
one
of
those
every
two
years
or
so.
What
would
be
a
good
keep
alive
here?
And
this
is
essentially
based
on
feedback
from
from
various
specifiers,
so
yeah?
We.
We
need
to
discuss
this,
of
course,
but
I
I
don't
expect
big
surprises.
B
We
might
throw
out
some
of
the
proposed
control
operators
if
they
are
not
clear,
but
others
I
think
are
very,
very
obvious.
So
I
think
we
should
be
able
to
actually
work
in
Google
Plus
call
these
two
documents
pretty
soon.
The
modules
document,
of
course
requires
more
attention
and
and
feedback
from
people
who
have
used
it.
B
So
both
people
who
have
written
specifications
and
people
who
have
put
that
into
their
CDA
Tools
in
in
one
one
way
or
another.
So
all
three
drafts
are
implemented,
but
we
we
don't
have
multiple
independent
implementations
yet
and
that's
usually
a
good
thing
too
actually
have
so
I
would
expect.
We
will
discuss
CDA
modules
a
little
bit
beyond
117.
B
So
one
thing
that
that
has
been
discussed
on
the
list
a
bit
is
the
diagnostic
notation
and
it
seems
we
actually
want
a
document
that
goes
a
little
bit
beyond
the
original
purpose
of
the
this
IDI
and
literates
a
document
this.
This
was
just
a
simple
extension
for
for
civil
diagnostic
notation
civil
diagnostic
notation
was
originally
defined
in
in
RFC
7049
in
2013
and
has
been
carried
over
to
the
current
sibo
standard,
but
we
already
extended
it
once
in
the
context
of
cddl.
B
So
it's
a
bit
confusing
mainly
for
people
that
RFC
8610
extends
the
diagnostic
notation
of
RC
8949,
whether
it
comes
later
in
the
sequence,
but
that's
the
result
of
this,
so
the
the
attention
that
we
have
got
points
to
maybe
a
need
to
actually
Define
the
ABN
f
for
edn.
B
Of
course,
we
have
implementations
and,
and
implementations
probably
are
employing
a
puzzle
generator.
So
it
should
not
be
too
hard
to
translate
the
models
for
those
puzzle,
generators
into
ABN
f,
so
that
that
might
be
an
addition
we
might
pursue
once
we
we
have
adopted
this,
but
maybe
there's
also
other
work
that
that
is
useful
in
the
diagnostic
notation
context.
So
this
is
a
document
where
I
see
active
technical
work
before
us,
but
probably
not
something
that
will
take
Beyond
iitf
118.
B
So
RC
7049
said
that
diagnostic
notation
is
not
meant
to
be
passed,
and
that
was
a
pretty
strong
concern
that
people
would
think
that
the
diagnostic
notation
is
actually
how
you
interchange,
sibo
documents
and
that's
very
much,
not
the
intention,
but
I
think
we
have
survived
with
the
diagnostic
notation
and
the
actual
sibo
encoding
being
around
for
for
a
decade
now
so
I
think
the
the
danger
of
of
people
confusing
this
is
smaller,
so
I
think
we
can
now
go
ahead
and
Define
the
ABN.
B
Yeah
I
think
as
soon
as
the
the
the
proposal
is
I
mean.
If,
if
somebody
says
no,
let's
not
do
that,
we
can
stop
that
work
now,
but
my
my
intention
would
be
to
do
a
dash
or
one
of
of
the
draft
ATF
that
has
the
ABN
f
in
it,
and
then
we
can
discuss
whether
that's
useful
and
decide
as
a
working
room.
B
Whether
we
want
to
continue
with
this
or
not,
and
that
could
be
at
117
that
could
be
earlier
depends
on
on
how
long
it
takes
to
actually
get
the
ibnf
in
there.
B
Okay,
then,
we
had
some
interesting
discussion
about
deterministic,
encoding
and
I.
Think
we
have
I,
probably
shouldn't,
say,
cut
the
guardian
knot.
I
think
we
We
Now,
understand
why
this
discussion
was
so
difficult
because
really
we
have
a
standard,
deterministic
encoding.
We
have
a
common
idea
of
a
standard,
gymnastic
encoding,
but
we
also
have
the
DC
numeric
reduction
so
recently,
I
proposed
on
the
mailing
list
that
this
should
be
the
the
two
documents
we
get.
The
first
one
might
actually
even
be
informational
because
the
the
digitalistic
encoding
is
defined
in
8949.
B
So
it
would
just
provide
a
little
bit
more
explanation
and
maybe
Define
a
profile
section
4.2
of
RFC
8949
does
provide
applications
with
some
lenients
here.
So
that
would
be
one
document
and
the
other
one
would
pick
up
this.
This
idea
of
numeric
reduction,
that
is
in
DC
bar
and
Define
that,
but
it
probably
could
be
a
very
short
document,
because
it's
essentially
just
sits
on
top
of
standard
deterministic
encoding
to
to
address
a
specific
area
of
application
of
c-box
Christopher.
C
C
You
know
not
quite
sure
how
to
get
started
on
the
split,
but
we
you
know
we're
glad
to
work
with
you
on
on
that
so
or
get
advice
or,
however,
you
want
to
do
it.
So
the
I
think
the
the
thing
that
is
is
hardest
is
on
the
first
one.
Like
you
know,
how
do
we
explain
the
choices?
How
do
we
explain?
You
know
you
know
our
particular
profile
for
section
4.2
and
the
choices
that
we
made
and
you
know.
Ideally
it
should.
C
Maybe
you
know,
have
somebody
else's
profile
and
maybe
anyhow,
that's
the
you
know.
My
question
on
that
one
on
the
DC
board,
numeric
reduction-
I-
think
wolf
is
you
know,
can
also
pull
out
some
of
the
very
specific
test
cases
and
things
of
that
nature
in
the
three
languages
that
you
know.
C
We
implemented
DC
board
in
so
far
to
kind
of
show
where
all
the
the
dirty
edges
are
to
help
people
be
aware
of
it
if
they're
implementing
it
in
fourth
or
something
weird,
so
all
all
reasonable.
B
Yeah,
so
it
seems
for
DC
numeric
reduction.
There
are
some
choices
that
have
to
be
made
or
have
been
made
by
you
there.
It
would
be
possible
to
define
a
different
numeric
reduction
and
if
you
have
looked
at
my
proof
of
concept
implementation
that
works
differently
from
what
what
you
did.
So
we
would
try
to
make
sure
to
describe
exactly
the
the
numeric
reduction
that
that
we
agree
is
the
one
everybody
should
be
using
in
this
area
of
application.
B
But
of
course
we
have
at
least
one
additional
case,
which
is
people
are
not
using
a
numeric
reduction.
So
we
would
essentially
have
two
widely
implemented
a
widely
recognized
choices
here
and.
C
I,
think
is
it
really
is
it?
Is
it
just
two
or
do
you
I
mean?
Is
this
more
like
the
same
thing
with
the
profiles
in
one
I
mean?
Is
there
I
mean
I?
Could
you
know
I
certainly
could
see,
see,
I
mean
I,
don't
mind,
profiles,
I
guess
is
maybe
the
the
the
the
other
side
of
the
equation.
C
I'm,
not
I,
think
we
can
come
up
with
a
really
good
one.
That
will
be
hard
for
somebody
to
say,
there's
a
better
numeric
reduction
out
there,
but
there
still
may
be
weird
edge
cases
where
somebody
goes
I.
Just
can't
do
this.
On
my
you
know
old
8-bit
processor,
that
I'm
using
in
the
constrained
thing.
B
Yeah
so
I
I
completely
agree,
but
my
objective
here
would
be
to
find
the
the
two
points
that
have
the
the
largest
attractiveness.
So
we
get
a
lot
of
critical
mass
on
on
both
those
points.
B
So
so
people
don't
see
a
need
to
invent
another
profile,
but
we
will
will
be
attracted
to
one
of
the
existing
once
so
one
one
additional
profile
that
that
you
may
not
be
thinking
much
about,
but
that
I
think
is
also
interesting,
is
doing
the
numeric
reduction,
but
then
only
doing
preferred
encoding
and
not
deterministing
encoding
so
that
that's
still
one
useful
way
of
of
employing
this
yeah
I
think
we
should
explain
that
great.
B
So,
let's
try
to
work
on
those
yeah
and
and
the
optimistic
objective
would
be
to
have
documents
in
individual
Dash
zero
zero
stage
as
input
for
117.
So
we
can
discuss
the
the
further.
C
So
just
you
know
just
to
be
clear:
we're
talking
about
two
new
drafts.
We
would
basically
not
we
would
that.
Would
that
would
replace
the
current
Guardian
draft
and
move
that
forward
in
the
Seaboard
group.
B
C
B
Did
that
might
be
the
best
way
or
the
quickest
way
to
get
to
a
dash
zero,
zero,
okay
yeah,
then
we
have
some
other
active.
Oh
I
forgot
one
thing.
B
So
if
we
do
the
DC
by
numeric
reduction,
we
probably
also
want
to
think
about
the
best
way
to
support
this
from
cddl,
because
cddl
is
is
pretty
closely
wedded
to
the
generic
data
model
that
is
defined
in
8949,
and
if
we
actually
fold
some
of
the
parts
of
that
model
onto
each
other,
then
we
have
to
Define
how
to
to
write
cddl
for
that
and
that's
something
where
I
don't
know.
B
C
Yeah
we've
implemented
CDs
in
our
libraries
we've.
Actually
it's
not
in
our
libraries.
It's
in
our
tools.
We
have
cddl
1-0
support
now
and
you
can
like
point
to
a
dictionary
and
it'll
do
more
stuff,
but
it's
you
know
really.
One
of
you
know
it's
the
first
time
we've
we
mostly
use
it
for
a
diagnostic,
not
for
for
other
stuff,
but
I.
Think,
as
you
know,
the
the
year
advances
you
know,
will
you
know
move
toward
the
newer
cddl
and
you
know
wolf
will
be.
C
A
I
think
the
matter
is
not
so
much
about
how
to
represent
the
choices,
but
how
to
represent
that.
Some
choice
is
taken
away
from
the
application
and
is
normalized
in
the
model
and
whether
that
is
whether
that
will
happen
through
a
well-known
type
or
through
through
a
CDI
control.
We
can
still
find
out
over
time.
C
Yeah,
so
you
guys
feel
like
it's
in
a
separate
document,
probably
because
I
think
we
can
do
the
the
DC
bore
numeric
reduction
fairly
quickly,
whereas
we,
you
know,
we
don't
even
have
an
implementation
yeah
for
I
mean
on
our
end
at
least
so.
B
Yeah
I
think
the
the
difficult
part
comes
in
when
you
have
a
cddl
model
that
actually
spans
components
that
make
use
of
numeric
reductions
and
components
that
don't
so.
For
instance,
cozy
doesn't
do
numeric
reaction,
but
if
you
transport,
something
in
cozy
that
does
then,
then
you
have
areas
of
your
specifications,
the
new
and
areas
that
don't
and
we
need
to
find
a
way
to
to
write
this
down
without
having
tons
of
of
additional
stuff
in
the
model
that
is
just
distracting.
B
Okay,
so
the
next
item
here
is
other
active
work.
There
is
this
process
document
civil
draft
numbers
that
I
think
has
has
had
a
good.
B
Run
up
to
its
01,
but
I
think
we,
we
probably
should
be
leaning
back
a
little
bit
and
see
whether
what
we
have
written
up
actually
works
for
a
majority
of
of
cases
and
well,
it's
informational
anyway.
It's
it's
just
a
way
for
people
to
organize
their
work
with
a
location
of
code
points
during
developing.
B
Based
format
but
I
think
if
we
we
actually
agree
on
on
a
at
least
a
good
current
practice
might
not
be
the
best
current
practice,
but
a
good
current
practice
that
that
will
continue
to
be
a
useful
document
so
that
that's
one
thing
and
the
the
other
are
technical
documents.
I've
already
mentioned
DNS
sibo,
which
is
of
Interest
by
itself,
or
also
as
a
customer
of
sibo
packed.
So
for
me,
this
is
right
now
pretty
pretty
much
at
the
top
of
the
list.
B
B
Of
course,
the
idea
is
that
many
of
these
Corpus
models
will
come
out
of
rfcs,
but
then
we
have
found
a
number
of
rfcs
that
have
really
useful
cddl,
but
that
needs
to
be
packaged
in
a
slightly
different
way
and
it's
fixed
in
some
way.
So
it
can
be
usefully
referenced
from
other
documents,
so
this
is
yeah.
That's
between
informational
and
standard
strike,
because
at
some
point
people
will
run
to
reference
the
the
models
in
there
and
then
it
becomes
possibly
a
candidate
for
being
standard
strike.
B
So
I
don't
know
how
much
time
we
will
have
to
discuss
these
things
in
at
117,
but
these
are
things
that
I
think
are
are
active
and
yeah
I
probably
missed
something.
So
if
you
think
there's
something
else
we
we
should
discuss
at
117
I
would
like
to
hear
about
it.
B
C
One
item
that
well
I
actually
have
a
couple
items,
but
one
in
particular.
So
you
know:
we've
had
some
pushback
by
various
communities
by
that,
oh,
you
know
don't
use
seaboor,
because
you
know
you
have
to
register
tags
with
Ayanna
and
that
doesn't
really
happen.
It's
too
hard
et
cetera
Etc
and
we
said
no.
It
shouldn't
be
too
hard.
The
specs
says
that
if
you
use
these
different
ranges,
all
you
need
to
have
is
a
spec.
C
You
know
in
a
persistent
fashion,
so
we
did
one
not
for
DC
board,
but
for
gordian,
which
all
needs
six
tags.
That
are,
you
know
where
we
can't
use
sub
tags
and
stuff,
and
it's
in
a
Range
that
that
is
supposed
to
be
available.
C
For
you
know,
spec
only
does
not
require
an
hour,
an
RFC
track
document
and
you
know
Ayanna
kicked
it
back
to
us
a
couple
of
times
and
I
know
that
it's
you
know
been
pushed
to
Karsten
and
and
others
so
we're
basically
experiencing
what
other
people
were
warning
us
about.
C
Seabor
so
I'm
wondering
if
there's
some
way,
you
know
I,
don't
know
if
it's
a
process
document
or
whatever
to
either
add
Clarity
like
if
there
is
some
requirement
that
you
know
somebody
on
the
keyboard.
You
know
one
of
the
keyboard
chairs
has
to
check
off
to
say:
yes,
there
actually
is
a
spec
and
it's
a
real
spec
before
the
you
know
before
Ayanna
approves
that
that
isn't
what
it
says
in
in
the
Seaboard
document
yeah.
So
we
you
know,
we
need
to
clarify.
A
That
I
think
I
think
I
can
clarify
here
as
far
as
I
understand
that
the
the
the
pushback
here
was
because
the
document,
because
the
documents
are
because
there
was
something
that
has
been
this
touched
into
a
working
group
and
if
the.
If
the
intention
with
the
specification
was
that
the
process
through
working
group,
then
there
would
be
a
different
process.
If
you
came
there
with
something
that
is
not
that
that
you're
not
bringing
to
IDF
that
process
should
have
been
way
smoother.
C
There
were
two
documents:
yeah.
There
are
two
documents,
so
maybe
this
there
was
a
confusion
there,
because
you
know
the
DC
bore
is
kind
of
what
dispatch
you
know
said:
hey
you
know
the
Seaboard
Community
ought
to
consider
taking
taking
this
up
the
gordian.
They
basically
said.
You
know
you
need
to
find
a
customer,
you
need
a
requirements
or
whatever
they
call
it
that
you
need
this
other
the
problem
statement,
document
Etc
and
was
not
referred
to
another
working
group.
C
So
you
know
we
just
needed
to
go
ahead
and
get
those
six
tags
in,
because
there
are
people
actively
using
this.
We
also
have
more
attacks.
We
want
to
register
at
an
even
higher
level.
You
know
at
a
you
know,
even
higher
numbers
that
are
very
specific
to
you
know
Industries.
So,
for
instance,
you
know
we're
using
seabor,
for
you
know,
cryptocurrency
wallets
that
have
you
know
some
very
specific.
C
You
know
things
that
are,
you
know
been
in
use
for
two
years,
so
you
know
we
we'd
also
like
Clarity
on
the
the
higher
tags
as
well.
So,
but
you
know
these
quartet,
you
know
these
core
six.
We
feel,
like
you
know,
we
we
spent
some
effort
to
to
make
it
that
that
they
were
a
small
number
of
tags.
C
C
What
we
don't
understand
is
how
we
could
have
let
Ayanna
know
you
know
not
to
to
hold
it,
and
so
you
know
again,
I
don't
know
if
that's
a
a
process
document
or
just
our
misunderstanding
and
the
specific
circumstances
of
our
of
the
fact
that
we,
you
know,
came
to
the
community,
which
sort
of
leads
me
to
my
next
topic,
which
is
you
know,
is
there
interest
by
seaboor
Community
to
have
you
know
a
seaboor
RFC
on,
say
graph
data
specifically
and
in
particular
graph
data
that
supports
Merkel
and.
A
A
C
A
I
think
this
this
would
go
into
the
agenda
wise
into
the
block
of
Guardian.
So
can
we
can
we
can
we
keep
the
keep
the
order
we
had?
We
had
on
the
agenda
sure.
C
B
Yeah,
let
me
try
to
to
answer
the
the
procedure
question.
So
the
the
operation
of
registries
is
generally
defined.
C
B
And
the
the
text
in
in
8949
which
ultimately
defines
how
to
run
these
Registries
makes
use
of
terms
that
are
defined
in
in
RFC,
81
26.
and
one
concept
that
8126
uses
a
lot
is
that
of
a
designated
expert.
So
there
is
no
connection
to
the
working
group
or
the
hurts
quite
likely.
The
the
designated
experts
are
somehow
active
in
a
working
group
as
well,
but
that's
not
officially
part
of
the
procedure
right
now.
The
two
designated
experts
for
Sea
World
tricks,
if
I
remember
correctly,
are
Christian
and
I.
Yes.
B
So
when
you
look
into
the
the
section
9.2
of
RFC
8949
this,
this
is
pretty
tough,
but
it
says
that
the
the
tanks
between
24
and
32
76
7.,
are
assigned
by
the
specification
required
model
which
is
defined
in
section
4.6
of
Roc
81,
26
I
know
these
numbers
by
by
heart,
because
I've
been
writing
a
few
INR
considerations.
Sections
in
the
last
couple
of
weeks
anyway.
B
So
specification
required
is
a
special
case
of
expert
review
where
the
expert
is
supposed
to
not
only
review
the
registration
request
itself,
but
also
a
specification
that
is
required
to
come
with
the
registration
request
and
well.
I
did
a
first
review,
it's
not
something
that
can
be
done
just
in
a
snap.
It
does
require
some
some
thinking,
so
we
we
also
made
sure
that
we
have
one
plus
two
numbers
available
that
are
first
come
first
served,
which
is
another
set
of
rules
defined
in
8126.
B
That
really
make
sure
you
get
the
number
right
away.
So
if
the
priority
is
is
on
speed,
that's
the
number
range
you
want
to
use.
But
of
course
these
are
not
not
the
the
nice
numbers.
These
are
the
numbers
that
that
cost.
You
three
bytes
instead
of
two,
so
it
may
be
desirable
to
try
to
get
numbers
in
in
the
24
to
255
range.
B
I
regularly
sent
an
output
of
of
a
script
that
looks
at
TAG
allocation,
and
you
have
to
remember
that
take
a
location
is
a
process
that
has
to
work
for
well,
half
a
century
or
so
until
we
completely
are
at
the
new
format.
So
we
shouldn't
be
allocating
tons
of
tags
in
one
year.
So
we
are.
We
then
don't
have
any
free
tag
numbers
in
the
next
year,
so
right
now
about
30
of
the
one
plus
one
space
are
taken.
B
So
there
is
some
frugality
that
the
experts
will
try
to
exercise
in
in
allocating
these
numbers.
It's
that
doesn't
mean
that
it's
hard
to
get
them,
but
it
just
means
it
will
get
a
second
look,
which
is
different,
for
instance,
for
one
plus
zero,
which
is
already
defined
as
standards
action
in
geography,
because
the
there
are
only
11
left.
B
So
we
we
looked
at
the
specification
and
there
are
some
questions
that
that
I
haven't
written
up
yet
and
what
confused
us
was
that
this
specification
is
is
was
both
presented
as
a
completed
specification
that
is
now
trying
to
get
tags
and
a
specification
that
might
be
input
to
an
ietf
process
that
is
likely
to
to
change
it.
B
B
B
So
if
you,
you
really
want
to
prioritize
the
the
speed
of
getting
the
allocation,
then
going
into
the
first
come
first
served
mechanism
would
be
good.
Okay,
so.
C
A
Okay
and
then
I'll
I'll
I'll
do
that
next
find
very
quickly,
because
then
we
can
use
I.
Think
the
rest
of
the
of
the
time
for
accordion.
We
had
working
group
adoption
calls
for
again.
Literals
and
CDI.
2.0
custom
already
gave
away
that.
Yes,
they
are
now
adopted
because
we
have
good
support
for
the
ctdl
2.0
documents
and
foreign.
A
Very
comfortable
accepting
this
based
on
the
interim
input
that
says
yep,
it's
like
look,
it's
looking
good
and
nobody
was
complaining.
So,
yes,
let's
go
ahead
with
this
offers,
which
is
customer,
think
please
submit
as
ITF
documents.
C
Yeah,
so
let
me
explain
some
of
our
dilemmas
that
are
going
on
right
now,
with
with
gordian
envelope
so
right
now,
gordians
pieces
of
the
gordian
envelope
have
been
in
use
in
practice
in
mostly
cryptocurrency
communities
for
the
last
couple
of
years
and
the
guardian
envelope
kind
of
pulls
it
all
together.
It
also
is
connected
Loosely
to
w3c,
in
the
sense
that
there
have
been
a
number
of
parties
there
who
are
frustrated
with
a
particular
graph
data
format.
Jason
LD
and
you
know,
there's
been
a
proposal.
C
I
think
there's
an
ITF
draft
on
taking
Jason
LD
and
doing
it
with
with
with
seabor,
but
also
loses
a
lot
because
it's
still
tied
to
its
you
know:
Jason
LD
Roots.
That
being
said,
there's
really
not
very
many
people
in
the
ITF
community
that
are
are
demanding.
C
You
know
graph
Seaboard
data.
We.
C
Etc
and
and
it's
not
a
very
transparent
process,
so
I
don't
really
understand
all
their
stuff,
but
they're
using
seabor
and
there's
been
various
inquiries
from
them
of.
Maybe
you
know
in
future
things
you
know
Levering
leveraging
some
of
the
gordian
capabilities
to
do
to
do
hash
based
Collision
they.
The
current
mdl,
which
is
being
used
for
mobile
driver's
licenses
in
Europe
and
in
the
United
States
with
is,
is
seabor
and
it
has
a
a
very
simple
hash
based
illusion
technique
in
it.
C
But
it
you
know
it's,
you
know
it's
ISO
and
others
are
wanting
to
do
do
that
stuff
with
that,
so
you
know
so
our
challenge
has
been.
You
know.
Is
the
ietf
community
interested
in
this,
and
you
know
we
wrote
up
some
use
cases
of
hey.
You
know
rf's.
You
know
there
are
two
rfcs
that
say
that
you
know.
Are
you
know
that
ITF
standards
should
minimize
data
and
there's
the
human
rights
considerations
Etc,
which
you
know,
makes
hash
based
collision?
C
And
you
know
other
techniques
for
minimal
disclosure
recommended,
but
they're.
You
know
no
ITF
specs
that
we
know
of
are
doing.
You
know
this
so
we
may
have
customers
in
ITF,
but
we
don't
know
because
right
now,
they're
not
asking
for
it.
So
that's
kind
of
the
root
of
the
problem
that
we
went
when
we
went
before
dispatch
is
you
know
we
have
a
solution
for
various
parties
that
just
happen
to
be
using
keyboard,
but
otherwise
ITF
so
far,
we've
not
identified
and
I
ITF
group.
There
is
some
discussion.
C
There
was
at
least
some
discussion
in
passing
that
the
by
the
supply
chain
group
that
you
know
maybe
gordian
envelope
might
you
know
be
something
that
they
would
like
to
use,
but
I,
don't
think
they're
really.
You
know
at
all
focused
at
that
layer.
You
know
the
the
data
layer
at
this
point
and
I,
don't
really
I
think
they
would
rather
see
somebody
else,
do
it
and
then
they
could
leverage
it
I
could
be
wrong
there.
But
that's
you
know.
My
interpretation
of
you
know
following
that
discussion.
C
You
know
separate
from
you
know.
One
of
the
other
issues,
just
to
be
blunt,
is
and
I
know
we're
running
out
of
time
is
that
we
really
want
gordian
envelope
not
to
be
in
the
security
area.
C
You
know
we're
really
only
using
one
cryptographic
function,
which
is
a
hash
we're
using
shot
256.
It's
well
understood
we're
using
a
hash.
You
know
a
Merkel
hash
tree,
which
is
well
understood.
Yes,
it
ought
to
get
you
know
additional
review,
but
it
you
know
we
really
want
to
focus
on
it
as
a
data
standard,
because
you
know
you
can
put
cosay
into
it.
You
can
put
you
know,
other.
You
know
all
kinds
of
other
cryptographic
formats
Etc
into
it.
C
Similarly,
you
know
we
have
tags
for
compression,
as
we
have
some
tags
for
encryption,
but
those
don't
are
not
do
not
specify
which
one
and,
in
fact
are
in
our
example.
You
know
we're
using
ITF
standards,
like
you
know,
Chacha
poly,
stripped
to
the
RFC
and
and
such
so
we're
really
trying
to
avoid
that's
another
layer.
You
know,
so
we
don't
want
to
get
bundled
into
Jose.
You
know
2.0
or
or
something
of
that
nature
either.
C
You
know
and
I
I
presume
there
might
also
be
people
that
maybe
don't
care
about
the
hash
based
Collision
but
would
like
to
have.
You
know
we
believe
a
seaboor
function,
a
seaboor
approach
that
can
handle
at
least
three,
maybe
four
of
the
different
graph
formats
that
are
out
there.
Edge
Edge
graphs,
node
graphs.
C
You
know
some,
you
know
single
one-way
graphs
Etc,
so
we
also
feel
like
there
might
be
some
desire
to
have
some
standardization
around
how
to
put
graph
data
into
into
seabor
that
might
be
valuable
to
people.
But
but
again,
just
just
brief
note.
A
We
need
to
move
ahead.
Just
a
brief
note
if
you
want,
if
you
want
answers
too,
please
come
to
the
point
and
make
it
short,
because
we're
about
to
run
out
of
time
right.
C
So
I'm,
just
trying
to
puzzle,
you
know
is,
is
the
you
know,
are
the
chairs
of
the
community
and
other
members
who
are
here
today
or
might
be
at
117
at
all
interested
in
taking
some
measure
of
Guardian
envelope
and
working
with
us
to
you
know:
have
it
be
a
seaboar
art
area
project?
And
if
not
you
know,
we
let
you
know,
let's
you
know,
we
don't
need
it
to
do
what
we
need
to
do.
C
We
can,
you
know
you
know,
but
but
we
have
multiple
companies
that
are
are
using
envelope
now,
and
you
know
we've
like
we
would
prefer
that
you
know
standards
first,
but
you
know
we
also
have
to
have
implementations
so
well.
A
The
chip,
the
chair
position
is
very
simple.
My
task
in
in
that
role
is
just
to
assess
the
the
the
interest
within
the
working
group
with
my
chair,
head
off.
I
do
have
some
interest
in
in
expressing
graph
structures.
A
I
think
I've
pointed
you
to
to
to
Coral
at
an
at
an
early
important
time
that
my
personal
interest
is
mainly
with
using
sibo
for
constrained
applications
where
that
already
have
something
that
that
already
work
on
minimized
data
and
will
not
will
probably
not
work
with
larger
data
structures
that
are
inflated
by
by
the
possibility
of
having
Illusions.
So
things
will
be
minimized
beforehand,
specifically
for
them,
but
that's
more
of
my
my
personal
take
here.
So
one
was
money.
B
Yeah
so
I
think
these
are
interesting
questions
on
the
other
hand,
I'm
actually
looking
at
the
the
document,
I
hope
I'm
looking
at
the
right
document,
draft
McNally
envelope
O2-
and
this
is
interesting-
it's
a
collection
of
things
that
that
maybe
aren't
as
closely
relate
to
each
other
as
you
you,
yes,
I
agree,
try
to
to
make
us
believe
in
the
document,
so
in
particular
the
the
tags
204
205,
206
interesting
in
that
day
embody
the
the
choice
of
a
specific
algorithm.
B
B
Okay
and
206
is
compressed
with
deflate
and
I
think
these
are
all
tags
which
are
really
likely
to
to
change
over
time,
as
people,
for
instance,
get
better
compression
libraries.
There
are
now
at
least
two
compression
libraries
that
that
are
widely
used
in
in
certain
areas
of
application
that
are
replacing
deflate
after
it
has
been
kind
of
the
de
facto
standard
for
for
a
quarter
of
a
century.
B
C
So
we
may
have
failed
one.
Second,
we
I
think
have
failed
somehow,
either
in
our
spec
or
in
our
writing
or
whatever,
to
say
that
these
were
very
specifically
designed
so
that
you
could
have
other
choices.
We
just
simply
said
you
know
that
the
we
just
simply
defined
a
default
choice.
That
was
a
current
ITF
standard,
but
all
of
these
we
know
people
are
going
to
be
doing
other
forms
of
compression
and
encryption
and
you
know,
etc,
etc.
So
the
design
was
that
these
were
independent.
C
We
may
have
failed
in
it
in
in
our
expression
of
it
in
this
RFC
to
to
demonstrate
that
these
were
independent.
But
you
know
we
don't
really
want
to
Define
compression
standards.
We
just
simply
say
if
it's
within
this
tag,
it's
compressed,
you
know
if
it's
within
this
tag,
it's
encrypted.
If
it's
within
this
Tech,
you
know
Etc,
the
only
one
that's
kind
of
challenging
for
for
us
was
the
the
hash,
algorithm
and
and
part
of
that
just
came
out
of
the
you
know.
C
Recognition
of
you
know
likely,
if
just
because
of
a
variety
of
different
factors,
if
we
you
know
because
our
original
version
was
Blake
and
we
basically
retreated
to
Shaw
256.-
was
that
there
was
a
lot
more
dependencies
there
and
we
kind
of
felt
like
well.
If
there
needs
to
be
another,
you
know
algorithm,
you
know,
you
know,
saw
three
God
forbid,
you
know
and
there's,
and
that
would
probably
just
be
a
different
route
envelope
tag.
That
would
basically
say
you
know,
use
this
other
half.
C
You
know
it
would
be.
You
know
another
one
plus
one
that
you
know
is
envelope
not
using
shot
256,
and
we
don't
really
want
to
specify
that
right
now,
Sean
Shaw
256
has
a
long
life,
so
I
think
we
may
have
failed
there
and
would
love
to
have
guidance
in
in
you
know,
expressing
that
better.
C
You
know
and
again
I
think,
there's
a
you
know,
really
good
likelihood
that
you
know
unless
there
are
more
people
in
the
community
that
the
you
know
in
the
Seaboard
community
that
want
to
tackle
this,
that
we
just
continue
implementing
this
have
multiple
implementers
and
we
come
back
to
the
ITF
Community
later
for
standardizing
seabor
I
mean
Guardian
on
Seaboard,
and
you
know
right
now.
C
It
feels
like
to
me:
that's
you
know,
you
know
greater
than
50
chance,
but
I
at
least
want
to
throw
it
out
that
you
know
that
it
is
possible
if
there's
critical
mass
in
the
Seaboard
Community
to
to
do
this.
That
we'd
be
glad
to
do
that
DC
board.
On
the
other
hand,
we
absolutely
want
to
do
everything
we
can
to
make
sure
at
least
DC
bore
and
the
numeric
reduction.
C
Things
are
well
defined
and
we
really
appreciate
Carson
that
you've
been
thinking
deeply
about
this
and
have
kind
of
pulled
together.
You
know
something
that
I
think
will
address.
You
know
various
people's
concerns,
so
what's
separate
that
happens
to
be
that
Guardian
uses
DC
board.
B
What
I
would
like
to
point
out
is
that
we
have
a
registry
for
hashtag
with
us,
so
have
a
look
at
RFC,
1954
and
I.
Think
we
really
want
to
make
use
of
that
registry
in
any
format
that
is
supposed
to
live
for
for
a
certain
amount
of
time.
We
have
a
registry
for
encryption,
algorithms,
and
encryption
is
complicated
enough,
that
this
requires
some
some
pretty
significant
thought
and
that
that's
defined
by
1952
and
and
filled
in
by
1953..
B
So
it
seems
that
the
the
202
is
essentially
a
way
to
exercise
a
function
that
that
is
defined
somewhere
else
and
that
just
gets
a
number
in
in
the
table
in
in
section
six
of
of
your
document,
I
think
we
have
to
discuss
this
a
bit
because
that
that's
a
place
where
I
would
say
the
specification
actually
has
a
big
hole,
because
those
functions
are
not
nearly
defined
by
by
the
document.
B
C
Okay,
so
let
me
so
I
guess
the
question
is,
you
know
so.
I
I
understand
your
review
as
the
designated
expert
for
these
numbers,
and
if
this
is
going
to
be
a
seabor
group
item,
you
know
these
concerns
and
you
know
affixing
them
and
addressing
them.
C
Etc
are
you
know
things
that
we
need
to
address
to
move
toward
consensus
in
the
seabor
community
in
ITF,
but
in
the
meantime
you
know
that
might
be
another
year
to
to
do
to
do
that
and
if
we're
not,
if
there
isn't
going
to
be,
you
know,
you
know
consideration,
we
need
to
kind
of
move
ahead.
If
this
isn't
going
to
be
a
you
know,
a
a
seaboard
work
item
you
know,
is
our
only
choice
to
move
to
the
the
three
bites.
C
I
I
hope.
Not
you
know.
We've
made
some
decisions
there.
You
know
you,
you
know
the
known
value
thing.
Maybe
we
could
architect
a
a
better
version.
I'm
gonna
I'll
talk
with
him
about
it.
It's
mostly
because
we
kept
on
running
into
assertions
that
were
the
same
and
large,
and
we
just
wanted
to
be
able
to
have
a
very
quick
way
to
have
a
reference.
C
Look
up
for
things
like
you
know,
for
the
common
you
know,
predicates,
you
know
without
having
to
go
to
an
Anna
registry
and
a
new.
You
know
a
new
tag,
and,
and
all
of
that
so
maybe
we
could
do
it
in
a
better
way,
but
we
thought
that
at
least
all
the
other
elements
were.
You
know
independent
with
the
exception,
as
I
said,
the
hash
algorithm.
C
You
know
we
have
some
experience
from.
You
know
the
the
you
know
the
people
that
are
trying
to
you
know
standardize
with
file
coin
ipfs
Etc
with
their
kind
of
weird
tagging
of
hashes
for
for
con.
What's
it
in
anyhow,
there's
that
you
know
they're
also
trying
to
advance
another
hash
table
draft,
and
we
just
wanted
to
get
out
of
that.
C
You
know
we
just
need
a
a
a
hash
tree
that
is
relatively
safe
and
consistent
and
that
you
know
you
don't
have
to
do
a
lot
of
games
to
sort
of
figure
out.
Oh
well,
you
know,
do
you
I
I,
don't
support
Blake,
3
and
thus
I
need
to
notify
the
party
that
I
don't
support.
Lakefree
I
only
support
nist,
algorithms
and
all
of
that
stuff.
We
were
just
trying
to
avoid
that
by
saying
this.
Just
lists
for
now
use
Shaw
256,
it's
well
supported.
It's
well
understood.
C
It
has
maybe
some
potential
weaknesses,
but
nobody
really
knows
you
know.
When
those
will,
you
know
when
those
will
come
into
play,
and
you
know
we
have
a
strategy
for
doing
that.
So
in
lieu
of
the
seaboor
community
tackling
this
we're,
you
know
we
would
really
like
to
see
these
tags.
You
know
you
know
accepted
soon
so
without
having
to
go
to
the
three
bites.
B
Yeah,
that's
probably
a
place
where
the
designated
experts
will
will
have
a
conversation
with
you
why
certain
things
cannot
be
done
in
three
bytes
instead
of
two
yeah,
but
I
think
that
that
we
first
of
all
have
to
understand
the
specification
and
but
the
the
strategy
of
the
specification
is
to
deal
with
egg
with
agility,
and
we
also
have
to
understand
this.
There's
two
or
two
things
so
I
think
we
should
we
need
to
close
this
meeting.
We
should
continue
this
discussion
offline.
C
Previous
item
I
would
love
there
to
be
some.
So
this
is
not
what
the
spec
says.
This
is
not
what
you
know
so:
I'm
I'm
fine.
If
that
is
the
way
it
has
to
be
that
the
you
know,
designated
experts
have
to
deeply
understand
the
choices
that
we
made
and
and
request
changes,
etc,
etc.
But
that's
not
what
the
spec
says.
The
spec
says
that
a
DOT.
You
know
that
the
the
doc
has
to
have
a
clear
specification.
C
So
if
that
is
not
true,
we
we
have
a
lot
of
other
companies
and
organizations
that
want
to
start
using
seaboor
and
are
going
no
we're
not
going
to
use
seaboor
because
we
have
to
register
these
tags
and
registering
a
tags
is
a
pain
in
the
ass.
This
is
an
example
of
that.
So,
yes,
you
know.
Maybe
you
know
we
just
have
to
you,
know
Punt
and
say
we're
only
going
to
try
to
register
the
three
byte
tags
and
do
the
first
use.
C
So
what
ever
and
tell
everybody,
just
don't
even
bother
with
anything
that
isn't
a
three
byte
tag.
I,
don't
think!
That's
a
good
idea
that
you
know
and
again
that's
not
really
what
the
spec
says
so
I
would
love
to
have
some
clarity.
C
You
know
from
the
Seaboard
community
of
what
is
the
designated
export
supposed
to
review
or
not
review
in
these.
B
So
let
me
quickly
answer
that
between
the
two
levels,
there
is
a
section
4.6
in
RFC
8126
that
that
is
probably
useful
to
to
read,
because
that's
the
section
that
is
being
referenced
by
8949.
Unfortunately,
it's
not
being
done
by
an
actual
exception
reference,
so
that
that's
something
we
didn't
quite
get
right.
The.
B
I'm,
sorry,
all
right,
8126,
it's
in
the
26.
got,
it
sorry
got
it
and
there
is
a
section
4.6
and
there
are
things
that
are
required
about
the
specification
that
are
written
down
only
there
and
and
maybe
you
you
get
a
better
feeling
of
what
what
we
are
trying
to
achieve.
C
A
I
will
pass
and-
and
maybe
as
a
note
on
on
algorithm
agility
I
think
generally,
if,
if
something
comes
into
the
designated
experts,
that
does
not
have
kind
of
that
says
that
yeah
we're
picking
one
algorithm
and
that
will
be
good
for
a
long
time.
C
C
Okay,
I
will,
you
know,
talk
with
wolf
and
the
rest
of
the
the
accordion
Community
about
this
and
move
forward.
I.
Thank
you
for
your
time.
C
I
know
we're
running
late,
so
are
is
any
of
this,
a
topic
for
the
iitf
meeting,
because
you
know
we're
hoping
to
bring
some
of
the
Seaboard
Community
who
are
not
active,
ITF
members,
the
DC,
the
the
excuse
me
the
gordian
community
who
are
not
currently
ietf
participants
to
the
San
Francisco
meeting,
because
a
lot
of
them
are,
you
know,
on
the
West
Coast.
B
Would
hope
that
we
have
completed
the
discussion
by
that
point,
but
okay
cool
there
are
things
that
that
we
want
to
discuss
further
from
there.
A
Thing
is
we:
we
do
have
a
one
hour
slot,
so
yeah
I
I
still
have
to
do
the
scheduling,
but
at
tops
this
I
think
tops.
This
will
get
like
15
minutes
and
if,
if
you
allow
me
in
the
personal
comment,
I
think
you'll
have
to
to
bring
things
to
the
point
very
fast
to
get
also
discussion
out
of
those
15
minutes.
A
B
C
C
Some
side
meetings
so
we'll
that
also
can
be
topic
for
side
beams.
So.
A
That
is
definitely
a
good
idea
and
something
that
we'll
need
to
advertise
through
the
sibo
channels
and
before
we
get
kicked
out
of
the
room,
which
is
probably
any
second
now.
Thank
you,
everyone
for
being
here,
thanks
for
the
discussions
and
I'll
try
to
make
all
of
this
into
a
preliminary
agenda
for
ITF
117.