►
From YouTube: Multi-Network community sync for 20230629
Description
Multi-Network community sync for 20230629
A
Thank
you
all
right,
welcome
everyone
at
the
multi-networking
common
sync
meeting
and
today's
June
28th
and
on
the
agenda
today.
Thank
you,
Michael
for
kind
of
keeping
the
track,
but
he
suggested
to
kind
of
revisit
our
scope
for
phase
one
because
I
think
into
our
according
to
our
initial
kind
of
schedule.
We
are.
A
We
are
over
what
I
think,
if
initially,
what
I
was
planning
to
have
this
phase
one
draft
of
the
cap
done
by
by
end
of
Q2?
So
basically,
by
end
of
this
week,
which
we
are
kind
of
behind
on
this
one,
so
I
want
to
kind
of
revisit
what
we
can
do,
what
we
should
scope
and
maybe
set
some
Target
date
of
when
we
want
to
finish
things
down
we're
having
things
done.
A
Next,
one
is
to
review
AIS
and
then,
lastly,
to
continue
on
the
cab
discussion.
If
you
have
any
other
AIS,
please
add
here
before
there
might
be
the
cap.
Discussions
always
takes
the
rest
of
the
meeting,
all
right,
so
the
phase
one
scope,
Target
date,
scope
and
then
the
target
date.
So
let
me
maybe
share
what
is
the
current
scope
and
just
to
quickly
show
you.
This
is
the
draft
of
the.
A
Of
the
initial
kind
of
scoping
that
we
have
with
the
requirements,
that's
what
kind
of
the
guidance
what
I'm
trying
to
use
as
a
guidance
of
what
to
do,
and
if
you
read
most
of
it
it
defines
I
think
up
to
all
this
place.
16
points
the
first
16
points
defines
on
how
the
Newport
Network
object,
that
we're
trying
to
Define
is
going
to
behave
so
I
think
we're
covering
like
100
percent
of
this,
with
just
defining
the
behavior
and
the
API
of
the
object.
So
basically
most
of
those
are
covered.
A
I
think
the
two
additional
items
that
we
haven't
covered
yet
is
the
are
back.
That's
one
thing
item
that
we
haven't
looked
at
yet
and
it's
like
additional
item
to
have,
and
then
lastly,
is
the
downward
API
or
maybe
just
a
feedback
of
information,
what
we
so
of
of
what
we
are
given
to
the
Pod.
A
So
the
question
is:
is
that
something
that
we
could
push
out
of
the
first
phase,
to
kind
of
shorten
it
and
just
kind
of
focus
on
the
API
itself,
its
behaviors
and
then
on
the
next
phases
and
push
back
the
the
two
on
the
to
the
next
phase?
Any
opinions.
A
I'm
not
sure
how
whether
we
could
use
and
live
without
rbac
is
that
something
that
we
have
to
have
from
the
day.
One
Maybe,
not
maybe
we
can,
we
can
live
without
the
r
back
and
then,
since
we're
gonna
be
just
Alpha
anyway.
I
think
that's
that
should
be
fine
to
push
out.
I
would
have
to
probably,
unless
anyone
has
some
knowledge
about
this.
B
A
Foreign
yeah
I
would
I
would
push
it
back
to
the
next
phase,
though
I
think
at
that
point
right,
whatever
is
not
going
to
do,
let's
first
push
it
to
phase
two
and
then,
if
anything,
then
we
can
revisit,
but
for
now
just
push
it
out
for
phase
one.
That's
what
I'm
thinking
and
you're
saying
that
our
back
is
okay
to
push
out
I'm
I
have
no
experience
with
that.
A
I
wonder
whether
if
you
provide
some
new
apis,
do
they
have
to
have
like
our
back
in
place
right
away
or
is
that
something
that
can
come
later
date?
Anyone
has
some
experience.
If
not,
then
I
will
just
try
to
Ping
locally
within
a
kind
of
my
team
to
kind
of
reach
and
and
see
whether
that's
available,
and
hopefully
it
is
but
I
don't
hear
any
restrictions
or
any
voices
to
have
it
in
as
they
must
Peter.
C
I
was
just
going
to
say
that
there's
a
general
point
which
is
I'd
like
to
get
something
out
and
I'd
rather
get
something
out
with
a
few
pieces
missing
and
say:
we
know
that
we
need
to
do
this
and
get
some
eyes
on
something
because
I
think
that'll
make
it
more
concrete
to
people
and
I.
Think
it'll
give
us
a
bit
more
momentum,
so
I'm
I'm
all
for
kicking
out
stuff
like
that
and
are
back
well
I
agree.
We
need
it,
but
you
know
this.
This
is
this
is
the
very
first
implementation
of
Alpha
One.
A
For
that
all
right,
so
so
let's
kick
this
guy
out,
that's
what
will
be
the
first
thing
and
then
the
other
thing,
if
you
read
through
those
like
the
other
just
describe,
how
did
the
network
should
behave
so
basically
that
we
should
have
the
default
Network
pod
network
that
it
should
be
and
your
reference
connect
to
Cluster
Network,
so
approach
shall
provides
I
think
most
of
the
other
one
is
just.
We
need
to
satisfy
the
requirements
and
it
can
be
done
just
by
and
it
kind
of
pushes
everything
into
implementation.
A
Like
the
isolation
aspects,
the
one
of
the
requirements
is
like
here:
every
port
has
to
connect,
had
to
have
connectivity
within
the
specific
pod
Network.
So
this
is
something
that
just
as
well
on
implementation
connect
to
each
other
manually
defined
by
it
again.
Pod
implementation,
so
I
think
most
of
the
other
one
are
mostly
of
how
things
should
be
defined
by
the
by
the
API
and
how
it
should
behave,
and
the
last
one
is
the
Pod
Network
information
interface
information.
Are
we
okay
with
pushing
that
out?
A
This
is
something
that
okay,
we
will
have
API.
We
will
have
so
so
what
will
what
we
will
end
up
with?
We
will
end
up
with
the
API
defined
and
being
able
to
either
to
specify
that
API
in
the
Pod.
That's
basically
it
that's
what
basically,
what
we
discard.
A
What
we
are
discussing
till
now-
and
this
is-
will
be
the
end
of
it
right
considering
phase
one,
do
we
need
this
is
this
is
a
big
one
to
be
honest,
because
this
one
gives
us
a
lot
of
feedback,
but
are
we
okay
to
not
have
it
in
the
first
go.
A
You
have
no
information
about
what
really
was
set
up
right
right
now.
What
we
would
have
is
maybe
just
the
status
that
I'm
I
have
some
some
proposals
to
maybe
slightly
update
the
status
of
the
Pod
itself,
but
then
that
will
be
the
only
feedback
of
what's
really
happening
inside
that
pod
namespace
in
terms
of
networking
right.
A
This
is
what,
and-
and
this
is
as
well
information
to
the
workload
inside
the
Pod,
but
to
be
honest,
I,
don't
assume
anyone
right
now,
jumping
with
Alpha
to
production
level
with
this
so
considering,
we
will
limit
this
one.
Definitely
nobody
will
because.
D
A
Of
little
add
value,
thoughts.
B
A
Yeah,
so
this
is
basically,
this
is
the
cap.
The
link
is
on
the
on
the
top
of
the
I'm
just
viewing
in
it
this
in
the
a
manner
of
just
like
this.
Let
me
chat,
chat,
chat,
chat.
Where
is
the
chat
here
here,
is
in
the
in
the
meeting
chat.
A
So
you
can
either
do
so.
So
basically,
what
I
did
is
this
is
this
is
my
site
but
I
I'm,
just
viewing
this
in
the
rich
DF.
For
my
comment,
I
I
put
it
all
and
I
now
combined
it
everything
into
one
Comet.
The
pr
itself
is
commented
is
a
lot
of
comments,
so
it's
kind
of
kind
of
divided
into
that.
So
this
is
just
a
clean
view
in
the
comet
any
other
thoughts.
A
I
know
you
probably
had
a
chance
to
kind
of
read
through
that,
but
right
now
those
two
elements
I
would
like
to
kind
of
push
out.
Those
are
the
only
items
we
could
push
out.
Maybe
that's
that's
the
wording.
I
think
Arabic.
We
agreed
on
17
anyone.
B
A
A
B
A
Exactly
sure,
okay,
this
guy
and
then
there
is
a
matter
of
the
date.
Do
we
want
to
Target?
Are
we
have?
What
is
it
so?
Basically,
128
shipped
sailed
right
right
now.
Next
one
is
29.
What
is
the
target
date
for
that?
Is
that
what
you
were
saying
so
Michael
you
were
making
something
about
end
of
September
or
something.
Oh.
C
A
But
for
those
item
where
were
you
11
and
17.
A
And
so.
A
Know
the
point
the
point
of
this
one
and
and
I
will
provide
that
one
example
of
a
maltose
mold
to
study,
for
example,.
A
For
example,
to
get
information-
maybe
not
Motors
I-
think
that's
that's
better.
Better
example
will
be
device
information,
so
device
plugin
today,
if
you,
if
you
pass
a
device
into
the
a
pod,
a
device
plugin
will
and
the
whole
mechan
is
around
device.
Plugins
from
cubelet
will
pass
a
environmental
variable
with
the
PCI
ID,
to
be
honest,
I'm,
not
sure
whether
that's
that's
cubelet
or
that's
specific
to
the
device
plugin
multis
uses
for
srov.
But
basically
what
you
end
up
with
is
would
end
up
app.
A
Is
the
workload
inside
the
Pod
to
get
access
what
PCA
IDs
has
been
assigned
to?
It
will
be
provided
through
that
environmental
variable
all
right
so
now.
This
17
is
to
provide
some
sort
of
information
about
all
the
interfaces
that
has
been
decided
and
defined
to
the
port,
all
right,
so
it
will
say
Okay
pod,
Network
blah
was
assigned
to
you.
This
is
the
IP.
This
is
the
Mac.
This
is
the
whatever
we
decide
to
find
information
to
provide,
but
basically
that
kind
of
things
right.
E
Now,
I,
don't
think
so.
I
would
say
that
I
in
favor
of
keeping
this
as
a
phase
one
because
of
our
like
spec-end
use
case
is
for
Hardware
devices,
and
this
was
definitely
particularly
challenging
in
the
hardware
devices
base
to
figure
out
how
to
pass
that
information
along
to
the
right
place.
It
needs
to
be
so
I
would
say:
I
would
be
I'd,
be
in
favor
of
keeping
this
in
the
in
a
phase.
One.
A
And
and
keep
in
mind
it's
not
like,
we
are
not
doing
that.
Never
it's
just
push
a
push
back
to
to
the
next
phase.
That's
that's
kind
of
our
reasoning
here
to
like
at
least
mine
reasoning.
A
I
know
that's
useful,
but
keep
in
mind.
It's
not
like.
Are
you
thinking?
Are
you
saying
that?
Because
you
think
you
you
can
start
doing
some
production
stuff
on
this.
E
But
what
I
think
is
that
we
should
align
these
requirements
with
what
what
we
have
in
in
the
use
cases
right.
E
E
Yeah,
absolutely
and
I
I
mean
I,
honestly
I.
If
we
wanted
to
kick
that
over
that's
to
the
next
phase.
That's
fine,
but
I
do
think
that
there
are
some
of
these
tricky
bits
in
here
that
if
we
leave
them
to
too
late,
it
might
require
us
to
like
Circle
back
in
the
design
process.
Right
so
and
that's
trade-offs
here
with
like.
If
we,
if
we
say
this
is
a
second
secondary
consideration,
then
yeah.
What
does
that
mean
mean.
A
No
not
so
so
let
me
maybe
clarify
on
that
one.
So,
right
now,
after
proposal
from
Team
on
the
cap
itself
right,
we
are
not
creating
separate
caps.
We
are
working
on
the
same
cap.
Every
every
face
is
at
the
same
cap
is
just
a
new
PR
updating
the
old
one
right
so
and
if
we
will
feel
that
until
we
will
feel
that
the
apis
are
not
there,
we
will
change
them
and
we
will
keep
them
in
Alpha
and
keep
changing
them.
So
there
is
that.
E
A
Because
this
is
I
would
consider
this
if
we
defined
of
what
parameters
we
want
to
right
now,
Define,
and
we
are
thinking
about
right.
What
I
mentioned
is,
if,
let's
think
about
that
like
so,
we
have,
we
are
defining
the
Pod
name
API,
and
then
we
are
defining
how
we
attach
it
in
the
pod,
how
you
get
access
to
that
information
from
the
workload
point
of
view,
isn't
that
just
an
add-on?
Okay,
now
we
have
to
figure
out
how
cubelet
exposes
that
to
the
pod.
E
Exactly
you
could
say
that
about
any
item
on
on
this
list
right
it
could.
It
could
cause
us
to
come
back
and
and
reconsider
that,
but
you've
convinced
me
for
this.
One
item:
Let's,
let's
Ponte,.
D
So
I
have
the
one
there's
several
questions
about
this
stuff,
so
the
so
this
means
the
without
the
artwork
that
you
are
going
to
implementing
this
stuff
to
the
cube.
The
Cuban
Legacy
is
that
correct.
D
A
This,
what
I'm,
thinking
at
the
the
general
way,
how
you
do
and
I
am
looking
at
the
dra
right
now.
This
is
just
a
recent
thing,
so
that's
my
kind
of
example
and
I
when
I
see
on
the
code
that
there's
a
lot
of
nice
things
about
this,
how
they
did
it
is
a
feature
flag
and
it's
all
behind
some
Alpha
guarding,
so
I'm
not
sure
exactly
familiar
that
with
with
yet,
but
that's
how
the
dra
did
it.
So
that's
I'm,
gonna
follow
the
same
thing.
D
So
this
means
the
the
the
first
time
implementing
this
stuff
is
the
feature
flag.
So
the
and
then
this
is
the
the
disabled
by
default.
Is
that
correct?
That's.
A
A
All
right
so
I
would
like
that
that
idea
of
us
trying
to
get
into
the
I,
let
me
see
kubernetes.
B
Just
one
sec
can
we
make
sure
Taylor
I,
don't
know
if
this
microphone
is
working
but
he's
been
posting
some
messages
in
chat.
A
So
E17
inhabiting
some
users
to
use
it
they
so
I
will
tell
you
other
ways.
Today's
implementation
and
I'm
bringing
upon
to
solve
the
time.
Don't
have
this
feature
today
anyway.
A
So
I
consider
this
as
a
just
a
super
enhancement
down
the
road
and
everyone's
gonna
use
it
and
adjusting
their
workloads
to
use
that
API,
which
today
doesn't
exist
anyway.
So
it's
not
like
we
are
blocking
from
usability
it
just
it's
not
there
as
it
is
today
anyway,
so
I'm,
considering
17
as
a
enhancement
to
what
you
can
do
today.
That's
that's
what
it
was
meant
to
do
to
enhance,
because
we,
when
we
were
discussing
about
that
requirement,
that
was
like
one
of
the
bullets.
A
That
was
a
pain
point
and-
and
we
tell
okay
with
this
approach-
let's
improve
that,
let's
have
a
better
kind
of
access
for
the
workloads
of
what
interfaces
a
airport
has,
because
that
wasn't
there
right.
So
that's
what
it
is.
So
it's
not
like.
We
are
blocking
really
some
of
this.
It's
just
and
what
I
want
to
say
it's
an
enhancement
down
the
road,
so
I,
don't
think
it's
a
big
blocker
for
use.
Usability
right,
you
can
still
provide
and
and
again
I'm
going
to
bring
up
the
multus
use
case
right.
A
So
you
you'll
have
a
reference
inside
the
Pod.
You
will
have
the
object
itself
that
can
point
to
network
attachment
definition
and
basically,
you
get
rid
of
you
get
rid
of
The
annotation
of
the
Pod
definition
on
the
on
the
Pod
for
for
for
attachments
to
the
Pod
right.
So
that's
that's
the
value
added
that
will
happen
with
our
feature
and,
of
course,
before
that
you
we
have
to
take
into
into
into
consideration
all
the
reviews
and
and
whatever
what
they
can.
The
rest
of
the
community
is
going
to
talk
about.
A
You
know
this
whole
kind
of
idea,
so
I
want
to
kind
of
address
to
this
I'm
looking
at
the
kind
of
schedule,
because
why
I'm
saying
this
is
really
scheduled
is
we
need
to
have
128?
A
This
is
for
128
I,
wonder
is
there
so
what
I'm
saying
is
we're
going
to
pause?
We
have
to
make
this
whole
cap
to
a
form
of
a
fully
okay.
Now
this
is
a
fully
reusable
usable
kind
of
code
that
we
want
to
implement
right.
Folks
have
to
review
this
and
that's
gonna,
take
time
so
and
then
feedback
and
then
discussion
and
additionally
we
are
modifying
the
pods.
A
So
we
have
to
go
to
the
I'm,
not
sure
which
team
is
it
Arc,
I'm,
not
sure
which
thing
responsible
for
pod
spec,
but
we
have
to
go
to
that
seg
and
convince
them
that
that's
something
that
we
want
to
do
so
all
that
gonna
take
time
and
I'm
I,
don't
think
we
can.
We
we
I
think
this
is
something
that
we
need
to
start
like
in
a
in
a
month
or
so
that
whole
process
or
even
faster,
probably
Patrick,
is
not
here
today.
A
G
Okay,
hi
I
can
talk,
I
can
turn
Mario
on
so
I.
I
was
just
thinking
that,
and
you
know
this
is
me
on
the
outside,
without
digging
in
and
we're
actually
doing
it,
but
11
with
our
back.
There
can
be
all
sorts
of
things
that
get
more
complex
with
the
implementation,
so
I
can
think
eleven
is
more
work
and
how
would
it
affect
getting
feedback
on
a
first
release
and
it
doesn't
seem
like
it's
gonna
have
a
major
effect.
It's
very
important
to
get
our
back
in.
G
It's
part
of
what
I'm
saying
for
a
lot
of
checklists
with
different
groups
on
what's
important,
but
it
doesn't
seem
like
a
first
release.
It
would
be
required.
17,
though,
seems
like,
if
you
have
it
it's
going
to
make
it
a
lot
easier
for
people
to
try
this
enhancement
out
and
use
it
with
whatever
use
case.
G
We
have
a
bunch
of
use
cases
already
listed
been
talked
about
for
months,
but
other
people
are
going
to
have
other
ideas,
so
if
they
come
in
and
they
have
less
hurdles
to
try
and
give
feedback,
then
you're
more
likely
to
get
more
feedback
quickly
for
this.
But
if
17
is
a
lot
of
effort,
that's
of
course
different
I'm
thinking
showing
just
comparing
the
two.
So
what
what
amount
of
effort
does
it
add
to
the
implementation
does?
Is
it
going
to
be
a
big
impact
in
the
time
to
get
that
first
release?
A
That's
fair
yeah,
this
one
I'm
not
sure
what
it
will
take,
because
this
has
to
be
some
sort
of
in
in
the
in
the
requirements
we're
talking
about
like
downward
API
right,
so
not
sure
who's.
Exposing
that
I
think
cubelet
would
have
to
expose
that
and
provide
some
sort
of
that's
what
I
would
think
you
expose
some
end
point
in
cubelet
that
you
could
query
and
then,
or
maybe
some
socket
I,
don't
know,
that's
something
that
we
need
to
figure
out.
A
What
will
be
the
best
way
to
to
kind
of
come
up
with
some
sort
of
server
that
can
reply
to
you
right
and
now,
with
the
gaming
error
coming
receiving
a
request
from
a
pod.
A
What
do
we
do
right?
How
do
we
then?
We
need
to
have
a
means
to
identify
that:
okay,
that's
coming
directly,
so
we
need
to
make
sure
it's
secure
and
it
and-
and
it
sends
out
that
the
right
information,
so
we
don't
leak
the
information,
because
that's
another
thing
right.
So
if
we
do
it
in
tubelet
that
centralized
piece
right,
can
we
I'm
not
sure
whether
we
want
to
push
it
on
CRI?
A
Because
that's
that's
yet
another
level
of
things,
because
that's
outside
of
kind
of
now
pushing
to
Cris
and
that's
now,
piracy
right
so
I,
don't
think
that's
a
valid
approach!
I
I'm,
really
not
so
familiar
with
all
this
area.
So
that's
why
I'm
considering
this
a
bigger
item,
you
see
because
right
now
that
that's
what
I
have
to
be
right,
Paul
would
have
to
have
a
means
to
reach
out
to
something
some
endpoint
to
to
get
that
info
right.
I'm,
not
sure
it
is
something
that
we
could
provide
in
the
Pod
spec.
A
That's
not
the
point
and
the
other
hand
would
be
to
provide
let's
the
other
idea
that
that
was
there
was
to
provide
it
through
and
the
environmental
variables
which
then
definitely
engages
CRI
right
or
cni,
or
something
that
that
expands
that
and
passes
the
environmental
variables
unless
the
downward
API
is
already
already
exists,
and
this
is
something
that
we
can
just
expand
and
there's
something
I'm
not
familiar.
I
know
that
I.
C
H
Yeah
more
early
point
is:
if
you
have
multiple
blocking
issues,
they
still
the
priority.
Still
matters
because
I
mean
I
can
I,
don't
know
a
whole
lot
about
well.
I
know
something
about
this
project
know
more
about
Nokia,
but
in
Nokia's
case
we're
trying
to
get
the
2012
release
G8
it's
in
their
lab
things
that
we
know
are
going
to
block
the
ga
or
lower
priority
the
things
that
are
blocking
their
progress
on
testing.
You.
H
B
A
All
right
any
other
comments.
Please
read
through
the
list
again
in
the
link.
If
you
find
something
else
that
we
should
push
out,
I
think
that's
what
I
kind
of
get
a
quick
scheme.
I
think
that
was
the
only
other
thing,
but
please
give
it
a
rate
through
the
17
items.
If
there's
anything
else,
we
should
kind
of
push
out
all
right
AI.
So
from
last
week
we
talked
about
the
any
other
stuff
to
the
scope.
Oh,
we
didn't.
Oh
I,
know
sorry
about
this
date.
A
A
No
voices
yeah,
okay,
thank
you!
So,
let's,
let's
try
that
I
will
try
to
I
try
to
look
at
Google
Bay.
What
is
the
schedule
for
129?
There
is
only
128
I
can
achieve
29,
so
I
will
kind
of
ping
that
one
and
and
see
what
is
the
kind
of
freeze
to
get
the
Caps
merged.
A
So
I
think
we
have
to
have
at
least
months
before
that
we
should
have
this
kind
of
file
in
in
order
and
yeah
yeah
September
what
you
said:
18th
okay,
there
you
go
and
and
then
try
to
kind
of
Target
this
so
that
we
can
have
at
least
some
deadlines
to
keep
okay.
E
And
our
definition
of
done
for
this
phase
would
be
to
have
the
camp
or
have
the
pull
request
that
implements
the
data
object.
A
So
the
the
current
Dawn
is
the
cap
merged
all
right.
Okay,
having
the
cap
merge,
that's!
That
is
what
I
I
will
consider
this
one
as
Don,
because
then
we
can
work
on
the
implementation.
Yes,.
E
A
What
we
want
to
do
is
the
current
requirements,
phase
that
we
have
at
PPR,
that's
called
psrpr
needs
to
get
merged
itself.
I
am
working
to
get
the
LG
TMS
for
that
and
get
it
merged
and
I'm,
unfortunately,
a
bit
behind,
but
I
am
trying
to
get
that
merged.
The
first
phase
of
this
cap
is
not
implementable,
so
it's
not
something
that
we
have
to
deal
with.
We
will
keep
updating
the
same
cap
and
what
I
mean
here
is
the
let's
call
it
a
phase,
one
PR
merged,
hey!
That's.
E
H
A
E
A
Now
we
need
to
keep
merging
it
because
right
now,
I
I,
why
I
want
to
merge
it,
because,
if
it's
merged,
then
it's
kind
of
set
in
stone,
I
know
you
can
create
a
PR
to
change
it,
but
we
need
to
get
there
and
I'm
struggling
with
getting
that
thing
merged
and
eventually
I
I,
don't
know
another
PR
will
be
have
to
be
created
with
this,
so
I
need
to
get
sure
that
the
requirements
is
merged.
Yes,
I
am
please
that's
that's
another
thing.
If
anything,
that's
what
I
thought!
A
Please
read
through
the
cap
yourselves
and
leave
LG
TMS
that
you're
okay
with
it,
if
there
is
just
just
just
leave
lgtm
so
that
the
community
knows
that
yes,
there
are
folks
that
are
okay
with
what
do
we
have
and
yes,
please,
let's
work
towards
getting
the
that
stuff
merged
as
well.
Even
if
you
are
not
a
member
of
mem
of
the
of
the
of
kubernetes
that
doesn't
matter,
you're
part
of
the
community
and
and
leaving
Health
GTM
counts
there
as
well.
Okay,
so
that's
what
I'm
thinking
it
will
be
still
a
bit.
A
I
know
it's
kind
of
different,
because
we
will
try
to
get
that
cap
mergeable
by
it
for
129
and
then
it's
gonna
add
phase
two,
which
will
be
again
be
implementable
right
so
that
because
they
have
those
phases
for
caps
right.
But
until
we
that's
what
I'm
thinking
we're
gonna
make
it
in
phases
and
Implement
them
in
phases,
and
until
we
get
to
all
the
phases
and
then
have
everything
in
place.
E
I
understand
that
our
goal
for
September
18th
proposed
possible
deadline,
whatever
that
may
happen
to
be
to
get
the
current
phase,
one
cap
merged
with
the
requirements
and
use
cases.
E
A
E
F
All
right
so,
when
yeah.
A
And
then,
as
soon
as
we
have
that
cap
merged
by
the
proper
like
cut-off
date,
then
we
can
kind
of
work
towards
making
it
implementable
and
then
and
then
we
have
a
a
free
range
to
to
post
our
PRS
by
the
way
having
this
cap
merged.
A
At
that
time
we
already
can
just
work
towards
having
the
pr
ready.
It
doesn't
block
us
from
that.
So
let's
make
sure
that
it's
low
only
I
can
create
PRS.
You
can
do
this
as
isaf,
even
today,
I
already
posted
the
initial.
The
link
is
I.
Think
here,
no,
it's
not
here.
It's
somewhere
in
the
one
of
the
minutes.
A
I
did
created
a
on
my
branch
on
my
local
branch
of
kubernetes
created
just
the
object
in
the
forms
that
we
had
it
thought
about
it,
but
but
by
that
time,
but
I
already
have
some
changes
right.
So
then
I
just
keep
updating
that
guy
and
then
create
a
PR
out
of
it
right.
So
it
doesn't
block
us
from
creating
the
change
itself.
It's
just
a
matter
of
kind
of
satisfying
the
process
right
as
well
here.
A
Pr
merged,
yes,
the
the
phase.
One
changes,
maybe
phase
one
kept
phase.
One
cap
changes:
PR
merged
yeah;
that's
that's
what
I
want
to
do?
Yes,
another
one
that
that's
that
yearly,
linking
the
pull
request.
That
one
is
something
that
was
supposed
to
be
done
a
few
months
back,
so
that
PR
that
you
just
linked
Taylor
is
something
that
has
to
be
done
right,
ASAP.
So
please
lgtm!
This
is
not
what
I'm.
This
is
not
the
there
should
be,
and
there
will
be
another
PR
with
four
phase.
One.
A
G
Maybe
before
3
700
gets
like
if
you're
going
to
bump,
if
you're
going
to
bump
out
11
the
ARP
our
back
and
bump
out
17.,
then
that
should
probably
be
updated
so
that
3700
shows
that
and
then
it'll
be
public.
Read
me
sure.
A
What's
important
from
the
current
requirements
list
is
the
requirements
themselves
and
the
list
of
what
we
want
to
do.
Phasing
out
is
just
an
add-on
and
then
I
can
create
this
phase,
one
that
I'm
saying
okay,
I
want
to
pull
this
one
guy
out
in
my
in
phase
one
I
will
just
change
the
ordering
right.
I,
don't
think
that's
a
bigger
deal,
because
it's
just
I'm
just
moving
things
out
from
one
face
to
the
other
I'm,
not
removing
some
requirements
that
we
all
agreed
on.
B
G
Then
you're
saying
everyone
needs
to
lgtm
3700,
so.
A
A
A
Yes,
so
please
please
review
if
you
see
that
there
were
like
bunch
of
kind
of
updates
from
last
week,
so
please,
if
you
can,
leave
the
gtms
and
then
I
will
have
another
argument
for
other
kind
of
leadership
to
okay
folks,
the
community
likes
it
and
we
want
to
push
towards
that.
Please,
please
lgtm
as
well
or
review
at
least
right.
A
So
and
from
your
perspective,
if
you
have
folks
in
your
teams
that
that
have
chair
or
what's
not
push
them
as
well
to
review
this
so
that
we
spread
it
around,
it's
not
only
one-sided,
so
LG
teams.
We
need
that
merch
ASAP!
Yes,.
A
Any
other
on
this
I
will
try
to
come
up
with
the
exact
date,
but
this
but
I
think
the
definition
I've
done
is
is
is
sound
all
right.
Let's,
let's
go
to
our
shower
AIS
now
so
from
last
week,
the
AI
we
had
was
the
discussion
around
the
param's
reference
in
the
Pod
Network,
and
shall
that
be
a
list,
and
and
thank
you
Tomo
for
the
cases
that
you
provided-
let's,
let's
maybe
walk
through
them,
the
first
one.
It's
the
what
you're
saying
is
maltus
case
yeah.
D
That's
why
I'm
enjoying
this
midnight
time
in
Japan
anyway,
the
yeah?
Let
me
explain
that
the
the
before
that
the
summary
of
the
questions
so
currently
are
we
in
the
Mouse
Network
cap,
the
working
Google
docsite.
We
have
the
Port
Network
object,
which
is
representing
some
kinds
of
a
network,
and
then
the
this
object
is
designed.
The
implementation,
independent
part
is
only
so.
The
implementation
dependent
stuff,
such
as
the
Sienna
or
this
stuff
is,
should
be
in
the
apartment,
Swift
So.
D
Currently,
the
practice
problems
left
is
the
simple
object
so
that
we
can.
We
can
only
one
object
into
the
airport.
Network
object
as
the
specification,
so
this
is
pretty
challenging
to
us.
The
I
have
the
February
request
the
case.
One
is
the
models
case,
the
so
sometimes
the
user
wants
to
create
that
two
Network
attachative
and
they're
both
may
specifying
the
one
network-
okay,
let's
imagine
exactly,
we
can
creating
their
own
brand
crop
kubernetes
environment,
then
for
each
worker
node
either
one
and
each
two
two
interfaces
connected.
D
D
The
user
want
to
create
another
Network,
but
this
this,
the
another
Network
sometimes
they're,
also
adding
the
SLB
supported
Hardware
in
the
at
the
server
and
then
try
to
connect
that
at
that
time
the
user,
of
course
want
to
use
to
connect,
use
the
models
to
connect
to
the
two-way
one
is
use,
creating
the
Mac
Vision
to
connect
and
then,
if
some
Port
is
required,
High
Speed
network.
At
that
time.
D
Of
course,
they
use
this
SRB
Hardware
Nick
and
then,
of
course,
that
this
case
they
do
not
using
the
Mac
video
at
that
time
that
they
use
is
the
CNR.
So
this
means
the
one
network
that
we
have.
The
user
may
have
the
two
ways
to
connect
macbear
versus
cerabinic.
So
at
that
time
the
one
network
is
belonging.
One
pot
that
pop
network
is
should
have
the
two
one
more
net
attachative
in
modus
case.
So
that
is
the
one
the
case
and
another
case
is
not.
D
So
so
that
maybe
they
are
yeah,
that's
that
that's
the
also
the
in
the
so
so
yeah
India
part
Network
I
forgot
the
name.
D
Network
attachment
or
some
stuff
they
you
you,
you
should
provide
some
Implement
passport
implementations
parameters
right
so
so
maybe
they've
issued
oh
well.
Maybe
we
can
add
The
annotation
some
stuff
to
specify
it
for,
for
each
spot
about
the
hey,
hey,
you
have
to
connect
to
connect
this
port
Network
I
I'd
like
to
use
the
Mac
appearance
side,
or
sometimes
the
SRB
side.
So.
A
H
D
Implementation
side,
the
so
the
problem
thread
is
for
the
implementation
side
right.
So
so
the
approach
the
how
to
use
the
parameters
object
is
the
is
the
driven
by
the
implemented
side.
So
in
this
case
the
models
will
care
about.
That
I
mean
that
the
problems
website
they
have
the
array
and
then
they
may
have
their
level
or
name
or
some
stuff
to
identify
which
item
is
applicable
to
WID
news
in
here
box,
side,
okay,
so
data
is
still
case
as
well
and
then
another
case
is
the
not
the
models
case.
D
I
mean
that
so
currently
the
Airport
network,
the
cap,
is
designed
not
only
to
the
cni,
so
that
this
is
about
that.
The
the
matches
specified
that
this
is
the
not
the
implementation
specific
so
at
that,
so
that
I'm
just
guessing
that
the
not
the
cni
side
but
the
other.
Some
like
the
some
startup
is
designing
the
the
you
creating
the
network
implementations
using
the
port
Network
side
at
that
time.
They
have
this
startup,
the
May
having
the
one
I
mean
two
or
more
object
for
one
network.
D
The
easiest
way
is
the
iPhone
and
then
the
trans,
the
transport
object
right
there,
Hoover
ipam
Network,
address
object
is
as
used
for
ipam
configuration,
but
of
course
this
is
only
the
IP
address
management.
So
the
then,
of
course
they
want
to
add.
The
powerful
network
was
above
the
transport
Network
or
some
stuff
to
specifying
their
network
configuration.
D
A
I
I
think
that's
that's
all
about
it.
My
only
and
I
you
ask
for
you
asked
for.
Why
would
we
keep
it
actually
just
single
element
and
my
only
reason
it
would
be
just
ux
Simplicity.
That
will
be
the
only
reasoning
but
I
don't
see
a
issue
with
having
kids
at
as
a
list
and
basically
it
will
be
up
to
the
implementation
how
it's
handled
right,
at
least
with
the
list.
A
We
are
not
shooting
ourselves
in
the
foot
because
having
a
single
item
converting
to
a
list
is,
is
a
nightmare
because
you
have
to
have
additional
field.
Then
this
way
we
are
kind
of
future
proof,
and
we
don't
have
to
deal
with
that.
If,
in
the
future
we're
gonna
decide,
we
have
even
more
cases
to
have
the
list
so
I
think
we
can.
We
can
convert
that
to
a
list.
Any
other
opinions
around
this.
A
H
D
E
E
D
Oh,
by
the
way,
the
I'm
also
find
that
the.
D
D
So
from
the
CNS
specification
point,
this
is
about
it.
Maybe
so
the
CMS
perspective
do
not
the
limit
one
net,
cni
config,
creating
the
alignment
of
this
sure.
So
so,
in
this
case,
of
course,
there
are
two
network
interface
is
not
belonging
in
the
one
network:
object,
okay
in
this
case,
so
the
one
that
okay.
So
let's,
let's
imagine
the
the
the
model's
case,
if
they're
using
this
stuff
and
then
one
net
attached
there
creating
a
two
interface
and
then
maybe
the
both
interface
is
not
in
the
same
network.
D
Right
from
the
stuff
I
mean
that
the
one
interface
have
the
10.,
10
or
10.10,
and
then
next
is
the
192
168,
something
so
how
to
deal
with
in
the
pop
Network
design.
I'm
I'm
just
coming
up
this
stuff.
So
this
is
not
related
to
the
problems
with
the
well
strategy.
That
is
the
problem.
Slip.
I,
think
I've.
A
I
think,
though,
this
is
very
I
would
consider
it
as
very
okay
Nate
and
you
have
a
hand,
go
ahead.
F
Sorry,
it's
just
a
question
about
the
case,
one
when,
when
we
say
that
one
pod
Network
we
have
several
definitions,
is
it
is
it
do
we
still
maintain
the
fact
that
a
single
pod
cannot
attached
twice
to
the
same
network.
A
Single
pole
attached
to
the
single
Network
yes,
so
this
is
something
that
that
I
think
in
in.
In
contrast
to
what
this,
this
I
think
this
example,
the
last
this
FYI
right,
so
I
think
that
was
left
right.
What
you
were
saying,
I
think
this
this
example
I
would
consider
this
as
a
implementation
specific
here
and
if
they
do
that,
then
they
have
to
handle
that,
but
they
if
but
if
they
don't
comply
to
our
requirements
here
with
with
the
cni,
they
will
not.
A
To
to
the
Pod
Network,
so
I
think
I'm,
considering
having
one
cni,
adding
two
interfaces
so
because
it
it
can
have
multiple
I'm,
not
sure,
can
you
can
you
can
con
cni
conf
have
Michael,
probably
can't
be
I?
Can
you
can
you
can
tell
us?
Can
a
conf
have
ability
to
specify
multiple
at
once?
Is
that
a
valid
think
or
or
because
I
know
you
can
have
a
list
and
basically
change
things
together,
but
is
the
chaining?
Is
it
allowed
in
a
cni?
Is
that
specific
I'm
not
sure?
I
A
C
D
I
I
D
I
D
So
so
the
at
the
cube.
Unfortunately,
this
I
joined
this
cubicle
and
then
I'm
I'm
listening
on
this
stuff
and
then
at
that
time
the
this
guy
is
thinking.
It's
thinking
that
the
CNR
aspects,
the
of
course
the
provides
the,
if
name
and
then
and
then,
but
also
there.
This
is
this
does
not
means
the
one
interface
is
only
created
and
actually
the
cni
spec
do
not
have
the
sentence
about
the
master
not
having
in
the
two
or
more
interface
I.
D
Think
that
so
so
that
this
is
like
the
using
the
IET
the
context,
the
CNR
spec
May
Implement
implement
the
one
one
more
interface
that
that's
the
I
think
about
it.
I.
A
E
It's
not
non-standard.
This
is
this
is
a
really
nuanced
thing,
but
okay,
so
both
Mike
and
Tomo
are
correct
from
my
standpoint,
which
is
cni.
Spec
has
the
has
the
one
environment
variable,
but
each
cni
ad
has
that
environment
variable.
So
if
you
have
a
delegating
cni
plug-in
like
multis
is
like
it
uses,
a
delegate
add
call
from
the
cni
libraries-
that's
that
is
legal
legal.
To
do
so.
I
A
I
C
A
Okay,
I
think
the
one
thing
could
I
take
out
yeah
we
can,
we
can
look
at.
Do
we
want
to
kind
of
handle
that?
Let
me
maybe
just
add
it
as
a
next
talking
point
but
but
yeah,
let's,
let's
just
finalize
that
on
on
whether
we
should
have
that
or
not
all
right,
I
think
the
decision,
the
the
ones
tldr
is
that
we
are
deciding
on
having
and
converting
params
list
to
a
list.
So
let's,
let's
get
that
right
thanks
everyone,
let's
hear
from
you
next.