►
From YouTube: IETF-CELLAR-20230404-1900
Description
CELLAR meeting session at IETF
2023/04/04 1900
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
C
Excellent
boy
that
was,
that
was
a
hang
time.
I
thought
I
I.
You
know,
of
course,
I
had
my
I
had
all
my
sound
off
because
we
were
I
was
doing
the
remote
participation
meet
Echo
client
in
the
room,
so
I
didn't
want
to
screw
that
up,
and
so
I
was
like
how
many
things
did
I
have.
How
many
places
did
I
mute
this,
where
I
need
to
turn
it
back
on.
C
So
I
would
like
to
thank
the
working
group
for
being
here
to
provide
adult
supervision
now
that
Michael
and
I
are
still
recovering
from
our
ITF
meeting
last
week,.
C
But
yeah.
C
A
C
Well,
of
course,
the
other
thing
is
for
everybody
in
your
time
zone
is
calling
you
in
your
time
zone
right
so.
A
C
Have
you
been
bad,
exactly
cool
so
welcome
to
everybody
else,
of
course,
as
well,
and
so
I've
done
a
little
chewing
on
the
agenda
that
we
have
in
headstock
since
this
morning.
So.
B
Yeah,
it
seems
like
you,
didn't,
send
it
so
I
think.
Maybe
a
few
people
aren't
here
because
they
forgot
about
it.
I.
A
A
I
was
like
that's
weird
Why:
didn't
it
go
out
so
I,
don't
know
I
mean
I
did
post
the
agenda
to
the
system
so
like?
Maybe
it
just
didn't
work.
A
They
I
think
I
think
maybe
we
should
should
ask
the
question
yeah
like
isn't
the
agenda
normally
go
out
when
we
post
it
or
is
that
no
longer
a
thing
or.
C
A
C
And
I
figure,
I'll
type
margins
name
in
because
he's
been
he's
been
typing
so
busily
on
flag.
But.
A
So
it
didn't
send
it
did
not
post
an
agenda.
Okay,
all
right!
Well,
while
you're
doing
that.
Maybe
I'll
send
the
mail
complaining
about
why
I
didn't
do
that.
Why
it
didn't
send
a
message
perfect.
C
Perfect
and
it'll.
Take
me
a
second
to
get
everybody's
name,
spelled
correctly
and
so
stalling
is,
is
working
well.
C
C
C
Do
we
want
to
accept
the
meeting
from
the
except
the.
B
C
C
So
this
is
greatness
and
okay,
so
that
happened
so
now.
Would
we
like
to
accept
the
meeting
minutes
from
the
last
meeting?
C
C
Excellent
perfect
so
accepted
without
objection.
C
Okay,
greatness
I,
updated
the
working
group
document
status
and.
C
Two
large-ish
sets
of
changes
for
atrovska.
C
It
is
now
waiting
for
write
up,
because
the
last
call
ended
and
basically
Murray
should
be
as
soon
as
he
recovers
from
his
ITF
meeting.
He
he
should
be.
He
should
be
putting
this
on
a
agenda
for
an
upcoming
ISD
telechat,
where
every
everyone
will
ballot
on
it
on
the
document
there
and
actually,
if
we
are
kind
of
walking
our
way
through
the
Milestone
review
a
little
bit
and
then
latroska
issues.
C
So
so,
basically,
the
waiting
for
write-up
is
basically
just
just
Murray
making
sure
that
he's
happy
with
the
thing
being
balloted
by
the
entire
isg
and
then
putting
it
on
an
agenda.
So
on
that
on
the
technical
aspect,
there
there's
there's
nothing
that
we
are,
that
there's
nothing
that
we
are
gating
on.
C
C
C
C
C
About
a
month
almost
exactly
a
month
ago,
yeah
Ellen
Davies
is
good,
so
yeah
I.
A
I
I
remember
this
discussion
and
I
think
that
actually
he's
a
little
bit
he's.
He
didn't
quite
understand
some
of
the
parts,
but.
C
Yeah
and
Andy
said
that
yeah
yeah
do
you?
Does
anybody
remember
if
we
replied
to
this.
B
C
A
Container
format,
we
changed
that
to
archive.org
reference.
A
And
you
responded
to
this
question
about
how
we
dealt
with
versioning
and
I.
Don't
know
that
he
understood
the
answer,
but
he
did
get
an
answer.
C
A
C
D
Do
they
have
to
review
the
new
draft
since
I
made
one
this
weekend?
They.
A
C
C
That
so
so
yeah
so
I
started
looking
earlier
today,
which
would
have
been,
which
was
later
than
I'd
hoped,
and
we
do
have
formal
write-ups
of
this
part
of
the
ITF
process.
But
what
what
they've
been?
What
they've
been
putting
on?
C
The
last
couple
of
agendas
was
like
YouTube
slide,
YouTube
videos
of
it,
so
I
wanted
to
get
I'm
going
to
and
I
can
do
this
write
the
nice
people
on
the
emoder
folks
and
ask
if
we
can
get
a
copy
of
the
slides
just
for
me
to
run
through
that
part
of
this,
the
slides
with
the
with
the
group
and
that
I
think
I
had
that
at
the
bottom
of
a
thing
for
any
other
business
for
For.
An
upcoming
meeting.
C
But
but
yeah
so
you're
Michael.
What's
your
walking
everybody
through
with
the
reviews,
as
as
good
good
good
to
know
so?
Yes,.
D
A
I
would
say
that
no
I
would
just
I
would
just
leave
it,
leave
it
be
for
a
month
or
so.
Until
we
get
review
comments
on
version
four.
A
And
unless
there's
something
really
urgent
but
I
can't
imagine
that
there
really
is,
but
just
leave
them
as
pull
requests
or
something
like
that.
C
So
yeah,
so
so
the
way
this
works
and
jump
in
here,
anytime
Michael,
is
that
the
so
there
are
15
people
on
the
internet,
engineering,
Steering
group-
and
this
is
a
standards
track
document,
so
that
requires
at
least
10
people
to
read
the
document
and
ballot
either
yes
or
no
objection.
C
So
at
least
two-thirds
of
the
area
directors
will
be
we'll,
be
reviewing
the
document
and
they
have
not
seen
it
before
so
you
may
get.
You
may
get
helpful
comments
and
you
may
get
somewhat
confused
questions
when
I
was
on
the
isg
I
wrote
plenty
of
both
so
Michael
is
Michael
is
giving
us
good
guy
advice
here,
which
is
to
it's
okay,
to
start
but
be.
C
A
Yeah,
don't
just
leave
it
as
as
there
don't
don't
don't
don't
go
further
with
it
until
until
we
have
we're
clearly
stable
with
what
we
have,
because
at
this
point
we
could
still
put
those
new
features
in
this
in
version
four,
if
you
wanted
to
right
as
far
as
the
documentation
process
goes,
maybe
that
makes
no
sense
from
a
from
the
status
on
the
ground
right
of
implementations
Etc,
but
but
what
I
really
don't
I
just
don't
want
to
confuse
the
isg
into
thinking
that
there's
things
that
we
that
there's
things
that
we
have
yet
to
do
that
we
we
actually
promise
to
do
right.
D
And
follow-up
question:
that's
for
ebma
my
almost
same
question:
we
have
at
least
one
or
two
features
that
we
want
to
add
as
ubml2
one
of
them
is
rational
numbers.
I
think
we
are
good,
so
technical
solution
now
that
we
just
need
to
make
a
document
for
it
so
I
same
question.
Should
we
start
making
a
new
document
and
I
think
a
sentence.
A
A
I
think
it's
a
reasonable
thing
to
to
start
an
ebml
V2
document.
Now
I,
don't
know
whether
we
want
to
make
this
document
a
a
diff,
so
we
just
add
things
to
the
existing
document
or
whether
we
want
to
really
revise
the
whole
thing.
As
Abyss
document
I,
don't
know
the
answer
to
that
question.
C
C
I
didn't
mean
to
shut
down
discussion.
I
was
just
saying
we
might
want
to
think
about
that
as
part
of
as
part
of
a
diff,
a
different
but
aligned
agenda
item.
D
Okay,
actually,
some
of
the
things
we
want
to
add
in
in
Metro
Square
five
will
need
the
rational
number
from
ebml2,
so
I
think
we
should
start
with
ebml.
Okay,
that
mean
it
should
be
permissioned
before
as
well,
but
I
mean
if
it's
just
update
document
with
new
things,
it
shouldn't
be
very
big.
D
C
Okay,
cool
so
so,
and
and
I
think
it's
probably
worth
me
actually
saying
this
out
loud
for
the
purposes
of
all
the
discussion
about
about
what
you
know.
What
what
when
to
start,
what
the
ietf
approval
process
is
going
to
focus
on.
What's
in
the
data
tracker,
not
so
much
what's
in
GitHub.
C
So
if
we
work
on
stuff
in
GitHub
and
don't
submit
new
drafts
or
new
update
draft
updates,
we're
not
going
to
confuse
anybody
that
we
need
to
worry
about
them
being
confused.
D
C
I'm
sorry
I
I
left
my
some
of
my
filters
for
what
I
say
out
loud
in
Japan.
Apparently.
C
C
Cool
excellent,
so
we
know
what
to
do
with
that
and
did
I
get
that.
C
Please,
please
feel
free
to
watch
my
notes
more
carefully
than
you
usually
do.
I
have
funny
stories
to
tell
you
all
anyway,
for
so
for
Flack,
so
Martin
did
the
the
Flack
revision
to
what
is
that
dash.
Eight
eight
and
Spencer
thinks
station
away
is
just
fine.
As
far
as
my
previous
comments
go,
we've
had
some
discussion
on
the
mailing
list.
Haven't
we
on
on
Flack.
B
C
C
B
Always
been
called
is
yes
rather
confusing
calling
its
these
ships,
it
format.
So
at
some
point
I
figured
it
should
be
named
streamable
subset,
but
that
isn't
100
correct.
So
I
asked
a
few
people.
I
got
some
replies
and
I
decided
to
stay
with
streamable
subset.
C
Perfect
and
I
just
I
just
have
to
you,
know
I
I'm
sympathetic
with
what
you
guys
are
talking
about.
From
my
perspective,
the
big
thing
is,
it's
not.
You
know
the
new
subset,
which
you
know
then
the
next
time
you
have
a
new
subset.
You
don't
know
what
to
call
it,
and
and
I
mean
we.
We
should
be
better
at
naming
things
that
we
are,
but
sometimes
we're
not
so
we
will
we
will
get.
C
We
will
worry
about
that
name
that
we
will
worry
about
the
next
name
when
we
see
what
the
next
thing
we
do
is
but
cool,
okay,
so
from
okay,
so
from
Spencer's
perspective
dancing
back
over
to
the
minutes.
For
a
second
does
anybody
need
to
look
at
the
diffs
4-08.
C
B
B
Comments,
I
just
merge
it
so
I
assume
anyone
interested
has
already
seen
it,
but
people
not
watching
the
guitar
might
want
to
look
at
the
diff.
Yes,.
C
Okay
cool,
so
next
up
on
this.
C
The
Spencer
Spencer
has
provided
comments
from
the
shepherd
which
have
been
addressed.
So
what
what
I'm
doing
now
for
Shepherd
right
up
is
not
reposting
all
those
comments
and
what
happened
to
them
and
stuff
like
that.
C
That
happened
in
the
working
group,
I'm,
basically
filling
out
a
chef,
a
It's
Like,
a
Shepherd
write-up
questionnaire
that
I
that
I
write
up
and
post
in
the
data
tracker
and
then
then
I
tell
Murray
that
you
know
basically
I
change
it
to
publication
requested
and
Murray
should
wake
up
at
some
point
after
that.
C
So
at
that
point
be
we
now
have
our
third
document
leaving
the
working
group.
C
Indeed,
do
we
need
to
do
we
need
to
and
I'm
going
to
be
saying
nice
things
about
a
number
of
things
on
the
on
the
write-up?
Just
just.
Thank
you
all.
B
A
C
C
C
To
the
people
on
the
call,
because
he's
already
nudged
us
and
Dave
I
think
it
probably
is
good
to
go
ahead
and
send
the
email
for
folks
that
might
not
be
on
the
call.
D
C
C
I'm
sorry
I
thought:
oh
I,
I'm,
sorry
I
thought
I
had
moved
this
and
I
might
have
moved
it
back
down.
C
A
A
So
I
made
it
back,
obviously
so
I
think
we
should
talk
about
it
to
me,
it's
pretty
obvious,
but
it's
probably
worth
seeing.
What's
obvious
to
me,.
C
And
perfect,
so
what
do
we
want
to
say
about
this.
C
B
C
I'm
typing
Mike
Michael:
you
want
to
get
us
started
on
framing.
A
A
The
problem
with
that
is
that
it
makes
it
to
some
people
who
don't
understand
the
RFC
is
immutable.
Then
it
tends
to
attract
comments
and
fixes
or
additions
which
actually
need
to
go
through
a
process.
A
A
On
the
other
hand,
the
RFC
editor
has
a
has
an
Errata
process
where
we,
basically
you
the
ads,
an
item
to
a
database
and
ideally,
what
you
do
is
you
provide
a
this?
Is
the
old
text
which
is
a
broken
and
here's
the
new
text
which
fixes
it
and
usually
I,
would
say
seventy
percent
of
the
time
it's
you
know
recognizing
that
there's
a
A
misstatement
in
the
English
there's.
A
You
know
something:
that's
just
not
quite
right
and
it
and
it
may
lead
to
a
wrong
technical
understanding,
and
sometimes
it's
just
you
know
what
there's
some
typo
and
we
missed
it
so,
but
there
are
Errata
where
we
need
to
clarify
some
existing
situation.
That
has
a
technical
impact
and
people
have
done
it
wrong
or
misinterpreted
it
in
general.
Errata
are
not
used
for
new
features,
so
that's
a
new
document,
okay,
so
the
issue
is,
we
should
whenever
we
have
find
technical
or
editorial
mistakes
in
the
document.
A
We
should
file
a
rata
for
that
and
we
can
also
fix
them
in
GitHub
and
that's
fine.
The
issue
is
that
we
need
to
be
clear
which
ones
are
Errata
fixes
and
which
ones
may
be
just
people
suggesting
an
entirely
new
feature
version
5,
for
instance,
for
what
was
it
matroska.
A
So
we
just
need
to
be
clear
because
not
everything
has
the
same
level
of
consensus.
Understanding
and
probably
we
should
have
a
branch
that
is
for
each
RFC.
As
it's
published.
We
should
probably
create
a
branch
in
GitHub
and
say
that's
where
we
would
put
typos
and
fixes
like
that.
That
are
also
written
down
as
a
rata.
That
would
be
the
best
thing
and
then
you
know
we
can
merge
that
Branch
when
we
have
new
version.
At
that
point
we
do.
B
Well,
matroska
already
has
the
very
nice
build
system
to
well
split.
The
versions
I
I
think
for
for
Flack,
The
branching
off
would
be
the
best
solution.
B
A
Even
though
we
have
the
build
system,
the
thing
is:
I
want
to
be
really
clear
for
people
who
are
outside
of
the
this
working
group
that
you
know
their.
B
Okay,
so
should
we
Branch
off
the
the
stable
States
or
should
be
branch
of
the
State
without
consensus,
because
usually
people
when
they
look
at
the
GitHub
they
look
at
the
master?
Should
the
master
mirror
their
RFC
or
shoots
the
master.
A
I'm,
okay,
that
the
master
is
our
work
in
progress.
That's
understood,
I
think
we
should
have
a
branch
called
RFC
XYZ,
which
we
branch,
which
only
has
the
the
erata
that
we
might
apply,
and
we
should
probably
update
the
readme
for
both
pieces
to
make
it
clear
what
their
there.
Thank
you.
D
I'm,
okay
with
the
branch,
but
on
ebml,
which
is
the
RFC
we
have
published
already.
We
have
a
tag
on
GitHub
that
says:
Errata
RFC,
97,
85,
8795,
four,
and
so
that
means,
if
you
go
on
GitHub
you,
you
click
on
that
label.
I
sent
a
link
on
the
chat
you
will
see,
which
one
are
closed,
the
one
star,
Mouse,
the
ones
that
are
refused.
You
can
see
the
ones
that
are
open.
You
have
a.
D
C
Okay,
so
the
conversation
we
were
having
is
a
very
good
conversation
for
us
to
have,
but
it
would
be
good
for
us
to
think
about
I
think
we're
Spencer's
opinion.
Is
that
we're
talking
about
the
way
things
would
work
if
they,
if
the
world
made
sense,
which
is
not
always
the
case
where
we're
talking
about
the
RSC
system,
so
if
I
was
to,
if
I
was
to.
C
Paste
this
link
into
the
chat.
C
Yeah
squawking
and
I
was
afraid
of
what
I
had
done
to
someone
okay,
so
up
at
the
top
of
this
that
Michael
has
just
opened.
There
is
a
thing
about
very
okay,
so
this
is
about
not
filing
Errata
but
how
to
verify
errata,
and
this
is
something
that
actually
happens
from
an
area
director
so
like,
basically
and
because
reasons
which
we
don't
have
to
talk
about.
C
Now
we
can
say
the
area
directly
that
people
are
going
to
report
Arana
and
the
the
area
director
is
going
to
probably
talk
to
us
and
then
say
what
should?
How
should
I,
how
should
I?
How
should
how
should
I
process
the
Errata?
That's
been
filed?
Okay,
so-
and
you
see
the
thing
about,
is
this
a.
C
Is
it
you
know,
is
this?
Is
this
a
technical
or
an
editorial
type
of
Verona?
And
then
these
here,
where
we
say
verified,
means
that
we
have
looked
at
it
and
we
agree
that
there's
a
problem
and
we
have
agreed
that
the
solution
that
was
proposed
is
is
reasonable
or
you
could
be
reported
I'm
I'm,
going
through
oh
and.
C
To
the
details,
but
well
I
think
that
person.
A
C
C
A
That
what
I'm
suggesting
we
should
be
doing
is
we
should
be
doing
exactly
like
this
with
these
issues
with
the
Errata.
But
what
I
would
like
to
do
is
I
would
like
to
have
a
branch.
A
Okay,
in
this
case
we
would
Branch
it
already,
which
says
you
know,
RFC
8794,
and
it's
exactly
the
the
the
base
point
of
that
Branch
should
be
the
the
exact
text
that
we
published,
with
whatever
rpcc
yes,
I
know:
I
realized
that
that
I
realized
that
right
and
and
then
we
should
apply
these
errata
to
as
as
there
and
the
commitment
in
the
commit
message
for
that
Errata
we
should
be
referencing.
A
You
know
the
the
Errata
that
we've
URL
that
we've
submitted
to
here,
so
so
that
the
the
GitHub
and
the
RFC
editor
are
are
are
synchronized
in
in
that
process
and
since
the
Iran
is
being
submitted
by
you
know,
one
of
us,
the
area
director
will,
you
know,
will
be
clued
in
and
know
that,
oh
okay,
this
is
we're.
This
is
the
process
we're
following
yeah.
C
If
you're
a
director,
if
the
area
director
has
comments
or
questions
he,
he
can
find
us
easily
enough
to
ask.
A
Right
so
it
should
be
easy,
but
but
all
I'm
saying
is
that
is
that
and
then
you
know
so
we
have,
you
know,
read
me
the
formal
and
official
specification,
so
I'm
saying
this
sentence
should
remain
only
on
the
branch,
the
RFC
87
94
branch
and
that
the
the
master
repository
should
say.
This
is
a
work
in
progress
and
that's
all
that's
what
I'm
trying
to
get
at
so
that
if
we
point
someone
at
you
know
this
new
Branch
I,
don't
know
you
saying
it:
it
virtually
exists
already.
A
Exists
right,
so
if
we
go
to
this,
if
I,
if
I
go
to
this
Branch,
then
it
should
say
this:
it's
official
blah
blah
blah
and
you
know
it
should
could
have
it's
one
commit
20
commits
behind
Master.
That's
perfect
right!
So
one
commit
ahead.
There's
something
update
the
powerful
to
do
so.
Okay,
so
we
did
that
right.
Great.
C
Oh
yeah,
so
I
actually
I
I
apologize
for
walking
people
through
the
list.
The
thing
that
I
the
thing
that
I
was
trying
to
get
to
was
the
next
thing
on
the
list
which
was
held
for
document
update
and
hilfer
document
update,
really
means
that
this
is
a
good
thing
to
do,
but
that
we're
not
going
to
agree
on
a
fix
now.
You
know
we
agree
that
the
the
Errata
is
is
a
problem.
C
We
are
not
agreeing
on
a
fix
now
and
if
the
document
is
ever
revised,
this
is
the
critical
part.
If
the
document
is
ever
revised,
we'll
process
it,
then
okay,
so
where
I,
where
I
was
headed
with
that
was,
as
Michael
said,
what
you're
going
to
find
in
the
Errata
system
as
verified
or
held
for
document
update,
is
not
going
to
be
any
new
features.
C
You
know
it's
not
going
to
be.
You
know.
Basically,
this
is
the
the
deal
with
the
Errata
is
saying
the
RC
was
published
at
some
point
in
time
and
what
the
working
group
was
thinking
about
at
that
point
in
time
was
this
and
they
may
have
gotten
a
few.
C
The
working
group
may
have
gotten
a
couple
of
things
wrong,
and
so
we
will
either
we
will
either
verify
them
or
we
will
say
yeah,
that's
right
or
we
will
do
a
held
for
document
update
and
the
next
time
we
revised
the
document
in
as
an
RFC.
We
would
we
would
we
would
process
it.
Then
a
lot
of
those
rejected
stuff
is,
you
know
some
people
have
that
aren't
really
errors,
but
I've
seen
more.
C
That
tend
to
be
the
ones
where
it's
like
I
think
that
this
I
think
that
the
way
this
should
work
is
this
other
way
over
here,
which
would
be
better.
But
it's
not
what
the
working
group
was
thinking
when
they
published
the
RFC.
Does
that
make
sense.
C
C
A
snapshot
of
the
next
version
of
the
RFC
by
looking
at
GitHub
and
and
what
what's
gotten
merged
about
saying
that
right.
D
Michael,
we
can
see
the
comments,
but
then,
at
least
in
our
case,
the
problem
is
that
you
need
to
generate
the
document
to
actually
see
the
the
results,
for
example,
for
Metro
scale.
If
we
make
a
change
in
the
XML
file,
unless
you
know
how
it's
going
to
generate
the
code,
you
don't
know
what
the
document
will.
Change
will
look
like.
So
even
if
you
have
a
branch-
and
you
can
see
the
changes,
we
would
need
to
generate
a
file
somewhere
on
the
site,
so
people
actually
see
the
actual
document.
B
In
that
case,
maybe
you
can
get
analogy.
You
can
do
releases
with
with
Errata,
because
the
router
for
ebml
came
in.
What
do
you
call
them
in
a
bunch
so
a
few
at
a
time,
so
you
could
use
the
GitHub
release.
C
Yeah
I
was
I
was
wondering
about
that.
I
I
have
not
had
a
lot
of
experience
with
that.
I've
had
I've
done
some
but
I'm
betting.
Somebody
here
knows
more
about
that
to
me,
probably
quite
a
bit
more.
D
But
technically
for
every
change,
we
do
we
actually
compile
the
document
into
the
final
version
and
it
leads
available
as
an
artifact
on
GitHub
for
each
pull
requests
actually
each
build.
You
have
an
artifact
that
you
can
it's
a
zip
file
with
the
HTML
and
text
file,
I
think
and
the
XML
file
that
you
can
upload
so
that
the
compile
file
exists.
D
D
For
releases,
but
I
don't
know
if
they
do
it
for
interim
jobs
or
something
like
that
jobs.
A
We
don't
know
but
I,
think
I
think
it's
enough.
I
I
think
that
what
what
was
said
Martin
said
I
think
it's
enough
that
yeah,
okay,
so
occasionally
we're
gonna
produce
a
a
we're.
Gonna
render
it
and
produce
what's
going
on
and
and
and
I
think
that's
fine
anyway!
We'll
want
to
do
that
so
that
what
we
can
provide.
C
A
For
their
patch
process.
C
D
C
So
I
think
I
think
that
we
and
I'm
just
cleaning
up
what
notes
I've
taken
and
please
like
I,
say,
feel
free
to
correct
anything
I'm
getting
here.
But
basically
so
so.
Our
plan
is
that
we
would
have
a
version
and
get
a
hub
that
matches
the
RC
as
published,
and
we
have
a
version
that
matches
the
RC
as
corrected
and
then
we
have.
We
may
also
have
version
one
or
more
versions
in
GitHub
that
matches
like
the
next
release
and
I'm.
C
So
I'm
saying,
like
ebml
V2
release
of
of
the
specification
which
we
would
love
to
publish
as
an
RC
as
well.
A
C
We
we
may
not
need
it.
We
may
not
need
okay,
so
the
easy
one
is
we
get
something
that's
perfect
as
the
RFC
and
so
we're
just
working
on
the
next
version
and
nobody
ever
finds
an
error.
So
we
would
not
need.
We
would
not
need
that,
but,
basically
for
us
to
be
able
to
come
up
with
something
that
somebody
could
find
and
understand.
C
And
I,
if
no
no
I
I
I'm
agreeing
with
you
I
I
I
I
promise,
I'm
gonna
do
a
better
job
in
2023
of
telling
people
that
I'm
agreeing
with
them
before
I
keep
talking
but
I
agree
with
you
do
we
want
to
try
to
set
ebml
up
that
way.
Now.
D
C
A
C
Cool
okay,
so
I'll
just
put
that
in
the
notes,
and
do
people
have
time
to
take
a
look
at
this
in
the
next
month
and
actually,
when
I
said
the
next
month,
I
mean
like
the
next.
C
A
B
Well,
Dave
said
something
in
the
chat
about
no
time
to
wait:
seven
overlapping
with
ITF
118.
C
C
Yeah,
but
not
all
the
ones
around
it,
I
haven't,
looked
to
see
if
they
published,
where
we're
going
to
be.
But
if
we're,
if
we're
at
the
same
place,
we've
been
multiple
times.
C
I
I've
usually
been
over
on
across
the
street
anyway.
So
and
it's
been
lovely.
A
Yeah,
there's
no
venue
information,
posted
I
assume
it's
the
same.
One.
C
A
Dave,
where
will
no
time
to
wait,
be
hosted.
C
C
And
Dave
was
also
asking
any
good
ITF
parties
to
crash
I'm
a
soup.
Well,
we'll
we'll
talk
we'll
talk
before
I,
say
anything
we'll
talk.
A
C
I
I
am
not
I,
am
not.
The
I
am
not
I'm,
not
the
right
person
to
ask.
A
C
A
So
there
you
go
anyway,
all
right,
so
anything
else
from
anybody.