►
From YouTube: [SIG Network] Meeting 20201105
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Yeah,
definitely,
I
think
we,
it
should
be
really
quick.
This
week,
no
candidates,
we
do
have
a
project
proposal,
but
I
believe
we're
gonna
have
to
punt
it
again.
B
The
main
question
that
we
had
last
time
was:
how
can
we
handle
making
sure
that
the
srov
network
operator
is
upstream
compatible
for
some
background
for
those
who
might
not
be
familiar,
it
does
have
bias
towards
openshift
at
the
moment,
and
I
think
that
we
need
zengui
and
pong
here
in
order
to
answer
that
question,
so
I'm
gonna
add
a
to
do
and
then
I'm
gonna
move
this
to
next
week,
and
I
will
sync
with
them
and
talk
about
that,
and
if
they
can't
make
the
next
section
session,
then
I
will
proxy
for
them.
B
So,
okay.
A
Thanks
doug,
just
a
quick
reminder
too:
please
add
anybody
who's
on
the
call.
Please
add
your
name
to
the
attendees
section
in
the
agenda
doc
so
that
we
have
a
record
of
who
attends
meeting
for
future
membership
candidates
and
other
voting,
and
things
like
that.
B
Yeah
no,
no
worries
thanks
for
the
reminder.
I
appreciate
it
so
yeah.
I
think
I've
got
the
next
two
items.
The
first
one
is
who
should
we
have
as
editors
of
the
spec
doc?
That
is
it's
up
for
public
editing
in
like
suggested
change
mode,
which
I
think
that
we're
all
happy
with,
but
as
for
having
who
can
approve
those,
I
I
guess
I
would
generally
suggest
that.
B
B
C
No,
I
don't
have
an
issue
with
that.
Do
you
have
that
list
handy
or
or
just
rattle
it
off
the
top
of
your
head
and.
B
B
Repo,
but
I
can
look
at
the
list
from
the
group
which
would
be
adrian
kairis
dave,
kremens,
dan
williams,
myself
moshe
levy
and
robert
dower
and
suresh
christian.
C
B
All
right
cool-
I
will
put
it
down
here
and
make
a
note
to
myself
here.
If
anyone
has
a
problem
with
this
in
the
future,
bring
it
up,
we
can
always
add
it
to
the
governance,
but
I
will
add
those
people.
A
Yeah,
I
don't
have
a
problem
with
that
either
the
current
list
largely
overlaps
with
you
know
some
repo
owners
and
such,
but
we
should
probably
change
that
list.
A
As
in
editors
of
the
google
doc,
I
will
work
that
out
with
you
doug
once
you
have
the
final
list
of
people
who
should
be
editors
of
that
doc.
Just
let
me
know,
and
then
I
can
go,
add
those
people
and
then
remove
anyone
who's,
currently
an
editor
who
is
not
on
that
list.
B
That
sounds
perfect
and
I'm
making
a
note
to
also.
B
A
B
All
right,
cool
I'll
give
it
a
shot.
If
I
don't
have
the
privilege,
I
will
hit
you
up
for
sure.
B
B
Regardless
the
next
one
that
I've
got
on
here
from
last
week,
which
is
we're
thinking
about
with
our
updates
for
device
info
bumping
the
version
and
it
brought
up
the
question
of
what
should
the
spec
version
1.2
be
constituted?.
B
A
I
mean
clearly
device
info.
Spec
is
something
that
we've
added.
C
C
B
Hi
yeah
billy.
I
think
that
you
have
put
it
better
than
I
did
here
in
the
notes
yeah.
So
maybe
it's
maybe
it's
a
multi-part
question
which
is:
do
we
have
enough
changes
to
constitute
a
minor
change?
C
A
I
mean
it's
basically
whenever
we
make
a
change
and
we
think
so
maybe
we
should
formalize
that
process
more,
but
gut
feeling
yeah,
I
mean
you
know
you
can
always
go
with
like
the
systemd
style.
I
love
every
time.
You
make
a
change.
You
bump
the
number
by
one,
but
either
way
you
know,
we've
got
a
couple
of
things.
I
think
that
probably
is
enough
to
constitute
a
1.2.
B
B
Yeah
I'll
give
up
plus
one.
I
I
think
that
it's
enough
to
constitute
a
1.2.
It's
been
a
while
there's
been
a
few
minor
things
and
then
certainly
device
info
spec
alone,
I
think,
is
probably
enough.
An
infiniband,
I
think,
is
also
significant
in
a
way.
B
Yeah,
I
think
that's
good,
should
we
put
it
to
a
vote.
A
Yeah,
I'm
four
vote.
Yep,
let's
go
for
it.
I
mean
we've
voted
to
approve
all
the
items
in
the
spec,
so
there
shouldn't
be.
You
know
any
problem
with
the
spec
as
it
exists
today.
It's
just
a
question
of
bumping,
the
number
and
messaging
that.
B
Sounds
good
yeah
so
for
a
vote.
Anyone
not
in.
B
B
Okay,
nice,
I
guess
with
a
new
version
that
probably
means
some
updates
to
the
github
repo
dan
you've
done
that
in
the
past,
I'm
happy
to
volunteer
to
go
through
that
process.
B
B
C
All
right,
yeah,
I
just
was
going
to
give
an
update
on
some
of
the
device
info
specs
since
we
approved
it.
So
the
spec
has
been
that
we've
approved
a
google
doc,
so
that
has
been
converted
into
a
mark
into
markdown
and
placed
into
the
repo
that's
linked
here,
so
that
spec
changes
have
been
merged.
C
C
I
have
two
pr's
sitting
out
there.
The
first
one
takes
the
is
in
the
network
attachment
client,
that's
where
the
network
status
structure
is
actually
defined.
So
we
added
the
device
info
data
structure
to
there
and
added
some
utility
functions
to
help
manage
that
data,
like
the
marshall
and
the
marshal
of
the
data
and
writing
it
to
some
device,
plug-in
file
and
cni
files,
so
that
pr
sitting
up
there.
C
If
anyone
would
like
to
take
a
look
at
it,
it
was
based
off
adrian's
original
poc
that
he'd
been
working
on
for
multiple
months
so
and
then
doug
added
a
comment
here
that
we
that
that
repo
has
not
been
version
or
tagged
at
all,
so
he's
thinking
of
tagging
it
before
we
merge
the
device
info
spec
stuff
to
it.
So
doug
I'll.
Let
you
talk
to
that.
B
Yeah-
and
I
think
that
we
can
make
this
fairly
simple,
especially
with
the
previous
conversation
about
spec
version,
but
I
think
that
I'm
just
gonna
tag
it
at
a
v
1.1.0
before
this.
Just
because
billy
has
and
it's
it's
one
method
but
changes
the
number
of
parameters.
B
It
probably
would
be
nice
if
people
could
track
stuff
like
that,
so
I'm
gonna
tag
it
at
the
1.1.0
to
match
the
spec,
and
if
anyone
has
any
other
input
on
that
or
a
different
idea,
speak.
B
Touch
with
me
and
I'll
and
we
can
go
from
there,
so
thanks
billy,
yep.
C
Yep
and
then
I
went
ahead
and
pushed
in
a
second
pr
for
multis
that
one's
a
work
in
progress,
because
it
depends
it's
it's
dependent
on
the
network,
attachment
definition
client
going
in.
So
it's
def,
it's
not
building
right
now,
but
I
have
it
building
locally.
C
So
I
just
want
to
put
the
base
coat
up
if
anyone
wanted
to
look
at
it,
and
so
that
actually
is
step
two,
which
is
where
multis
will
read
in
the
device
plug-in
file,
make
a
copy
of
it
and
forward
it
to
or
pass
the
name
up
to
the
cni's
and
then
put
whatever
either
the
cni
can
write
its
own
file
or
take
the
device
plug-in
file
and
then
update
the
network
status
by
adding
the
device
info.
So
that
code
is
in
the
multis
pr.
C
So
just
this
all
happened
like
a
day
or
two
ago,
so
figure
since
with
the
upcoming
meeting,
I
would
just
push
it
out
if
anyone
would
like
to
take
a
look.
Have
any
comments
feel
free
to
you
know,
provide
feedback
and,
if
not
sometime
in
probably
early
next
week,
we'll
try
to
merge
some
of
this
stuff.
If
there's
no
issues
so
like,
I
said
it's
just
an
update,
if
anybody
wanted
to
take
a.
D
B
All
right,
yeah,
one
thing
that
we
put
in
the
governance
dock
was
that
we
would
prefer
merging
by
github
robot,
and
I
was
chatting
with
zinc
me
this
morning
and
he's
like
hey.
Do
we
give
an
example
of
that?
Yet
so
I'm
like
no,
no,
we
haven't
implemented
that,
but
I
think
it's
a
good
idea,
I'll
I'll
do
some
looking
into
it.
B
My
current
quote:
unquote,
simple
idea
is
to
make
a
custom
github
action
that
basically
would
have
a
workflow
that
looked
something
like
check
if
the
whatever
tests
are
currently
there
pass
and
then
check
for
maybe
some
labels
on
the
pull
request
to
see
that
it's
been
approved
and
then
merge
it.
B
Based
on
that,
I
I
lean
to
that
just
because
we
can
kind
of
customize
it
a
little
bit
to
our
own
rules
without
you
know
using
something
super
huge
like,
for
example,
you
know
maybe
what's
used
for
something
as
big
as
like
a
core
kubernetes
might
be
overkill
for
some
of
our
our
projects,
but
I
wanted.
D
B
B
Yeah
no
worries,
you
know
what
I'll
I'll
try
example,
one
on
a
private
repo
and
see
if
it
looks
haywire
something
like
that
and
I'll
bring
it
I'll,
bring
it
back
to
the
group
but
yeah.
If
anyone
thinks
of
something
hears
or
something,
yeah
feel
free
to
hit
me
up
or
if
anyone
has
interest
and
stuff
like
that.
D
A
All
right
thanks
doug,
do
we
have
any
other
business.
A
A
Switch
all
right,
if
not
thanks
everybody
for
a
good
meeting.
We
approved
spec,
v12
and
we'll
see
everybody
in
two
weeks.
All
right.
A
To
move
it
forward,
or
I
yeah
I
mean
I
I
care,
I
don't
know
if
I
have
time
to
check
it
out
or
unless
you
know
it
just
needs
a
really
quick
review
on
that.
Well,
I'm
happy
to
take
a
look
though,
but
that's.