►
From YouTube: IETF-CORE-20220224-1500
Description
CORE meeting session at IETF
2022/02/24 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
B
B
B
C
So
we
just
had
a
one
hour
meeting
between
the
some
of
the
authors
of
the
young
sibo
documents
and
some
area
directors
and
some
of
the
young
luminaries,
and
we
were
discussing
how
to
do
the
yangcatalog.org
support
for
sid
files
and
about
halfway
through
the
discussion.
Today
we
decided
we
really
have
to
write
this
up
in
the
corset
document,
and
this
is
a
pretty
substantial
amount
of
information
that
needs
to
go
in
there.
B
C
C
So,
let's
see,
maybe
that
is
a
way
to
get
at
least
the
young
zebra
document
through
the
process.
But
the
the
main
point
is
we.
We
will
have
another
update
to
the
sid
document.
We
will
have
another
process
round
on
this,
maybe
even
the
telechat
date
and
but
that
that
will
allow
us
a
significant
jump
ahead,
because
the
information
that
is
in
corset
essentially
was
negotiated
with
ayanna.
B
C
B
B
B
All
right,
so
that
will
conclude
the
initial
round
of
updates.
Now
the
main
next
presentation
will
be
on
conditional
attributes
and
bill
has
just
submitted
a
new
version
and
should
join
any
minute
to
present
it.
We
have
the
slides
already
and
I
have
a
preference
of
discussing
transport
indication
somewhere
in
between
1630
and
17,
ct
to
accommodate
also
some
points
from
klaus,
so
until
bill
joins,
I
think
we
can
rather
move
to
co-op
attacks.
Instead,
I
can
move
it
up.
B
B
D
D
So
this
is
a
quick
status
update
of
what's
happened
and
what
will
possibly
happen
soon,
all
right
so
moving
on
the
draft
has
basically
moved
since
the
last
interim
meeting
I
attended
was
in
september,
so
so
the
dark
effect
has
moved
on
now
from
zero
zero
to
zero
to
it's,
it's
a
fresh,
zero
to
just
fresh
out
of
the
oven.
Like
half
an
hour
ago.
I
submitted
it
to
the
using
the
submission
tool,
so
you
might
already
see
the
mail
on
the
mailing
list.
B
D
D
Obviously
it
doesn't
mean
that
there
will
be
more
issues
in
future,
but
at
least
these
three
have
closed
and
potentially
there
might
be
one
or
two
coming
up
still
well,
anyway,
just
to
see
what
has
been
resolved,
we
have
discussed
the
the
value
of
the
band
attribute
in
the
conditional
observed
draft.
How
do
we
actually
specify
or
indicate
a
band
that
contains
something
that
the
the
client
would
like
to
observe
upon?
So
the
value
of
the
bread
hang
on
this
is.
This
is
not
correct.
D
D
But
then
the
the
question
was
whether
its
value
is
significant
and
and
after
the
discussions
we
decided
to
go
with
the
approach
that
the
presence
of
the
band
query
parameter
is
is
enough
and
it
should
not
actually
have
a
value,
so
in
drop
zero.
Two,
this
is
what's
happened,
so
ben
does
not
have
a
value
anymore.
It's
just
a
query
parameters,
as
you
can
see
in
the
second
bullet
point
the
example
with
the
temperature,
and
so
that's
that's
good,
of
course.
D
Now
that
raises
the
question
whether
we
should
actually
include
some
more
guidance
and
what
to
do
if,
if
a
server
is
faced
with
a
query
where
the
query
parameter
does
have
a
value.
So,
for
example,
if
it
says
band
equals
zero,
angry
gt
on
some
value
and
and
lt
some
value
or
if
it
becomes
then
equals
to
one,
should
we
accept
that
or
ignore
that?
Or
does
anybody
have
any
comments
on
how
we
go
forward.
C
Attributes
that
have,
for
instance,
integer
values,
and
if
you
set
it
to
cook,
what
do
you
do
so
this
is
not
a
new
problem.
It
just
is
so
we
we,
the
the
empty
value,
is
something
we
we
haven't
defined
very
well.
I
mean
the
the
underlying
problem.
Is
that
we're
using
a
term
here
attribute
that
is
not
really
defined?
So
maybe
we
should
do
something
about
that.
C
D
So
the
the
key
question
now
is
is
whether,
if
this
is
a
known
problem,
then
perhaps
it's
best
not
to
say
anything
more
or
it
should
be.
Should
we
actually
explicitly
address
this
issue
if
somebody
has
put
that
equals
zero
and
then
equals
one,
I
have
to
check
the
librarian
to
m
specifications
and
how
they
have
actually
defined
it.
So
that's
one
of
the
issues
that
I
came
in
my
mind,
but
this
is
something
that
perhaps.
C
As
I
said
generally,
we
are
using
options
to
do
things
in
our
documents
and
now
that
we're
using
three
parameters
in
a
particular
way
yeah.
I
think
it's
a
good
idea
to
introduce
a
term
for
for
using
query
parameters
in
this
way
and
and
I'm
fine
with
the
term
attribute,
but
maybe
we
should
really
just
have
a
section
called
attributes
that
introduces
that,
and
that
also
can
be
referenced
by
other
documents.
That
may
want
to
talk
about
query
parameters.
D
Okay,
I'll
move
on
to
the
next
slide,
and
then
we
also
disco
this
hasn't
been
an
ongoing
discussion
for
a
while
about
about
proxies
and
how
they
can
interfere
with
the
operation
of
this
of
the
conditional
observed
attributes-
and
I
proposed
this
this
text
at
the
last
meeting-
and
there
was
a
slight
modification-
it
was
proposed
that
the
server
instead
of
may
use
max
age.
It
should
be,
should
use,
and
I
don't
think
there
was
a
very
strong
opinion
either
way.
D
D
D
Considerations,
this
is
I
I
decided
to
include
this.
Please
comment
if
you
think
this
is
necessary,
but
I
thought
it
would
be
good
to
consider
whether
we
need
a
conditional
attribute
registry
so
that
we
can
map
all
these
parameter
names
to
what
they're
supposed
to
do
and
and
then
make
it
a
bit
easier
so
that
anybody
else
who
wants
to
include
new
parameters
or
new
conditional
attributes
could
have
an
expert
review.
D
C
D
A
Is
it
is
it?
Does
it
make
sense
to
start
defining
attributes
kind
of
query,
attributes
for
general
purpose
use
and
in
in
a
list
I
mean
this-
is
I
I
don't
know
the
rfc
number
by
head,
but
there
is
that
one
that
talks
about
us
not
not
interfering
with
the
applications
with
the
uri
space
and
we
can
define
for
a
particular
application,
those
attributes
and
yeah.
A
C
D
A
Just
thinking
about
the
topic
of
those
that
attribute
registry
a
bit
more,
if
you
really
want
this
to
be
general
pro,
if
this
develops
into
something
general
purpose,
it
might
update
the
rfc
to
be.
I
don't
know
the
number
yet
for
resource
directory
and
extend
that,
because
we
have
an
attribute
registry
there
for
the
various
attributes.
We
are
using
there
and
it
might
make
sense
to
to
swallow
in
that.
B
So
bill
thanks
again,
I
think
if
you
produce
an
extra
vision,
incorporating
this
last
comments
from
today,
you
can
present
it
in
vienna
or
at
least
at
ipf113,
somehow
yeah,
that
that
feels
like
that
should
be
indeed
ready
to
move
on
with
working
group
last
call
yep.
Okay,
so
you
plan
to
what
10
online,
I
guess.
D
B
B
A
Yep,
so
this
is,
this
is
just
a
few
slides
of
an
older
interim
that
I've
picked
into
here,
so
that
we
have
a
bit
have
something
on
the
screen
to
talk
over
about
so
just
to
get
everyone
on
board.
This
is
about
how
do
we
reconcile
that
there
might
be
a
co-op
server
that
has
co-op
addresses
that
resource
that
has
resources
both
accessible
on
co-op
and
unquote
over
tcp?
A
A
C
A
That
is
something
that
will
depend
a
lot
on
the
particular
applications
security
model.
If
the
application
requires
that
no
one
can
even
redirect
their
traffic-
and
I
wonder
how
they
do
that,
because
they
just
accept,
accept
rooted
advertisements,
unsecured
dude,
ra
messages,
but
still
if
the
application
wants
to
be
very
sure
that
their
traffic
is
not
redirected,
then
they'll
have
to
place
the
same
requirements.
They
do
for
all
the
links
that
feed
into
their
action.
A
On
the
topic
of
the
uri
alliancing
being
opt
in
on
the
server
side,
that
is
something
where
I'm
still
some.
Some
of
the
text
is
not
fully
in
sync,
with
the
mental
model
of
the
and
with
the
with
the
story
that
I'm
trying
to
get
across
here.
That
is,
it
is
not
even
uri
elias
thing
all,
even
though
it
looks
like
it
looks
to
wireshark
on
the
on
the
on
the
network
like
that,
because
all
parties
agree
what
the
uri
actually
means.
A
A
A
So
that
was
the
one
point
emphasizing
that
this
is.
This
is
probably
not
uri
alliancing,
it's
just
a
form
of
compression
and
just
just
to
be
sure.
This
is
only
about
the
case
where
someone
wants
to
do
away
with
the
proxy
uri
proxy
scheme:
option
co-op
literally
containing
co-op
saving
those
five
bytes
and
in
to
do
that
going
through
that,
if
that
is
not
done,
it's
just
it's
just
regular
proxy
and
there's
no
chance
of
confusion
about
the
involved.
Your
eyes.
A
And
the
third
controversial
point
is
the
use
of
the
host
relation,
which
is
primarily
there
currently
for
two
reasons.
One
is
two
things
come
together.
One
is
that,
even
though
this
was
an
option
in
critical
negotiation,
we
will
usually
not
want
to
advertise
a
proxy
for
each
individual
resource,
because
in
every
discovery
step
we
might
provide
like
half
a
dozen
resources.
A
So
those
ideas
range
from
it
is
served
by
the
same
physical
device
over
to
it
is
an
implied
relationship
between
every
resource
to
the
to
the
same
resource,
but
stripping
every
path
and
query
component
down
to
the
root
of
that
device
and
the
third
being
that
this
is
just
a
name,
just
a
relationship
that
is
implicitly
defined
when
a
link
is
placed
in
link
format
document
without
an
explicit
relation
link,
relation
and
yeah.
That's
that's
just
the
value,
and
it
means
no
more
nothing
more
than
yeah.
A
A
If
people
make
that
assumption,
but
we
I
don't
think
we
need
it
and
the
third
one
is
the
one
that
I'm
hinging
everything
here
on,
because
the
rfc
6690
says
that
this
is
an
implied
relation
between
those
resources,
that's
kind
of
default
value
of
rel
and
every
document
we
have
out
there
now
has
a
lot
of
these,
and
it's
just
simple
to
say
it's
just
simple-
to
express
this
relation
between
those
resources
in
terms
of
they
are
all
hosted
on
slash
and
slash,
has
a
proxy.
Therefore,
you
can
reach
that
resource
through
that
proxy.
A
But
slide
three
shows
the
the
essentials
we
already
have
that
top
line.
Here
it
has
this
implicit,
real
hosts,
tying
it
to
slash
and
if
we
just
add
a
single
line
that
is
also
tied
to
slash,
but
with
this
particular
relation-
and
you
don't
see
my
mouse
cursor
moving
around
frantically
but
think
of
me
pointing
at
the
blue
thingy
here
and
basically
following
that
chain
of
links,
the
client
can
arrive
at
the
proxy
to
use.
A
B
So
personally,
I
think
this
is
important
work
I
believe,
would
be
good
to
happen
in
the
working
group.
It's
good
anyway,
if
you
produce
a
new
revision
out
of
the
reviews,
and
you
present
it
at
idf-113,
also
in
front
of
a
broader
audience
and
then,
of
course,
starting
from
people
here
today.
What
do
you
think
overall
of
this
approach?
Do
you
think,
is
a
good
way
to
to
handle
the
multiple
transports
in
co-op
or
does
anyone
have
a
big
concern
about
this
approach
as
a
whole?.
C
So,
five
years
ago
we
made
this
promise
to
adam
roach,
who
was
idea
at
the
time
that
we
would
solve
this
problem,
and
I
think
it
it
would
be
good
to
actually
make
good
on
that
promise
and
yeah
of
the
various
ways
to
to
address
it.
This
indeed,
has
been
the
most
promising
way,
so
I'm
all
for
pursuing
this.