►
From YouTube: IETF-CORE-20230830-1400
Description
CORE meeting session at IETF
2023/08/30 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
C
D
D
A
A
D
D
A
Yeah
that
they're
it's
incredible
to
see
how
how
quickly
they
learn
and
and
develop,
and
all
of
that
so
yeah
I
really
enjoyed
this
time
and
we
went
to
the
we
went.
We
were
in
the
south
of
Italy,
which
honestly
like
it
wasn't
that
good
of
an
idea
given
the
floods
and
everything
that
was
happening
with
our
usual
luck,
but
but
yeah.
We
were
at
the
beach
for
for
a
month
and
he
was
like
tasting
the
sand
and
enjoying
the
water.
It
was
really
nice
but
yeah
anyway.
Sorry
enough
about
me.
B
A
E
A
B
B
E
We
will
meet
for
a
physical
interim
and
we
are
currently
setting
up
the
the
program
for
that.
If
you're
on
the
digital
TRG
mailing
list
are
we
set
up
page
where
you
can
indicate
your
your
interest
and
maybe
even
suggest
the
topic.
So
please
use
that
page.
Even
if
you
haven't
fully
completed
your
your
planning,
yet
please
use
it.
So
we
have
some
some
databases
for
scheduling,
so
Friday
November
3rd
in
Prague,
in
the
meeting
hotel
at
least.
It
currently
looks
like
that.
E
B
E
Okay,
so
it's
a
short
slide
set
I
hope
we
will
have
more
discussion
than
we
are
presenting
things
and
I
want
to
talk
about
the
the
qualcon
work
about
the
hrefci
work
and
about
the
corrections
and
verifications.
So
my
Qualcomm
segments
always
begin
with
this
slide,
so
you
probably
have
seen
that
before.
E
So
we
have
four
documents
that
that
comprise
carlcon.
One
is
an
RFC
already,
the
the
C1
encoding
off
for
gang
data
that
sibo
encoding
is
most
efficient
if
it
gets
SIDS
and
the
way
these
SIDS
are
allocated
is
defined
in
the
corset
document.
That
actually
was
in
the
isg
already,
and
we
found
a
few
problems
with
that
which
made
the
isg
push
this
back
to
the
working
group.
So
the
question
is:
when
can
we
push
this
over
again
to
the
isg?
E
So
we
we
just
have
to
plan
for
for
a
relatively
long
times
until
PR's
actually
merged
and
so
on.
So
what
what
we
will
do
is
actually
we
will
have
a
core
fog
or
branch
of
this
tool
for
a
couple
of
months
and
then
we
will
finally
try
to
get
this
into
the
the
main
line
to
so.
The
Ping
tool
right
now
creates
output.
That
is
both
Incorrect
and
incomplete,
and
we
have
to
do
a
couple
of
patches,
nothing,
nothing
major,
but
it's
a
significant
program.
E
E
E
E
So
we
also
don't
need
a
Sid
for
carconf
for
that.
But
of
course
we
want
to
provide
the
SIDS
for
rescuff,
so
that
has
no
no
change
on
the
direction
we
have
taken
for
the
corset
document,
but
it
really
simplifies
so
so
best.
Look
at
the
example
in
the
comma
document,
which
is
now
I,
think
very
streamlined,
very
simplified
and
and
having
this
redundancy
really
didn't.
Do
anything
useful.
So
it's
good
that
this
is
good.
Okay,
thank
you.
So
there
was
one
more
item
that
Diana
asked
us
to
do
so.
E
There's
now
a
comma-15
and
at
this
point
really
I
would
like
to
see
reviews
from
from
people
who
have
implemented
this
or
are
otherwise
involved
with
comma.
So
please,
if,
if
you
are
interested
in
the
core
conf
world,
please
review
the
komai
document,
Dash
15.,
so
that's
all
I'm
I
was
planning
to
say
on
komai,
so
this
has
been
sitting
there
for
four
months
already
because
of
the
other
vacation
times.
But
when
you
come
back
from
your
vacations,
please
do
a
review
of
that
now
to
the
new
cause.
E
It
a
version.
As
you
remember,
the
the
Sid
files
we
we
generate
to
a
company
Yang
models
which
provide
numeric
identifiers
for
for
the
next
best
identifiers
in
those
models.
Those
are
in
Yang
Json
now
and
it
appears
not
to
be
too
easy
to
edit
them
by
hand,
because
people
have
been
making
mistakes
in
the
past.
E
So
I
tried
to
to
not
edit
them
by
hand
either
and
wrote
a
little
tool
that
converts
the
young
Json
into
CSV.
It
accumulated
separated
videos
which
you
can
feed
into
Excel.
If
you
are
so
inclined
or
some
other
tool,
and
then
you
can
convert
them
back
into
a
valid
Sid
file
and
I
wrote
this
tool
in
such
a
way
that
that
the
the
Json
to
CSV
converter
actually
undoes
all
the
the
weirdness
that
the
current
version
of
pjang
does.
E
So
you
can
even
put
this
into
your
workflow
without
editing
the
CSV
file
at
all,
because
the
the
conversion
already
fixes
some
of
the
awareness
then
anyway.
So
the
the
question
that
we
we
had
discussed
since
June
or
so
was
what
exactly
are
the
identifiers
that
are
getting
used
in
an
ipco
action
and
so
the
the
incorrect
identifier
1716
that
we
had
in
the
example.
This
has
now
been
replaced
by
1775
and
1776..
E
I
chose
to
give
these
things
new
numbers,
since
this
is
still
a
draft.
I
could
have
decided
to
reuse
old
numbers.
For
instance,
the
the
daytime
input
could
have
gotten
the
16
1716.,
but
I
think
it's
less
confusing,
since
the
the
old
version
has
been
around
for
so
long.
It's
less
less
confusing
to
use
new
numbers
for
these
two
things.
E
E
F
E
Yeah,
so
what
you
are
saying
is
essentially
that
the
the
downside
of
of
missing
a
number
here
is
limited,
because
we
can
always
generate
numbers
for
them.
Of
course,
that's
still
some
some
overhead
for
people
who
are
trying
to
use
this,
but
because
I
don't
know
anybody
who
would
be
trying
to
use
these
Phantom
identifiers
I
think
we
are
on
the
safe
side
here,
because.
E
Yeah
I
think
the
the
interesting
observation
is
that
the
Sid
fire
might
have
completely
bogus
City
assignments
that
that
are
not
defined
anywhere
in
the
model,
and
things
would
still
be
fine
because
nobody
would
be
using
them.
So
the
the
downside
side
of
having
too
much
in
there
also
is
limited,
but
I
think
it
just
complicates
things
confuses
people.
So
let's
not
do
that.
E
E
B
B
E
Yeah,
so
the
courses
have
been
on
alert
since
the
117
meeting,
so
okay,
so
I'm
I'm,
going
on
vacation
next
week
on
on
Tuesday.
So
whatever
needs
to
be
done,
I
need
to
do
now,
or
it
will
only
be
done
later
in
in
September
yeah,
but
we
I
think
we
can
take
that
offline.
How
exactly
we
are
going
to
do
this.
B
B
D
D
D
D
D
That's
a
terrible
thing!
I
think
the
bigger
question
is
longer
term
in
three
years,
when
someone
finds
a
bug,
who's
going
to
know
this
code
well
enough
to
actually
determine
whether
the
fix
is
actually
appropriate.
So
that's
actually
the
bigger
question
that
I
think
I,
actually
I
sent
an
email
to
Francesca
yesterday
or
something
about
that
so
I
think
that's
the
the
end
thing.
D
The
other
side
of
it
to
me
is
that
when
it
comes
to
users
of
this,
this
mechanism,
such
as
over
an
anima
where
we
have
data
structures
that
are
not
rpcs,
that
there
is
a
frequent
lack
of
understanding
about
that
process
within
the
Yang
community.
So
you
get
Yang
reviews
that
kind
of
don't
make
sense.
E
You
know
I,
ask
you
a
question
on
that,
but
yesterday
and
I
said
this
is
for
data
in
Flight.
It's
not
data
at
rest
and,
of
course,
the
the
comments
I
mean
these
were
helpful
comments.
I'm,
not
complaining
we're
about
data
at
rest.
Again,
it's
really
different.
It's
not
not
in
the
hands
of
the
people.
We're
drinking.
E
So
you
remember
that
the
core
href
document
defines
CIS
and
CI
references
which
are
concise
equivalents
of
Uris
and
URI
references.
So
you
you
never
have
to
have
a
parser
for
Uris
and
all
their
their
idiosyncrasies
in
a
constraint
device,
but
can
directly
use
the
the
CIS
even
for
generating
Co-op
options
and
so
on.
E
E
Since
we
don't
have
negative
numbers
in
Co-op
options,
we
just
mirror
the
negative
number
to
a
non-negative
number,
so
minus
1
becomes
zero.
Minus
two
becomes
one
and
so
on.
So
the
the
coabs
scheme
actually
has
an
encoding
length
of
zero
and
chord
s
has
an
encoding
length
of
of
one
byte.
So
this
is
fine
I
think.
E
So
these
options
need
to
be
added,
probably
in
an
appendix
to
the
specification
and
and
all
the
things
like
finding
a
good
option
number
and
so
on
have
to
be
done.
And
then
we
would
have
a
dash
14
and
maybe
another
work,
no
plus
color.
We
are
getting
good
in
doing
this
one
week,
second
working
glass,
chords
and
then
we
would
ship
it.
E
Yeah
realistically,
right
now
and
pushing
the
button
on
on
a
document
going
into
the
isg
is,
is
not
an
urgent
thing,
because
we,
the
queue,
needs
to
go
down
to
a
reasonable
size.
So
if
we
do
this
one
week
earlier,
that's
not
going
to
help
us
a
lot.
So
I
think
we
have
a
little
bit
of
time
for
forgetting
this
right.
Okay,.
E
Good,
so
with
that,
let's
move
on
to
Corrections
and
clarifications,
so
we
had
an
idea
a
long
time
ago,
I
think
2017
or
so
to
have
a
document
that
gathers
Corrections
and
clarifications
after
we,
we
found
out
that
it's
not
so
easy
to
to
do.
An
FAQ
like
document
like
the
one
that
we
had
started
in
the
Eric
working
group,
so
on
FAQ
for
implementers
might
have
done
a
similar
job,
but
we
decided
it
would
be
good
to
focus
on
Corrections
and
and
clarifications
and
not
not
on
explaining.
E
So
we
we
have
this
document
and
it
has
been
revived
and
in
particular
we
have
a
GitHub
repository
that
that
has
some
30
issues
right
now,
some
of
which
have
quite
Lively
discussions,
and
these
discussions
also
interact
with
discussions
that
happen
in
implementation,
wrappers
and
right
now.
There
is
an
interesting
thread
in
the
californium
repo,
where
they
are
discussing
issues
around
blockwise
transfers
and
and
fetch
and
so
on.
E
So,
let's
quickly
talk
about
the
current
discussions
about
blockwise
transfer.
Again
this
is
a
pull
request
and
and
California
a
repository
and
what
happened
there
was
the
californium
client
exhibited
some
specific
behavior
behavior
that
is
not
required
by
the
protocol,
but
it
just
happened
to
work
that
way
and
do
token
reuse
for
all
requests
that
together
constitute
a
blockwise
transfer
and
that's
definitely
a
choice
that
California
could
do.
Rfc
91,
75
I
think
actually
gives
you
reasons
why
this
is
not
the
best
way
to
do
this.
E
Yeah
catering
for
zephyrus
deviant
expectations
of
of
what
a
client
needs
to
do
so
we
have
two
levels
on
which
we
need
to
discuss.
This.
One
is,
of
course,
that
people
are
running
systems
out
there
and
they
may
not
be
able
to
fix
their
servers
because
they
are
somewhere
in
a
wall
and-
and
so
you
might
not
have
control
over
the
server
and
and
the
software
state
that
that
runs
on
that
thing,
so
some
form
of
emergency
fix
is
definitely
needed.
E
But
of
course
the
the
downside
is
that
if
people
start
to
perceive
this
as
actually
a
fix
that
fixed
a
bug
in
California,
when
Californian
is
now
doing
things
right
again,
they
might
write
server
further
servers
that
that
rely
on
this
non-specified
Behavior.
So
that's
a
very
dangerous
situation
we
are
in
here
and
I
think
we
need
to
handle
this
with
with
the
utmost
care.
E
So
this
is
one
specific
question
and
the
the
question
of
course,
is:
why
are
the
Zephyr
people
doing
that
and
the
the
problem,
of
course,
is
that
RFC
one
problem
is
that
RFC
9175
took
its
time
so
that
the
tools
you
need
to
solve
all
these
problems
only
recently
have
me
come
available
and,
in
particular,
I
think,
with
a
request.
Tag
option
isn't
even
implemented
in
California,
so
you
you
couldn't
just
start
using
request
tag
here
to
solve
that
that
State
Management
problem
to
probably
solve
the
State
Management
problem.
E
So
that's
always
a
problem.
When
we
introduced
fetch
for
about
half
a
decade,
people
were
saying
yeah,
but
not
everybody
has
implemented
Fetch
and
therefore
you
need
to
provide
a
get
an
alternative
as
well,
and
it
took
us
half
a
decade
to
get
rid
of
that
argument
so
that
that's
definitely
something
that
that
needs
to
be
thought
about.
E
But
that's
not
actually
true,
because
post
requests
are
rarely
stateless.
So
you
you,
you
cannot
react
to
a
club
request
that
that
gives
you,
the
third
block
of
a
post,
that
that
very
rarely
makes
sense.
I
mean
you
might
have
an
application
where
you
are
giving
posts
to
specific
semantics
where
that
makes
sense.
E
But
that's
not
true
for
fetch.
Fetch
can
actually
be
implemented,
stateless
in
many
situations
and
if
you
actually
want
to
do
that,
that
means
that
all
the
block
2
transfers
each
of
the
block
two
transfers
need
to
send
all
the
block
1
blocks
each
time.
So
if
you
have
n
block
one
transfers
and
M
Block
2
transfers
in
reality,
you
get
an
N
by
m
number
of
transfers
and
that's
what
I
call
ridiculous
in
in
the
the
other
report
discussion.
E
So
I
think
some
thinking
is
going
to
be
required
to
solve
this
problem
with
a
minimum
amount
of
trouble
generated
for
implementers
and
implementations,
so
I'm
I'm
not
suggesting
we
do
that
design
now
here
in
this
meeting,
I
think
we
need
a
little
bit
more
preparation
for
that.
But
I
would
like
to
bring
this
up
as
an
example
for
a
correction
and
clarification
issue
that
actually
requires
our
attention
and
our
timely
attention.
E
That
says
how
we
we
want
to
do
this
Corrections
clarifications,
work
very
important
so
that
that's
the
process
link
on
this
slide.
An
important
focal
point
of
this
work
is
the
issues
on
the
GitHub
repository
for
the
corrections
clarifications
a
document.
So
this
is
where
we
already
have
discussion,
sometimes
a
lot,
sometimes
a
little
for
almost
30
issues
that
that
we
need
to
discuss.
So
these
may
be
editorial
issues.
These
may
be
technical
issues.
That's,
of
course,
all
work.
We
need
to
do
to
actually
classify
these
things
and.
E
C
E
E
B
E
B
B
E
C
Just
a
brief
question:
coming
back
to
the
to
the
reusing,
the
blog,
the
token
inside,
a
block
transfer
thing
and
because
there's
probably
not
much
sense
in
me,
dog
piling
onto
the
on
the
comments
that
are
already
in
the
in
the
20
2088
pull
request.
Is
there
a
concrete
issue
in
on
the
sapphire
side
that
one
could
weigh
into
because
I
think
that's
really
where
the
action
is.
F
C
If
Eclipse,
if
California,
wants
to
still
do
it,
this
way
personally
I
think
it's
kind
of
it's
apart
from
that,
not
forcing
other
implementations
to
do
it
right.
It's
not
really
bad
behavior,
especially
considering
the
the
non-traditional
request,
point
of
view,
so
nothing
bad
happens
because
Eclipse
does
it
this
way,
except
for
the
other
implementations,
and
that's
where
we
should
look
where
I
would
like
to
weigh
in.
E
E
Thank
you
so
just
on
the
status
of
this
2088
that
is
already
merged,
so
California
now
has
I
will
have
in
the
next
release
an
option
for
reinstating
the
old
Behavior
so
that
that
little
bit
of
damage
has
already
done.
But
I
think
it's
important
to
alert
this
Azure
server
that
the
problem
is
not
gone
because
that's
just
a
California
specific
change.