►
From YouTube: IETF-CORE-20230621-1400
Description
CORE meeting session at IETF
2023/06/21 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
B
B
A
B
B
C
B
B
B
B
B
B
B
Both
Garcia
and
corcom
I
and
non-traditional
responses
about
which
we
were
expecting
a
discussion,
especially
from
Christian,
but
we
have
some
material
if
we
want
to
to
have
an
early
discussion
at
least,
and
that
can
continue
at
the
next
interim,
for
example,
anything
more
or
any
bashing.
Otherwise,
we
can
go
for
this.
B
C
Yeah
so
I
was
hoping
we
were
going
to
have
a
nice
discussion
about
corresponsive
side,
try
not
to
take
the
whole
time,
so
I
only
have
nine
slides,
I.
Think
so.
I
think
everybody
here
is
aware
of
the
fact
that
we
have
these
four
documents,
one
of
which
is
an
RCA
one,
is
has
been
in
isg
processing.
It
has
been
pushed
back
to
the
working
group,
which
is
called
Sid.
C
One
is
in
working
class
called
past
stage,
but
since
we
decided
to
make
one
significant
simplifying
round
at
this
and
one
more
that
has
reached
broken
glass
called
past
so
a
couple
of
years
ago,
but
probably
needs
to
ingest
all
the
changes
that
that
have
happened
in
in
the
landscape.
So
I
want
to
talk
about
corset
and
core
comma
today,
because
well,
Yankee
was
out
there
and
I
quickly.
Talk
about
Yankee
at
the
end
and
yang
library
is
maybe
too
early
to
to
do.
C
The
finishing
touches
on
I
mean
the
main
work
has
been
done
so
talking
about
course.
Sid
car
seat
is
really
about
a
location
of
Yang
SIDS
that
are
needed
for
Yang
sibo
to
get
its
full
efficiency,
and
this
is
an
interesting
thing,
because
it's
pioneering
a
location
of
identifiers
over
a
large
flat
space.
C
C
What
we
needed
to
do
for
for
three
months
now
and
haven't
gotten
through,
is
running
a
patched
up
being
to
generate
the
Sid
file
example
in
in
the
document,
and
the
special
thing
here
is
that
we
probably
don't
want
to
disrupt
all
the
people
that
actually
are
using
the
existing
citride
education.
So
we're
actually
going
to
use
the
the
existing
Sid
file
as
input
to
peeing,
which
is
something
that
that
it
can
do
so.
C
So
this
is
where
we
are
and
just
to
remind
you
me
remind
you
what
this
means
is.
We
already
have
numbers
like
17
15
to
1719,
which
are
data
identifiers.
That
point
into
the
example
that
we
were
using
the
iitf
system
module
and
we
have
to
fix
those
a
little
bit
because
we
Yang
didn't
output.
The
the
full
string
here,
it
should
have
said,
slash,
input
and
and
slash
output
for
rpcs,
but
it
also
left
out
a
point
in
the
tree.
C
So
there
will
be
a
document
there
that
describes
how
to
do
the
allocation,
and
what
we
need
is
a
couple
of
sentences
that
say
that
alternative
process
are
acceptable
as
long
as
the
objectives
which,
fortunately,
we
have
documented,
are
still
addressed,
so
the
whole
section
2.
Of
course
it
tells
us
what
those
objectives
are
and
if
you
come
up
with
an
alternate
process
that
actually
fulfills
these
objectives,
but
also
fulfills
objectives
that
this
specific
allocation
has
and
the
AP.
C
C
So
this
is
what
needs
to
be
done
and
the
the
timeline
that
I
see
is
we
can
do
those
process
process
exception
edits.
You
can
do
them
in
parallel
with
the
pigeon
works
or
one
of
Laura's
students
I
think,
has
a
fog
of
peeing.
That
does
more
useful
things
here,
and
we
may
be
able
to
leverage
that
and
based
on
these
two,
we
should
prepare
Dash,
21.
C
They
decided
that
it's
better
to
fully
push
this
back
into
the
working
group
and
maybe
doing
your
working
with
us
call
it's
a
reasonable
way.
I
mean
the
the
chairs
can
always
declare
consensus,
but
if
I
were
a
chair
on
this
I'm,
not
because
I'm
an
offer,
I
would
probably
think
I.
I
don't
have
a
good
basis
for
for
declaring
consensus.
C
B
Think
it's
good
to
have
one
more
all,
considering
also
what
you
presented
if
you
check
the
current
status
right
now.
After
all,
the
dance
we
had
with
Eric
is
saying
waiting
for
working
rupture
go
ahead,
so
we
put
the
status
like
after
we
passed
an
intended
last
last
call,
so
we
just
have
to
reverse
it
further
back,
but
that's
fine
and
I
just
like
to
confirm
with
Jaime
who
is
also
Shepherd
right,
I
think
we
can
definitely
go
for
this
yeah.
C
Good,
so
this
is
the
plan
for
corset.
Now,
let's
talk
about
the
Kumai,
we
had
a
pretty
important
discussion
at
the
London
igf,
where
we
at
the
hackathon
said
that
this
is
all
great,
but
it's
just
too
complicated.
We
need
to
reduce
the
complexity,
and
so
so
I
started
doing
some
complexity
reduction,
but
then
I
think
Christian
came
with
the
idea
to
to
maybe
simplify
the
significant
significantly
because
we
do
have
Fetch
and
Patch
which
we
didn't
have
when
this
originally
was
designed.
C
So
we
can
use
those
to
simplify
things
and
then
the
question
was
how
how
radical
are
we
and
I
think
we
now
have
converged
on
the
non-radical
solution?
So
we
we
don't,
do
we
don't
use
sketch
I'll
put
for
accessing
individual
parts
of
the
tree,
but
we
keep
get
put
and
delete
for
whole
data,
so
access,
so
I'm,
I'm
personally,
I
just
don't
know
enough
about
Yang
to
know
when
how
data
access
makes
sense,
but
several
people
have
told
me
they
would
like
to
use
that.
C
So
so,
let's
keep
that
in
so
today,
I
merged
the
the
branch
that
has
all
those
changes
and
submitted
it
as
a
dish
13.
So
it
was
on
the
GitHub
repository
all
the
time,
but
maybe
it
needs
to
be
advertised
more
openly,
and
this
means
we.
We
now
have
an
official
internet
draft
that
we
can
discuss
on
the
list
and
if
there
is
any
need
for
discussion,
maybe
even
at
the
interim
there
are
two
little
wild
cards
in
there.
One
is.
There
is
a
ZIP
file.
C
Example
in
there
and
one
question
is:
do
the
pean
changes
we
do
forecast?
It
actually
impact
this
Sid
file
as
well?
I,
don't
think
so,
but
we
we
need
to
check
with
Yang
experts,
and
the
other
observation
is
that
the
Sid
file
is
for
a
module
that
uses
RC
young
data,
which
we
actually
replaced
by
SX
structure
in
in
the
other
draft,
and
maybe
we
need
to
check
whether
this
is
needed
here
as
well.
C
C
Good,
okay,
so
in
need
to
tell
him
what
we
discussed
today
and
finally,
just
just
a
further
Outlook
a
look
into
the
crystal
ball.
As
I
said,
we
may
want
to
finish
Yang
Library
again
check
whether
this
is
the
the
right
level
of
complexity.
For
what
we're
trying
to
do
here
and
the
other
thing
that
people
are
banging
on
our
doors
about
is
the
fact
that
even
with
Yang
sibo,
as
as
the
container
representation
format,
the
actual
data
that
the
Yang
model
is
about
are
still
like
in
an
XML
document.
C
So
they
are
all
text
based.
We
have
text
based
IP
addresses
and
that
really
hurts
for
IPv6.
We
have
text
based
dates
and
so
on,
and
it
probably
would
be
a
good
thing
if
we
had
a
way
to
switch
an
existing
Zhang
model
to
a
more
efficient
representation.
But
nobody
knows
how
to
do
that.
So
this
is
going
to
be
a
design
effort
and
not
just
a
slam
dunk.
Let's
write
this
up
and
standardize
it.
C
So
the
question
of
course,
is
how
do
you
handle
the
fact
that
new
binary
formats
are
going
to
come
in
and
how?
How
does
a,
how
does
the
evolution
work
with
potentially
different
players
being
at
different
levels
of
evolution
on
on
this?
So
this
is
the
the
hard
part
and
I'm
just
saying
this,
so
so
it
doesn't
seem
like
we
are
completely
done.
I
think
we
are
in
a
very
good
shape,
but
doing
this
will
really
unlock
the
the
for
a
few
more
things
that
we
might
want
to
do.
B
C
So
it's
probably
a
good
idea
to
actually
write
up
another
blueprint
in
particular
to
with
respect
to
the
way
we
have
been
using
responses.
Like
the
multicast
responses.
Excuse
me
the
responses
to
multicast
requests
and
the
yeah
I'm
still
falling.
In
the
same
time
and
the
the
notifications
that
come
to
observe
requests,
they
are
part
of
this
bigger
picture
and
they
they
actually
are
innovations
that
we
did
at
the
time
without
having
the
a
big
picture.
So
that's
one
aspect:
writing
up
the
big
picture,
essentially,
writing
up
an
architecture.
C
The
other
thing
that
this
document
actually
does
is
it
defines
a
few
options,
and
these
have
had
very
little
review.
I'm
not
aware
of
implementations
of
them,
the
the
some
of
them
just
show
one
way
of
doing
things
mostly
to
illustrate
the
architecture,
not
necessarily
to
be
finalized
versions
of
options
that
we
actually
want
to
introduce.
C
So
when
we
discuss
what
what
the
the
is
this
a
normative
document
or
not,
we
should
consider
that
we
probably
want
to
extract
these.
These
normative
parts
anyway,
maybe
not
do
all
of
them
at
the
same
point
in
time,
maybe
apply
some
more
thinking.
It
doesn't
really
make
sense
to
to
provide
a
count
of
additional
responses
you
receive,
which
this
Leisure
for
responses
option
does.
C
And
then
do
one
or
more
normative
documents
that
just
Define
these
these
options,
but
again
we
need
these
options
to
actually
illustrate
the
architecture.
So
this
is
a
bit
of
a
difficult
situation
to
to
have
illustrations
in
here
that
aren't
actually
meant
for
for
consumption
as
a
normative
document
so
best
case.
We
will
do
all
this
quickly
enough
together
that
that
we
don't
need
that
and
can
just
point
from
this
document
to
the
normative
ones
or
we
might
want
to
to
put
in
the
illustrative
options
with
a
big
caveat
folks.
C
C
C
A
C
A
C
B
Thank
you,
I
I
was
saying
at
least
personally
I
don't
find
the
terminology
confusing
especially
multicast
responses
to
me
means
a
response
sent
over
multicast.
Irrespective
of
how
the
request
was
so
I,
don't
know
even
multicast
sent
response,
it
is
clearer
and
better
to
me
becomes
a
bit
more
cumbersome.
C
C
Have
to
make
some
abbreviation
and
I'm
just
noticing
that
I
trip
up
on
this
all
the
time
and
that
maybe
just
be
a
function
of
my
age
or
it
may
be,
maybe
an
indication
that
we
should
further
improve
the
terminology
and
I
would
say
this.
This
comment
on
configured
requests
versus
phantom
requests,
which
essentially
are
all
in
the
same
class,
but
when
we
use
the
term
configure,
we
probably
should
be
limited
to
the
cases
where
there's
actual
configuration
going
on
and
have
another
term
for
the
whole
set
of
non-traditionally
transmitted
requests.
B
Also,
I
think
the
overall
strategy
you
had
in
mind
before
is
good
meaning
having
the
architecture
informative.
It's
it's
about
acknowledging
that
things
are
yeah
broader
than
original.
Imagine
somehow
documents
popped
up
and
thinking
that
way,
so,
let's
just
flat
the
ground
to
have
a
common
understanding
and
yeah.
That
sounds
like
informative.
Well,
the
options
are
another
story.
B
I
agree,
I
had
the
impression
from
a
quick
chat
from
Christian
that
he
had
in
mind
yet
another
possible
option
actually
quite
similar
in
in
scope
to
the
option:
multicast
timeout,
the
finding
group
com
proxy.
So
that
option
is
very
explicit
and
tells
the
proxy
send
me
back.
Multiple
responses
to
this
same
request
for
X
seconds,
then
stop
Christianity
in
mind.
Well
something
similar,
but
with
no
fixed
indication
in
in
terms
of
seconds
and
so
on.
B
B
A
C
B
B
C
B
B
B
C
B
C
B
B
A
B
C
Are
we?
We
have
had
an
official
site
meetings
for
a
long
time
in
the
call
working
group,
so
the
the
main
problem
is
setting
up
things
like
audio
and
possibly
video
in
a
way
that
that
remote
participation,
kind
of
works
and
since
quite
a
few
people
will
not
be
on
site
that
that's,
maybe
interesting,
but
yeah
I.
Think
the
high
high
bandwidth
communication,
where
I
think
Marco
Antonio,
probably
have
ways
of
having
high
bandwidth
communication.